Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

On Tue, Dec 05, 2017 at 11:27:58AM +0100, Pavel Machek wrote: > Hi! > > > > Our ability to determine that userland hasn't been tampered with > > > depends on the kernel being trustworthy. If userland can upload > > > arbitrary firmware to DMA-capable devices then we can no longer trust > > > the

Re: [PATCH 4.4 05/27] x86/efi: Build our own page table structures

On Mon, 2017-12-04 at 16:59 +0100, Greg Kroah-Hartman wrote: > 4.4-stable review patch.  If anyone has any objections, please let me know. > > -- > > From: Matt Fleming > > commit 67a9108ed4313b85a9c53406d80dc1ae3f8c3e36 upstream. [...] It looks like

Re: [PATCH V2 1/2] efi: move ARM CPER code to new file

On 12/7/2017 2:38 PM, Ard Biesheuvel wrote: diff --git a/include/linux/cper.h b/include/linux/cper.h index 723e952..0a2d5c5 100644 --- a/include/linux/cper.h +++ b/include/linux/cper.h @@ -494,6 +494,13 @@ struct cper_sec_pcie { /* Reset to default packing */ #pragma pack() +static const

Re: [PATCH V2 1/2] efi: move ARM CPER code to new file

Hi Tyler, On 7 December 2017 at 19:25, Tyler Baicar wrote: > The ARM CPER code is currently mixed in with the other CPER code. Move it > to a new file to separate it from the rest of the CPER code. > > Signed-off-by: Tyler Baicar > --- >

[PATCH V2 0/2] CPER ARM error information parsing

Break out the ARM CPER code into a new file so it's separate from the main of the CPER code. Add parsing for the ARM error information value based on UEFI 2.7 spec tables 263-265. Tyler Baicar (2): efi: move ARM CPER code to new file efi: parse ARM error information value

[PATCH V2 1/2] efi: move ARM CPER code to new file

The ARM CPER code is currently mixed in with the other CPER code. Move it to a new file to separate it from the rest of the CPER code. Signed-off-by: Tyler Baicar --- drivers/firmware/efi/Kconfig| 5 ++ drivers/firmware/efi/Makefile | 1 +

[PATCH V2 2/2] efi: parse ARM error information value

ARM errors just print out the error information value, then the value needs to be manually decoded as per the UEFI spec. Add decoding of the ARM error information value so that the kernel logs capture all of the valid information at first glance. ARM error information value decoding is captured

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

> I am curious though, is the above notion of having hardware require signed > firmware an implication brought down by UEFI? If so do you have any pointers > to where this is stipulated? Or is it just a best practice we assume some > manufacturers are implementing? It's a mix of best practice and

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

On Tue, 5 Dec 2017 18:01:46 +0800 Gary Lin wrote: > The series of patches introduce Security Version to EFI stub. > > Security Version is a monotonically increasing number and designed to > prevent the user from loading an insecure kernel accidentally. The > bootloader maintains

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

* Gary Lin wrote: > On Thu, Dec 07, 2017 at 09:18:16AM +0100, Ingo Molnar wrote: > > > > * Gary Lin wrote: > > > > > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote: > > > > > > > > * Gary Lin wrote: > > > > > > > > > On Wed, Dec

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

On Thu, Dec 07, 2017 at 09:18:16AM +0100, Ingo Molnar wrote: > > * Gary Lin wrote: > > > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote: > > > > > > * Gary Lin wrote: > > > > > > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote: > > > >

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

* Gary Lin wrote: > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote: > > > > * Gary Lin wrote: > > > > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote: > > > > > > > > * Gary Lin wrote: > > > > > > > > > On Tue, Dec