]>
Commit | Line | Data |
---|---|---|
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 | |
80 | MdePkg/MdePkg.dec\r | |
b55d6622 | 81 | OvmfPkg/OvmfPkg.dec\r |
5ab6a0e1 LE |
82 | \r |
83 | [Sources]\r | |
84 | DriverBinding.c\r | |
d0474399 | 85 | FuseFlush.c\r |
92a4d30e | 86 | FuseForget.c\r |
2e151d26 | 87 | FuseFsync.c\r |
fa97e372 | 88 | FuseInit.c\r |
b62a0c56 | 89 | FuseOpenDir.c\r |
72d4f133 | 90 | FuseRelease.c\r |
eaa7115d | 91 | Helpers.c\r |
334c13e1 LE |
92 | SimpleFsClose.c\r |
93 | SimpleFsDelete.c\r | |
94 | SimpleFsFlush.c\r | |
95 | SimpleFsGetInfo.c\r | |
96 | SimpleFsGetPosition.c\r | |
97 | SimpleFsOpen.c\r | |
b55d6622 | 98 | SimpleFsOpenVolume.c\r |
334c13e1 LE |
99 | SimpleFsRead.c\r |
100 | SimpleFsSetInfo.c\r | |
101 | SimpleFsSetPosition.c\r | |
102 | SimpleFsWrite.c\r | |
b55d6622 | 103 | VirtioFsDxe.h\r |
5ab6a0e1 LE |
104 | \r |
105 | [LibraryClasses]\r | |
106 | BaseLib\r | |
b55d6622 LE |
107 | DebugLib\r |
108 | MemoryAllocationLib\r | |
5ab6a0e1 LE |
109 | UefiBootServicesTableLib\r |
110 | UefiDriverEntryPoint\r | |
eaa7115d | 111 | VirtioLib\r |
5ab6a0e1 LE |
112 | \r |
113 | [Protocols]\r | |
114 | gEfiComponentName2ProtocolGuid ## PRODUCES\r | |
115 | gEfiDriverBindingProtocolGuid ## PRODUCES\r | |
b55d6622 LE |
116 | gEfiSimpleFileSystemProtocolGuid ## BY_START\r |
117 | gVirtioDeviceProtocolGuid ## TO_START\r |