]> git.proxmox.com Git - mirror_edk2.git/blame - OvmfPkg/VirtioFsDxe/VirtioFsDxe.inf
IntelFsp2Pkg: Update SEC_IDT_TABLE struct
[mirror_edk2.git] / OvmfPkg / VirtioFsDxe / VirtioFsDxe.inf
CommitLineData
5ab6a0e1
LE
1## @file\r
2# Provide EFI_SIMPLE_FILE_SYSTEM_PROTOCOL instances on virtio-fs devices.\r
3#\r
4# Copyright (C) 2020, Red Hat, Inc.\r
5#\r
6# SPDX-License-Identifier: BSD-2-Clause-Patent\r
7#\r
8#\r
9# Permission Model of this driver:\r
10#\r
11# Regardless of the UID and GID values this driver send in the FUSE request\r
12# header, the daemon (that is, the Virtio Filesystem device) always acts with\r
13# root privileges on the host side. The only time the daemon considers said UID\r
14# and GID fields is when creating a new file or directory. Thus, the guest\r
15# driver cannot rely on the host for enforcing any file mode permissions,\r
16# regardless of the "personality" that the guest driver poses as, because\r
17# "root" on the host side ignores all file mode bits.\r
18#\r
19# Therefore the guest driver has to do its own permission checking, and use the\r
20# host-side file mode bits only as a kind of "metadata storage" or "reminder"\r
21# -- hopefully in a way that makes some sense on the host side too.\r
22#\r
23# The complete mapping between the EFI_FILE_PROTOCOL and the host-side file\r
24# mode bits is described below.\r
25#\r
26# - The guest driver poses as UID 0, GID 0, PID 1.\r
27#\r
28# - If and only if all "w" bits are missing from a file on the host side, then\r
29# the file or directory is reported as EFI_FILE_READ_ONLY in the guest. When\r
30# setting EFI_FILE_READ_ONLY in the guest, all "w" bits (0222) are cleared on\r
31# the host; when clearing EFI_FILE_READ_ONLY in the guest, all "w" bits are\r
32# set on the host. Viewed from the host side, this sort of reflects that an\r
33# EFI_FILE_READ_ONLY file should not be written by anyone.\r
34#\r
35# - The attributes EFI_FILE_HIDDEN, EFI_FILE_SYSTEM, EFI_FILE_RESERVED, and\r
36# EFI_FILE_ARCHIVE are never reported in the guest, and they are silently\r
37# ignored when a SetInfo() call or a file-creating Open() call requests them.\r
38#\r
39# - On the host, files are created with 0666 file mode bits, directories are\r
40# created with 0777 file mode bits.\r
41#\r
42# - In the guest, the EFI_FILE_READ_ONLY attribute only controls the permitted\r
43# open mode. In particular, on directories, the EFI_FILE_READ_ONLY attribute\r
44# does not prevent the creation or deletion of entries inside the directory;\r
45# EFI_FILE_READ_ONLY only prevents the renaming, deleting, flushing (syncing)\r
46# and touching of the directory itself (with "touching" meaning updating the\r
47# timestamps). The fact that EFI_FILE_READ_ONLY being set on a directory is\r
48# irrelevant in the guest with regard to entry creation/deletion, is\r
49# well-mirrored by the fact that virtiofsd -- which runs as root, regardless\r
50# of guest driver personality -- ignores the absence of "w" permissions on a\r
51# host-side directory, when creating or removing entries in it.\r
52#\r
53# - When an EFI_FILE_PROTOCOL is opened read-only, then the Delete(), Write()\r
54# and Flush() member functions are disabled for it. Additionally, SetInfo()\r
55# is restricted to flipping the EFI_FILE_READ_ONLY bit (which takes effect at\r
56# the next Open()).\r
57#\r
58# - As a consequence of the above, for deleting a directory, it must be\r
59# presented in the guest as openable for writing.\r
60#\r
61# - We diverge from the UEFI spec, and permit Flush() on a directory that has\r
62# been opened read-write; otherwise the only way to invoke FUSE_FSYNCDIR on a\r
63# directory would be to Close() it.\r
64#\r
65# - OpenVolume() opens the root directory for read-only access. The Open()\r
66# member function may open it for read-write access. While the root directory\r
67# cannot be renamed or deleted, opening it for read-write access is useful\r
68# for calling Flush(), according to the previous paragraph, or for updating\r
69# the root directory's timestamps with SetInfo().\r
70##\r
71\r
72[Defines]\r
73 INF_VERSION = 1.29\r
74 BASE_NAME = VirtioFsDxe\r
75 FILE_GUID = 7BD9DDF7-8B83-488E-AEC9-24C78610289C\r
76 MODULE_TYPE = UEFI_DRIVER\r
77 ENTRY_POINT = VirtioFsEntryPoint\r
78\r
79[Packages]\r
cd473d41 80 EmbeddedPkg/EmbeddedPkg.dec\r
5ab6a0e1 81 MdePkg/MdePkg.dec\r
b55d6622 82 OvmfPkg/OvmfPkg.dec\r
5ab6a0e1
LE
83\r
84[Sources]\r
85 DriverBinding.c\r
d0474399 86 FuseFlush.c\r
92a4d30e 87 FuseForget.c\r
2e151d26 88 FuseFsync.c\r
e3bc9577 89 FuseGetAttr.c\r
fa97e372 90 FuseInit.c\r
b6ce961a 91 FuseLookup.c\r
f058cb69 92 FuseMkDir.c\r
da82d2e3 93 FuseOpen.c\r
b62a0c56 94 FuseOpenDir.c\r
a70860f4 95 FuseOpenOrCreate.c\r
d98d7e30 96 FuseRead.c\r
72d4f133 97 FuseRelease.c\r
bea1f51d 98 FuseRename.c\r
647340b0 99 FuseSetAttr.c\r
ba118463 100 FuseStatFs.c\r
0771671c 101 FuseUnlink.c\r
6f7bc719 102 FuseWrite.c\r
eaa7115d 103 Helpers.c\r
334c13e1
LE
104 SimpleFsClose.c\r
105 SimpleFsDelete.c\r
106 SimpleFsFlush.c\r
107 SimpleFsGetInfo.c\r
108 SimpleFsGetPosition.c\r
109 SimpleFsOpen.c\r
b55d6622 110 SimpleFsOpenVolume.c\r
334c13e1
LE
111 SimpleFsRead.c\r
112 SimpleFsSetInfo.c\r
113 SimpleFsSetPosition.c\r
114 SimpleFsWrite.c\r
b55d6622 115 VirtioFsDxe.h\r
5ab6a0e1
LE
116\r
117[LibraryClasses]\r
118 BaseLib\r
9307d7c7 119 BaseMemoryLib\r
b55d6622
LE
120 DebugLib\r
121 MemoryAllocationLib\r
cd473d41 122 TimeBaseLib\r
5ab6a0e1
LE
123 UefiBootServicesTableLib\r
124 UefiDriverEntryPoint\r
eaa7115d 125 VirtioLib\r
5ab6a0e1
LE
126\r
127[Protocols]\r
128 gEfiComponentName2ProtocolGuid ## PRODUCES\r
129 gEfiDriverBindingProtocolGuid ## PRODUCES\r
b55d6622
LE
130 gEfiSimpleFileSystemProtocolGuid ## BY_START\r
131 gVirtioDeviceProtocolGuid ## TO_START\r
b6b240f9
LE
132\r
133[Guids]\r
134 gEfiFileInfoGuid\r
135 gEfiFileSystemInfoGuid\r
136 gEfiFileSystemVolumeLabelInfoIdGuid\r