ChanServ changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
quarkyalice_ has quit [Ping timeout: 480 seconds]
quarkyalice has joined #asahi
cth451_desktop has quit [Remote host closed the connection]
quarkyalice has quit [Ping timeout: 480 seconds]
jabashque has quit [Quit: Connection closed for inactivity]
chadmed has quit [Remote host closed the connection]
chadmed has joined #asahi
chadmed has quit [Remote host closed the connection]
chadmed has joined #asahi
cth451_desktop has joined #asahi
<sven>
dart/dev is not enough for nvme fwiw
<sven>
you should be able to put the root fs onto some mass storage thing though
chadmed has quit [Quit: Konversation terminated!]
Scott[m]1 has joined #asahi
jbowen has quit [Quit: leaving]
yuyichao has quit [Ping timeout: 480 seconds]
bps has quit [Ping timeout: 480 seconds]
jbowen has joined #asahi
bps has joined #asahi
jbowen has quit [Quit: leaving]
jbowen has joined #asahi
<cth451_desktop>
sven: thanks for the heads-up. I did not reserve space for root on the SSD as I have already alloc'd a iSCSI LUN for it.
<cth451_desktop>
Are there any gotchas for the initramfs loaded via m1n1? I'm sideloading a valid initrd that worked on other arm64 machines but on M1 it's reporting ENOENT for /bin/init.
<marcan>
cth451_desktop: define sideloading? there was code recently added to add the SEPFW to the initrd, maybe that is broken or maybe the initrd you used doesn't work and that's all there is :)
<marcan>
I actually haven't tried a linux boot since that patch, I should
<marcan>
(cc sven)
<marcan>
I remember some cpio shenanigans from when I did ps4-kexec, related to the trailer
<marcan>
are we doing that?
<marcan>
I think we aren't, that might explain why a concatenated initrd wouldn't work
<marcan>
cth451_desktop: quick test, load your initrd uncompressed
<marcan>
if that works then I'm pretty sure this is it
<marcan>
I remember poring over the linux initrd uncompress code until I made sense of this for ps4-kexec
<cth451_desktop>
marcan: Uncompressed initrd triggers a memory allocation failure in m1n1
<marcan>
ha
<marcan>
how big is it?
<marcan>
this is with linux.py?
<cth451_desktop>
170MiB (an entire recoery environment with iSCSI initator and such), and yes loaded via linux.py
<marcan>
hm, what failure?
<cth451_desktop>
One second, sideloading one now as I don't remember the details
<marcan>
though yeah, m1n1 heap is 128MB and the cpio code started allocating the entire initramfs there again I think
<marcan>
but... I actually kind of would expect it to silently overflow
<marcan>
I don't think we check for that
<cth451_desktop>
TTY> dlmalloc: out of memory
<cth451_desktop>
then the system reboots
<marcan>
interesting
<sven>
i've been booting linux with that patch fwiw
<sven>
but uhh.. my initrd is rather small
<marcan>
sven: and probably not compressed
<sven>
mine is compressed i think
<marcan>
hm
<marcan>
I seem to recall not having the CPIO trailer in would cause issues
<marcan>
with concatenated compression
<cth451_desktop>
a dirty hack for sure, but is there a way to just make the heap slightly larger?
<marcan>
well... as I said this is interesting because we don't actually have a heap top
<sven>
hrm, so i read the linux code and i thought it just eats whatever you feed it
<marcan>
unless it's already overflowing and corrupting
<sven>
and yeah, mine is compressed
<marcan>
Chainsaw: look for self.heap_base += 128 * 1024 * 1024 # We leave 128MB for m1n1 heap
<marcan>
in proxyutils.py
<marcan>
change that to 512 or something
bps has quit [Ping timeout: 480 seconds]
<marcan>
anyway the way the cpio code does the re-malloc of the initrd kind of defeats the purpose of all the careful memory management in payload.c, so I want to redo that
<marcan>
for payloads we should pre-alloc some space and just memmove; for linux.py, it should just deal with it in python and basically do the same thing
<marcan>
let me see what I can do
<sven>
sounds good :)
<sven>
btw. i just realized that apple locks the dcp and the dcpext DARTs in iBoot :/
<marcan>
locks?
<marcan>
as in the registers?
<sven>
yup
<marcan>
heh, so that is why they reference the pagetables in the ADT
<marcan>
annoying
<sven>
yeah :-(
<marcan>
but we can still modify them, right?
<sven>
let me check, but i think so
<sven>
we just can't point them anywhere else
<marcan>
maybe only some streams
<marcan>
which is probably so the DCP firmware is safe I guess
<sven>
uh.. the lock bit is global
<sven>
it just locks all streams
<marcan>
yeah but I bet some L2 pagetables are in writable RAM
<marcan>
and some are locked behind something else
<sven>
oh, possibly
<sven>
let me check
<sven>
erm.. wtf
<sven>
i think i can even overwrite the first level tables
<sven>
like.... why even bother locking it then?!
<marcan>
all of them?
<sven>
let me double check
<sven>
but i think so
<marcan>
I would expect the first level for one stream or subset to be locked
<sven>
dcpext only has a single stream i thinbk
<marcan>
alternatively, wasn't there one stream set to bypass (15?)
<sven>
ah, yes
<sven>
yeah, stream 15 is set to bypass
<marcan>
now I wonder what that one does... and what it's a backdoor for
<sven>
weird
<marcan>
would be nice to know e.g. if it's for firmware access, and constrained some other way
<sven>
bypass usually means that streams gets access to everything
<marcan>
yeah, but there might be some other constraint in that access path
<marcan>
basically what I want to know is does DCP firmware have a backdoor to system RAM or not
<sven>
yeah, i'm checking if there's this DAPF address filter thing behind it
<marcan>
Apple aren't stupid enough to leave that in
<marcan>
... I hope
<marcan>
but I could see this mechanism being part of keeping DCP safe from the AP, with something else constraining it to only its firmware area
<sven>
hrm, so i don't think there's a DAPF behind it
<sven>
or maybe it's just at another MMIO location
quarkyalice has joined #asahi
<sven>
hrm, actually, i think there is
<sven>
soo.. i don't really know how this DAPF thing works but i believe it's an additional filter behind the DART
<sven>
and it looks like maybe it contains some whitelisted MMIO regions
<sven>
but dunno :/
<cth451_desktop>
I'm not entirely sure whether bumping the heap to 512M changed anything.
<cth451_desktop>
The kernel still can't find init
<marcan>
cth451_desktop: I just pushed some completely untested code to the kboot-fw branch
<marcan>
don't even have m1n1 installed and I need to go to sleep :)
<marcan>
but give that a shot
<cth451_desktop>
marcan: thanks
<marcan>
(I was upgrading macos)
<marcan>
also another thing to check is that the kernel is built for the compression method you are using
<marcan>
you can also test the payload codepath by doing `cat m1n1.macho devtree.dtb initramfs.cpio.gz kernel > m1n1.payload.macho` and doing a chainload.py to that; that should also work
<marcan>
well, except the payload are is probably too small for your initramfs :p
<marcan>
*area
<marcan>
_max_payload_size = 64*1024*1024;
<marcan>
64MB max right now but you can increase it in m1n1.ld
kettenis has joined #asahi
<cth451_desktop>
The kernel is in fact a general purpose distro kernel
<cth451_desktop>
(plus patches)
<marcan>
ah, distro config you mean
<marcan>
should work
<cth451_desktop>
(where we use on SBSA servers)
<cth451_desktop>
defaults to gzipped initrds, but also configured to work with zstd and xz as well
<kettenis>
Instead of putting the SEPFW in the initrd, can't we just pass its address and size along in the device tree somehow?
<marcan>
we could use a reserved memory region thing
<kettenis>
the initrd approach isn't going to work on non-linux OSes...
<marcan>
but linux already has a firmware mechanism...
<marcan>
it might make sense to do it in the DT though, as you say
<kettenis>
to load firmware into memory...
<kettenis>
but it already is in memory
<marcan>
I'd poke robher
<kettenis>
I suspect that modifying initrd isn't going to play nice with distros that sign the initrd
<marcan>
heh, how does that work?
<robher>
already in memory, then reserved-memory...
<marcan>
but yeah, good point
<robher>
ah, what marcan already said...
<robher>
Is SEPFW something that could be extracted and put into linux-firmware? I'd assume distros put at least some of linux-firmware into their initrds.
<kettenis>
doubt Apple will give permission to distribute it
<marcan>
robher: no, we do not have a license to it and I'm pretty sure it's paired with things, plus encrypted
<svenpeter[m]>
Sepfw itself is encrypted and I believe paired with the machine
<marcan>
we can't distribute any of the firmwares. so far everything is preloaded by iBoot except SEPFW (which is passed in RAM), things in auxiliary Flash memories (which we don't touch), and the stupid broadcom wifi thing
<svenpeter[m]>
It also needs two more blobs that are essentially hashes of iBoot,etc. which are definitely paired to the machine
<marcan>
for the latter, we'll have to make our installer pull it out of macos and stuff it in /boot or something, where the OS can then copy it out or directly use it
<robher>
ok, then I'd go the /reserved-memory route.
<marcan>
the licensing situation is basically that every machine owner has a license to macos by definition, but we don't have a license to redistribute anything
<marcan>
so our installer will take care of downloading the bits we need from Apple's CDN and doing whatever it needs to do
<marcan>
we won't distribute anything ourselves, and I highly doubt Apple will object to this usage (it's equivalent to installing macOS normally and then erasing most of it)
<cth451_desktop>
kettenis: distros don't usually sign initrds. the initrd images are usually generated on the fly when new kernels or other modification request so.
<kettenis>
doesn't redhat do full secure boot, at least on x86?
<AlessandroFerrari[m]>
i think fedora does too right?
<cth451_desktop>
I believe they only sign the kernel and associated modules? I could be wrong though.
<kettenis>
i thought some of the u-boot approaches for secure boot did sign the initrd
<kettenis>
but maybe i'm mistaken
<kettenis>
that stuff doesn't really interest me as it makes tinkering impossible
<cth451_desktop>
Also makes life harder for sysadmins
<cth451_desktop>
The point here is, initrds are per-machine specific and it kind of defeats the purpose to sign initrd locally (since whoever got access to the hardware would presumably have access to private keys on the system)
<cth451_desktop>
Since RH/fedora distributes their kernel and users use the modules and images verbatim, the signatures are actually tamper proof seals since end-users don't have the siging keys
<cth451_desktop>
Embedded devices are another story though. Vendors who distributes pre-compiled kernel images and initrds may choose to sign them if they are not supposed to be user-modifiable
<cth451_desktop>
(for example most android devices)
<kettenis>
so the node in /reserved-memory basically just needs am appropriate compatible string and a reg property
quarkyalice has quit [Ping timeout: 480 seconds]
quarkyalice has joined #asahi
quarkyalice has quit [Ping timeout: 480 seconds]
quarkyalice has joined #asahi
quarkyalice has quit [Quit: Leaving]
reillyeon4 has joined #asahi
reillyeon has quit [Quit: Ping timeout (120 seconds)]
reillyeon4 is now known as reillyeon
arekm has quit [Remote host closed the connection]