Tim Gardner [Thu, 16 Jun 2016 06:41:35 +0000 (09:41 +0300)]
UBUNTU: SAUCE: UEFI: Add secure boot and MOK SB State disabled sysctl
BugLink: http://bugs.launchpad.net/bugs/1593075
This is a better method for detecting the state of secure boot and
the MOKSBState override, as opposed to grepping status from the kernel log.
Both variables return 0 or 1. If secure_boot==0 then signed module
enforcement is not enabled. Likewise, if moksbstate_disabled==1 then
signed module enforcement is not enabled. The only conditions uder which
signed module enforcement is enabled is when secure_boot==1 and
moksbstate_disabled==0.
Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Tim Gardner [Mon, 18 Apr 2016 15:22:31 +0000 (09:22 -0600)]
UBUNTU: SAUCE: UEFI: Display MOKSBState when disabled
BugLink: http://bugs.launchpad.net/bugs/1571691
It would be much simpler if one could pass MOKSBState via a global variable,
but the the EFI bits appear to be managed and linked a bit differently then
a normal text section. Hence the shennanigans with boot_params.secure_boot.
Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Andy Whitcroft <andy.whitcroft@canonical.com> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Dave Young [Fri, 24 Jun 2016 13:34:14 +0000 (07:34 -0600)]
UBUNTU: SAUCE: UEFI: kexec/uefi: 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: Tim Gardner <tim.gardner@canonical.com>
Josh Boyer [Thu, 3 Oct 2013 14:14:23 +0000 (10:14 -0400)]
UBUNTU: SAUCE: UEFI: MODSIGN: Support not importing certs from db
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 not import things from the db
variable.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Josh Boyer [Fri, 26 Oct 2012 16:42:16 +0000 (12:42 -0400)]
UBUNTU: SAUCE: UEFI: 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.
In the opposite case, Secure Boot 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.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Dave Howells [Tue, 23 Oct 2012 13:36:28 +0000 (09:36 -0400)]
UBUNTU: SAUCE: UEFI: Add an EFI signature blob parser and key loader.
X.509 certificates are loaded into the specified keyring as asymmetric type
keys.
[labbott@fedoraproject.org: Drop KEY_ALLOC_TRUSTED] Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Josh Boyer [Fri, 20 Jun 2014 12:53:24 +0000 (08:53 -0400)]
UBUNTU: SAUCE: UEFI: hibernate: Disable in a signed modules environment
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 in
a secure modules environment.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Josh Boyer [Wed, 6 Feb 2013 00:25:05 +0000 (19:25 -0500)]
UBUNTU: SAUCE: UEFI: efi: Disable secure boot if shim is in insecure mode
A user can manually tell the shim boot loader to disable validation of
images it loads. When a user does this, it creates a UEFI variable called
MokSBState that does not have the runtime attribute set. Given that the
user explicitly disabled validation, we can honor that and not enable
secure boot mode if that variable is set.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Matthew Garrett [Fri, 9 Aug 2013 22:36:30 +0000 (18:36 -0400)]
UBUNTU: SAUCE: UEFI: Add option to automatically enforce module signatures when 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 enforces this automatically when enabled.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Conflicts:
arch/x86/boot/compressed/eboot.c
Matthew Garrett [Fri, 8 Feb 2013 19:12:13 +0000 (11:12 -0800)]
UBUNTU: SAUCE: UEFI: x86: Restrict MSR access when module loading is restricted
Writing to MSRs should not be allowed if module loading is restricted,
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: Tim Gardner <tim.gardner@canonical.com>
Matthew Garrett [Fri, 9 Aug 2013 07:33:56 +0000 (03:33 -0400)]
UBUNTU: SAUCE: UEFI: kexec: Disable at runtime if the kernel enforces module loading restrictions
kexec permits the loading and execution of arbitrary code in ring 0, which
is something that module signing enforcement is meant to prevent. It makes
sense to disable kexec in this situation.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Josh Boyer [Mon, 25 Jun 2012 23:57:30 +0000 (19:57 -0400)]
UBUNTU: SAUCE: UEFI: acpi: Ignore acpi_rsdp kernel parameter when module loading is restricted
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. Disable it in that case.
Signed-off-by: Josh Boyer <jwboyer@redhat.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Matthew Garrett [Fri, 9 Mar 2012 14:28:15 +0000 (09:28 -0500)]
UBUNTU: SAUCE: UEFI: Restrict /dev/mem and /dev/kmem when module loading is restricted
Allowing users to write to address space makes it possible for the kernel
to be subverted, avoiding module loading restrictions. Prevent this when
any restrictions have been imposed on loading modules.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Matthew Garrett [Fri, 9 Mar 2012 13:46:50 +0000 (08:46 -0500)]
UBUNTU: SAUCE: UEFI: asus-wmi: Restrict debugfs interface when module loading is restricted
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 any of
these features are enabled.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Matthew Garrett [Fri, 9 Mar 2012 13:39:37 +0000 (08:39 -0500)]
UBUNTU: SAUCE: UEFI: ACPI: Limit access to custom_method
custom_method effectively allows arbitrary access to system memory, making
it possible for an attacker to circumvent restrictions on module loading.
Disable it if any such restrictions have been enabled.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Matthew Garrett [Thu, 8 Mar 2012 15:35:59 +0000 (10:35 -0500)]
UBUNTU: SAUCE: UEFI: x86: Lock down IO port access when module security is enabled
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.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Matthew Garrett [Thu, 8 Mar 2012 15:10:38 +0000 (10:10 -0500)]
UBUNTU: SAUCE: UEFI: PCI: Lock down BAR access when module security is enabled
Any hardware that can potentially generate DMA has to be locked down from
userspace 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: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Conflicts:
drivers/pci/syscall.c
Matthew Garrett [Fri, 9 Aug 2013 21:58:15 +0000 (17:58 -0400)]
UBUNTU: SAUCE: UEFI: Add secure_modules() call
Provide a single call to allow kernel code to determine whether the system
has been configured to either disable module loading entirely or to load
only modules signed with a trusted key.
Bugzilla: N/A
Upstream-status: Fedora mustard. Replaced by securelevels, but that was nak'd
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Steve Beattie [Tue, 10 May 2016 11:44:04 +0000 (12:44 +0100)]
UBUNTU: SAUCE: (no-up) disable -pie when gcc has it enabled by default
In Ubuntu 16.10, gcc's defaults have been set to build Position
Independent Executables (PIE) on amd64 and ppc64le (gcc was configured
this way for s390x in Ubuntu 16.04 LTS). This breaks the kernel build on
amd64. The following patch disables pie for x86 builds (though not yet
verified to work with gcc configured to build PIE by default i386 --
we're not planning to enable it for that architecture).
The intent is for this patch to go upstream after expanding it to
additional architectures where needed, but I wanted to ensure that
we could build 16.10 kernels first. I've successfully built kernels
and booted them with this patch applied using the 16.10 compiler.
Patch is against yakkety.git, but also applies with minor movement
(no fuzz) against current linus.git.
Signed-off-by: Steve Beattie <steve.beattie@canonical.com>
[apw@canonical.com: shifted up so works in arch/<arch/Makefile.] BugLink: http://bugs.launchpad.net/bugs/1574982 Signed-off-by: Andy Whitcroft <apw@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com>
The kernel boot parameter 'nr_cpus=' allows one to specify number of
possible cpus in the system. In the normal scenario the first cpu (cpu0)
that shows up is the boot cpu and hence it gets covered under nr_cpus
limit.
But this assumption will be broken in kdump scenario where kdump kenrel
after a crash can boot up on an non-zero boot cpu. The paca structure
allocation depends on value of nr_cpus and is indexed using logical cpu
ids. This definetly will be an issue if boot cpu id > nr_cpus
This patch modifies allocate_pacas() and smp_setup_cpu_maps() to
accommodate boot cpu for the case where boot_cpuid > nr_cpu_ids.
This change would help to reduce the memory reservation requirement for
kdump on ppc64.
BugLink: http://bugs.launchpad.net/bugs/1558828
In case of ARCH_THUNDER, there is a need to allocate the GICv3 ITS table
which is bigger than the allowed max order. So we are forcing it only in
case of 4KB page size.
Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com> Signed-off-by: Robert Richter <rrichter@cavium.com>
[ dannf: Depend on ARM64_4K_PAGES instead of !ARM64_64K_PAGES now that
16K pages are available ] Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mehmet Kayaalp [Thu, 10 Mar 2016 21:22:13 +0000 (16:22 -0500)]
UBUNTU: SAUCE: (noup) KEYS: Support for inserting a certificate into x86 bzImage
BugLink: http://bugs.launchpad.net/bugs/1558553
The config option SYSTEM_EXTRA_CERTIFICATE reserves space in vmlinux file,
which is compressed to create the self-extracting bzImage. This patch adds the
capability of extracting the vmlinux, inserting the certificate, and
repackaging the result into a bzImage.
It only works if the resulting compressed vmlinux is smaller than the original.
Otherwise re-linking would be required. To make the reserved space allocate
actual space in bzImage, a null key is inserted into vmlinux before creating
the bzImage:
make vmlinux
scripts/insert-sys-cert -b vmlinux -c /dev/null
make bzImage
After null key insertion, the script populates the rest of the reserved space
with random bytes, which have poor compression. After receiving a bzImage that
is created this way, actual certificate can be inserted into the bzImage:
Seth Forshee [Tue, 19 Jan 2016 16:20:43 +0000 (10:20 -0600)]
UBUNTU: SAUCE: cred: Add clone_cred() interface
This interface returns a new set of credentials which is an exact
copy of another set. Also update prepare_kernel_cred() to use
this function instead of duplicating code.
Andy Whitcroft [Fri, 27 Nov 2015 17:38:30 +0000 (17:38 +0000)]
UBUNTU: SAUCE: (no-up) add compat_uts_machine= kernel command line override
We wish to use the arm64 buildds to build armhf binaries in 32bit chroots.
To make this work we need uname to return armv7l machine type. To achieve
this add a kernel command line override for the 32bit machine type.
Add compat_uts_machine=<type> to allow the LINUX32 personality to return
that type for uname.
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>
Conflicts:
include/net/ip_tunnels.h
Tetsuo Handa [Sat, 29 Mar 2014 06:39:24 +0000 (15:39 +0900)]
UBUNTU: SAUCE: kthread: Do not leave kthread_create() immediately upon SIGKILL.
Commit 786235ee "kthread: make kthread_create() killable" changed to
leave kthread_create() as soon as receiving SIGKILL. But this change
caused boot failures if systemd-udevd worker process received SIGKILL
due to systemd's hardcoded 30 seconds timeout while loading fusion
driver using finit_module() [1].
Linux kernel people think that the systemd's hardcoded timeout is a
systemd bug. But systemd people think that loading of kernel module
needs more than 30 seconds is a kernel module's bug.
Although Linux kernel people are expecting fusion driver module not
to take more than 30 seconds, it will definitely not in time for
trusty kernel. Also, nobody can prove that fusion driver module is
the only case which is affected by commit 786235ee.
Therefore, this patch changes kthread_create() to wait for up to 10
seconds after receiving SIGKILL, unless chosen by the OOM killer,
in order to give the kthreadd a chance to complete the request.
The side effect of this patch is that current thread's response to
SIGKILL is delayed for a bit (likely less than a second, unlikely
10 seconds).
Andy Whitcroft [Wed, 16 Apr 2014 18:40:57 +0000 (19:40 +0100)]
UBUNTU: SAUCE: vt -- maintain bootloader screen mode and content until vt switch
Introduce a new VT mode KD_TRANSPARENT which endevours to leave the current
content of the framebuffer untouched. This allows the bootloader to insert
a graphical splash and have the kernel maintain it until the OS splash
can take over. When we finally switch away (either through programs like
plymouth or manually) the content is lost and the VT reverts to text mode.
BugLink: http://bugs.launchpad.net/bugs/1210848
On an ASUSTek G60JX laptop, the intel_ips driver spams the log with a warning message: "ME failed to update for more than 1s, likely hung". This ME doesn't support the feature, so requesting it be blacklisted for now.
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Nick Jenkins <tech.crew.jenkins@gmail.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
UBUNTU: SAUCE: (no-up) trace: add trace events for open(), exec() and uselib() (for v3.7+)
BugLink: http://bugs.launchpad.net/bugs/462111
This patch uses TRACE_EVENT to add tracepoints for the open(),
exec() and uselib() syscalls so that ureadahead can cheaply trace
the boot sequence to determine what to read to speed up the next.
It's not upstream because it will need to be rebased onto the syscall
trace events whenever that gets merged, and is a stop-gap.
[apw@canonical.com: updated for v3.7 and later.]
[apw@canonical.com: updated for v3.19 and later.] BugLink: http://bugs.launchpad.net/bugs/1085766 Signed-off-by: Scott James Remnant <scott@ubuntu.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Conflicts:
fs/open.c
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Xiangliang Yu [Thu, 7 Mar 2013 14:29:16 +0000 (14:29 +0000)]
UBUNTU: SAUCE: (no-up) PCI: fix system hang issue of Marvell SATA host controller
BugLink: http://bugs.launchpad.net/bugs/1159863
Hassle someone if this patch hasn't been removed by 13.10.
See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1159863/comments/2
Fix system hang issue: if first accessed resource file of BAR0 ~
BAR4, system will hang after executing lspci command
Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Instead of SEMI_MT, present a full mt interface with simulated contact
positions for >=3 fingers. Enables e.g. multi-finger tap and drag for
old userspace applications which only count the contact positions.
Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1084192
Reverting this in the kernel as opposed to adding a sysctl
to the procps package guarentees that this regression will be
propagated to the Raring LTS kernel.
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
The Myricom GB driver firmware is no longer in use. Furthermore,
CONFIG_MYRI_SBUS is no longer defined.
Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Ben Hutchings <ben@decadent.org.uk> Cc: James Bottomley <JBottomley@Parallels.com> Cc: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Andy Whitcroft [Tue, 3 Apr 2012 10:42:41 +0000 (11:42 +0100)]
UBUNTU: SAUCE: (no-up) elide some ioctl warnings which are known benign
BugLink: http://bugs.launchpad.net/bugs/972355
We have been seeing increasing reports of scarey ioctl messages in
dmesg, such as the below often in bulk:
mdadm: sending ioctl 1261 to a partition!
mdadm: sending ioctl 800c0910 to a partition!
Looking at the upstream discussions these are all benign and can be safely
suppressed. This patch is based on some discussions at the link below,
on some work SUSE did in this area. This is not suitable for upstreaming
as we need some refactoring to fix the 32bit compat ioctl mess.
Chase Douglas [Fri, 24 Feb 2012 23:05:50 +0000 (15:05 -0800)]
UBUNTU: SAUCE: (no-up) Input: synaptics - add second variant of two-button clickpad
This is necessary for clickpad detection of Synaptics trackpads in Dell
Mini 10 series of laptops.
no-up comments: Keep both, so long as they continue to apply cleanly.
The patches apply only to a couple of old Dell minis, and Dell has said
they don't intend to use those touchpads again. Upstreaming these
patches stalled due to lack of information/response, and continuing to
pursue it probably isn't worth the effort, so they can be marked no-up.
There's no harm in keeping the patches, but if they become a problem
they can be dropped.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Andy Whitcroft [Fri, 3 Dec 2010 09:51:33 +0000 (09:51 +0000)]
UBUNTU: SAUCE: (no-up) add support for installed header files to ubuntu directory
BugLink: http://bugs.launchpad.net/bugs/684666
We need the aufs headers in the linux-libc-headers, add support for
including files from the ubuntu include directory.
projects / mirror_ubuntu-zesty-kernel.git / log