Chainsaw has quit [Read error: Connection reset by peer]
Chainsaw has joined #asahi-dev
<alyssa>
Oh, nice. DCP should be alive now.
<alyssa>
Guess tomorrow will try to swap my first frame with DCP then.
<alyssa>
marcan: DCP is surprisingly forgiving of questionable input, btw
<alyssa>
w/e, not complaining
<alyssa>
but, e.g. I think the random kernel VA floating around in the DCP shmem are opaque handles for XNU to use later / as debug / something like that.
<alyssa>
at least on my version of dcp fw, zeroing out the addr field in mgr.swap_start works fine
<alyssa>
the userspace<--->kernelspace ABI for IOGPU does this sort of thing (with opaque userspace VAs flying around), could be similar
<alyssa>
although there are of course extant security questions regardless of its use, if we allow the possibility of malicious coprocessor firmware
<alyssa>
(and if we don't allow that possibility, why use a DART?)
quarkyalice has quit [Remote host closed the connection]
quarkyalice has joined #asahi-dev
<alyssa>
(I *am* quite curious about Apple's threat model for coprocessors, which necessarily is different from our own.)
PhilippvK has joined #asahi-dev
phiologe has quit [Ping timeout: 480 seconds]
amw has quit [Ping timeout: 480 seconds]
amw has joined #asahi-dev
<marcan>
alyssa: remember all of this is deadline-driven development
<marcan>
don't try to find rational reasons for the design choices
<marcan>
the answer is always "it was rushed"
<marcan>
the threat model is obviously that copros shouldn't ever see kernel VAs and the kernel shouldn't ever trust copros
<marcan>
... whether they managed to stick to that is another story
<marcan>
if you look at IOSurface - those 64-bit bools are hidden pointers to the previous embedded fields
<marcan>
the marshaling code turns them into a bool to signify non-nullness and then on the other side puts back the pointer to the preceding structure
<marcan>
so evidently they don't *intend* to leak kernel pointers
<marcan>
yes, I fully expected the swap_start pointer to be total BS
<marcan>
I only had that in because copypasta :p
<marcan>
it's probably completely ignored
<marcan>
remember this is an API that used to be local that has been shoved across a CPU boundary
<marcan>
leaking kernel VAs breaks kASLR if a copro is compromised, and apple are big on kASLR, so that is definitely not intended
chadmed has quit [Remote host closed the connection]
chadmed has joined #asahi-dev
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
quarkyalice has quit [Remote host closed the connection]
quarkyalice has joined #asahi-dev
<sven>
marcan: i think that physical address reply to the crashlog request is a bug as well btw.
<sven>
i can just not reply and crashlogs will still work fine
aleasto has joined #asahi-dev
nico_32 has quit [Ping timeout: 480 seconds]
<marcan>
yeah, it doesn't make much sense does it?
<marcan>
but I wonder how they managed that, heh
<marcan>
maybe a path out of a function not returning anything?
<marcan>
or just they translate it in-place then unconditionally return or something
<marcan>
kinda weird
<pipcet[m]>
I assume the crashlog location is locked somehow and you can't change it from its locked iova?
<marcan>
either it's preallocated or it isn't
<marcan>
if it's preallocated there's no function to change it, so you can't
<sven>
yeah, i dunno how the managed to mess that up
<sven>
especially (well, on SMC at least) the syslog does it correctly: it gets an address and never replies.
nico_32 has joined #asahi-dev
jbowen has joined #asahi-dev
jbowen has quit [Ping timeout: 483 seconds]
<j_ey>
anyone know where to find the kernelcache on macOS? System/Library/Caches/com.apple.kernelcaches/ is empty
<sven>
hrm, i guess i should finally submit that 4k fixes. i just noticed i've been using them for the past month or so with 4k pages and nothing broke :D
<j_ey>
sven: ^_^
<sven>
the good news is that nvme works just fine with 4k pages, but that was kinda expected anyway :D
<j_ey>
using img4tool.. I extracted the im4p and the im4m, both file says are 'data'
<j_ey>
oh, I had to extract im4p and then extract the payload from that
<pipcet[m]>
extract the payload from the ...right.
<j_ey>
well that got a bit further at least
<j_ey>
got to the login screen!
<j_ey>
is anyone else using m1n1 with an rpi4 connected to the m1?
yuyichao has joined #asahi-dev
gladiac has quit [Quit: k thx bye]
<alyssa>
sven: I wonder if locked DARTs do too with my patches
<sven>
do what too?
<sven>
oh, work on 4k kernels?
<sven>
i don't see why they wouldn't
<sven>
the changes are outside of the dart driver
<sven>
will probably send them later today and make sure to cc you. then you can even try yourself ;)
<alyssa>
;D
<sven>
alyssa: just submitted it, you should've gotten it as well :)
<sven>
now.. mailbox next i guess
<alyssa>
👀
<alyssa>
holy bananas that's a lot of email
<sven>
the most interesting changes happen in two commits
<alyssa>
sven: I can't believe I'm suggesting this but it might be worth seeing if you can do a frankenkernel smashing together your IOMMU patches with corellium's repo to see if thunderbolt 4k pages works
<sven>
nope, won't work
<sven>
or at least not without much effort
<alyssa>
ack
<sven>
the thunderbolt darts aren't even supported by my code right now
<alyssa>
are they special darts?
<sven>
small variant of the current one
<sven>
they support 64 streams instead of 16
<alyssa>
right ok
<sven>
and their pcie driver might also break because m1n1 already did the tunables
<alyssa>
"Pretend that iommu_dma_get_sgtable is not implemented since I can neither test this function right now nor do I fully understand how it is used."
<alyssa>
this is a mark of quality right here 🙃
<sven>
"The whole dma_get_sgtable() idea is fundamentally unsafe" is already a good start, yes :D
<sven>
hah, and the commit message that introduced (well, move it there) mentions "The comments are spot on and should be near the central API"
<alyssa>
How... delightful
<sven>
so i *think* that function actually doesn't need any change, but i'd rather wait until something runs into that and fails in an obvious way than just hoping it's correct