Seth Forshee [Thu, 21 Jan 2016 17:52:04 +0000 (11:52 -0600)]
UBUNTU: SAUCE: overlayfs: Be more careful about copying up sxid files
When an overlayfs filesystem's lowerdir is on a nosuid filesystem
but the upperdir is not, it's possible to copy up an sxid file or
stick directory into upperdir without changing the mode by
opening the file rw in the overlayfs mount without writing to it.
This makes it possible to bypass the nosuid restriction on the
lowerdir mount.
It's a bad idea in general to let the mounter copy up a sxid file
if the mounter wouldn't have had permission to create the sxid
file in the first place. Therefore change ovl_set_xattr to
exclude these bits when initially setting the mode, then set the
full mode after setting the user for the inode. This allows copy
up for non-sxid files to work as before but causes copy up to
fail for the cases where the user could not have created the sxid
inode in upperdir.
Seth Forshee [Tue, 19 Jan 2016 19:12:02 +0000 (13:12 -0600)]
UBUNTU: SAUCE: overlayfs: Skip permission checking for trusted.overlayfs.* xattrs
The original mounter had CAP_SYS_ADMIN in the user namespace
where the mount happened, and the vfs has validated that the user
has permission to do the requested operation. This is sufficient
for allowing the kernel to write these specific xattrs, so we can
bypass the permission checks for these xattrs.
To support this, export __vfs_setxattr_noperm and add an similar
__vfs_removexattr_noperm which is also exported. Use these when
setting or removing trusted.overlayfs.* xattrs.
In the mark_source_chains function (net/ipv4/netfilter/ip_tables.c) it
is possible for a user-supplied ipt_entry structure to have a large
next_offset field. This field is not bounds checked prior to writing a
counter value at the supplied offset.
Problem is that xt_entry_foreach() macro stops iterating once e->next_offset
is out of bounds, assuming this is the last entry.
With malformed data thats not necessarily the case so we can
write outside of allocated area later as we might not have walked the
entire blob.
Fix this by simplifying mark_source_chains -- it already has to check
if nextoff is in range to catch invalid jumps, so just do the check
when we move to a next entry as well.
Also, check that the offset meets the xtables_entry alignment.
Reported-by: Ben Hawkes <hawkes@google.com> Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Chris J. Arges <chris.j.arges@canonical.com> Acked-by: Brad Figg <brad.figg@canonical.com> Signed-off-by: Brad Figg <brad.figg@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
UBUNTU: SAUCE: (no-up) ACPI: Disable Windows 8 compatibility for some Lenovo ThinkPads
The AML implementation for brightness control on several ThinkPads
contains a workaround to meet a Windows 8 requirement of 101 brightness
levels [1]. The implementation is flawed, as only 16 of the brighness
values reported by _BCL affect a change in brightness. _BCM silently
discards the rest of the values. Disabling Windows 8 compatibility on
these machines reverts them to the old behavior, making _BCL only report
the 16 brightness levels which actually work. Add a quirk to do this
along with a dmi callback to disable Win8 compatibility.
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>
Michael Cyr [Fri, 26 Aug 2016 19:06:45 +0000 (14:06 -0500)]
UBUNTU: SAUCE: Return TCMU-generated sense data to fabric module
BugLink: http://bugs.launchpad.net/bugs/1615665
If an error status is passed to target_complete_cmd, then by default it
queues the command to target_complete_failure_work, which will generate
Logical Unit Communication Failure sense data, overwriting any sense data
already set in the command. This means that any sense data returned by
TCMU does not get returned to the fabric module.
This change implements a transport_complete function for target-user which
will set the SCF_TRANSPORT_TASK_SENSE flag if we have valid sense data,
which will cause target_complete_cmd to queue the command to
target_complete_ok_work instead of target_complete_failure_work.
Signed-off-by: Michael Cyr <mikecyr@linux.vnet.ibm.com> Reviewed-by: Andy Grover <agrover@redhat.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Chen Yu [Fri, 19 Aug 2016 17:25:57 +0000 (10:25 -0700)]
UBUNTU: SAUCE: PCI: Workaround to enable poweroff on Mac Pro 11
BugLink: http://bugs.launchpad.net/bugs/1587714
People reported that they can not do a poweroff nor a
suspend to ram on their Mac Pro 11. After some investigations
it was found that, once the PCI bridge 0000:00:1c.0 reassigns its
mm windows to ([mem 0x7fa00000-0x7fbfffff] and
[mem 0x7fc00000-0x7fdfffff 64bit pref]), the region of ACPI
io resource 0x1804 becomes unaccessible immediately, where the
ACPI Sleep register is located, as a result neither poweroff(S5)
nor suspend to ram(S3) works.
As suggested by Bjorn, further testing shows that, there is an
unreported device may be (using) conflict with above aperture,
which brings unpredictable result such as the failure of accessing
the io port, which blocks the poweroff(S5). Besides if we reassign
the memory aperture to the other place, the poweroff works again.
As we do not find any resource declared in _CRS which contain above
memory aperture, and Mac OS does not use this pci bridge neither, we
choose a simple workaround to clear the hotplug flag(suggested by
Yinghai Lu), thus do not allocate any resource for this pci bridge,
and thereby no conflict anymore.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=103211 Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Rafael J. Wysocki <rafael@kernel.org> Cc: Lukas Wunner <lukas@wunner.de> Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Reference: https://patchwork.kernel.org/patch/9289777/ Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
UBUNTU: SAUCE: powerpc/pseries: Increase RMA size to 512MB.
BugLink: http://bugs.launchpad.net/bugs/1614309
When trying to boot large kernel and initrd images on large systems
(with hundreds of CPUs and Terabytes of memory), we sometimes run out
of memory for the flattened device tree (FDT).
Increase the memory allocated for the Real Mode Area (RMA) to 512MB to
allow more room for the FDT.
Ben Hutchings [Tue, 16 Aug 2016 16:27:00 +0000 (10:27 -0600)]
UBUNTU: SAUCE: security,perf: Allow further restriction of perf_event_open
https://lkml.org/lkml/2016/1/11/587
The GRKERNSEC_PERF_HARDEN feature extracted from grsecurity. Adds the
option to disable perf_event_open() entirely for unprivileged users.
This standalone version doesn't include making the variable read-only
(or renaming it).
When kernel.perf_event_open is set to 3 (or greater), disallow all
access to performance events by users without CAP_SYS_ADMIN.
Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
makes this value the default.
This is based on a similar feature in grsecurity
(CONFIG_GRKERNSEC_PERF_HARDEN). This version doesn't include making
the variable read-only. It also allows enabling further restriction
at run-time regardless of whether the default is changed.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
UBUNTU: SAUCE: Clear Linux: reduce e1000e boot time by tightening sleep ranges
The e1000e driver is a great user of the usleep_range() API,
and has any nice ranges that in principle help power management.
However the ranges that are used only during system startup are
very long (and can add easily 100 msec to the boot time) while
the power savings of such long ranges is irrelevant due to the
one-off, boot only, nature of these functions.
This patch shrinks some of the longest ranges to be shorter
(while still using a power friendly 1 msec range); this saves
100msec+ of boot time on my BDW NUCs
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Arjan van de Ven [Tue, 23 Jun 2015 06:26:52 +0000 (01:26 -0500)]
UBUNTU: SAUCE: Clear Linux: i8042: decrease debug message level to info
Author: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Miguel Bernal Marin <miguel.bernal.marin@linux.intel.com> Signed-off-by: Jose Carlos Venegas Munoz <jos.c.venegas.munoz@intel.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Josh Boyer [Fri, 26 Oct 2012 16:36:24 +0000 (12:36 -0400)]
UBUNTU: SAUCE: UEFI: KEYS: Add a system blacklist keyring
This adds an additional keyring that is used to store certificates that
are blacklisted. This keyring is searched first when loading signed modules
and if the module's certificate is found, it will refuse to load. This is
useful in cases where third party certificates are used for module signing.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
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.
projects / mirror_ubuntu-zesty-kernel.git / log