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. https://kernel-team.pages.debian.net/kernel-handbook/ch-source.html#s-acceptance 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. https://asahilinux.org/2021/03/progress-report-january-february-2021/ https://github.com/AsahiLinux/docs/wiki/Developer-Quickstart https://github.com/AsahiLinux/docs/wiki/SW%3ABoot 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. https://github.com/librerpi/rpi-open-firmware https://github.com/librerpi/rpi-open-firmware/blob/master/docs/cracking-rpi4-hmac.txt -- bye, pabs https://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part