Paolo Pisati [Thu, 3 Oct 2019 13:48:44 +0000 (13:48 +0000)]
UBUNTU: [Packaging] arm64: snapdragon: switch kernel format to Image
BugLink: https://bugs.launchpad.net/bugs/1846704
Older uboot don't know how to treat Image.gz kernels, and
linux-snapdragon has always used Image as the kernel format target for
that reason: ease the transition by using the same format - starting
with Ubuntu F, we'll switch to Image.gz (and probably merge this
flavour into generic).
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Acked-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: SAUCE: aufs: rwsem owner changed to atmoic_long_t in 5.3
Commit 94a9717b3c40 ("locking/rwsem: Make rwsem->owner an
atomic_long_t") in 5.3-rc1 changed rwsem->owner from a task
struct pointer to an atomic long. Update aufs accordingly.
Seth Forshee [Thu, 10 Oct 2019 15:26:50 +0000 (10:26 -0500)]
UBUNTU: [Config] Enable lockdown under secure boot
Set CONFIG_LOCK_DOWN_IN_SECURE_BOOT=y and
CONFIG_ALLOW_LOCKDOWN_LIFT_BY_SYSRQ=y to automatically enable
lockdown when booted under secure boot and to allow lifting of
lockdown via sysrq.
Seth Forshee [Thu, 10 Oct 2019 15:57:25 +0000 (10:57 -0500)]
UBUNTU: SAUCE: (lockdown) arm64: Allow locking down the kernel under EFI secure boot
Add support to arm64 for the CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT
option. When enabled the lockdown LSM will be enabled with
maximum confidentiality when booted under EFI secure boot.
Robert Holmes [Tue, 23 Apr 2019 07:39:29 +0000 (07:39 +0000)]
UBUNTU: SAUCE: (lockdown) KEYS: Make use of platform keyring for module signature verify
This patch completes commit 278311e417be ("kexec, KEYS: Make use of
platform keyring for signature verify") which, while adding the
platform keyring for bzImage verification, neglected to also add
this keyring for module verification.
As such, kernel modules signed with keys from the MokList variable
were not successfully verified.
Signed-off-by: Robert Holmes <robeholmes@gmail.com> Signed-off-by: Jeremy Cline <jcline@redhat.com>
(cherry picked from commit 7985392b917f8da1a8f12b2ab1e3be027f280e10
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: SAUCE: (lockdown) Add a SysRq option to lift kernel lockdown
Make an option to provide a sysrq key that will lift the kernel lockdown,
thereby allowing the running kernel image to be accessed and modified.
On x86 this is triggered with SysRq+x, but this key may not be available on
all arches, so it is set by setting LOCKDOWN_LIFT_KEY in asm/setup.h.
Since this macro must be defined in an arch to be able to use this facility
for that arch, the Kconfig option is restricted to arches that support it.
Signed-off-by: Kyle McMartin <kyle@redhat.com> Signed-off-by: David Howells <dhowells@redhat.com>
cc: x86@kernel.org Signed-off-by: Jeremy Cline <jcline@redhat.com>
(cherry picked from commit 8d188f1184a7e9993abdad8b2214925cb04064d4
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
David Howells [Mon, 30 Sep 2019 21:28:16 +0000 (21:28 +0000)]
UBUNTU: SAUCE: (lockdown) efi: Lock down the kernel if booted in secure boot mode
UEFI Secure Boot provides a mechanism for ensuring that the firmware
will only load signed bootloaders and kernels. Certain use cases may
also require that all kernel modules also be signed. Add a
configuration option that to lock down the kernel - which includes
requiring validly signed modules - if the kernel is secure-booted.
Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Jeremy Cline <jcline@redhat.com>
(cherry picked from commit cab56884183a0985401bd4d00e38cfb7858e71ad
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
David Howells [Tue, 27 Feb 2018 10:04:55 +0000 (10:04 +0000)]
UBUNTU: SAUCE: (lockdown) efi: Add an EFI_SECURE_BOOT flag to indicate secure boot mode
UEFI machines can be booted in Secure Boot mode. Add an EFI_SECURE_BOOT
flag that can be passed to efi_enabled() to find out whether secure boot is
enabled.
Move the switch-statement in x86's setup_arch() that inteprets the
secure_boot boot parameter to generic code and set the bit there.
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
cc: linux-efi@vger.kernel.org
[Rebased for context; efi_is_table_address was moved to arch/x86] Signed-off-by: Jeremy Cline <jcline@redhat.com>
(cherry picked from commit 4ba25f86f2d7a1db93f374840deddc33a3702fa9
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Peter Jones [Mon, 2 Oct 2017 22:18:30 +0000 (18:18 -0400)]
UBUNTU: SAUCE: (lockdown) Make get_cert_list() use efi_status_to_str() to print error messages.
Signed-off-by: Peter Jones <pjones@redhat.com>
(cherry picked from commit 12615d1a90d1cf5df8ee662b96e1f27a518ef5e7
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Peter Jones [Mon, 2 Oct 2017 22:22:13 +0000 (18:22 -0400)]
UBUNTU: SAUCE: (lockdown) Add efi_status_to_str() and rework efi_status_to_err().
This adds efi_status_to_str() for use when printing efi_status_t
messages, and reworks efi_status_to_err() so that the two use a common
list of errors.
Signed-off-by: Peter Jones <pjones@redhat.com>
(cherry picked from commit 3f5ca21ac793f30fa544808b470ff5ebd1940dca
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Peter Jones [Mon, 2 Oct 2017 22:25:29 +0000 (18:25 -0400)]
UBUNTU: SAUCE: (lockdown) Make get_cert_list() not complain about cert lists that aren't present.
Signed-off-by: Peter Jones <pjones@redhat.com>
(cherry picked from commit 614aa23ccc2817579f114b4b1d03b70b838d91af
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Kai-Heng Feng [Thu, 3 Oct 2019 15:38:09 +0000 (23:38 +0800)]
x86/PCI: Avoid AMD FCH XHCI USB PME# from D0 defect
BugLink: https://bugs.launchpad.net/bugs/1846470
The AMD FCH USB XHCI Controller advertises support for generating PME#
while in D0. When in D0, it does signal PME# for USB 3.0 connect events,
but not for USB 2.0 or USB 1.1 connect events, which means the controller
doesn't wake correctly for those events.
00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller [1022:7914] (rev 20) (prog-if 30 [XHCI])
Subsystem: Dell FCH USB XHCI Controller [1028:087e]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Clear PCI_PM_CAP_PME_D0 in dev->pme_support to indicate the device will not
assert PME# from D0 so we don't rely on it.
This causes an early udevadm trigger to fail. On some installer versions of
Ubuntu, this will cause init to exit, thus panicing the system very early
during boot.
Removing the bus_type from the parent device will remove some of the extra
empty files from /sys/devices/vio/, but will keep the rest of the layout for
vio devices, keeping them under /sys/devices/vio/.
It has been tested that uevents for vio devices don't change after this fix,
they still contain MODALIAS.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1845584
The memory region intel-lpss-pci uses has been declared as
write-combining
[ 0.001728] 5 base 4000000000 mask 6000000000 write-combining
This leads to the system hangs up during booting up.
Tuowen Zhao(ztuowen@gmail.com) provides a diff patch for intel-lpss
driver to claim to use un-cacheable memory while calling
__devm_ioremap(), and it works well. But it haven't been accepted by
maintainer yet.
To avoid the potential impact on other machines, I add a quirk to list
the machines which has the write-combining area in MTRR which overlaps
with the address that intel-lpss uses, only the machines in the list
pass the DEVM_IOREMAP_UC to __devm_ioremap().
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203485 Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: SAUCE: shiftfs: mark slab objects SLAB_RECLAIM_ACCOUNT
BugLink: https://bugs.launchpad.net/bugs/1842059
Shiftfs does not mark it's slab cache as reclaimable. While this is not
a big deal it is not nice to the kernel in general. The shiftfs cache is
not so important that it can't be reclaimed.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1841977
The way we messed with setting i_nlink was brittle and wrong. We used to
set the i_nlink of the shiftfs dentry to be deleted to the i_nlink count
of the underlay dentry of the directory it resided in which makes no
sense whatsoever. We also missed drop_nlink() which is crucial since
i_nlink affects whether a dentry is cleaned up on dput().
With this I cannot reproduce the bug anymore where shiftfs misleads zfs
into believing that a deleted file can not be removed from disk because
it is still referenced.
Fixes: commit 87011da41961 ("shiftfs: rework and extend") Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Seth Forshee [Wed, 21 Aug 2019 20:09:45 +0000 (15:09 -0500)]
UBUNTU: SAUCE: selftests: fib_tests: assign address to dummy1 for rp_filter tests
The rp_filter test tries to ping using the dummy1 interface
without assigning it an IP address. Give the interface an IP
address so the tests will pass.
BugLink: https://bugs.launchpad.net/bugs/1837231
This used to pass an unsigned long to copy_from_user() instead of a
void __user * pointer. This will produce warning with a sufficiently
advanced compiler.
Currently shiftfs does not handle O_DIRECT if the underlay supports it.
This is blocking dqlite - an essential part of LXD - from profiting from
the performance benefits of O_DIRECT on suitable filesystems when used
with async io such as aio or io_uring.
Overlayfs cannot support this directly since the upper filesystem in
overlay can be any filesystem. So if the upper filesystem does not
support O_DIRECT but the lower filesystem does you're out of luck.
Shiftfs does not suffer from the same problem since there is not concept
of an upper filesystem in the same way that overlayfs has it.
Essentially, shiftfs is a transparent shim relaying everything to the
underlay while overlayfs' upper layer is not (completely).
UBUNTU: SAUCE: usbip: add -Wno-address-of-packed-member to EXTRA_CFLAGS
Fails to build with gcc 9.1.0 due to
-Werror=address-of-packed-member. One example:
usbip_network.c: In function 'usbip_net_pack_usb_device':
usbip_network.c:79:32: error: taking address of packed member of 'struct usbip_usb_device' may result in an unaligned pointer value [-Werror=address-of-packed-member]
79 | usbip_net_pack_uint32_t(pack, &udev->busnum);
| ^~~~~~~~~~~~~
All of these are code which is explicitly packing a struct, so
add -Wno-address-of-packed-member to EXTRA_CFLAGS to disable this
warning.
UBUNTU: SAUCE: test_bpf: remove expected fail for Ctx heavy transformations test on s390
This test has started passing on s390, and because it is expected
to fail this is causing a test failure. I haven't tracked down
why it is now passing yet, but let's go ahead and remove the
expected fail for now to prevent showing failures in adt.
Seth Forshee [Thu, 27 Jun 2019 18:11:33 +0000 (13:11 -0500)]
UBUNTU: SAUCE: selftests/powerpc: disable signal_fuzzer test
This test is causing an oops which results in a hange during ADT
testing. This is a new tests, and it crashes kernels in older
releases, therefore it is not a regression. Disable the test for
now so that ADT can run.
Andy Whitcroft [Wed, 8 May 2019 13:24:40 +0000 (14:24 +0100)]
UBUNTU: SAUCE: tools -- fix add ability to disable libbfd
BugLink: https://bugs.launchpad.net/bugs/1826410
In commit 14541b1e7e ("perf build: Don't unconditionally link the libbfd
feature test to -liberty and -lz") the enablement code changed radically
neutering our override. Adapt to that new form.
Fixes: 546d50456e ("UBUNTU: SAUCE: tools -- add ability to disable libbfd") Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1828092
We're seeing on the order of 10K cma_alloc() failure messages on
certain systems (HiSilicon D06 w/ SMMU BIOS-disabled, HP m400s).
While we continue to try and identify a solution that avoids
these messages altogether, in the meantime let's lessen the impact
(slow boot time, etc) by ratelimiting these messages. On a D06
w/ SMMU disabled, this drops the error messages count from 10758 to
21.
Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Andrea Righi [Sat, 20 Apr 2019 07:41:00 +0000 (09:41 +0200)]
UBUNTU: SAUCE: integrity: downgrade error to warning
BugLink: https://bugs.launchpad.net/bugs/1766201
In 58441dc86d7b the error "Unable to open file: ..." has been downgraded
to warning in the integrity/ima subsystem. Do the same for a similar
error message in the generic integrity subsystem.
Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Khalid Elmously <khalid.elmously@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Currently, btrfs workloads employing shiftfs cause regression.
With btrfs unprivileged users can already toggle whether a subvolume
will be ro or rw. This is broken on current shiftfs as we haven't
whitelisted these ioctls().
To prevent such regression, we need to whitelist the ioctls
BTRFS_IOC_FS_INFO, BTRFS_IOC_SUBVOL_GETFLAGS, and
BTRFS_IOC_SUBVOL_SETFLAGS. All of them should be safe for unprivileged
users.
UBUNTU: SAUCE: shiftfs: lock down certain superblock flags
BugLink: https://bugs.launchpad.net/bugs/1827122
This locks down various superblock flags to prevent userns-root from
remounting a superblock with less restrictive options than the original
mark or underlay mount.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Before this commit we used to rely on an llseek method that was
targeted for regular files for both directories and regular files.
However, the realfile's f_pos was not correctly handled when userspace
called lseek(2) on a shiftfs directory file. Give directories their
own llseek operation so that seeking on a directory file is properly
supported.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Tyler Hicks <tyhicks@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Before this commit we used to keep a reference to the shiftfs mark
mount's shiftfs_super_info which was stashed in the superblock of the
mark mount. The problem is that we only take a reference to the mount of
the underlay, i.e. the filesystem that is *under* the shiftfs mark
mount. This means when someone performs a shiftfs mark mount, then a
shiftfs overlay mount and then immediately unmounts the shiftfs mark
mount we muck with invalid memory since shiftfs_put_super might have
already been called freeing that memory.
Another solution would be to start reference counting. But this would be
overkill. We only care about the passthrough mount option of the mark
mount. And we only need it to verify that on remount the new passthrough
options of the shiftfs overlay are a subset of the mark mount's
passthrough options. In other scenarios we don't care. So copying up is
good enough and also only needs to happen once on mount, i.e. when a new
superblock is created and the .fill_super method is called.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: SAUCE: shiftfs: fix passing of attrs to underaly for setattr
BugLink: https://bugs.launchpad.net/bugs/1824717
shiftfs_setattr() makes a copy of the attrs it was passed to pass
to the lower fs. It then calls setattr_prepare() with the original
attrs, and this may make changes which are not reflected in the
attrs passed to the lower fs. To fix this, copy the attrs to the
new struct for the lower fs after calling setattr_prepare().
Additionally, notify_change() may have set ATTR_MODE when one of
ATTR_KILL_S[UG]ID is set, and passing this combination to
notify_change() will trigger a BUG(). Do as overlayfs and
ecryptfs both do, and clear ATTR_MODE if either of those bits
is set.
UBUNTU: SAUCE: shiftfs: use translated ids when chaning lower fs attrs
BugLink: https://bugs.launchpad.net/bugs/1824350
shiftfs_setattr() is preparing a new set of attributes with the
owner translated for the lower fs, but it then passes the
original attrs. As a result the owner is set to the untranslated
owner, which causes the shiftfs inodes to also have incorrect
ids. For example:
# mkdir dir
# touch file
# ls -lh dir file
drwxr-xr-x 2 root root 4.0K Apr 11 13:05 dir
-rw-r--r-- 1 root root 0 Apr 11 13:05 file
# chown 500:500 dir file
# ls -lh dir file
drwxr-xr-x 2 10005001000500 4.0K Apr 11 12:42 dir
-rw-r--r-- 1 10005001000500 0 Apr 11 12:42 file
Fix this to pass the correct iattr struct to notify_change().
Reviewed-by: Christian Brauner <christian.brauner@ubuntu.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: Tyler Hicks <tyhicks@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1823186
Shiftfs currently only passes through a few ioctl()s to the underlay. These
are ioctl()s that are generally considered safe. Doing it for random
ioctl()s would be a security issue. Permissions for ioctl()s are not
checked before the filesystem gets involved so if we were to override
credentials we e.g. could do a btrfs tree search in the underlay which we
normally wouldn't be allowed to do.
However, the btrfs filesystem allows unprivileged users to perform various
operations through its ioctl() interface. With shiftfs these ioctl() are
currently not working. To not regress users that expect btrfs ioctl()s to
work in unprivileged containers we can create a whitelist of ioctl()s that
we allow to go through to the underlay and for which we also switch
credentials.
The main problem is how we switch credentials. Since permissions checks for
ioctl()s are
done by the actual file system and not by the vfs this would mean that any
additional capable(<cap>)-based checks done by the filesystem would
unconditonally pass after we switch credentials. So to make credential
switching safe we drop *all* capabilities when switching credentials. This
means that only inode-based permission checks will pass.
Btrfs also allows unprivileged users to delete snapshots when the
filesystem is mounted with user_subvol_rm_allowed mount option or if the
the callers is capable(CAP_SYS_ADMIN). The latter should never be the case
with unprivileged users. To make sure we only allow removal of snapshots in
the former case we drop all capabilities (see above) when switching
credentials.
Additonally, btrfs allows the creation of snapshots. To make this work we
need to be (too) clever. When doing snapshots btrfs requires that an fd to
the directory the snapshot is supposed to be created in be passed along.
This fd obviously references a shiftfs file and as such a shiftfs dentry
and inode. This will cause btrfs to yell EXDEV. To circumnavigate this
problem we need to silently temporarily replace the passed in fd with an fd
that refers to a file that references a btrfs dentry and inode.
BugLink: https://bugs.launchpad.net/bugs/1823186
/* Introduction */
The shiftfs filesystem is implemented as a stacking filesystem. Since it is
a stacking filesystem it shares concepts with overlayfs and ecryptfs.
Usually, shiftfs will be stacked upon another filesystem. The filesystem on
top - shiftfs - is referred to as "upper filesystem" or "overlay" and the
filesystem it is stacked upon is referred to as "lower filesystem" or
"underlay".
/* Marked and Unmarked shiftfs mounts */
To use shiftfs it is necessary that a given mount is marked as shiftable via
the "mark" mount option. Any mount of shiftfs without the "mark" mount option
not on top of a shiftfs mount with the "mark" mount option will be refused with
EPERM.
After a marked shiftfs mount has been performed other shiftfs mounts
referencing the marked shiftfs mount can be created. These secondary shiftfs
mounts are usually what are of interest.
The marked shiftfs mount will take a reference to the underlying mountpoint of
the directory it is marking as shiftable. Any unmarked shiftfts mounts
referencing this marked shifts mount will take a second reference to this
directory as well. This ensures that the underlying marked shiftfs mount can be
unmounted thereby dropping the reference to the underlying directory without
invalidating the mountpoint of said directory since the non-marked shiftfs
mount still holds another reference to it.
/* Stacking Depth */
Shiftfs tries to keep the stack as flat as possible to avoid hitting the
kernel enforced filesystem stacking limit.
/* Permission Model */
When the mark shiftfs mount is created shiftfs will record the credentials of
the creator of the super block and stash it in the super block. When other
non-mark shiftfs mounts are created that reference the mark shiftfs mount they
will stash another reference to the creators credentials. Before calling into
the underlying filesystem shiftfs will switch to the creators credentials and
revert to the original credentials after the underlying filesystem operation
returns.
/* Mount Options */
- mark
When set the mark mount option indicates that the mount in question is
allowed to be shifted. Since shiftfs it mountable in by user namespace root
non-initial user namespace this mount options ensures that the system
administrator has decided that the marked mount is safe to be shifted.
To mark a mount as shiftable CAP_SYS_ADMIN in the user namespace is required.
- passthrough={0,1,2,3}
This mount options functions as a bitmask. When set to a non-zero value
shiftfs will try to act as an invisible shim sitting on top of the
underlying filesystem.
- 1: Shifts will report the filesystem type of the underlay for stat-like
system calls.
- 2: Shiftfs will passthrough whitelisted ioctl() to the underlay.
- 3: Shiftfs will both use 1 and 2.
Note that mount options on a marked mount cannot be changed.
/* Extended Attributes */
Shiftfs will make sure to translate extended attributes.
/* Inodes Numbers */
Shiftfs inodes numbers are copied up from the underlying filesystem, i.e.
shiftfs inode numbers will be identical to the corresponding underlying
filesystem's inode numbers. This has the advantage that inotify and friends
should work out of the box.
(In essence, shiftfs is nothing but a 1:1 mirror of the underlying filesystem's
dentries and inodes.)
/* Device Support */
Shiftfs only supports the creation of pipe and socket devices. Character and
block devices cannot be created through shiftfs.
projects / mirror_ubuntu-focal-kernel.git / log