00:45 <bloom> ohh right ok

00:45 <bloom> the CSC bits in the Corellium code, the intended use is very much not swizzling

00:45 <bloom> but rather doing arbitrary colourspace transforms

00:46 <bloom> most importantly, YUV->RGB

00:46 <bloom> (there are a few variants of YUV, specifying an arbitrary matrix covers them all)

00:47 <bloom> Presumably the 3 x 2-bit enable register is a separate enable for each of 3 planes

00:47 <bloom> and there are 2 more sets of CSC matrix registers

00:47 <bloom> which would then be flexible enough for handling, e.g

00:48 <bloom> Desktop as RGB, a video player overlay plane as YUV, and a cursor plane

08:48 <sven> huh. i get "DRAM: alloc space exhausted" with the latest u-boot now

09:20 <sven> huh. somehow something broke the framebuffer

09:21 <pipcet[m]> corrupt boot args, maybe?

09:21 <sven> no

09:42 <kettenis> sven: you could try bumping the following #define in include/configs/apple.h

09:43 <kettenis> #define CONFIG_SYS_MALLOC_LEN SZ_64M

09:43 <sven> it crashes in video_clear shortly afterwards. didn't have time to debug what's going on and just disabled the framebuffer for now :D

09:44 <sven> oh.. maybe it's confused because i have nothing connected to hdmi

09:44 <sven> fb init: 640x1136 (32) [s=640] @0x9e0df0000

09:44 <sven> it probably doesn't like that for some reason

09:47 <kettenis> it'll trust whatever m1n1 passes as the framebuffer

09:50 <sven> i think m1n1 passes FDT: framebuffer@9e0df0000 base 0x9e0df0000 size 0x2c6000 in that case

09:50 <sven> let me try if this works if i connect my screen

09:51 <jannau> sven: I can reproduce the error with no screen connected

09:51 <jannau> works fine with screen

09:51 <sven> yup, also works fine again with a screen here

12:34 <sven> ugh. i think some clock gates actually have *two* parents

12:35 <pipcet[m]> so it's a DAG not a tree?

12:35 <sven> i think so

12:36 <sven> https://f.svpe.de/d30e6d91527db3ab66dcd9ae394f650d3888900d6967bb8e891cb3cbe03610f6_pmgr_clocks.txt

12:36 <sven> still need to confirm this. let's see if i can get the hv up and running

15:20 <jannau> Emantor: which kernel did you use for the hypervisor? I have no luck with xnu-7195.121.3~9/DEVELOPMENT_ARM64_T8101 it fails early over an assertion: https://gist.github.com/jannau/d27a43515909abb6485ca75367c388f6

15:22 <Emantor> jannau: did you use the Apple KDK?

15:22 <Emantor> I didn't try open source darwin.

15:23 <Emantor> I used KDK version 11.4_20F71.

15:23 <jannau> yes, assuming you mean kernel debug kit

15:23 <Emantor> Yes.

15:25 <Emantor> Unfortunately mu 5.12.4 kernel has borked xhci support on the ASMedia Chip, so my USB dies from time to tim -_-. Still waiting for the NixOS channel to advance…

15:25 <Emantor> I'll reboot this machine and spin up the guest to get my version, brb

15:25 <jannau> I think it is the version I used, let me check quickly in macos

15:29 <Emantor> Yes, Darwin Kernel Version 20.5.0: Sat May 8 05:10:31 PDT 2021; root:xnu-7195.121.3~9/DEVELOPMENT_ARM64_T8101 looks to be the same.

15:34 <Emantor> jannau: did you chainload current m1n1.macho beforehand?

15:34 <jannau> the kmutil command prints an error

15:34 <jannau> yes, I've chainloaded

15:35 <Emantor> whats the error?

15:36 <jannau> ti fails to find com.apple.iokit.IOACPIFamily as dependency for com.apple.driver.AppleHPET

15:38 <Emantor> Are you missing the kmutil inspect line? I also updated the sources line to the original kernelshamans blog entry for the cache creation.

15:39 <jannau> yes, that is without the inspect line

15:39 <Emantor> Could be that you need another `-r /Library/Developer/KDKs/KDK_11.4_20F71.kdk/System/Library/KernelExtensions` or something like that.

15:39 <Emantor> You

15:39 <Emantor> need the inspect line, otherwise not all extensions are found.

15:41 <jannau> yes, my fault it was printing a different error without and it looked garbled but was only a typo in the path

15:42 <jannau> still generates the same file which fails

