Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Asahi Linux Progress Report: January/February 2021

asahilinux.org

Post reply on HN
Print view View original

31–40 of 69 posts

Re: Asahi Linux Progress Report: January/February 2021

#31

Post by marcan_42 »

pabs3 wrote: post #26
marcan_42 wrote: post #24

Earlier quoted context omitted.

Everything except the GPU (and display controller)... which is a bigger challenge than every other driver combined :) (their kernel runs only on the boot-time framebuffer so far) Unfortunately, we've yet to hear any feedback from Corellium (they've been CCed on my upstream submissions), nor have they interacted with the Linux kernel community in any other way, so I have no idea what their plans are. So far, after wor…

Hmm, I see them participating on linux-arm-kernel list, nothing since January though: https://lore.kernel.org/linux-arm-kernel/?q=corellium

Mohamed is not a Corellium employee, but rather a third party who early on volunteered to attempt to upstream some of their patches.

The only e-mail from a Corellium employee to Linux mailing lists, to date, is this one:

https://lore.kernel.org/linux-arm-kernel/ce74bb29-1237-b0e7-...

This is the most puzzling bit to me: nobody from Corellium participated in the upstreaming discussion about their own code either.

Re: Asahi Linux Progress Report: January/February 2021

#32

Post by marcan_42 »

pabs3 wrote: post #29
marcan_42 wrote: post #27

Earlier quoted context omitted.

It depends on whether the PD controller chip supports sending SOP'DEBUG/SOP"DEBUG packets, and, for those that do, whether it is exposed to the host OS or the firmware running on it does so. However, even once you have that working, you still need to connect the other pins to a serial port adapter, and I don't know if any other laptops implement this in a compatible way, so you would probably still need some kind of…

So what is different about an M1 that lets you do this without the serial port adaptor?

M1 machines expose serial over Type C, so of course if you cross-connect two M1s they can talk to each other over serial. Conveniently, one of the pin pair options you can select is SBU1/2, which are cross-connected on standard cables, like a null modem serial cable, so you end up with TX connected to RX in both directions and it just works.

This is not a standard Type C feature, so unless another machine happens to also implement a 1.2V serial port compatible with Apple's version and pinout completely by chance, it won't work.

It only works on a specific port on Apple devices (the same one used for DFU, which has the fun debug features like this one), not on all the others.

Re: Asahi Linux Progress Report: January/February 2021

#33

Post by kkielhofner »

als0 wrote: post #6

> On the other hand, the rest of the 64-bit ARM world has largely converged on two competing standards: UEFI + ACPI (largely used by servers running Windows or Linux), It's not supposed to be just for servers, the Arm Base Boot Requirements (BBR) require it for any non-embedded use https://developer.arm.com/documentation/den0044/latest The new ARM64 laptops follow BBR so they have UEFI+ACPI, which means they can run…

I spent about five minutes wandering through the doc you linked trying to figure out how they define "embedded" and gave up.

In any case I've done plenty of hairy "embedded" development stuff (kernels, uboot, weird hardware drivers, etc) but I draw the line at device trees. I may have some kind of PTSD or something but I just refuse to deal with them in any way. Of course passing a path to a compiled binary device tree is fine but I refuse to do anything else.

I've met plenty of people that have no problem with them, make a living working with them, etc but other than the niche that is device tree expertise (and income) they may be experiencing some kind of Stockholm Syndrome.

I truly hate them and while they'll likely always have a place in the (hopefully) deep deep deep "embedded" world the sooner UEFI + ACPI generally takes over in the ARM ecosystem the better.

Re: Asahi Linux Progress Report: January/February 2021

#34

Post by pabs3 »

marcan_42 wrote: post #32
pabs3 wrote: post #29

Earlier quoted context omitted.

So what is different about an M1 that lets you do this without the serial port adaptor?

M1 machines expose serial over Type C, so of course if you cross-connect two M1s they can talk to each other over serial. Conveniently, one of the pin pair options you can select is SBU1/2, which are cross-connected on standard cables, like a null modem serial cable, so you end up with TX connected to RX in both directions and it just works. This is not a standard Type C feature, so unless another machine happens to…

