Hi Ard,
On 10/22/2017 04:14 PM, Ard Biesheuvel wrote:
> ARM shares its EFI stub implementation with arm64, which has some
> special handling in the virtual remapping code to
> a) make sure that we can map everything even if the OS executes
>with 64k page size, and
> b) make sure that adjacent
On Thu, 2017-10-19 at 15:51 +0100, David Howells wrote:
> From: Chun-Yi Lee
>
> When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image
> through kexec_file systemcall if securelevel has been set.
The patch title and description needs to be updated to refer to
lockdown, not securelev
James Morris wrote:
> > + default:
> > + pr_info("Secure boot could not be determined\n");
>
> Perhaps make this pr_warning and include the unknown mode value?
Done.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a messa
James Morris wrote:
> I have to wonder, though, after everything is locked down, how easy will
> it be for new things to slip in which need to be included in the lockdown,
> but are not.
That's always a possibility, and short of reviewing every change, particularly
in the drivers, I'm not sure
j...@suse.com wrote:
> hm... patch 4 only prevents write_mem() but not read_mem().
> Or I missed anything?
Actually, yes, as it happens, patch 11 prevents you from even opening /dev/mem
and /dev/kmem by locking down open of /dev/port. So I've moved this bit to
patch 4, simplified and posted a ne
Alan Cox wrote:
> There are a load of standard tools that use this so I think you are going
> to need a whitelist. Can you at least log *which* MSR in the failing case
> so a whitelist can be built over time ?
Will the attached change work for you?
David
---
diff --git a/arch/x86/kernel/msr.c b
I think I should replace this patch with the attached. This will prevent
/dev/mem, /dev/kmem and /dev/port from being *opened*, and thereby preventing
read, write and ioctl.
David
---
commit e68daa2256986932b9a7d6709cf9e24b30d93583
Author: Matthew Garrett
Date: Wed May 24 14:56:02 2017 +0100
Commit
e69176d68d26 ef/libstub/arm/arm64: Randomize the base of the UEFI rt services
region
implemented randomization of the virtual mapping that the OS chooses for
the UEFI runtime services. This was motivated by the fact that UEFI usually
does not bother to specify any permission restriction