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: <CACi5LpMv_LB3wi7qn33b6mysdK_weki0YYsG0EkqPhR8FvFq5w@mail.gmail.com>
Date:   Wed, 28 Feb 2018 00:29:16 +0530
From:   Bhupesh Sharma <bhsharma@...hat.com>
To:     Jonathan Toppins <jtoppins@...hat.com>
Cc:     linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        astone@...hat.com, Jonathan Masters <jcm@...hat.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>, rafael.j.wysocki@...el.com,
        Ingo Molnar <mingo@...nel.org>,
        Prarit Bhargava <prarit@...hat.com>,
        James Morse <james.morse@....com>,
        andriy.shevchenko@...ux.intel.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64/acpi: make ACPI boot preference configurable

On Tue, Feb 27, 2018 at 8:14 PM, Jonathan Toppins <jtoppins@...hat.com> wrote:
> On 02/27/2018 07:40 AM, Bhupesh Sharma wrote:
>> Hi,
>>
>> On Tue, Feb 27, 2018 at 11:35 AM, Jonathan Toppins <jtoppins@...hat.com> wrote:
>>> This patch allows a user to configure ACPI to be preferred over
>>> device-tree.
>>>
>>> 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.
>>
>> Hmm. Not sure if I correctly understand what you mean here by the term
>> 'incorrect device tree'. Do you mean a corrupted device tree blob (but
>> normally we can catch those cases via the device tree header) or a
>> deliberate (or a broken) firmware attempt to pass an incorrect device
>> tree blob to the OS.
>
> I mean a device tree that doesn't list all devices in the SOC. So it is
> more incomplete than incorrect. It could also be incorrect in that it
> doesn't list proper timings, memory/pci/etc.
>
>>
>> If its the later, I think the onus should be on the firmware (u-boot
>> or UEFI or others.. ) to fix the problems. I know we carry a lot of
>> fixes in the kernel for x86 firmware quirks but then we have several
>> broken x86 machines on which kernel has been running since several
>> years now.
>>
>> IMO, if we have a known firmware quirk (to fix the broken DTB being
>> passed from the firmware), we can look at adding it in the early arm64
>> kernel code (similar to the quirk handling we do in the x86 early
>> kernel code for broken firmware), rather than forcing ACPI as the boot
>> method.
>>
>>> 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.
>>
>> Or, if decide to depreciate DTB as the boot method for such boards,
>> can we look at setting 'acpi=force' in the bootagrs always to make
>> sure that ACPI (and no fallback on DTB) is forced as the boot method
>> for such arm64 machines.
>
> For arm64 DT is suppose to *not* be the preferred method, yet still DT
> is preferred if the firmware provides both tables to the kernel.

That is true mainly for arm64 systems which are compliant to SBSA/SBBR
specifications and are mainly targeted for server markets.

However several arm64 products in embedded applications are still not
SBSA/SBBR compliant (and I have worked on a couple of such
implementations earlier) and still use bootloaders like u-boot (and
also closed-source implementations) which have no support for ACPI
currently and still rely on a DT to pass the system hardware
information to the kernel.

So far only open source implementation of a ACPI compliant firmware is
EDK2/UEFI which supports ACPI as the preferred boot method and I am
not sure if all u-boot/in-house firmware implementations are planned
to be ported over to EDK2/UEFI for embedded applications.

Even if they do, it would be safe to assume that to maintain backward
compatibility they will still look to support boot via DT as the
default boot method rather than ACPI.

Regards,
Bhupesh