I see. So will Linux on the M1 have enough driver/etc support to do the serial stuff?

Re: Asahi Linux Progress Report: January/February 2021

#35

Post by monocasa »

marcan_42 wrote: post #12
stefan_ wrote: post #11

Earlier quoted context omitted.

Doesn't the MacOS kernel use some bastardized version of device tree? I'm not sure of their commitment to UEFI/ACPI..

On ARM it does, as I mentioned in the article (though it isn't directly useful to us, as it's too different from Linux ones). But yeah, assuming there will be no Intel machines in Apple's line-up at some point in the future, I wouldn't be surprised if they drop out of the Forum.

They even use device tree on x86 too (in addition to ACPI/EFI). The plaintext password and user guid is passed in chosen fields for instance when boot.efi unlocks an FDE disk.

Re: Asahi Linux Progress Report: January/February 2021

#36

Post by ur-whale »

marcan_42 wrote: post #25
protoman3000 wrote: post #15

How did they figure all of this out from a non-documented platform, especially the specifics of Stage 1 (LLB)? [1] It blows my mind. [1] https://github.com/AsahiLinux/docs/wiki/SW:Boot

That's mostly just imported from existing iPhone research, where people have been reverse engineering iBoot (from exploitable phones, since it's encrypted) for a long time now. Combining that with what is known about how the M1 works from observation / the boot config data structures yields a decent picture, without actually seeing the code. Here's a fun one though: how I found and documented the Apple-proprietary me…

>my plan is to run macOS under a thin hypervisor built on m1n1 that can log hardware accesses

The fact that people like you exist in this world really makes me happy.

Re: Asahi Linux Progress Report: January/February 2021

#37

Post by chaorace »

I remember getting to the midpoint and thinking "Man, all of these PowerPC-isms really takes me back to the Wii modding days!".

Imagine my face when I read this line: "m1n1 traces its past to mini, which is a minimal environment that I wrote for the Nintendo Wii’s security CPU".

As if there was any doubt: Hardware reverse engineers are a very special breed of dedicated people. There aren't many of them, but those that are around tend to stay around!

Re: Asahi Linux Progress Report: January/February 2021

#39

Post by marcan_42 »

pabs3 wrote: post #34
marcan_42 wrote: post #32

Earlier quoted context omitted.

M1 machines expose serial over Type C, so of course if you cross-connect two M1s they can talk to each other over serial. Conveniently, one of the pin pair options you can select is SBU1/2, which are cross-connected on standard cables, like a null modem serial cable, so you end up with TX connected to RX in both directions and it just works. This is not a standard Type C feature, so unless another machine happens to…

I see. So will Linux on the M1 have enough driver/etc support to do the serial stuff?

Sure; Linux already has a driver for a variant of the USB-C chips in these Macs, so normal functionality should work with minimal changes. I don't know if the driver exposes the low-level command protocol to userspace off the top of my head (since we need that to send vendor-specific commands), but if it doesn't, we can probably get away with just using raw I²C access to the chip directly, via i2c-dev. Alternatively, we could add an interface, e.g. a debugfs entry for the Type-C driver that exposes raw commands.

Not sure what approach we'll end up with, but there are certainly multiple ways of doing this under Linux.

Re: Asahi Linux Progress Report: January/February 2021

#40

Post by marcan_42 »

marcan_42 wrote: post #20
darcien wrote: post #18

Earlier quoted context omitted.

Looks like their website is built with Hugo[1], and Hugo automatically generates RSS. So you can grab it manually if they don't provide a link for it by appending index.xml in the section URL. Here's the one for the blog: https://asahilinux.org/blog/index.xml Might be nice if we have an actual link to the RSS somewhere in the blog though. [1] https://github.com/AsahiLinux/AsahiLinux.github.io

I'll add a link later; this was on my TODO list but I didn't get a chance to do it yet.

Link (and header s) added!
Post reply on HN