[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian on Apple M1 hardware

On Sat, 2021-03-13 at 10:05 +0000, Pip Cet wrote:

> I think it's too early to conclude they're not interested in
> upstreaming changes.

Perhaps, but normally when companies are interested in upstreaming
changes, they engage with the Linux kernel community early and often;
posting an RFC patch sketch before it works, posting final patch series
when it works, posting new patch series in response to feedback etc.

> I'd like to disagree with the 'likely". It's possible, sure, but it's
> also possible someone (possibly the Asahi Linux project) will polish
> the Corellium work (which, well, works) and submit that to upstream.

The HN thread made it clear that Asahi Linux folks are not using a fair
bit of Corellium's work and that Corellium's work is often suboptimal
in terms of how the Linux kernel code normally works; reusing/tweaking
drivers vs duplicating them etc.

> I don't think we have to, or want to, pick a side here.

Ultimately what ends up in mainline is the side that will be picked.

> You're describing this as what sounds like a lengthy process, and it
> will be until everything is included in its "final" form, but I'd
> just like to remark that I consider this architecture potentially
> important and that taking a "there's no rush" attitude towards it
> might be the wrong approach...

For better or worse the Debian Linux kernel team does generally not
accept patchsets that aren't upstream or aren't near acceptance, the
same applies to all hardware including Apple M1 devices.


You can of course start working on supporting Apple M1 devices using
not yet upstreamed code, which is definitely a good idea, but of course
the final support will be solely based on upstreamed code.

> IOW, wouldn't it be nice to have something working soon?

I expect some folks who own or are able to own Apple M1 hardware would
like to have support for Linux, but I guess most people using Linux on
Apple M1 hardware will be doing so in virtual machines or Docker.
Personally I am stuck on decade old x86 hardware for now.

> independently of the question of who upstreams whose work?

Agreed that who does the work is not relevant.

> AIUI, the boot process does not involve macOS; installing a
> kernel/bootloader image is currently only possible from the recovery
> OS included with macOS, but that's not that unusual. It does mean an
> inconvenient extra step installing a bootloader for users, which I
> believe is precisely what Apple intended...

That is correct, but it does involve a proprietary iBoot2 Apple signed
binary blob, which according to Asahi folks has to be on the same
partition as the operating system kernel or the next part of the boot
chain, which for Asahi Linux will be:

   SecureROM → iBoot1 (on NOR flash) → iBoot2 (on the OS partition) → m1n1 → U-Boot → GRUB → Linux
   ^           ^                        ^                              ^         ^        ^       ^
   immutable   \ proprietary & signed   /                              \ open source and unsigned /  

Presumably the iBoot2 blob isn't released under a license that allows
redistribution, so folks wanting to install Debian on Apple M1 devices
will need to grab a copy of that from their macOS partition, which
means that Debian cannot ship a d-i image that will just work, we have
to get the user to run something on macOS to grab iBoot2.

The Asahi Linux post I pointed at has relatively detailed descriptions
of how the Apple M1 devices boot and the requirements of each stage.


The Raspberry Pi devices are in a similar situation, but at least there
is a chance the libre firmware reimplementation will be usable
eventually and for now the bootrom either doesn't require signatures or
parts of the boot chain are buggy enough that the boot restrictions are
easily bypassed.




Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: