linux-kernel - Re: [PATCH v5 0/3] x86: make rsdp address accessible via boot params

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:   Wed, 10 Oct 2018 08:39:42 +0200
From:   Juergen Gross <jgross@...e.com>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     linux-kernel@...r.kernel.org, xen-devel@...ts.xenproject.org,
        x86@...nel.org, linux-doc@...r.kernel.org, tglx@...utronix.de,
        mingo@...hat.com, bp@...en8.de, hpa@...or.com, corbet@....net,
        boris.ostrovsky@...cle.com,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH v5 0/3] x86: make rsdp address accessible via boot params

On 10/10/2018 08:23, Ingo Molnar wrote:
> 
> * Juergen Gross <jgross@...e.com> wrote:
> 
>> In the non-EFI boot path the ACPI RSDP table is currently found via
>> either EBDA or by searching through low memory for the RSDP magic.
>> This requires the RSDP to be located in the first 1MB of physical
>> memory. Xen PVH guests, however, get the RSDP address via the start of
>> day information block.
>>
>> In order to support an arbitrary RSDP address this patch series adds
>> the physical address of the RSDP to the boot params structure filled
>> by the boot loader.
>>
>> Juergen Gross (3):
>>   x86/xen: fix boot loader version reported for pvh guests
>>   x86/boot: add acpi rsdp address to setup_header
>>   x86/acpi: take rsdp address for boot params if available
>>
>>  Documentation/x86/boot.txt            | 32 +++++++++++++++++++++++++++++++-
>>  arch/x86/boot/header.S                |  6 +++++-
>>  arch/x86/include/asm/acpi.h           |  7 +++++++
>>  arch/x86/include/asm/x86_init.h       |  2 ++
>>  arch/x86/include/uapi/asm/bootparam.h |  4 ++++
>>  arch/x86/kernel/acpi/boot.c           |  6 ++++++
>>  arch/x86/kernel/head32.c              |  1 +
>>  arch/x86/kernel/head64.c              |  2 ++
>>  arch/x86/kernel/setup.c               | 17 +++++++++++++++++
>>  arch/x86/kernel/x86_init.c            |  3 +--
>>  arch/x86/xen/enlighten_pvh.c          |  2 +-
>>  11 files changed, 77 insertions(+), 5 deletions(-)
> 
> I have some vague memories of an older variant of this feature breaking stuff and resulting in 
> me involuntarily participating in an overly long bisection session.
> 
> If that memory is right and I'm not confusing it with some other patchset, could you please 
> provide some more context, what that old problem was, how it was resolved, whether it is 
> expected to trigger on any machines, etc., to create some warm fuzzy feelings about this 
> patch-set and to reduce my bisectofobia? ;-)

You can just dive into the discussion we had back in February:

https://lore.kernel.org/lkml/20180213163244.j2zuxyhs4kbfhwgj@gmail.com/

The scheme I have used in V5 of the series is the one you agreed to use
back then.

A quick summary of the problem you mentioned:

There are some downstream variants of grub2 with a patch breaking the
boot protocol by writing garbage past the end of setup_header. Adding
a new field at the end of setup_header (here: rsdp_address) resulted in
those grub2 variants clobbering the preset value of 0.

The solution is to let grub2 report back the used boot protocol version
with setting a flag "I am reporting back my version". The kernel now is
capable to know which fields of setup_header are known to grub2 and can
act accordingly.

The related grub2 patch series is under review right now.


Juergen