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 <email address hidden>
Signed-off-by: Andy Whitcroft <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>
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 <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>
Signed-off-by: Andy Whitcroft <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>
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 <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>
Signed-off-by: Andy Whitcroft <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>
Two kernfs-based filesystems are currently mountable from
non-init user namespaces, sysfs and cgroupfs. Both of these have
use cases which end up attempting to mount the same superblock
from different user namespaces, but sget() no longer allows this
so these mount attempts will fail.
Update kernfs_test_super() to return false whenever s_user_ns is
not the current user namespace, resulting in a new super block
being allocated for these mounts. kernfs, sysfs, and cgroupfs are
all equipped to handle this situation.
(cherry picked from commit ee6825c80e870fff1a370c718ec77022ade0889b)
Signed-off-by: Stefan Bader <email address hidden>
Signed-off-by: Colin King <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>
Currently Xen uses default_cpu_present_to_apicid() which will always
report BAD_APICID for PV guests since x86_bios_cpu_apic_id is initialised
to that value and is never updated.
With commit 1f12e32f4cd5 ("x86/topology: Create logical package id"), this
op is now called by smp_init_package_map() when deciding whether to call
topology_update_package_map() which sets cpu_data(cpu).logical_proc_id.
The latter (as topology_logical_package_id(cpu)) may be used, for example,
by cpu_to_rapl_pmu() as an array index. Since uninitialized
logical_package_id is set to -1, the index will become 64K which is
obviously problematic.
While RAPL code (and any other users of logical_package_id) should be
careful in their assumptions about id's validity, Xen's
cpu_present_to_apicid op should still provide value consistent with its
own xen_apic_read(APIC_ID).
Signed-off-by: Boris Ostrovsky <email address hidden>
Signed-off-by: Konrad Rzeszutek Wilk <email address hidden>
(cherry picked from commit ed6069be7204541c1da532ad8bbf892e34513552)
Signed-off-by: Stefan Bader <email address hidden>
Signed-off-by: Colin King <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>
