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
yuyichao has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi-re
chadmed has joined #asahi-re
jbowen has quit [Ping timeout: 480 seconds]
balrog has quit [Ping timeout: 480 seconds]
balrog has joined #asahi-re
PhilippvK has joined #asahi-re
phiologe has quit [Ping timeout: 480 seconds]
jbowen has joined #asahi-re
latko[m] has joined #asahi-re
jbowen has quit [Ping timeout: 480 seconds]
_jannau_ has joined #asahi-re
Rhys[m] has joined #asahi-re
mini has joined #asahi-re
riker77 has joined #asahi-re
deathdisco[m] has joined #asahi-re
ogimgd[m] has joined #asahi-re
jbowen has joined #asahi-re
jbowen has quit [Ping timeout: 480 seconds]
IsfarSifat[m] has quit [Server closed connection]
IsfarSifat[m] has joined #asahi-re
wollymilkcap[m] has quit [Server closed connection]
wollymilkcap[m] has joined #asahi-re
jbowen has joined #asahi-re
sppdqd[m] has quit [Server closed connection]
sppdqd[m] has joined #asahi-re
josipknezovic[m] has quit [Server closed connection]
josipknezovic[m] has joined #asahi-re
jbowen has quit [Ping timeout: 480 seconds]
Major_Biscuit has joined #asahi-re
NotHere[m] has quit [Server closed connection]
NotHere[m] has joined #asahi-re
long[m] has quit [Server closed connection]
long[m] has joined #asahi-re
matthewayers[m] has quit [Server closed connection]
matthewayers[m] has joined #asahi-re
ryanhrob[m] has quit [Server closed connection]
ryanhrob[m] has joined #asahi-re
why2[m] has quit [Server closed connection]
why2[m] has joined #asahi-re
sproede[m] has quit [Server closed connection]
sproede[m] has joined #asahi-re
Rhys[m] is now known as Rhys[m]1
Rhys[m]1 is now known as Rhys[m]12
Rhys[m]12 has quit [Quit: Reconnecting]
Rhys[m]12 has joined #asahi-re
jbowen has joined #asahi-re
jbowen has quit [Ping timeout: 480 seconds]
yrlf has quit [Server closed connection]
yrlf has joined #asahi-re
suricato has quit [Server closed connection]
suricato has joined #asahi-re
Retr0id has joined #asahi-re
jbowen has joined #asahi-re
jbowen has quit [Ping timeout: 480 seconds]
<sven>
phire: given that we're talking about strings let's move it here because some people want to be absolutely not exposed to any direct reverse engineering talk
<phire>
point
<sven>
which strings make you think that the firmware is responsible for setting up GART?
<phire>
well the strings include: "AGXSecureGart::unmap Timed out waiting for FW to process secure unmap after %llu ns" @%s:%d
<phire>
which susgest the firmware is somewhat involved in the process of mapping
<sven>
hm, weird
<phire>
though I'm with alyssa. I'm expecting registers controlled by the cpu
<sven>
there's also stuff like "kernel_gart_tables" @%s:%d which make it sounds it's the kernel itself
<sven>
if I were to speculate even more: AGXSecureSharedGartTableBacking maybe it's both actually? :D
<phire>
It could require interaction on both sides?
<sven>
could be
<sven>
still a bit weird, but who knows
<phire>
So, assuming it is registers, they seem to be missing from ADT
<sven>
only sort of
<sven>
the registers are part of the agx node
<sven>
the gart node just loads this gart kext which is very very small and only calls back into the main kext
<phire>
the sgx node?
<sven>
let me check again, it's been a while
<phire>
I've never seen those registers written to. only read
<sven>
yeah, i assumed they were in the sgx node
<phire>
0x4000-0x401c seem to be id/version registers
<phire>
0x11008-0x11014 seem to be some perf counters
<phire>
a few of the registers seem to count up when work is executed
<phire>
Then there are a few shared memory regions, gpu-region-base, gfx-handoff-base and gfx-shared-region-base
<phire>
I suspect work is being passed in via gfx-handoff
<phire>
but it's passing in these pointers that we are assuming are GART pointers
<sven>
did you also check the second register range given in the adt?
<phire>
depends on if trace_device("/arm-io/sgx", True) automatically picks them up
<sven>
hm... i think it does
<phire>
yeah, I think it does
<phire>
maybe it's on the agx-asc node's registers
jbowen has joined #asahi-re
yuyichao has quit [Ping timeout: 480 seconds]
<phire>
no, that only has the expected asc traffic
jbowen has quit [Ping timeout: 480 seconds]
alyssa has joined #asahi-re
<alyssa>
phire: are u tracing the *-region/handoff-base memory?
<alyssa>
or how does that work
<phire>
yes
<phire>
That's where I'm getting these "pointers" that I don't know where they point to
Glanzmann has joined #asahi-re
Glanzmann has left #asahi-re [#asahi-re]
<phire>
There is very little data sent via the ASC interface. It basically looks like little more than a keepalive
<phire>
oh hang on, the pointers witten to gfx-shared-region-base actually point at real physical memory
<phire>
they are also all unaligned
jbowen has joined #asahi-re
blassphemy[m] has joined #asahi-re
<alyssa>
unaligned pointers can sometimes be aligned pointers with extra data shoved in the bottom (and sometimes top) bits
<alyssa>
i don't remember if apple does that, i think they do
<alyssa>
arm definitely does
<phire>
yeah, it's always 0x3
<phire>
or 0x1
<sven>
could be kind of valid bit(s)
<alyssa>
sure
<sven>
in the DART PTEs the lowest two bits are used for that
<alyssa>
and what's pointed to at that address & ~0x3
<alyssa>
?
<phire>
stuff that doesn't seem to be that interesting at a first glance
<phire>
first pointer points to nulls
<alyssa>
womp womp
<phire>
second points to a table with data like: 0x00600004061e0447, 0x00600004061e4447, 0x00600004061e8447...
<phire>
few hundred 64bit values with slight increments between them
<phire>
it's only bits 16-23 that change
<alyssa>
no chance any of those are tagged pointers?
<alyssa>
(0x4061e4440 or something)
<alyssa>
Incidentally, strings implies that AVE uses a GART too
<phire>
it's outside of physical memory
<phire>
and doesn't look virtual
<alyssa>
Hm
<alyssa>
maybe it's time to pop open ghidra/ida
<alyssa>
give getGartPhysicalBaseAddress a looksies
<phire>
not sure I want to go much beyond looking at strings RE wise
<phire>
the fact that I'm seeing physical pointers in this gfx-shared-region is interesting
<phire>
implies something has direct access to physical memory
<alyssa>
nod
<phire>
um, let me just check this isn't just stale data from iboot
<alyssa>
possible
<phire>
nope, it's clear at boot
<phire>
however... the cpu didn't write into it
<phire>
I think it's data belonging to the firmware
<alyssa>
Could be, yeah
<phire>
I think the cpu only ever writes into gfx-handoff
<phire>
I see it following a pattern of writing what looks like a pointer (like 0x1506f90000), then a size (0x14000), then setting a flag (to signal work is ready)
<phire>
my theory is that these are command buffer pointers
<phire>
or pointers to some kind of task structure that has all the deatils
<alyssa>
what's at the pointer?
<phire>
its' not valid
<alyssa>
hm
<phire>
reading it actually crashes m1n1
<alyssa>
so it's a GART VA maybe
<phire>
yes, that's the leading theory
<phire>
so I need to work out where GART is. though I probally should sleep at some point
<phire>
might need to RE the kext
yuyichao has joined #asahi-re
Major_Biscuit has quit [Ping timeout: 480 seconds]