15:43 <Emantor> hm, you are running the same commandline with -- "cpus=1 debug=0x14e…" as in the wiki entry? Than I am out of ideads.

15:45 <jannau> yes. the only idea I have is to do everything from the second mac os install with relaxed security

15:48 <Emantor> I did everything on the "primary" macOS installation, since the development/Linux one isn't accessible with m1n1 running.

15:49 <jannau> ok, I did the same. switching between m1n1 and mac os on the secondary install is not that much more inconvenient than booting the primary mac os install

15:54 <Emantor> Are you sure CTRR is disabled for the correct Boot Volume?

15:54 <Emantor> bputil has -c, --disable-kernel-ctrr

16:46 <bloom> how do I switch clip space to -1, 1 hnnngh

17:32 <marcan> jannau: do you have ctrr disabled?

17:33 <marcan> oh Emantor already said that

17:34 <marcan> also heck, how does chainloading even work with ctrr?

17:37 <Emantor> Maybe you have to ask nicely through an IMPDEF register to turn it on?

17:42 <bloom> % DYLD_LIBRARY_PATH=/Users/bloom/mesa/build/src/gallium/targets/libgl-xlib/ deqp-runner run --caselist ~/VK-GL-CTS/android/cts/master/gles2-master.txt --deqp ~/VK-GL-CTS/bld/modules/gles2/deqp-gles2 --output scissor-run -- --deqp-visibility=hidden --deqp-surface-width=256 --deqp-surface-height=256

17:42 <bloom> ^ note to self

18:20 <jannau> Emantor, marcan: apparently I hadn't ctrr disabled. not sure how it got enabled. working now

18:25 <Emantor> \o/

18:38 <marcan> Emantor: nah, the point of ctrr is iBoot should lock it down already

18:46 <Emantor> there seems to be code to handle ctrr lockdown in the darwin kernel, see https://github.com/apple/darwin-xnu/blob/a1babec6b135d1f35b2590a1990af3c5c5393479/osfmk/arm64/amcc_rorgn.c#L553 foe example

18:47 <sven> that's only meant for secondary cores afaik

18:50 <Emantor> https://github.com/apple/darwin-xnu/blob/8f02f2a044b9bb1ad951987ef5bab20ec9486310/osfmk/arm64/cpu.c#L847 indicates that this needs to be done by the first cpu being started in the cluster.

18:51 <Emantor> but I am just grepping source code, don't mind me (:

18:51 <Emantor> .oO(Whats does CTRR even mean?)

18:52 <sven> oh, maybe i confused it with KTRR

18:52 <sven> so KTRR is kernel text readonly region

18:53 <jannau> "Configurable Text Read-only Region"

18:53 <sven> essentially you setup a memory region and from the on only code from that region is allowed to run in kernel mode

18:53 <bloom> CTRR The Reversible RTCC

18:53 <sven> then there's a second set of registers in the memory controller that disallow writes to that region

18:54 <bloom> RRTC

18:55 <Emantor> The code looks like this has to be reconfigured after sleep since the MMU lock state is lost.

18:55 <VinDuv> CTRR being per cluster doesn’t means it’s not already enabled on the cluster that contains the boot CPU

18:56 <sven> hm, i thought iboot had some fancy way to relock KTRR after deep sleep

18:56 <sven> but who knows

18:57 <Emantor> VinDuv: Yes, but how does iBoot know which pages are to be protected? code looks like its configurable and setup by the kernel itself.

18:57 <sven> it loads the kernel, it knows which region is supposed to be executable in kernel mode

18:59 <Emantor> right, since the macho is loaded. To me kernel loading still is "copy bytes over there, jump to it.". Hm, idk.

18:59 <Emantor> Anyhow, I am off to sleep, gn8.

19:02 <sven> hm.... so CTRR seems to also make coprocessor firmware readonly. maybe.

19:02 <sven> https://googleprojectzero.blogspot.com/2020/07/one-byte-to-rule-them-all.html

19:02 <sven> "Thus, the regions that are locked down are all __TEXT segments of coprocessor firmwares; this strongly suggests that Apple has added a new mitigation to make coprocessor __TEXT segments read-only in physical memory, similar to KTRR on the AMCC (probably Apple's memory controller) but for coprocessor firmwares instead of just the AP kernel. This

19:02 <sven> might be the undocumented CTRR mitigation"

19:02 <sven> ofc this is all not documented anywhere :D

19:10 <sven> actually, siguza documented it. looks it's XNU itself which setups KTRR https://siguza.github.io/KTRR/