linux-kernel - Re: [PATCH] arm64/acpi: make ACPI boot preference configurable

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]

Message-ID: <1454e833-e3b9-780b-c5db-a6f73e799352@redhat.com>
Date:   Tue, 27 Feb 2018 09:28:52 -0500
From:   Jonathan Toppins <jtoppins@...hat.com>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:     prarit@...hat.com, Jon Masters <jcm@...hat.com>,
        Bhupesh Sharma <bhsharma@...hat.com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Will Deacon <will.deacon@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        astone@...hat.com, James Morse <james.morse@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Ingo Molnar <mingo@...nel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] arm64/acpi: make ACPI boot preference configurable

On 02/27/2018 02:22 AM, Ard Biesheuvel wrote:
> Hi Jonathan,
> 
> On 27 February 2018 at 06:05, Jonathan Toppins <jtoppins@...hat.com> wrote:
>> This patch allows a user to configure ACPI to be preferred over
>> device-tree.
>>
> 
> This comes up once a year or so, and the consensus has been so far
> that it is not up to the kernel to reason about whether DT or ACPI
> should be preferred if both are supplied, Instead, it is up to the
> firmware to ensure that only one of those is provided, and we added a
> generic driver to EDK2 that implements this.

I am assuming EDK2 is some sort of firmware code base, not that I have
ever heard of it before. This logic compared with the implementation in
the kernel seems divergent. The kernel is clearly making a choice about
which boot table (DT vs ACPI) to configure with. So to claim it is not
the kernel's job to reason about which to use is clearly incorrect. The
only thing this patch is doing is making it easier for distributions to
configure which preference the kernel has.

> 
>> Currently for ACPI to be used a user either has to set acpi=on on the
>> kernel command line or make sure any device tree passed to the kernel
>> is empty. If the dtb passed to the kernel is non-empty then device-tree
>> will be chosen as the boot method of choice even if it is not correct.
> 
> Your firmware is terminally broken if it provides an incorrect DT, and
> we should not be fixing it in the kernel.

This logic would seem akin to me asking Bjorn to remove all PCI quirks
from the kernel, because the systems that use them are "terminally
broken" or "don't follow the standard". This doesn't seem like a valid
reason to deny a change that would allow the kernel to boot on more
hardware. Further it seems rather rigid to effectively say that we only
run on perfect firmware.

> 
>> To prevent this situation where a system is only intended to be booted
>> via ACPI a user can set this kernel configuration so it ignores
>> device-tree settings unless ACPI table checks fail.
>>
> 
> 'only intended to be booted via ACPI' is a property of the system, not
> of the OS. If you need this functionality for development, you can
> append 'acpi=on' to the kernel command line via kconfig.

This is not for development this is for production rate shipping firmware.