Now that the HV works I've started looking into the new atcphy with TBT5 support for m4 pro and it luckily doesn't look too bad: MMIO pokes are different and you need start a random co-processor in the middle of it and then just never interact with it again but all the sequencing with dwc3, resets, etc. seems to be the same.
Thunderbolt, M3 GPU, gaming, and even M5 progress! We've got it all in the latest Asahi Linux progress report.
Fixed: Only a single core is available when you boot Linux or other third-party operating systems from a custom raw boot object on Mac computers with M5 Pro, M5 Max, and M5 Ultra chips. (182898702) (FB23916610)
The bug I filed was fixed ^-^
https://developer.apple.com/documentation/macos-release-notes/macos-27_3-release-notes
I published a detailed article:
⚠️Dangerous Device: Exploiting CVE-2026-31695 in the Linux Kernel via struct device⚠️
I managed to make make the PoC exploit absolutely stable, despite the elusive race condition during the attack.
The Asahi Linux downstream Kernel 7.2.12 has initial USB4 / Thunderbolt 3 support. It does not yet support the 2 features (PCIe and DisplayPort tunnelling) everyone expects. Tunnelling of USB3 and Host to Host (Ethernet over USB4) are working on all supported M1, M2 and M3 devices.
This means USB3 ports and integrated devices on Thunderbolt hubs might work. USB4 network speed is much slower than the theoretical 40 Gbps due to interaction between the Linux driver and the IOMMU (DART),
#asahilinux
And here we go: macOS on M5 running under our hypervisor 🥳
It's a bit cozy in EL1/0 now with what's effectively three separate VMs: SPTM (GL2) + TXM (GL0), XNU (EL2) + user space (EL0), and Secure Kernel/cL4 (GL1) + user space (GL0). I should be able to get that cleaned up and merged this weekend.
Exclaves boot status: BOOTED_EXCLAVEKIT 😁
Unknown: InternalExclaveLauncher/ResourceManager.swift:911: Fatal error: 'try!' expression unexpectedly raised an error: Launcher.Device at PC: 0x0000c00a1c7c, LR: 0x0000c009a2f8
clearly, this is progress!
Has anyone done some secure kernel / cL4 research? Does SPTM really not enable stage 2 translation and can cL4 really write whatever page tables it wants?
That’s not a big issue for the hypervisor, probably. I just also wanted to store my shadow pagetables there and they have to move now. Also gotta figure out how virtualization works together with MTE
#asahilinux
Started looking into M5 hypervisor bringup. I think it’s already known that the SoC supports MTE now which I ran into very early. In MTE you need quite a bit of RAM (1/32 of your total) to store the allocation tags for each 16 byte physical address space chunk. From what I can tell this is always implementation defined, Apple seems to just use normal RAM: there’s a TagOffset_EL2 that points close to the end of RAM with just the right size and that’s where those tags are stored.
Sounding the alarm for #Apple / #Macintosh fans in the US Midwest - ran across this Facebook post: A giant piie of stuff that must go in 30 days! Located in Kansas City, MO area.
An article on Aftermath about how depressing AI slop has made emulation and decompilation projects, and crushed existing communities https://aftermath.site/ai-slop-hobbies-in-software-emulation/
And hey, it links to me and @glyph's blogposts
(Thx for the heads up @mostol)
✅ #40c3 ticket
✅ Hotel in Hamburg
omfg they're ALL FUCKING <255
4 EM OV TLS CA - G3C OV TLS
56 EM EV TLS CA - G3C EV TLS
66 EM OV CS CA - G3B Code signing
115 EM EV TLS CA - G3B EV TLS
155 EM OV TLS CA - G3B OV TLS
156 EM DV TLS CA - G3B DV TLS
230 EM DV TLS CA - G3C DV TLS
237 EM OV CS CA - G3C Code signing
4 times the SECP384-R1 base point is (0x138251cd52ac9298c1c8aad977321deb97e709bd0b4ca0aca55dc8ad51dcfc9d1589a1597e3a5120e1efd631c63e1835, 0xcacae29869a62e1631e8a28181ab56616dc45d918abc09f3ab0e63cf792aa4dced7387be37bba569549f1c02b270ed67)
https://repository.emsign.com/certs/EMOVTLSCAG3C.crt
for the non-cryptographers at the back of the room: the private key is 4, just the number 4, nothing more
Certificate:
Data:
Version: 3 (0x2)
Issuer: C=IN, O=eMudhra Technologies Limited, CN=emSign Root TLS CA - G3
Subject: C=US, O=eMudhra Inc, CN=EM OV TLS CA - G3C
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub:
04:13:82:51:cd:52:ac:92:98:c1:c8:aa:d9:77:32:
1d:eb:97:e7:09:bd:0b:4c:a0:ac:a5:5d:c8:ad:51:
dc:fc:9d:15:89:a1:59:7e:3a:51:20:e1:ef:d6:31:
c6:3e:18:35:ca:ca:e2:98:69:a6:2e:16:31:e8:a2:
81:81:ab:56:61:6d:c4:5d:91:8a:bc:09:f3:ab:0e:
63:cf:79:2a:a4:dc:ed:73:87:be:37:bb:a5:69:54:
9f:1c:02:b2:70:ed:67
ASN1 OID: secp384r1
NIST CURVE: P-384
The two hardest problems in Computer Science are
1. Human communication
2. Getting people in tech to believe that human communication is important
how to use: grab sptm, txm and a kernelcache. they're all in the preboot volume or just use ipsw extract --sptm and --kernel and then python3 proxyclient/tools/run_guest.py -l m4_`date +%Y%m%d-%H%M%S`.log --sptm-mode=emulation --sptm m4pro_sptm.b --txm m4pro_txm.b m4pro_kernelcache.b -S debug=0x14e serial=3 wdt=-1
RE: https://social.treehouse.systems/@sven/117338725720247630
(Almost) all of that is upstream in m1n1 now which means that our hypervisor finally works with SPTM, TXM and XNU on at least M4 Pro now! It's not perfectly stable but good enough to trace most hardware. Let's see about M5 next, it might just work if I manage to disable cL4 / exclaves there.
Other than that I guess it's back to the thunderbolt series and then atcphy on M4 Pro!