Patrick Pedersen [Sat, 15 Jul 2017 12:27:21 +0000 (14:27 +0200)]
UBUNTU: SAUCE: (no-up) HID: Add quirk for Lenovo Yoga 910 with ITE Chips
BugLink: http://bugs.launchpad.net/bugs/1708120
As with previous generations of this device (see https://patchwork.kernel.org/patch/7887361/), the ITE
HID Sensor Hub, responsible for the accelerometer and als sensor, requires a quirk entry.
Without the entry, the Sensor Hub can't be accessed and the kernel fails to report any movements. As a result
iio-sensor-proxy receives no new data.
It shall additionally be noted that the i2c-hid 'sleep' bug (present since kernel ver. 4.3)
still affects the driver. This means that the sensor hub will not report any movement, until
the device is suspended and resumed.
Signed-off-by: Patrick Pedersen <ctx.xda@gmail.com> Signed-off-by: Chris MacNaughton <chris.macnaughton@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Seth Forshee [Wed, 2 Aug 2017 14:43:28 +0000 (09:43 -0500)]
UBUNTU: [Config] CONFIG_SATA_HIGHBANK=y
BugLink: http://bugs.launchpad.net/bugs/1703430
This changed from y to m after trusty without justification.
Having it built as a module causes issues with booting on some
ARM systems.
BugLink: http://bugs.launchpad.net/bugs/1704479
As Novalink has required a change in config file to change the
IBMVETH to module state instead of built in.
UBUNTU: [Debian] Support sphinx-based kernel documentation
The kernel has been transitioning to using sphinx instead of
DocBook for generating documentation. Starting in 4.13 the old
DocBook support has been completely removed, breaking our
linux-doc build. Update the build deps and copy the html docs
from their new location.
We still need to keep the DocBook build dependency for generating
perf manpages.
Seth Forshee [Thu, 25 May 2017 13:15:08 +0000 (08:15 -0500)]
UBUNTU: [Debian] Run 'silentoldconfig' when not editing a configuration
Config options which are '-' for a given flavor may have values
specified in common configuration files. Thus the initial config
file created by concatinating the fragments will have values for
these options which Kconfig will later delete.
However, when 'fdr editconfig' is run and the prompt to edit a
given configuration is declined, Kconfig does not modify the
config and these values remain. If any of these values is
enforced config-check will produce an error. We need to run
'make slientoldconfig' in this case so that the config files
will be accurate.
/tmp/kernel-sforshee-fb8075f-U05S/build/ubuntu/hio/hio.c: In function 'ssd_bio_endio':
/tmp/kernel-sforshee-fb8075f-U05S/build/ubuntu/hio/hio.c:2100:5: error: 'struct bio' has no member named 'bi_error'; did you mean 'bi_iter'?
bio->bi_error = error;
^~
/tmp/kernel-sforshee-fb8075f-U05S/build/ubuntu/hio/hio.c: In function 'ssd_make_request':
/tmp/kernel-sforshee-fb8075f-U05S/build/ubuntu/hio/hio.c:8461:2: error: too many arguments to function 'blk_queue_split'
blk_queue_split(q, &bio, q->bio_split);
^~~~~~~~~~~~~~~
In file included from /tmp/kernel-sforshee-fb8075f-U05S/build/ubuntu/hio/hio.c:30:0:
/tmp/kernel-sforshee-fb8075f-U05S/build/include/linux/blkdev.h:958:13: note: declared here
extern void blk_queue_split(struct request_queue *, struct bio **);
^~~~~~~~~~~~~~~
Seth Forshee [Fri, 2 Jun 2017 18:45:22 +0000 (13:45 -0500)]
UBUNTU: SAUCE: (efi-lockdown) efi: Don't print secure boot state from the efi stub
During boot the efi stub prints what amounts to debugging
messages about the secure boot state to the efi console. which
appear on the screen during boot. The same information is printed
in dmesg while the kernel is booting, so they serve no purpose
aside from debugging issues in the efi stub. Remove them.
Seth Forshee [Thu, 4 May 2017 13:09:04 +0000 (08:09 -0500)]
UBUNTU: SAUCE: (efi-lockdown) efi: Sanitize boot_params in efi stub
The efi stub will set the value of boot_params.secure_boot
without first checking whether boot_params has been sanitized. If
they have not, the value of secure_boot will be cleared later
when boot_params is sanitized. This currently happens with grub
as it currently does not clear the sentinel, and thus the kernel
cannot determine the secure boot state.
Since the efi stub is modifying a field in an area subject to
sanitization, it must first sanitize boot_params if needed. Later
sanitization by the decompressor will do nothing as the sentinel
value will have been cleared.
Josh Boyer [Fri, 5 May 2017 07:21:59 +0000 (08:21 +0100)]
UBUNTU: SAUCE: (efi-lockdown) MODSIGN: Allow the "db" UEFI variable to be suppressed
If a user tells shim to not use the certs/hashes in the UEFI db variable
for verification purposes, shim will set a UEFI variable called
MokIgnoreDB. Have the uefi import code look for this and ignore the db
variable if it is found.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: David Howells <dhowells@redhat.com>
(cherry picked from commit d88a05741dd4e3ec91690da8a8025f15ca9e37e9
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Josh Boyer [Fri, 5 May 2017 07:21:59 +0000 (08:21 +0100)]
UBUNTU: SAUCE: (efi-lockdown) MODSIGN: Import certificates from UEFI Secure Boot
Secure Boot stores a list of allowed certificates in the 'db' variable.
This imports those certificates into the system trusted keyring. This
allows for a third party signing certificate to be used in conjunction
with signed modules. By importing the public certificate into the 'db'
variable, a user can allow a module signed with that certificate to
load. The shim UEFI bootloader has a similar certificate list stored
in the 'MokListRT' variable. We import those as well.
Secure Boot also maintains a list of disallowed certificates in the 'dbx'
variable. We load those certificates into the newly introduced system
blacklist keyring and forbid any module signed with those from loading and
forbid the use within the kernel of any key with a matching hash.
This facility is enabled by setting CONFIG_LOAD_UEFI_KEYS.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: David Howells <dhowells@redhat.com>
(cherry picked from commit dc5fd3fc2faf24eed23ed8317f2315fb49ff6382
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Dave Howells [Fri, 5 May 2017 07:21:58 +0000 (08:21 +0100)]
UBUNTU: SAUCE: (efi-lockdown) efi: Add an EFI signature blob parser
Add a function to parse an EFI signature blob looking for elements of
interest. A list is made up of a series of sublists, where all the
elements in a sublist are of the same type, but sublists can be of
different types.
For each sublist encountered, the function pointed to by the
get_handler_for_guid argument is called with the type specifier GUID and
returns either a pointer to a function to handle elements of that type or
NULL if the type is not of interest.
If the sublist is of interest, each element is passed to the handler
function in turn.
Signed-off-by: David Howells <dhowells@redhat.com>
(cherry picked from commit cb3666f519f625a709b4a24f5a9307fb9ed4784a
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Dave Howells [Fri, 5 May 2017 07:21:58 +0000 (08:21 +0100)]
UBUNTU: SAUCE: (efi-lockdown) efi: Add EFI signature data types
Add the data types that are used for containing hashes, keys and
certificates for cryptographic verification along with their corresponding
type GUIDs.
Signed-off-by: David Howells <dhowells@redhat.com>
(cherry picked from commit 2e3003b76149804455a19ee319fcf5753b6ecb4a
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
David Howells [Fri, 5 May 2017 07:21:56 +0000 (08:21 +0100)]
UBUNTU: SAUCE: (efi-lockdown) KEYS: Allow unrestricted boot-time addition of keys to secondary keyring
Allow keys to be added to the system secondary certificates keyring during
kernel initialisation in an unrestricted fashion. Such keys are implicitly
trusted and don't have their trust chains checked on link.
This allows keys in the UEFI database to be added in secure boot mode for
the purposes of module signing.
Signed-off-by: David Howells <dhowells@redhat.com>
(cherry picked from commit d2123d28abfa79a66af0fa42fcc4fa306bfda0b6
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
David Howells [Wed, 7 Dec 2016 10:28:39 +0000 (10:28 +0000)]
UBUNTU: SAUCE: (efi-lockdown) Lock down TIOCSSERIAL
Lock down TIOCSSERIAL as that can be used to change the ioport and irq
settings on a serial port. This only appears to be an issue for the serial
drivers that use the core serial code. All other drivers seem to either
ignore attempts to change port/irq or give an error.
Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: David Howells <dhowells@redhat.com>
(cherry picked from commit 83bd921f9ac911f2644bdc5abd31dd4d56cfeb4e
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
David Howells [Tue, 22 Nov 2016 10:10:34 +0000 (10:10 +0000)]
UBUNTU: SAUCE: (efi-lockdown) scsi: Lock down the eata driver
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
The eata driver takes a single string parameter that contains a slew of
settings, including hardware resource configuration. Prohibit use of the
parameter if the kernel is locked down.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> Signed-off-by: David Howells <dhowells@redhat.com>
cc: Dario Ballabio <ballabio_dario@emc.com>
cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>
cc: "Martin K. Petersen" <martin.petersen@oracle.com>
cc: linux-scsi@vger.kernel.org
(cherry picked from commit 83b96284c638df0320251a0c502d850130095568
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Lee, Chun-Yi [Wed, 23 Nov 2016 13:52:16 +0000 (13:52 +0000)]
UBUNTU: SAUCE: (efi-lockdown) bpf: Restrict kernel image access functions when the kernel is locked down
There are some bpf functions can be used to read kernel memory:
bpf_probe_read, bpf_probe_write_user and bpf_trace_printk. These allow
private keys in kernel memory (e.g. the hibernation image signing key) to
be read by an eBPF program. Prohibit those functions when the kernel is
locked down.
Signed-off-by: Lee, Chun-Yi <jlee@suse.com> Signed-off-by: David Howells <dhowells@redhat.com>
(cherry picked from commit 59e44bdc67df6cdcd4627f2b5b0b4d7e735c23fc
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Linn Crosetto [Wed, 23 Nov 2016 13:39:41 +0000 (13:39 +0000)]
UBUNTU: SAUCE: (efi-lockdown) acpi: Disable APEI error injection if the kernel is locked down
ACPI provides an error injection mechanism, EINJ, for debugging and testing
the ACPI Platform Error Interface (APEI) and other RAS features. If
supported by the firmware, ACPI specification 5.0 and later provide for a
way to specify a physical memory address to which to inject the error.
Injecting errors through EINJ can produce errors which to the platform are
indistinguishable from real hardware errors. This can have undesirable
side-effects, such as causing the platform to mark hardware as needing
replacement.
While it does not provide a method to load unauthenticated privileged code,
the effect of these errors may persist across reboots and affect trust in
the underlying hardware, so disable error injection through EINJ if
the kernel is locked down.
Signed-off-by: Linn Crosetto <linn@hpe.com> Signed-off-by: David Howells <dhowells@redhat.com>
(cherry picked from commit 1f3424cef8e1ac3b770a2b9087a9f7a937d63f00
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Linn Crosetto [Wed, 23 Nov 2016 13:32:27 +0000 (13:32 +0000)]
UBUNTU: SAUCE: (efi-lockdown) acpi: Disable ACPI table override if the kernel is locked down
From the kernel documentation (initrd_table_override.txt):
If the ACPI_INITRD_TABLE_OVERRIDE compile option is true, it is possible
to override nearly any ACPI table provided by the BIOS with an
instrumented, modified one.
When securelevel is set, the kernel should disallow any unauthenticated
changes to kernel space. ACPI tables contain code invoked by the kernel,
so do not allow ACPI tables to be overridden if the kernel is locked down.
Signed-off-by: Linn Crosetto <linn@hpe.com> Signed-off-by: David Howells <dhowells@redhat.com>
(cherry picked from commit 95c6461495bf8d85daa48d77d29c36852b7b8bab
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Josh Boyer [Tue, 22 Nov 2016 08:46:16 +0000 (08:46 +0000)]
UBUNTU: SAUCE: (efi-lockdown) acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down
This option allows userspace to pass the RSDP address to the kernel, which
makes it possible for a user to circumvent any restrictions imposed on
loading modules. Ignore the option when the kernel is locked down.
Signed-off-by: Josh Boyer <jwboyer@redhat.com> Signed-off-by: David Howells <dhowells@redhat.com>
(cherry picked from commit 0495804df6187a2a52d2a5a086d3f44a10594272
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Matthew Garrett [Tue, 22 Nov 2016 08:46:16 +0000 (08:46 +0000)]
UBUNTU: SAUCE: (efi-lockdown) ACPI: Limit access to custom_method when the kernel is locked down
custom_method effectively allows arbitrary access to system memory, making
it possible for an attacker to circumvent restrictions on module loading.
Disable it if the kernel is locked down.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: David Howells <dhowells@redhat.com>
(cherry picked from commit 92399e07fe1628f60b39ec541c16b2786234f11a
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Matthew Garrett [Tue, 22 Nov 2016 08:46:16 +0000 (08:46 +0000)]
UBUNTU: SAUCE: (efi-lockdown) asus-wmi: Restrict debugfs interface when the kernel is locked down
We have no way of validating what all of the Asus WMI methods do on a given
machine - and there's a risk that some will allow hardware state to be
manipulated in such a way that arbitrary code can be executed in the
kernel, circumventing module loading restrictions. Prevent that if the
kernel is locked down.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: David Howells <dhowells@redhat.com>
(cherry picked from commit 37b6f12b0ffcb731a1eab47c552659f64ab2b312
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Matthew Garrett [Tue, 22 Nov 2016 08:46:17 +0000 (08:46 +0000)]
UBUNTU: SAUCE: (efi-lockdown) x86: Restrict MSR access when the kernel is locked down
Writing to MSRs should not be allowed if the kernel is locked down, since
it could lead to execution of arbitrary code in kernel mode. Based on a
patch by Kees Cook.
Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: David Howells <dhowells@redhat.com>
(cherry picked from commit 02704579cfdfb2e63401172a421ea373d53007a3
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Matthew Garrett [Tue, 22 Nov 2016 08:46:16 +0000 (08:46 +0000)]
UBUNTU: SAUCE: (efi-lockdown) x86: Lock down IO port access when the kernel is locked down
IO port access would permit users to gain access to PCI configuration
registers, which in turn (on a lot of hardware) give access to MMIO
register space. This would potentially permit root to trigger arbitrary
DMA, so lock it down by default.
This also implicitly locks down the KDADDIO, KDDELIO, KDENABIO and
KDDISABIO console ioctls.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: David Howells <dhowells@redhat.com>
(cherry picked from commit fdde4a7f63e87d1f9d16aed21ac186e41d602e77
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Matthew Garrett [Tue, 22 Nov 2016 08:46:15 +0000 (08:46 +0000)]
UBUNTU: SAUCE: (efi-lockdown) PCI: Lock down BAR access when the kernel is locked down
Any hardware that can potentially generate DMA has to be locked down in
order to avoid it being possible for an attacker to modify kernel code,
allowing them to circumvent disabled module loading or module signing.
Default to paranoid - in future we can potentially relax this for
sufficiently IOMMU-isolated devices.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: David Howells <dhowells@redhat.com>
(cherry picked from commit 61c0fbd9f8b9f291ef046ccf7645fb3fc46d9d1e
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Matthew Garrett [Wed, 23 Nov 2016 13:28:17 +0000 (13:28 +0000)]
UBUNTU: SAUCE: (efi-lockdown) uswsusp: Disable when the kernel is locked down
uswsusp allows a user process to dump and then restore kernel state, which
makes it possible to modify the running kernel. Disable this if the kernel
is locked down.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: David Howells <dhowells@redhat.com>
(cherry picked from commit 6e81952a04eec972366f86579b6877d01ad622b0
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Josh Boyer [Tue, 22 Nov 2016 08:46:15 +0000 (08:46 +0000)]
UBUNTU: SAUCE: (efi-lockdown) hibernate: Disable when the kernel is locked down
There is currently no way to verify the resume image when returning
from hibernate. This might compromise the signed modules trust model,
so until we can work with signed hibernate images we disable it when the
kernel is locked down.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: David Howells <dhowells@redhat.com>
(cherry picked from commit 693ea9dae1c8724abb2d37648ee2ded900de0ceb
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Dave Young [Tue, 22 Nov 2016 08:46:15 +0000 (08:46 +0000)]
UBUNTU: SAUCE: (efi-lockdown) Copy secure_boot flag in boot params across kexec reboot
Kexec reboot in case secure boot being enabled does not keep the secure
boot mode in new kernel, so later one can load unsigned kernel via legacy
kexec_load. In this state, the system is missing the protections provided
by secure boot.
Adding a patch to fix this by retain the secure_boot flag in original
kernel.
secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the
stub. Fixing this issue by copying secure_boot flag across kexec reboot.
Signed-off-by: Dave Young <dyoung@redhat.com> Signed-off-by: David Howells <dhowells@redhat.com>
(cherry picked from commit 0f3579c6022a5bed492100b27a49ea2e6cf79655
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Matthew Garrett [Tue, 22 Nov 2016 08:46:15 +0000 (08:46 +0000)]
UBUNTU: SAUCE: (efi-lockdown) kexec: Disable at runtime if the kernel is locked down
kexec permits the loading and execution of arbitrary code in ring 0, which
is something that lock-down is meant to prevent. It makes sense to disable
kexec in this situation.
This does not affect kexec_file_load() which can check for a signature on the
image to be booted.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: David Howells <dhowells@redhat.com>
(cherry picked from commit de842605efb941d9e67d5d24f5435bf635a249fb
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Matthew Garrett [Tue, 22 Nov 2016 08:46:16 +0000 (08:46 +0000)]
UBUNTU: SAUCE: (efi-lockdown) Restrict /dev/mem and /dev/kmem when the kernel is locked down
Allowing users to write to address space makes it possible for the kernel to
be subverted, avoiding module loading restrictions. Prevent this when the
kernel has been locked down.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: David Howells <dhowells@redhat.com>
(cherry picked from commit e2e7964001bad227c5083a3af47ac52c61bfa04d
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
David Howells [Mon, 21 Nov 2016 23:55:55 +0000 (23:55 +0000)]
UBUNTU: SAUCE: (efi-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>
(cherry picked from commit 37d1503ec080faf72878bf544a641767dc1515e9
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
David Howells [Mon, 21 Nov 2016 23:36:17 +0000 (23:36 +0000)]
UBUNTU: SAUCE: (efi-lockdown) Add the ability to lock down access to the running kernel image
Provide a single call to allow kernel code to determine whether the system
should be locked down, thereby disallowing various accesses that might
allow the running kernel image to be changed including the loading of
modules that aren't validly signed with a key we recognise, fiddling with
MSR registers and disallowing hibernation,
Signed-off-by: David Howells <dhowells@redhat.com>
(cherry picked from commit a6b8c6722739e360f2587d67c0977e264ade1024
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Josh Boyer [Mon, 21 Nov 2016 23:55:55 +0000 (23:55 +0000)]
UBUNTU: SAUCE: (efi-lockdown) efi: Add EFI_SECURE_BOOT bit
UEFI machines can be booted in Secure Boot mode. Add a EFI_SECURE_BOOT bit
that can be passed to efi_enabled() to find out whether secure boot is
enabled.
This will be used by the SysRq+x handler, registered by the x86 arch, to find
out whether secure boot mode is enabled so that it can be disabled.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: David Howells <dhowells@redhat.com>
(cherry picked from commit c7fa9ead2f377781622668f7ee2b73bf7f6e8110
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
export ARCH=arm; export CROSS_COMPILE=arm-linux-gnueabihf-
make defconfig
make snap-pkg
The resulting kernel snap will be generated in $(objtree)/snap
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Daniel Axtens [Thu, 29 Jun 2017 03:45:44 +0000 (13:45 +1000)]
UBUNTU: SAUCE: PCI: Support hibmc VGA cards behind a misbehaving HiSilicon bridge
BugLink: https://bugs.launchpad.net/bugs/1698706
The HiSilicon D05 board has some PCI bridges (PCI ID 19e5:1610) that
are not spec-compliant: the VGA Enable bit is set to 0 in hardware
and writes do not change it.
This stops VGA arbitrartion from marking a VGA card behind the bridge
as a boot device, and therefore breaks Xorg auto-configuration.
The hibmc VGA card (PCI ID 19e5:1711) is known to work when behind
these bridges.
Provide a quirk so that this combination of bridge and card is eligible
to be the default VGA card.
This fixes Xorg auto-detection.
Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: Rongrong Zou <zourongrong@gmail.com> Signed-off-by: Daniel Axtens <daniel.axtens@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com>
[saf: Adjusted context for 4.12] Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: SAUCE: hio: Fix incorrect use of enum req_opf values
BugLink: http://bugs.launchpad.net/bugs/1701316
Patch from Huawei to fix incorrect use of enumerated values for
bio operations as bitmasks. A reordering of the enum in 4.10
caused a change in behavior which has been leading to data
corruption.
UBUNTU: SAUCE: (no-up) net: Zeroing the structure ethtool_wolinfo in ethtool_get_wol()
CVE-2014-9900
memset() the structure ethtool_wolinfo that has padded bytes
but the padded bytes have not been zeroed out.
Change-Id: If3fd2d872a1b1ab9521d937b86a29fc468a8bbfe Signed-off-by: Avijit Kanti Das <avijitnsec@codeaurora.org> Signed-off-by: Brad Figg <brad.figg@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Colin Ian King [Wed, 7 Jun 2017 12:28:24 +0000 (13:28 +0100)]
UBUNTU: SAUCE: (noup) Update spl to 0.6.5.9-1ubuntu2, zfs to 0.6.5.9-5ubuntu7
Sync with upstream 4.12 compat fixes to build with 4.12. Tested against
upstream 4.12-rc4 and ubuntu Artful 4.11 kernels.
SPL:
* Add 4.12 compat patch from upstream to build with 4.12 kernel:
- 8f87971e1fd11e Linux 4.12 compat: PF_FSTRANS was removed
ZFS:
* Add 4.12 compat patches from upstream to build with 4.12 kernel:
- 608d6942b70436 Linux 4.12 compat: super_setup_bdi_name()
- e624cd19599047 Linux 4.12 compat: PF_FSTRANS was removed
- 2946a1a15aab87 Linux 4.12 compat: CURRENT_TIME removed
- 3e6c9433474f0b Linux 4.12 compat: fix super_setup_bdi_name() call
Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
dann frazier [Tue, 28 Mar 2017 20:42:36 +0000 (14:42 -0600)]
UBUNTU: SAUCE: PCI: Restore codepath for !CONFIG_LIBIO
BugLink: http://bugs.launchpad.net/bugs/1677319
While LIBIO is needed on arm64, it is still new infrastructure that hasn't
had a lot of testing on other architectures. This specifically impacts
Ubuntu architecures that define PCI_IOBASE: armhf, arm64 and s390x.
Restore the pre-LIBIO infrastructure when CONFIG_LIBIO=n, which we'll use
for those builds.
= Verification of correctness =
The files referred to in this test are:
- pci.c: drivers/pci/pci.c with this series applied
- pci.c.lpc: Same as pci.c, but without this patch.
- pci.c.orig: Ubuntu's pci.c, prior to this patchset.
Test #1: Architectures that will use LIBIO and define PCI_IOBASE
(i.e. arm64) use the new LIBIO code:
$ unifdef -DCONFIG_LIBIO -DPCI_IOBASE pci.c > a
$ unifdef -DPCI_IOBASE pci.c.lpc > b
$ diff -u a b
--- a 2017-03-29 14:36:07.444552427 -0600
+++ b 2017-03-29 14:36:16.652547367 -0600
@@ -3241 +3240,0 @@
-
(i.e., whitespace only)
Test #2: Architectures that will *not* use LIBIO and define PCI_IOBASE
(i.e. armhf & s390x) should use pre-LIBIO code.
$ unifdef -UCONFIG_LIBIO -DPCI_IOBASE pci.c > a
$ unifdef -DPCI_IOBASE pci.c.orig > b
$ diff -U0 a b
--- a 2017-03-29 14:42:20.640348198 -0600
+++ b 2017-03-29 14:43:02.204325557 -0600
@@ -3254,2 +3254 @@
-int pci_register_io_range(struct fwnode_handle *fwnode, phys_addr_t addr,
- resource_size_t size)
+int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
(i.e., just the expected changes in prototype - new *fwnode param and
removal of unnecessary "__weak" annotation).
Test #3: Architectures that will neither use LIBIO nor define PCI_IOBASE
(i.e. ppc64el & x86) should use pre-LIBIO code.
$ unifdef -UPCI_IOBASE -UCONFIG_LIBIO pci.c > a
$ unifdef -UPCI_IOBASE pci.c.orig > b
$ diff -U0 a b
--- a 2017-03-29 14:45:58.064229981 -0600
+++ b 2017-03-29 14:46:11.392222753 -0600
@@ -3246,2 +3246 @@
-int pci_register_io_range(struct fwnode_handle *fwnode, phys_addr_t addr,
- resource_size_t size)
+int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
@@ -3266,0 +3266 @@
+
(Again, just the expected changes in prototype - new *fwnode param and
removal of unnecessary "__weak" annotation).
Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
zhichang.yuan [Sat, 11 Mar 2017 13:36:08 +0000 (21:36 +0800)]
UBUNTU: SAUCE: PCI: Apply the new generic I/O management on PCI IO hosts
BugLink: http://bugs.launchpad.net/bugs/1677319
After introducing the new generic I/O space management(LIBIO), the original PCI
MMIO relevant helpers need to be updated based on the new interfaces defined in
LIBIO.
This patch adapts the corresponding code to match the changes introduced by
LIBIO.
[Note that the removal of __weak on pci_register_io_range is intentional, as
there are no other users. See: https://lkml.org/lkml/2017/1/30/848 -dannf]
Signed-off-by: zhichang.yuan <yuanzhichang@hisilicon.com> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> #earlier draft Acked-by: Bjorn Helgaas <bhelgaas@google.com> #drivers/pci parts
(v7 submission)
Reference: http://www.spinics.net/lists/linux-pci/msg59176.html
[dannf: included a few changes from zhichang based on list feedback:
tighter arch-restriction, build fix for non-LIBIO builds & a return code
optimization] Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
zhichang.yuan [Mon, 13 Mar 2017 02:42:43 +0000 (10:42 +0800)]
UBUNTU: SAUCE: LPC: Add the ACPI LPC support
BugLink: http://bugs.launchpad.net/bugs/1677319
The patch update the _CRS of LPC children based on the relevant LIBIO
interfaces. Then the ACPI platform device enumeration for LPC can apply the
right I/O resource to request the system I/O space from ioport_resource and
ensure the LPC peripherals work well.
Signed-off-by: zhichang.yuan <yuanzhichang@hisilicon.com> Signed-off-by: John Garry <john.garry@huawei.com>
(v7 submission)
Reference: http://www.spinics.net/lists/linux-pci/msg59174.html
[dannf: Include fix from zhichang to support early LPC bus probing] Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
zhichang.yuan [Mon, 13 Mar 2017 02:42:42 +0000 (10:42 +0800)]
UBUNTU: SAUCE: LIBIO: Support the dynamically logical PIO registration of ACPI host I/O
BugLink: http://bugs.launchpad.net/bugs/1677319
For those hosts which access I/O based on the host/bus local I/O addresses,
their I/O range must be registered and translated as unique logical PIO before
the ACPI enumeration on the devices under the hosts. Otherwise, there is no
available I/O resources allocated for those devices.
This patch implements the interfaces in LIBIO to perform the host local I/O
translation and set the logical IO mapped as ACPI I/O resources.
Signed-off-by: zhichang.yuan <yuanzhichang@hisilicon.com> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
(v7 submission)
Reference: https://www.spinics.net/lists/arm-kernel/msg568096.html
[dannf: Include fix from zhichang to support early LPC bus probing] Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
zhichang.yuan [Mon, 13 Mar 2017 02:42:40 +0000 (10:42 +0800)]
UBUNTU: SAUCE: LPC: Support the device-tree LPC host on Hip06/Hip07
BugLink: http://bugs.launchpad.net/bugs/1677319
The low-pin-count(LPC) interface of Hip06/Hip07 accesses the peripherals in
I/O port addresses. This patch implements the LPC host controller driver which
perform the I/O operations on the underlying hardware.
We don't want to touch those existing peripherals' driver, such as ipmi-bt. So
this driver applies the indirect-IO introduced in the previous patch after
registering an indirect-IO node to the indirect-IO devices list which will be
searched in the I/O accessors.
As the I/O translations for LPC children depend on the host I/O registration,
we should ensure the host I/O registration is finished before all the LPC
children scanning. That is why an arch_init() hook was added in this patch.
Signed-off-by: zhichang.yuan <yuanzhichang@hisilicon.com> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com> Acked-by: Rob Herring <robh@kernel.org> #dts part
(v7 submission)
Reference: https://www.spinics.net/lists/arm-kernel/msg568096.html
[dannf: Applied from zhichang to fix probing issue w/o relying on ACPI _DEP] Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
zhichang.yuan [Mon, 13 Mar 2017 02:42:39 +0000 (10:42 +0800)]
UBUNTU: SAUCE: OF: Add missing I/O range exception for indirect-IO devices
BugLink: http://bugs.launchpad.net/bugs/1677319
There are some special ISA/LPC devices that work on a specific I/O range where
it is not correct to specify a 'ranges' property in DTS parent node as cpu
addresses translated from DTS node are only for memory space on some
architectures, such as Arm64. Without the parent 'ranges' property, current
of_translate_address() return an error.
Here we add special handlings for this case.
During the OF address translation, some checkings will be perfromed to
identify whether the device node is registered as indirect-IO. If yes, the I/O
translation will be done in a different way from that one of PCI MMIO.
In this way, the I/O 'reg' property of the special ISA/LPC devices will be
parsed correctly.
zhichang.yuan [Mon, 13 Mar 2017 02:42:37 +0000 (10:42 +0800)]
UBUNTU: SAUCE: LIBIO: Introduce a generic PIO mapping method
BugLink: http://bugs.launchpad.net/bugs/1677319
In commit 41f8bba7f55(of/pci: Add pci_register_io_range() and
pci_pio_to_address()), a new I/O space management was supported. With that
driver, the I/O ranges configured for PCI/PCIE hosts on some architectures can
be mapped to logical PIO, converted easily between CPU address and the
corresponding logicial PIO. Based on this, PCI I/O devices can be accessed in a
memory read/write way through the unified in/out accessors.
But on some archs/platforms, there are bus hosts which access I/O peripherals
with host-local I/O port addresses rather than memory addresses after
memory-mapped.
To support those devices, a more generic I/O mapping method is introduced here.
Through this patch, both the CPU addresses and the host-local port can be
mapped into logical PIO, then all the I/O accesses to either PCI MMIO devices or
host-local I/O peripherals can be unified into the existing I/O accessors
defined asm-generic/io.h and be redirected to the right device-specific hooks
based on the input logical PIO.
Peter Hurley [Thu, 16 Mar 2017 03:08:26 +0000 (14:08 +1100)]
UBUNTU: SAUCE: tty: Fix ldisc crash on reopened tty
BugLink: http://bugs.launchpad.net/bugs/1674325
If the tty has been hungup, the ldisc instance may have been destroyed.
Continued input to the tty will be ignored as long as the ldisc instance
is not visible to the flush_to_ldisc kworker. However, when the tty
is reopened and a new ldisc instance is created, the flush_to_ldisc
kworker can obtain an ldisc reference before the new ldisc is
completely initialized. This will likely crash:
Colin Ian King [Fri, 12 May 2017 14:49:53 +0000 (15:49 +0100)]
UBUNTU: SAUCE: exec: ensure file system accounting in check_unsafe_exec is correct
BugLink: http://bugs.launchpad.net/bugs/1672819
There are two very race windows that need to be taken into consideration
when check_unsafe_exec performs the file system accounting comparing the
number of fs->users against the number threads that share the same fs.
The first race can occur when a pthread creates a new pthread and the
the fs->users count is incremented before the new pthread is associated with
the pthread performing the exec. When this occurs, the pthread performing
the exec has flags with bit PF_FORKNOEXEC set.
The second race can occur when a pthread is terminating and the fs->users
count has been decremented by the pthread is still associated with the
pthread that is performing the exec. When this occurs, the pthread
peforming the exec has flags with bit PF_EXITING set.
This fix keeps track of any pthreads that may be in the race window
(when PF_FORKNOEXEC or PF_EXITING) are set and if the fs count does
not match the expected count we retry the count as we may have hit
this small race windows. Tests on an 8 thread server with the
reproducer (see below) show that this retry occurs rarely, so the
overhead of the retry is very small.
Below is a reproducer of the race condition.
The bug manifests itself because the current check_unsafe_exec
hits this race and indicates it is not a safe exec, and the
exec'd suid program fails to setuid.
$ cat Makefile
ALL=a b
all: $(ALL)
a: LDFLAGS=-pthread
b: b.c
$(CC) b.c -o b
sudo chown root:root b
sudo chmod u+s b
test:
for I in $$(seq 1000); do echo $I; ./a ; done
Seth Forshee [Fri, 12 May 2017 20:29:18 +0000 (15:29 -0500)]
UBUNTU: SAUCE: Fix module signing exclusion in package builds
BugLink: http://bugs.launchpad.net/bugs/1690908
The current module signing exclusion implementation suffers from
two problems. First, it looks for the signed-inclusion file
relative to the path where make is executed and thus doesn't work
if the source and build directories are different. Second, the
signed-inclusion file lists only the module name, but the strings
searched for in the file include the path (and the path to the
module install location at that).
Fix these problems by updating scripts/Makefile.modinst to look
for signed-inclusion relative to the path of the source tree and
to use only the module name when matching against the contents of
that file.
Jay Vosburgh [Wed, 11 Nov 2015 13:04:50 +0000 (13:04 +0000)]
UBUNTU: SAUCE: fan: add VXLAN implementation
Generify the fan mapping support and utilise that to implement fan
mappings over vxlan transport.
Expose the existance of this functionality (when the module is loaded)
via an additional sysctl marker.
Signed-off-by: Jay Vosburgh <jay.vosburgh@canonical.com>
[apw@canonical.com: added feature marker for fan over vxlan.] Signed-off-by: Andy Whitcroft <apw@canonical.com>
Conflicts:
drivers/net/vxlan.c
include/uapi/linux/if_link.h
net/ipv4/ipip.c
Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Switch to a single tunnel for all mappings, this removes the limitations
on how many mappings each tunnel can handle, and therefore how many Fan
slices each local address may hold.
NOTE: This introduces a new kernel netlink interface which needs updated
iproute2 support.
BugLink: http://bugs.launchpad.net/bugs/1470091 Signed-off-by: Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
[saf: Fix conflicts during rebase to 4.12] Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Conflicts:
include/uapi/linux/if_tunnel.h
net/ipv4/ipip.c
Colin Ian King [Tue, 2 May 2017 14:32:47 +0000 (15:32 +0100)]
UBUNTU: SAUCE: (noup) Update spl to 0.6.5.9-1ubuntu1, zfs to 0.6.5.9-5ubuntu5
Add upstream SPL compat patches from upstream to build with 4.11 kernel:
- 8d5feecacfdcca Linux 4.11 compat: set_task_state() removed
- 94b1ab2ae01e9e Linux 4.11 compat: vfs_getattr() takes 4 args
- 9a054d54fb6772 Linux 4.11 compat: add linux/sched/signal.h
- bf8abea4dade11 Linux 4.11 compat: remove stub for __put_task_struct
Add upstream ZFS compat patches from upstream to build with 4.11 kernel:
- a3478c07475261 Linux 4.11 compat: iops.getattr and friends
- 4859fe796c5b03 Linux 4.11 compat: avoid refcount_t name conflict
Tested and verified against the Ubuntu ZFS autotest regression tests
Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: SAUCE: (namespace) block_dev: Forbid unprivileged mounting when device is opened for writing
For unprivileged mounts to be safe the user must not be able to
make changes to the backing store while it is mounted. This patch
takes a step towards preventing this by refusing to mount in a
user namepspace if the block device is open for writing and
refusing attempts to open the block device for writing by non-
root while it is mounted in a user namespace.
To prevent this from happening we use i_writecount in the inodes
of the bdev filesystem similarly to how it is used for regular
files. Whenever the device is opened for writing i_writecount
is checked; if it is negative the open returns -EBUSY, otherwise
i_writecount is incremented. On mount, a positive i_writecount
results in mount_bdev returning -EBUSY, otherwise i_writecount
is decremented. Opens by root and mounts from init_user_ns do not
check nor modify i_writecount.
Seth Forshee [Tue, 9 Feb 2016 19:26:34 +0000 (13:26 -0600)]
UBUNTU: SAUCE: (namespace) ext4: Add module parameter to enable user namespace mounts
This is still an experimental feature, so disable it by default
and allow it only when the system administrator supplies the
userns_mounts=true module parameter.
Seth Forshee [Thu, 15 Dec 2016 17:03:08 +0000 (11:03 -0600)]
UBUNTU: SAUCE: (namespace) evm: Don't update hmacs in user ns mounts
The kernel should not calculate new hmacs for mounts done by
non-root users. Update evm_calc_hmac_or_hash() to refuse to
calculate new hmacs for mounts for non-init user namespaces.
Seth Forshee [Sat, 18 Oct 2014 11:02:09 +0000 (13:02 +0200)]
UBUNTU: SAUCE: (namespace) ext4: Add support for unprivileged mounts from user namespaces
Support unprivileged mounting of ext4 volumes from user
namespaces. This requires the following changes:
- Perform all uid, gid, and projid conversions to/from disk
relative to s_user_ns. In many cases this will already be
handled by the vfs helper functions. This also requires
updates to handle cases where ids may not map into s_user_ns.
A new helper, projid_valid_eq(), is added to help with this.
- Update most capability checks to check for capabilities in
s_user_ns rather than init_user_ns. These mostly reflect
changes to the filesystem that a user in s_user_ns could
already make externally by virtue of having write access to
the backing device.
- Restrict unsafe options in either the mount options or the
ext4 superblock. Currently the only concerning option is
errors=panic, and this is made to require CAP_SYS_ADMIN in
init_user_ns.
- Verify that unprivileged users have the required access to the
journal device at the path passed via the journal_path mount
option.
Note that for the journal_path and the journal_dev mount
options, and for external journal devices specified in the
ext4 superblock, devcgroup restrictions will be enforced by
__blkdev_get(), (via blkdev_get_by_dev()), ensuring that the
user has been granted appropriate access to the block device.
- Set the FS_USERNS_MOUNT flag on the filesystem types supported
by ext4.
sysfs attributes for ext4 mounts remain writable only by real
root.
Seth Forshee [Thu, 2 Oct 2014 20:34:45 +0000 (15:34 -0500)]
UBUNTU: SAUCE: (namespace) fuse: Restrict allow_other to the superblock's namespace or a descendant
Unprivileged users are normally restricted from mounting with the
allow_other option by system policy, but this could be bypassed
for a mount done with user namespace root permissions. In such
cases allow_other should not allow users outside the userns
to access the mount as doing so would give the unprivileged user
the ability to manipulate processes it would otherwise be unable
to manipulate. Restrict allow_other to apply to users in the same
userns used at mount or a descendant of that namespace. Also
export current_in_userns() for use by fuse when built as a
module.
Seth Forshee [Thu, 26 Jun 2014 16:58:11 +0000 (11:58 -0500)]
UBUNTU: SAUCE: (namespace) fuse: Support fuse filesystems outside of init_user_ns
In order to support mounts from namespaces other than
init_user_ns, fuse must translate uids and gids to/from the
userns of the process servicing requests on /dev/fuse. This
patch does that, with a couple of restrictions on the namespace:
- The userns for the fuse connection is fixed to the namespace
from which /dev/fuse is opened.
- The namespace must be the same as s_user_ns.
These restrictions simplify the implementation by avoiding the
need to pass around userns references and by allowing fuse to
rely on the checks in inode_change_ok for ownership changes.
Either restriction could be relaxed in the future if needed.
For cuse the namespace used for the connection is also simply
current_user_ns() at the time /dev/cuse is opened.
Seth Forshee [Sun, 15 Feb 2015 20:35:35 +0000 (14:35 -0600)]
UBUNTU: SAUCE: (namespace) fs: Allow CAP_SYS_ADMIN in s_user_ns to freeze and thaw filesystems
The user in control of a super block should be allowed to freeze
and thaw it. Relax the restrictions on the FIFREEZE and FITHAW
ioctls to require CAP_SYS_ADMIN in s_user_ns.
UBUNTU: SAUCE: (namespace) capabilities: Allow privileged user in s_user_ns to set security.* xattrs
A privileged user in s_user_ns will generally have the ability to
manipulate the backing store and insert security.* xattrs into
the filesystem directly. Therefore the kernel must be prepared to
handle these xattrs from unprivileged mounts, and it makes little
sense for commoncap to prevent writing these xattrs to the
filesystem. The capability and LSM code have already been updated
to appropriately handle xattrs from unprivileged mounts, so it
is safe to loosen this restriction on setting xattrs.
The exception to this logic is that writing xattrs to a mounted
filesystem may also cause the LSM inode_post_setxattr or
inode_setsecurity callbacks to be invoked. SELinux will deny the
xattr update by virtue of applying mountpoint labeling to
unprivileged userns mounts, and Smack will deny the writes for
any user without global CAP_MAC_ADMIN, so loosening the
capability check in commoncap is safe in this respect as well.
UBUNTU: SAUCE: (namespace) fs: Allow superblock owner to access do_remount_sb()
Superblock level remounts are currently restricted to global
CAP_SYS_ADMIN, as is the path for changing the root mount to
read only on umount. Loosen both of these permission checks to
also allow CAP_SYS_ADMIN in any namespace which is privileged
towards the userns which originally mounted the filesystem.
projects / mirror_ubuntu-artful-kernel.git / log