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]

Date:   Tue, 27 Feb 2018 09:44:09 -0500
From:   Jonathan Toppins <jtoppins@...hat.com>
To:     Bhupesh Sharma <bhsharma@...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 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. So it
seems reasonable to eventually have a default that effectively does
acpi=force for arm64. This patch was taking the halfway approach to just
have the kernel prefer acpi. I would prefer to just change to kernel
bool values instead of compiling in kernel command line args, as command
line args are usually left for the end user to play with.

-Jon