00:44 <marcan> I mean I briefly worked for a black company :p

01:02 <alyssa> ⬛

01:18 <chadmed> TheLink: working with oss is like doing a coding assignment at uni. you spend two weeks writing something up, submit it, wait another 5 weeks, go in for code review with your assessor. then walk out 2 hours later feeling like you shouldnt be allowed near a computer ever again

01:20 <chadmed> and its always the reviewer not understanding your code thats the problem, not the code itself ;)

04:41 <phire> Is it possible that DCP exists for HDCP reasons? That by moving it to a coprocessor they only need to certify that coprocessor rather than all of macos?

05:32 <sven> fwiw, the secure enclave is also somehow involved in HDCP

05:46 <sven> chadmed: that's surprisingly accurate. except that for me usually the code is also the problem :D

05:52 <phire> well, you would need a few things involved in HDCP. especially hardware video decoding

06:50 <marcan> yeah, the SEP does some HDCP things

14:02 <alyssa> phire: Oh, that's possible.

18:37 <DanielHuisman[m]> Hey, I'm trying to run macOS on the m1n1 hypervisor on a MacBook Pro. It's connected to a laptop running Ubuntu with a USB-C cable. After starting I see the rainbow Apple logo, but nothing else appears to be happening. There are a few lines of logging in the hypervisor, but it quickly halts. I have posted the command I used and logs here: https://hastebin.com/raw/uxelihoqov.

18:38 <DanielHuisman[m]> Additionally, I'm not entirely sure how to see output from the macOS kernel, so basically I have nothing to go on for debugging this issue.

18:41 <marcan> DanielHuisman[m]: you need to open the secondary USB interface with e.g. picocom to see serial output

18:43 <marcan> if you're on Linux, you can add udev rules like these to have it properly identified: https://mrcn.st/p/UKqxUOw2

18:43 <marcan> /dev/m1n1-sec would then be where the xnu serial output goes

18:44 <marcan> if you don't have any active tracers in the hypervisor, it's actually normal for there to be next to no logging; without any tracers, there is very little the hypervisor is doing after all.

18:44 <marcan> if you see a progress bar under the rainbow logo then it's working; if you don't see that then something likely went wrong

18:45 <DanielHuisman[m]> Ah thanks, I will try that.

18:45 <DanielHuisman[m]> There is no progress bar, so yeah something is wrong :p

18:45 <marcan> I actually haven't tried a retail kernel, though I'd hope it would work. I might try that later this week, since I just upgraded to 12.0 and I might not bother with the dev kernel thing if I don't have to

18:46 <marcan> you can look for a call to #self.patch_exception_handling() in hv.py and uncomment that (it's hacky)

18:46 <marcan> that will add a nasty exception handler patch which might catch early boot problems for you

18:46 <marcan> terrible idea once things work, since it makes everything super slow

18:47 <marcan> oh also, make sure you have all the bputil security stuff disabled!

18:47 <marcan> I saw someone run into that, they still had KTRR/CTRR enabled

18:47 <marcan> that will definitely make the kernel panic if not disabled

18:47 <DanielHuisman[m]> I think I have that disabled. I followed the dev guide on the wiki

18:47 <marcan> do note that csrutil will re-enable some of those if you run it after bputil

18:48 <marcan> IIRC

18:48 <marcan> anyway, I need to get some sleep, but hope that helps get you somewhere :)

18:49 <marcan> oh yeah, another possibility is that the MBP has extra devtree nodes that need to be removed. broken phandle links in the ADT will make the kernel panic early too

18:49 <DanielHuisman[m]> I hope so, thanks for the pointers

18:49 <marcan> I really should add a consistency checker for that

18:50 <marcan> basically the hv removes a bunch of nodes for e.g. the USB port it's using, and it has to remove a lot of downstream nodes that depend on them; if the MBP has something the mac mini does not (unsure if it would, I haven't looked) then that could cause a panic if they are left behind