lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 11 Jan 2018 12:51:07 +0000
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Daniel Kiper <daniel.kiper@...cle.com>,
        Ingo Molnar <mingo@...hat.com>
Cc:     linux-efi@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        xen-devel <xen-devel@...ts.xenproject.org>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        "H. Peter Anvin" <hpa@...or.com>, Juergen Gross <jgross@...e.com>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 0/4] x86/xen/efi: Initialize UEFI secure boot state during
 dom0 boot

On 9 January 2018 at 14:22, Daniel Kiper <daniel.kiper@...cle.com> wrote:
> Hi,
>
> Initialize UEFI secure boot state during dom0 boot. Otherwise the kernel
> may not even know that it runs on secure boot enabled platform.
>

Hi Daniel,

I must say, I am not too thrilled with the approach you have chosen
here. #including .c files in other .c files, and using #defines to
override C functions or other stub functionality is rather fragile. In
particular, it means we have to start caring about not breaking
Xen/x86 code when making modifications to the EFI stub, and that code
is already difficult enough to maintain, given that it is shared
between ARM, arm64 and x86, and runs either from the decompressor or
the kernel proper (arm64) but in the context of the UEFI firmware.
None of the stub code currently runs in ordinary kernel context.

So please, could you try to find another way to do this?

Thanks,
Ard.


>
>  arch/x86/xen/Makefile                          |    4 +++-
>  arch/x86/xen/efi.c                             |   14 +++++++++++++
>  drivers/firmware/efi/libstub/secureboot-core.c |   77 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  drivers/firmware/efi/libstub/secureboot.c      |   66 +++++------------------------------------------------------
>  4 files changed, 99 insertions(+), 62 deletions(-)
>
> Daniel Kiper (4):
>       efi/stub: Extract efi_get_secureboot() to separate file
>       x86/xen/efi: Initialize boot_params.secure_boot in xen_efi_init()
>       efi: Tweak efi_get_secureboot() and its data section assignment
>       efi: Rename efi_get_secureboot() to __efi_get_secureboot() and make it static
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