linux-kernel - Re: [RFC PATCH 4/7] irqchip/apple-aic: Add support for Apple AIC

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: <d0eedc9e-2412-048a-9c7c-1e4a79aadb3b@marcan.st>
Date:   Fri, 22 Jan 2021 00:29:58 +0900
From:   Hector Martin 'marcan' <marcan@...can.st>
To:     Arnd Bergmann <arnd@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>
Cc:     Mohamed Mediouni <mohamed.mediouni@...amail.com>,
        Mark Rutland <mark.rutland@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Marc Zyngier <maz@...nel.org>, Will Deacon <will@...nel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Stan Skowronek <stan@...ellium.com>
Subject: Re: [RFC PATCH 4/7] irqchip/apple-aic: Add support for Apple AIC

On 21/01/2021 19.37, Arnd Bergmann wrote:
> On Thu, Jan 21, 2021 at 10:48 AM Linus Walleij <linus.walleij@...aro.org> wrote:
>>
>> However weird it may seem, Apple is not in the file
>> Documentation/devicetree/bindings/vendor-prefixes.yaml
> 
> Since Apple are already using both the "AAPL" and the "apple"
> prefix themselves, I have a bad feeling about reusing either of
> them for defining the devicetree.org bindings that we add to
> linux/Documentation/devicetree/bindings. The question is: if
> not "apple", what else should we use here?

This ties into the larger question of how we should handle devicetrees 
in general on these platforms.

The two extremes are:

1) Have the bootloader outright convert ADT to FDT and make Linux 
support the entirety of Apple's devicetree structure, or

2) Maintain our own devicetrees and ignore Apple's entirely

My feeling is that 1) is a non-starter, because Linux ARM device trees 
and Apple ARM device trees have seen independent evolution from the 
PowerPC era, and many details are completely different. Plus conversion 
is non-trivial, because the endianness is different and the format is 
too ambiguous to do programmatically without complex logic.

On the other hand, cranking out devicetrees by hand for every device 
variant that Apple puts out is a waste of time.

Obviously at the bare minimum the bootloader will need to move some 
dynamic information from the ADT to the FDT, but that can be a very 
specific set of properties (memory layout, MAC addresses, etc).

My current thinking is that we should write offline, automated tooling 
to parse, diff, and automatically convert portions of Apple devicetrees 
into Linux ones. Then we can more easily maintain our own, but still 
ultimately have humans decide what goes into the Linux device trees.

It's worth noting that AIUI Apple does not consider their devicetree 
layout to be stable, and it may change any time. On M1 devices, the 
devicetree is provided as part of the iBoot2 firmware bundle, which 
means it changes from one macOS version to the next (this is paired with 
the Darwin kernel itself, and they are upgraded as a unit). It includes 
placeholder values that iBoot2 then replaces with data from NOR before 
handing control over to the kernel. My goal for our long-term project 
[1] is to keep up with iBoot2 updates so that we do not have to instruct 
users to dig up old macOS versions.

Quick TL;DR on how these things boot:
- Boot ROM boots
- iBoot1 (system firmware) in NOR flash which looks for a bootable OS in 
internal storage (only!) in the form of an APFS container+volume and 
then boots
- iBoot2 (OS loader) which loads a bunch of firmware blobs and the 
devicetree off of storage, customizes it with system data from NOR, and 
then loads a wrapped mach-o file containing
- A Darwin kernel, or in our case a Linux bootloader which then boots
- A standard arm64 Linux blob

The boot ROM is ROM. iBoot1 only ever rolls forward (downgrades 
impossible). iBoot2 downgrades are possible but Apple already proved 
they can break this willingly or not, at least in betas (macOS 11.2 
Beta2 iBoot1 cannot boot Beta1 iBoot2). The secureboot chain goes all 
the way up to the mach-o kernel load, that is the first point where we 
can change boot policy to load anything we want (with user consent).

[1] https://asahilinux.org/

-- 
Hector Martin "marcan" (marcan@...can.st)
Public Key: https://mrcn.st/pub