audk/OvmfPkg/VirtioFsDxe/VirtioFsDxe.inf

137 lines
5.0 KiB
INI
Raw Normal View History

## @file
# Provide EFI_SIMPLE_FILE_SYSTEM_PROTOCOL instances on virtio-fs devices.
#
# Copyright (C) 2020, Red Hat, Inc.
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
#
# Permission Model of this driver:
#
# Regardless of the UID and GID values this driver send in the FUSE request
# header, the daemon (that is, the Virtio Filesystem device) always acts with
# root privileges on the host side. The only time the daemon considers said UID
# and GID fields is when creating a new file or directory. Thus, the guest
# driver cannot rely on the host for enforcing any file mode permissions,
# regardless of the "personality" that the guest driver poses as, because
# "root" on the host side ignores all file mode bits.
#
# Therefore the guest driver has to do its own permission checking, and use the
# host-side file mode bits only as a kind of "metadata storage" or "reminder"
# -- hopefully in a way that makes some sense on the host side too.
#
# The complete mapping between the EFI_FILE_PROTOCOL and the host-side file
# mode bits is described below.
#
# - The guest driver poses as UID 0, GID 0, PID 1.
#
# - If and only if all "w" bits are missing from a file on the host side, then
# the file or directory is reported as EFI_FILE_READ_ONLY in the guest. When
# setting EFI_FILE_READ_ONLY in the guest, all "w" bits (0222) are cleared on
# the host; when clearing EFI_FILE_READ_ONLY in the guest, all "w" bits are
# set on the host. Viewed from the host side, this sort of reflects that an
# EFI_FILE_READ_ONLY file should not be written by anyone.
#
# - The attributes EFI_FILE_HIDDEN, EFI_FILE_SYSTEM, EFI_FILE_RESERVED, and
# EFI_FILE_ARCHIVE are never reported in the guest, and they are silently
# ignored when a SetInfo() call or a file-creating Open() call requests them.
#
# - On the host, files are created with 0666 file mode bits, directories are
# created with 0777 file mode bits.
#
# - In the guest, the EFI_FILE_READ_ONLY attribute only controls the permitted
# open mode. In particular, on directories, the EFI_FILE_READ_ONLY attribute
# does not prevent the creation or deletion of entries inside the directory;
# EFI_FILE_READ_ONLY only prevents the renaming, deleting, flushing (syncing)
# and touching of the directory itself (with "touching" meaning updating the
# timestamps). The fact that EFI_FILE_READ_ONLY being set on a directory is
# irrelevant in the guest with regard to entry creation/deletion, is
# well-mirrored by the fact that virtiofsd -- which runs as root, regardless
# of guest driver personality -- ignores the absence of "w" permissions on a
# host-side directory, when creating or removing entries in it.
#
# - When an EFI_FILE_PROTOCOL is opened read-only, then the Delete(), Write()
# and Flush() member functions are disabled for it. Additionally, SetInfo()
# is restricted to flipping the EFI_FILE_READ_ONLY bit (which takes effect at
# the next Open()).
#
# - As a consequence of the above, for deleting a directory, it must be
# presented in the guest as openable for writing.
#
# - We diverge from the UEFI spec, and permit Flush() on a directory that has
# been opened read-write; otherwise the only way to invoke FUSE_FSYNCDIR on a
# directory would be to Close() it.
#
# - OpenVolume() opens the root directory for read-only access. The Open()
# member function may open it for read-write access. While the root directory
# cannot be renamed or deleted, opening it for read-write access is useful
# for calling Flush(), according to the previous paragraph, or for updating
# the root directory's timestamps with SetInfo().
##
[Defines]
INF_VERSION = 1.29
BASE_NAME = VirtioFsDxe
FILE_GUID = 7BD9DDF7-8B83-488E-AEC9-24C78610289C
MODULE_TYPE = UEFI_DRIVER
ENTRY_POINT = VirtioFsEntryPoint
[Packages]
EmbeddedPkg/EmbeddedPkg.dec
MdePkg/MdePkg.dec
OvmfPkg/OvmfPkg.dec
[Sources]
DriverBinding.c
FuseFlush.c
FuseForget.c
FuseFsync.c
FuseGetAttr.c
FuseInit.c
FuseLookup.c
FuseMkDir.c
FuseOpen.c
FuseOpenDir.c
FuseOpenOrCreate.c
FuseRead.c
FuseRelease.c
FuseRename.c
FuseSetAttr.c
FuseStatFs.c
FuseUnlink.c
FuseWrite.c
Helpers.c
OvmfPkg/VirtioFsDxe: implement EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume() With the help of the VirtioFsFuseOpenDir() and VirtioFsFuseReleaseFileOrDir() functions introduced previously, we can now open and close the root directory. So let's implement EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume(). OpenVolume() creates a new EFI_FILE_PROTOCOL object -- a reference to the root directory of the filesystem. Thus, we have to start tracking references to EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, lest we unbind the virtio-fs device while files are open. There are two methods that release an EFI_FILE_PROTOCOL object: the Close() and the Delete() member functions. In particular, they are not allowed to fail with regard to resource management -- they must release resources unconditionally. Thus, for rolling back the resource accounting that we do in EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume(), we have to implement the first versions of EFI_FILE_PROTOCOL.Close() and EFI_FILE_PROTOCOL.Delete() in this patch as well. With this patch applied, the UEFI shell can enter the root directory of the Virtio Filesystem (such as with the "FS3:" shell command), and the "DIR" shell command exercises FUSE_OPENDIR and FUSE_RELEASEDIR, according to the virtiofsd log. The "DIR" command reports the root directory as if it were empty; probably because at this time, we only allow the shell to open and to close the root directory, but not to read it. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-12-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
2020-12-16 22:10:48 +01:00
SimpleFsClose.c
SimpleFsDelete.c
SimpleFsFlush.c
SimpleFsGetInfo.c
SimpleFsGetPosition.c
SimpleFsOpen.c
SimpleFsOpenVolume.c
OvmfPkg/VirtioFsDxe: implement EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume() With the help of the VirtioFsFuseOpenDir() and VirtioFsFuseReleaseFileOrDir() functions introduced previously, we can now open and close the root directory. So let's implement EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume(). OpenVolume() creates a new EFI_FILE_PROTOCOL object -- a reference to the root directory of the filesystem. Thus, we have to start tracking references to EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, lest we unbind the virtio-fs device while files are open. There are two methods that release an EFI_FILE_PROTOCOL object: the Close() and the Delete() member functions. In particular, they are not allowed to fail with regard to resource management -- they must release resources unconditionally. Thus, for rolling back the resource accounting that we do in EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume(), we have to implement the first versions of EFI_FILE_PROTOCOL.Close() and EFI_FILE_PROTOCOL.Delete() in this patch as well. With this patch applied, the UEFI shell can enter the root directory of the Virtio Filesystem (such as with the "FS3:" shell command), and the "DIR" shell command exercises FUSE_OPENDIR and FUSE_RELEASEDIR, according to the virtiofsd log. The "DIR" command reports the root directory as if it were empty; probably because at this time, we only allow the shell to open and to close the root directory, but not to read it. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-12-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
2020-12-16 22:10:48 +01:00
SimpleFsRead.c
SimpleFsSetInfo.c
SimpleFsSetPosition.c
SimpleFsWrite.c
VirtioFsDxe.h
[LibraryClasses]
BaseLib
BaseMemoryLib
DebugLib
MemoryAllocationLib
TimeBaseLib
UefiBootServicesTableLib
UefiDriverEntryPoint
VirtioLib
[Protocols]
gEfiComponentName2ProtocolGuid ## PRODUCES
gEfiDriverBindingProtocolGuid ## PRODUCES
gEfiSimpleFileSystemProtocolGuid ## BY_START
gVirtioDeviceProtocolGuid ## TO_START
[Guids]
gEfiFileInfoGuid
gEfiFileSystemInfoGuid
gEfiFileSystemVolumeLabelInfoIdGuid