ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
<alyssa> BUG_ONs be fun
Emantor has quit [Quit: ZNC - http://znc.in]
Emantor has joined #asahi-dev
<alyssa> oh derp
<alyssa> okay this next one will take some thought to resolve
DarkShadow44 has quit [Quit: ZNC - https://znc.in]
DarkShadow44 has joined #asahi-dev
DarkShadow44 has quit [Quit: ZNC - https://znc.in]
JTL has quit [Quit: WeeChat 2.9]
JTL has joined #asahi-dev
DarkShadow44 has joined #asahi-dev
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
<j_ey> ah, /System/Volumes/Preboot has it
<j_ey> anyone seen this stream error when trying to chainload macOS? https://paste.gg/p/anonymous/349b8a37b7294de380c9db2c4227ec60
<sven> what does file ~/kernelcache report?
<sven> j_ey: ^--
<j_ey> 'data'
<sven> should be dev.kc.macho.development: Mach-O 64-bit filetype=12 arm64e
<j_ey> hmm
<j_ey> i rebooted into macOS, and it also reports 'data' there
<sven> maybe it's a kernelcache wrapped in img4 or something like that?
<j_ey> it is
<j_ey> 00000000 30 84 01 64 63 bd 16 04 49 4d 47 34 30 84 01 64 |0..dc...IMG40..d|
<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> robin suggested to do it that way *shrug*
<j_ey> well that's a scary comment!
<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
<tophevich[m]> It's not a good example, but it might help in the future, you can mark line ranges: https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/drm_gem_cma_helper.c#L407-L408
<sven> hrm, now that i'm reading the swiotlb code again it seems that the untrusted stuff won't work correctly
<sven> that code only aligns allocations to a PAGE_SIZE boundary afaict
<sven> ... ofc i only figure this out just after i submitted the series
<marcan> :D
<marcan> sounds about right
<sven> urgh.. this is gonna be even more complicated now :(
<j_ey> marcan: "m1n1.fw.asc: Handle DARTless ASCs" nice! I had started to try hack that to get it working
<marcan> it's a bit partial, I think ioreporting needs changes too
<marcan> I was just testing SMC
<marcan> but it should be a start
<j_ey> more complete than what I got :D
<alyssa> sven: uhhh
<pipcet[m]> marcan: piodma sid is in the adt, i've only ever seen 4.
<pipcet[m]> and I can switch my framebuffer to 4k@60hz now, with ugly hacks which I hope you guys can avoid :-)
peerp[m] has joined #asahi-dev
<alyssa> pipcet[m]: hackless DCP driver incoming
<pipcet[m]> alyssa: awesome :-)
<sven> (*may still include hacks in the RTKit part)
<pipcet[m]> alyssa: anything I can test/review/comment on?
<pipcet[m]> alyssa: (sorry for working in parallel, this was an "if I can't get 4k out of this mini I better return it quick" thing)
<alyssa> umm
<alyssa> no, these things take time
<alyssa> that's life
<pipcet[m]> I'm not sure I understand?
<pipcet[m]> I wasn't expecting a working driver anytime soon, but I'm confident now that we can have one, so time to think of a name for the mini ;)
nesnass has joined #asahi-dev
<j_ey> pipcet[m]: you can look here for the No Warranties branches https://github.com/mu-one/linux/branches
nesnass has quit [Quit: Igloo IRC: https://iglooirc.com]
nesnass has joined #asahi-dev
nesnass has quit [Ping timeout: 480 seconds]
quarkyalice has quit [Remote host closed the connection]
quarkyalice has joined #asahi-dev
quarkyalice has quit [Remote host closed the connection]
quarkyalice has joined #asahi-dev
JTL has quit [Quit: WeeChat 2.9]
JTL has joined #asahi-dev
JTL has quit []
JTL has joined #asahi-dev
JTL has quit []
JTL has joined #asahi-dev
<marcan> pipcet[m]: the question is whether UPPipe2::map_buf() always is supposed to go to piodma or not
aleasto has quit [Quit: Konversation terminated!]
<alyssa> (do we understnad what piodma is yet?)
kendfinger has quit [Read error: Connection reset by peer]
kendfinger has joined #asahi-dev
<alyssa> why cant i spell
<alyssa> Just swapped my first frame with DCP
<alyssa> from linux
<alyssa> need to sort out some IOMMU stuff to get 4k properly
<alyssa> 2 files changed, 333 insertions(+), 8 deletions(-)
<alyssa> ^ versus yesterday's push
<alyssa> Needs a metric tonne of cleanup and then wiring into KMS
<alyssa> (Goal for today was swap a frame, tomorrow is wire into KMS, monday is 4k, tuesday is cursors/overlay planes.)