ChanServ changed the topic of #asahi-re to: Asahi Linux: porting Linux to Apple Silicon macs | Hardware / boot process / firmware interface reverse engineering | WARNING: this channel (only) may contain binary reverse engineering discussion | RE policy: https://alx.sh/re (MANDATORY READ) | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-re
<Jamie[m]>
(although AVE might be completely un-looked-at too?)
<rqou_>
do you have any notes on avd?
Catyre has joined #asahi-re
Catyre has quit [Remote host closed the connection]
doggkruse has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
L1Q has quit [Ping timeout: 480 seconds]
phiologe has joined #asahi-re
PhilippvK has quit [Ping timeout: 480 seconds]
RevHelix has quit [Quit: I am going to make my own channel, with blackjack and hookers!]
<chadmed>
rqou_: i gave up on touchid (mesa) if you wanna have a crack at that. it has a private interface to SEP that i _think_ might be impossible to snoop on from the HV and im not skilled enough to really go beyond what ive already pushed into m1n1 :/
<chadmed>
the only data that is trafficked between it and the APs seems to be an encrypted command buffer of some kind to bring it up and tell it to wait for a fingerprint. everything else goes to the SEP
<chadmed>
and to really rub salt in the wound, tracing the SEP is too slow to reliably get anything useful. mesa seems to time out waiting for the SEP to tell it something which invalidates the input data and makes macos refuse to accept it
<nicolas17>
oh what? I thought the touchid sensor was connected to the SEP *only*
<chadmed>
no it talks to the APs over the same SIO interface that the kb and touchpad do
<nicolas17>
I always thought it was AP <-> SEP <-> mesa sensor, and no AP <-> mesa connection at all
<nicolas17>
interesting
<chadmed>
the only repeatable and intelligible data is a bringup sequence (which seems to just be the APs asking if its awake)
<chadmed>
after that the data is encrypted and changes on every boot (the format/packet size stays the same though which is why i think its an encrypted command buffer)
<nicolas17>
if it's the AP encrypting it, it should be possible to intercept...
<chadmed>
i dont think it is
<nicolas17>
but that would need code-level RE
<nicolas17>
well how does the AP come up with that encrypted buffer? either it has some plaintext and encrypts it, or it gets encrypted data from (say) the SEP and forwards it
<chadmed>
theres a few functions in one of the mesa drivers associated with encrypting and transmitting a command buffer
<chadmed>
BUT, theres also a much much smaller driver which is just a shim for the SEP interface and i think thats the one these machines use
<nicolas17>
can m1n1 set a breakpoint on that code, so you know which one is running?
<chadmed>
i could probably check without dicking around in m1n1 too but im like ~80% sure that its not the full fat driver
<chadmed>
and i say that because after the power on pings early in boot, theres no more data sent across the interface for a while then all of a sudden there is just encrypted commands
<chadmed>
theres no apparent negotiation or anything like that
<chadmed>
it just stops after powering it on then a few seconds later there is encrypted data
<nicolas17>
could it be doing the "negotiation" via the SEP?
<chadmed>
and these are the only two DMA channels associated with mesa on the SPI bus so it _must_ be talking to the SEP over a private interface
<chadmed>
well yeah but like i said the SEP tracer isnt really useful for this (yet)
<nicolas17>
ah, need better SEP tracing first, I see
<chadmed>
i did try hacking on the tracer sven wrote but it was a goose chase
<chadmed>
to effectively trace mesa i think we need to know a) the endpoint in the SEP the APs use to talk to it about mesa, and b) whatever interface mesa talks to the SEP over which might even just be staight up impossible idk
<chadmed>
the SEP FW is encrypted so we cant really look at it in ghidra can we?
<nicolas17>
the Mac SEP FW is encrypted
<nicolas17>
SEP for older iPhones can be decrypted, but I'm not sure how useful it would be
<chadmed>
yeah so figuring out how mesa interacts with the SEP is going to be almost impossible
<chadmed>
if we sort of do the same thing apple does (use the SEP to mediate authentication) then we might not need to, but then touchid support is effectively blocked until we have SEP support
<nicolas17>
I thought you had to do that anyway
<chadmed>
well my initial plan was to see if we could get fingerprint data out of mesa directly somehow and do it like that until the SEP works
<chadmed>
but alas no
<chadmed>
it does send some silly amount of data over SIO when your finger is on it, which i originally thought might be fingerprint data
<chadmed>
but idk what it is now im doubting myself constantly :P
<nicolas17>
hm, I think there isn't a direct SEP-Mesa hardware connection
<nicolas17>
rather the AP has to forward the data between them, but it's encrypted and the AP can't see what it is
<nicolas17>
I'm not entirely sure, there's some ambiguity in the way this is written, or I'm too tired to read it confidently
<nicolas17>
if that's right, then you should see the encrypted garbage being sent to mesa actually came verbatim from the SEP, and viceversa, and the AP is just forwarding ciphertext back and forth
<nicolas17>
and maybe you don't see that because the SEP tracer isn't catching it
<nicolas17>
take none of this as fact, I'm joining the speculation :)
<nicolas17>
but yeah I believe the AP can't see raw fingerprint data by design
<sven>
pretty sure that’s how it works
<chadmed>
yeah it cant i tried poking at the big data packet and it was all nonsense
<nicolas17>
so in hardware/wiring it's not AP <-> SEP <-> mesa as I said earlier, rather it's SEP <-> AP <-> mesa; *but* it's encrypted end-to-end
<chadmed>
yeah
<chadmed>
let me look at the logs i dumped
<chadmed>
yeah there is some sort of negotiation sequence but ofc its encrypted. xnu seems to only load the sep shim driver too
<chadmed>
AppleMesaSEPDriver
<nicolas17>
so yeah I think if you're not seeing encrypted data coming from mesa and then immediately the *same* encrypted data going to the SEP, then the SEP trace is incomplete :)
<chadmed>
like i said, tracing the sep at all results in it not working properly so yes i cannot see the data on the SEP <-> AP leg
<nicolas17>
oh I missed that
<nicolas17>
bleh how is it so timing sensitive?
<chadmed>
because the SEP is involved in basically everything and tracing it at all results in everything just slowing to an absolute crawl
<chadmed>
the system takes about 15 or 20 minutes to get to a login screen then an equal amount of time to settle down after logging in until you can click anything
<chadmed>
then you have the problem of getting into system settings to the touchid module and trying to get it to enrol a fingerprint
<nicolas17>
producing how many gigabytes of log until login screen? :D
<chadmed>
macos just gives up waiting for the data and doesnt validate the fingerprint
<chadmed>
i didnt even bother logging with the SEP tracer enabled, the volume of output is about on par with lina's gpu logs, probably worse
<nicolas17>
oh, tracer enabled but throwing the traced data away?
<chadmed>
i was still trying to figure out which EP is even mesa's so there was no point logging a bunch of undocumented garbage data
<chadmed>
i still dont know which EP it is :)
<chadmed>
i would hazard a guess that it is 0x18 since some XNU logs relating to AppleMesaSEPDriver appear just before EP 0x18 is announced as being enabled but that doesnt necessarily mean anything
<nicolas17>
I'll go back to my userland comfort zone :p
nicolas17 has quit [Ping timeout: 480 seconds]
the_lanetly_052 has joined #asahi-re
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan>
SEP can't possibly be quite as bad as lina's logs... she's logging *every single memory access from CPU to GPU-mapped memory*
<marcan>
even if there's a lot of traffic, just logging buffers back and forth has to be faster
<marcan>
maybe I should take a look at that tracerr?
<marcan>
*tracer
<chadmed>
if you disable the SKS EP its nowhere near as bad to be fair
<marcan>
might be doing something silly with trace modes...
<marcan>
or that, yeah, just filter it
<marcan>
there's also that thing lina did to speed up the whole m1n1 USB comms 3x (?)
<marcan>
I should poke her to push that
<chadmed>
yeah tracing SIO doesnt grind the kb and trackpad down anymore which is lovely
<marcan>
I don't think it's upstream yet?
<chadmed>
actual?
<chadmed>
huh... maybe it really just was that SKS endpoint
<chadmed>
either way i had a poke earlier and there were some messages on the sbio endpoint of SEP but _only_ immediately after taking your finger off the sensor and they had no data so there's still something missing somewhere
<chadmed>
there was no SEP traffic coinciding with the polling stuff over SIO
<sven>
the endpoint should be SBIO
<sven>
and the tracer isn’t nearly as bad as the GPU one
<sven>
but it’s still pretty verbose
<sven>
you probably want to disable SKS at least and there’s even a allowlist for endpoints already
<chadmed>
yeah i turned off SKS and its fast enough to interact with the sensor and macos is happy with it so thats cool
<rqou_>
is there a way to get m1n1 to break into the shell (and disassemble code) when a mmio register is written?
<rqou_>
i'm taking a look at avd, half of its regs overlap something mapped in pmgr for some reason, and i cannot for the life of me figure out where any of these registers are being written from
<rqou_>
the first half of avd overlaps pmgr[51] (on m1 max)
bisko has joined #asahi-re
the_lanetly_052 has quit [Ping timeout: 480 seconds]
bisko has quit [Ping timeout: 480 seconds]
bisko has joined #asahi-re
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bisko has joined #asahi-re
bisko has quit [Ping timeout: 480 seconds]
bisko has joined #asahi-re
Catyre has joined #asahi-re
bisko has quit [Read error: Connection reset by peer]
bisko has joined #asahi-re
Catyre has quit [Ping timeout: 480 seconds]
<Jamie[m]>
oh yeah idk what’s up with the first half of it
<Jamie[m]>
sorry didn’t get chance to assemble my notes, gotta sleep now, will find them tomorrow
<Jamie[m]>
or maybe you will have reproduced all my work by that point :)
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
MajorBiscuit has joined #asahi-re
nehsou^ has joined #asahi-re
MajorBiscuit has quit [Ping timeout: 480 seconds]
nehsou^ has quit [Ping timeout: 480 seconds]
Misthios has quit [Quit: Misthios]
Misthios has joined #asahi-re
<marcan>
rqou_: pmgr is a kitchen sink of nonsense and the ADT reg ranges are a huge mess
<marcan>
pmgr directly maps some device ranges, and some devices directly map pmgr ranges
<marcan>
entirely possible that the first half is just pmgr stuff shoved into that driver for no good reason
<rqou_>
marcan: after some more poking, i think the thing is a "axi2af" block, with a bunch of tunables. unfortunately i can't seem to actually get the tunable data from the PMGR kext, because every tool i've tried chokes on what i assume is the macho chained fixup data (but might be a different problem)
<marcan>
just hypervisor log it?
<marcan>
we should put that nonsense in m1n1 anyway
<rqou_>
that doesn't give me the masks
<marcan>
you could fake the read data as 000 and fff to get the masks, but tbh it probably doesn't matter much
<rqou_>
oh yeah, could do that
<rqou_>
not sure if this can be handled in m1n1, the tunables might get lost when the device is power/clock gated?
<marcan>
that's something to work out
<rqou_>
yeah
<marcan>
lots of things seem to stick across power/clock gates though
<marcan>
especially apple stuff
<marcan>
so I wouldn't be surprised if this does
<rqou_>
in the hv trace i see it getting poked multiple times, not just at boot
<marcan>
ah
<rqou_>
or maybe none of this is actually needed, i haven't tried actually poking the hardware yet
<marcan>
can you tell if it really loses the data?
<rqou_>
haven't tried at all yet, will need to investigate
<rqou_>
it's possible it's only important for performance tuning
<rqou_>
the AVD kext definitely also makes calls into the AMCC driver to tune some caching behavior (do we understand any of that yet?)
<marcan>
no, also seriously?
<marcan>
that's so goofy
<marcan>
let's ignore all that for now
<rqou_>
i mean, the adt outright says so: "function-mcc_dataset = 125:M$DS()"
<marcan>
maybe it's something like "don't cache AVD streams"?
<rqou_>
maybe
<rqou_>
at least this one doesn't involve a hacky layering violation
<sven>
fwiw, sone atc tunables stick around even through a atc reset, but others have to be reapplied again and again
<sven>
*some
<sven>
and yet macOS applies them all again and again (and my driver too because if I have to apply some tunables I might as well apply them all)
<rqou_>
on a different topic, i didn't see anything whatsoever touch btcoex in the "converged ipc" kexts, so if that's the issue it's either a command sent from macos userspace or a problem on the wifi side
<rqou_>
i'm guessing probably the latter
<marcan>
it seems the btc_mode is 0 when the nvram says it should be set to 1
<marcan>
so either something about nvram loading is broken or something isresetting it
rqou_ has quit [Ping timeout: 480 seconds]
nicolas17 has joined #asahi-re
nicolas17 has quit [Ping timeout: 480 seconds]
<sven>
afaict most of the fancy stuff happens inside BlueTool anyway (like firmware selection or sending the right calibration data)
<sven>
but sounds like btcoex is mostly a WiFi thing
nicolas17 has joined #asahi-re
MajorBiscuit has joined #asahi-re
MajorBiscuit has quit []
bisko has joined #asahi-re
rqou_ has joined #asahi-re
<marcan>
yeah, I think it's mostly handled on the wifi side