nicolas17 has quit [Quit: Konversation terminated!]
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
benpoulson has joined #asahi-dev
hays has quit [Remote host closed the connection]
hays has joined #asahi-dev
benpoulson has quit [Ping timeout: 480 seconds]
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
cste005 has quit [Quit: Leaving]
maxkofler has joined #asahi-dev
maxkofler has quit [Quit: Quit]
the_lanetly_052__ has joined #asahi-dev
mps has joined #asahi-dev
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
TristenNollman[m] has joined #asahi-dev
SergioLopez[m] has joined #asahi-dev
<marcan>
chadmed: the python firmware thing is relevant, but doesn't need to be automagic for gentoo IMO
<marcan>
so just package it as a python package and maybe add a python-exec wrapper to run it with the right arguments by default
<marcan>
no need to run it as a postinstall or anything
<marcan>
gentoo users can be told to do it manually :)
<marcan>
sven: two streams per dispext almost implies 2 monitors on M1, or MST? which would be unheard of for Apple but...
<marcan>
one theory I have is that maybe dcpext can route the two planes to different outputs? so you lose one plane per output but you get two
<marcan>
but I didn't really see anything sane in the current firmware API to imply it actually supports doing this sanely, though who knows
<sven>
don't know yet, all i know is that 0 is dispext0,0 and 1 is dispext0,1
<marcan>
maybe the hardware can do it and the firmware can't, that'd be very apple
<sven>
(in that crossbar mux)
<sven>
yeah, could be
<marcan>
also, that would explain the two eDP outputs vs one DISP0
<marcan>
maybe DISP0/DCP can also do two outputs
<sven>
I don't think it supports MST fwiw. I can only route a single stream to DPPHY
<_jannau_>
ok, so I can just create a merge request for the asahi-fwextract ebuild
<sven>
I can route two streams to DPIN0/1 and tunnel them both over USB4 then
<_jannau_>
maybe the crossbar is prepared for MST but dcp/disp is still lacking
<sven>
as I said, I don't think the crossbar even supports MST via DP alt-mode
<marcan>
maybe it's just for the TB equivalent?
<marcan>
but can you route *separate* DISPEXTs to the same USB4 PHY? I mean that has to work, right? (especially for t6k)
<sven>
yup
<sven>
i could also configure the atcphy0 crossbar to dispext0,0 and the atcphy1 crossbar to dispext0,1
<marcan>
so in theory m1 should support two external monitors then, if dispext can do that
<sven>
or the atcphy0 crossbar to dispext1,0 and dispext2,0 if using USB4 tunneling
<sven>
at least the crossbar part I think
<marcan>
interesting
<sven>
and XNU debug strings clearly call this dispextN,M
<sven>
dispext%u,%u -> atc%u,%u (atc%u-%s)
<sven>
first %u in atc is the atc index second on selects between "dpphy", "dpin0" and "dpin1"
<sven>
and dpin0/1 is usb4 tunneling
<sven>
i'll play around with it a bit once I actually get dp alt mode up in m1n1 :D
e1eph4nt has quit [Ping timeout: 480 seconds]
<marcan>
ha, AppleDCPDPTXProxy has strings which imply this matrix of routes: die[01]:dispext[0123]:core[01] -> atc[0123]:{dptx,lpdptx}:{dpphy,dpin[01]}
<marcan>
I wonder if that implies they can route DP streams across dies in t6002, that would be neat
<marcan>
and core0/1 is definitely a thing then
<marcan>
not sure what the dptx/lpdptx story is about though
<marcan>
if you look at DCPs on the die shot though, they clearly have two symmetric halves, so that supports the "two cores" idea too
<marcan>
there's also this: IOMFB: DCPLink::start failed with 0x%x (pipe:%u)
<marcan>
I think DCPLink is the main DCP thing, so maybe there's somehow a whole separate instance per core?
<sven>
interesting
<marcan>
from DCP.bin:
<marcan>
port %p (port%u, core%u)
<marcan>
dcpav-edp-core0-nub
<marcan>
dcpav-dpext-core0-nub
<marcan>
dcpav-dpext-core1-nub
<marcan>
core%u -> atc%u,%u (supportsHPD=%u)
<marcan>
I swear if this thing actually supports two ext displays on M1...
<sven>
lol :D
<sven>
that would be fun
<sven>
weird that apple doesn't make use of that then though
<marcan>
yeah... well, apple doesn't make use of a lot of things in these socs...
<sven>
huh, also DCP itself needs to know to which atc its stream is routed? ("core%u -> atc%u,%u (supportsHPD=%u)")
<_jannau_>
but why would apple not support that? no resources for fixing issues/testing it properly
<marcan>
I have a feeling that Apple have this thing where sometimes they can't ship certain hardware features because the software isn't ready on time, and they're too proud to admit to it or add it back in later, so they just don't
<marcan>
but everyone is clamoring for multiple monitor support, and it's *bizarre* they didn't ship it with M2 at least if it can do it
<sven>
i kinda hope this actually works. would be a fun tweet. "Here's my M1 macbook air with two external screen running Asahi Linux" :D
<marcan>
:D
<sven>
maybe it's also just broken in some way
<marcan>
yeah
<sven>
and they didn't manage to fix it for M2 in time
<marcan>
I mean there's also that mystery ANE1 in t6001
<marcan>
or two of them in t6002
<sven>
dptx,lpdptx <-- any idea what lpdptx means?
e1eph4nt has joined #asahi-dev
<marcan>
"low power" I think, I think that's the one for the internal panel?
<sven>
ah, makes sense I guess
<marcan>
the M1 has 6 (!) lanes of LPDPTX, 4 of which are connected to the internal panel
<marcan>
and also, 12 (!!) lanes of LPDPRX (!?)
<_jannau_>
I have problems reading it different than "low power" as synonym for eDP but I'm confused what thta has to do with the dp-xbar routing
<marcan>
I suspect the LPDPRX stuff is for DisplayPort cameras (?)
<sven>
for dpphy the mux control has two fields, DPPHY_SELECT0 = 23, 20, E_DISPEXT and DPPHY_SELECT1 = 11, 8, E_DISPEXT
<marcan>
but it could also support some kind of input passthrough a la old iMacs
<sven>
both are always set to the same value
<marcan>
sven: separate lanes?
<sven>
yeah, could be
<sven>
it's unfortunately one of the few registers where they don't just give us the name/fields in debug strings
<marcan>
apple calls the display eDP and the lanes LPDP so I think they are synonyms
benpoulson has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
<sven>
hrm, so if DCP.bin knows about core0/1 the firmware should have sone support for it, shouldn’t it?
<sven>
*some
<marcan>
you'd think so, yeah
<marcan>
there's unused bits in the DCP message bitfield, I could see them sneaking a pipe ID in there...
<sven>
I’m going to be very happy if this works out
<sven>
dual external screen is the only thing that makes me want to upgrade my mba
e1eph4nt has joined #asahi-dev
<marcan>
:D
jakebot60 has joined #asahi-dev
hir0pro has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
<phire>
come over and join us people who use ultrawide monitors
<phire>
I have very view regrets, except my particular one has more than a few firmware bugs.
<phire>
*very few
e1eph4nt has joined #asahi-dev
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
veloek_ is now known as veloek
hir0pro has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hir0pro has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
<DmitrySharshakov[m]>
jannau: how's audio routed into DCP? I couldn't find its way inside the driver
<povik>
what do you mean routed?
<povik>
the firmware interface for it hasn't been reversed yet
<DmitrySharshakov[m]>
I mean DP audio
<DmitrySharshakov[m]>
You answered this probably
<sven>
yeah, we don't know how that routing works yet
<sven>
so there's nothing in the driver
<povik>
we know the SIO coprocessor serves as a kind of DMA controller for the audio stream
<DmitrySharshakov[m]>
Understood, thanks
<povik>
but that's about it
<sven>
oh, so we might actually need a SIO DMA driver in linux?
<_jannau_>
there are other endpoints on the DCP rtkit interface which could be related to audio
<sven>
that also reminds me that I wanted to look at that firmware to see if it's literally a co-processor that polls HW regs to pretend that they actually support DMA
<_jannau_>
the dcpep calls itself do not mention audio
<povik>
sven: we might. i will be happy to write a dmaengine driver for it
<povik>
but then there's the other pieces involving DCP...
<povik>
btw where does KNOWN_MSGS in trace_dcp come from?
<povik>
asking for the AOP interfaces
e1eph4nt has joined #asahi-dev
<shorne>
Hello, I am jumping right into s2idle suspend stuff and compiling the kernel with CONFIG_SUSPEND (it seems onts not enabled on asahi by default)
<shorne>
SOme general questions, if I am not reverse englineering (yet) do I need to care about m1n1?
<sven>
yeah, because wifi and pcie will break if you enable that
<shorne>
yeah, thats what I want to see
<shorne>
Also, I see the docs about configuring m1n1 all discuss setting it up from macOs
<sven>
uh, are you sure?
<sven>
most people use a second linux machine
<shorne>
do I need to switch back to macOS to change m1n1 settings
<shorne>
ah.. hence basic questions
<sven>
i'm still confused what you are trying to do
<shorne>
Oh, its 2 different things. One is just compiling and internalling the kernel, not questions about that.
<shorne>
the question about m1n1 is completely separate
<sven>
marcan: ^-- can you maybe try to connect two external screens via a single usb4 dock on the pro/max and trace the crossbar?
<jannau>
oh, you actually ment USB4, my dock is thunderbolt 3
<sven>
i think thunderbolt 3 is similar enough to usb4
<Dcow[m]>
I have thunderbolt monitor. If it help, I can setup tracer over weekend
<sven>
a single one isn't enough
<Dcow[m]>
it's 5k
<sven>
I'd like to see two screens on a single usb4 connection
<jannau>
the studio display might work
<sven>
does 5k always require 2 separate dp streams?
<jannau>
with another monitor connected
<sven>
yeah, that should work as well
<sven>
I neither have a studio display nor a pro/max though :D
<Dcow[m]>
it's LG Ultrafine 5k, not studio, but it's AFAIK it's tiled
<Dcow[m]>
but it's working with m1 mini
<sven>
might be still interesting to see
<sven>
but i'm mostly interested in what happens on pro/max with two display streams going over a single atcphy port
<Dcow[m]>
what trace are you intrestred, m1 or m1 max?
<sven>
if it works on the m1 it's likely just a single stream and i can test that myself
<Bastian[m]>
may be a dumb question, would this be something different than these adapter things https://www.amazon.com/dp/B09N6R91DZ do to get dual monitor support?
<dottedmag>
I have 5K LG UltraFine monitor (5120x2880) that is definitely multi-stream and it works with M1.
<dottedmag>
If this is an interesting configuration I can set it up in a ~week's time for tracing.
<sven>
huh, yeah. if it's definitely multi-stream that would be very interesting
<dottedmag>
OK, I'll ping you once I'm around this monitor again :)
<sven>
Bastian[m]: yes, display link doesn't use DP altmode or DP tunneling at all
<jannau>
Bastian[m]: no, displaylink is not a display output for this question
<sven>
it's just a usb3 device that needs a driver which sends the framebuffer over some proprietary protocol
<dottedmag>
I know this LG is multi-stream because I saw how utterly broken it is under Linux on Intel + GNOME or sway. It was funny seeing GNOME using two parts of displays as two outputs, and even somewhat usable.
<ar>
displaylink is cursed. i had a docking station for a work laptop based on that a couple jobs ago, and it was very bad experience
<Bastian[m]>
I love that the answers start with yes and no :D thank you
<sven>
hrm, i'm quite surprised that it works at all on the M1
<dottedmag>
Me too. Maybe that's the reason why Apple does not advertise two-monitors support for M1: it would be too hard to tell apart which combinations would work and which ones won't.
<sven>
just to confirm, it comes up with the full 5k resolution on the m1?
<dottedmag>
Yes.
<dottedmag>
Ah, does it matter how is it connected? I only tried Thunderbolt.
e1eph4nt has joined #asahi-dev
<sven>
hrm, so looking at the spec from display port it seems that 5k should be possible even with a single stream
<jannau>
my dell 4k display which needs mst support for 60fps is not driven in mst mode by macos
<jannau>
but the lg display was sold by apple so maybe they handle it specially
<sven>
so maybe that display just supports the higher bandwidth DP modes and linux just messes up and tries to use MST instead?
<marcan>
maz: this isn't released/merged anywhere yet, but feel free to merge/cherry pick bits/150-xhci-firmware
<sven>
would still be interesting to see what exactly happens
<dottedmag>
Hmm. Might be.
<sven>
either way, let me know once you're that monitor again. i'd like to see a full atcphy + crossbar trace
<sven>
+around
<marcan>
you need https://github.com/lzfse/lzfse (lzfse.so in your ld path) and then clone asahi-installer and run `python -m asahi_firmware.update /boot/efi/asahi /boot/efi/vendorfw/firmware.tar /boot/efi/vendorfw/manifest.txt && /usr/bin/update-vendor-firmware`
<Dcow[m]>
Do I need to have new installation of macos for hv?
<Dcow[m]>
or I can add m1n1 into chain for the current one?
<dottedmag>
sven: roger that
<marcan>
sven: apple historically had 5K displays in tiled mode (e.g. the one in my iMac, which doesn't work, so I'm stuck at 4K)
<marcan>
though that almost looks like a videowall thing, with the bezel stuff
<marcan>
but who knows, maybe it's a generic thing that also works for that 5K stuff
<sven>
I wonder what exactly it does to support that
<marcan>
maybe this is what that core0/core1 thing is for?
<sven>
yeah, could be
<sven>
would be interesting to see how it configure the crossbar in that setup
<sven>
I think it can route any dispext to any atcphy (i.e. even across cores) fwiw
e1eph4nt has quit [Ping timeout: 480 seconds]
<sven>
the top level handler is display-crossbar0 and there's also only a single one in the t6x ADTs which contains all dispexts and all atcs
<sven>
and I don't see anything that limits e.g. dcpext0 to only atcphy0 and 1
<marcan>
interesting
<marcan>
guess they really went all out on that d2d link
<sven>
yup. also makes our lives easier since we can mix and match dcpexts to atcphys however we want :-)
<sven>
*lifes
<nicolas17>
what's atcphy?
<sven>
the type-c phy that sits behind each usb c port and handles all the magic low-level physical stuff
<nicolas17>
oh, Apple Type-C?
<sven>
probably
<DmitrySharshakov[m]>
Essentially a multiplexer which can connect Type-C pins to either DisplayPort, Thunderbolt, USB 3 or some debug stuff probably
<DmitrySharshakov[m]>
Btw does atc support 2x2 scheme where you give 2 lanes for DP and 2 for USB 3 link?
<marcan>
the debug stuff is unrelated
<DmitrySharshakov[m]>
Of course that works with TB, but that should be a variant for the DP altmode as well IIRC
<sven>
it's also much more than a mux
<DmitrySharshakov[m]>
marcan: It uses SBU?
<sven>
but yes, it supports USB3+DP-altmode at the same time
<marcan>
the debug stuff is muxed by the type C controller chip and never uses the SS lanes
<marcan>
ATC is exclusively about the SS lanes
<marcan>
and it is not a mux, it is a PIPE multi-phy and a bunch of stuff around it
<marcan>
DisplayPort, TB, USB3 are not separate PHYs
<marcan>
it's a combined PIPE PHY
<nicolas17>
"PHY Interface for PCI Express"?
<marcan>
yeah, lol
<DmitrySharshakov[m]>
marcan: Ah, alright, quite a lot more complex thing
<nicolas17>
damn acronyms
<sven>
yeah, it also does dwc3 and thunderbolt NHI power, reset and clocks
<marcan>
the HS lanes are connected directly to dwc3, right?
<sven>
there's a usb2 phy somewhere inside ATCPHY as well
<marcan>
of course, but I mean there's no mux
<sven>
i don't think so
<marcan>
it's the same usb2 phy block as the debug block
<marcan>
so probably pretty dumb and stand alone
<sven>
there's just some weird interaction if you switch the SS lanes to USB3 and try to use USB2 at the same time without bringing up the USB3 PHY
<marcan>
that just sounds like dwc3 gets confused
<sven>
yeah, pretty much
<sven>
there's a lot of ways to confuse dwc3 if you slightly misconfigure atcphy
<sven>
and a few ways to trigger some watchdog that resets the entire SoC as well
<marcan>
lol
<marcan>
that's probably cio?
<nicolas17>
I wonder if the iPad Pro 3/4 uses the same
<sven>
that's what I think
<marcan>
or tmu
<nicolas17>
(iPad Pro 5 obviously does, since it's M1)
<sven>
so one way to break everything is to enable the CIO clock/power-domain/whatever without having powered up ATCPHY first
<sven>
resets the whole thing in ~3 seconds
<sven>
then there's what's likely the CIO watchdog which resets the SoC after ~30 seconds if you bring up ATCPHY and then enable the CIO power-domain/whatever but don't boot CIO
<marcan>
oh of course
<marcan>
if you do that, cio crashes
<marcan>
and that probably triggers the watchdog
<sven>
yeah
<sven>
there's another way to reset everything as well if you misconfigure some of the lanes even without involving CIO
<sven>
dunno what exactly I did to trigger that though
<marcan>
heh
<marcan>
I mean on t8112 the soc crashes if you *read* the wrong mmio range so...
<marcan>
there's lots of stupid stuff like that
<sven>
heh, yeah
<marcan>
anything that triggers a fault in the wrong place
<sven>
probably something dumb like that
<marcan>
also macos is even pickier because it enables AMCC IRQs
<marcan>
and then any weirdness gets a panic
<marcan>
we should implement that in linux some time, to catch mistakes
<sven>
yeah
<marcan>
(just don't make it into a panic...)
<sven>
yup :D
<nicolas17>
in theory could we tell the AMCC to make the kernel code pages permanently read-only like XNU does? and does that have a chance of getting upstreamed?
<marcan>
that happens in CPU registers
<nicolas17>
yeah I think they're MSRs
<marcan>
but that will never work for typical linux
<marcan>
because it can't work with modules
benpoulson has joined #asahi-dev
<marcan>
also, Lina told me the other day she figured out it breaks huge pages covering the read-only region, which is ridiculous
<marcan>
so given that little factoid, I'd consider it too broken to use in Linux
<marcan>
apparently that's why she'd been getting faults trying to read GPU firmware for crash dumps... Apple started setting CTRR for the firmware region, and m1n1 uses huge pages when it can
<marcan>
maz: so yes, we have another architecture break here, lovely.
<marcan>
in recent firmwares you can't use huge pages for lowmem, it throws up an address size fault (!)
e1eph4nt has joined #asahi-dev
<nicolas17>
well there's security models where the Linux kernel and its modules are signed and root can't load new modules at runtime, which is quite Apple-like and could allow for KTRR, but if it breaks other things... eh
<marcan>
I guess they implement CTRR in the MMU/TLB, and since they can't get the proper granularity if you use 32M pages, it just... forbids them in/overlapping the region
<marcan>
thankfully there is no 32M region that overlaps user RAM and the CTRR region, so this only affects special-purpose memory
<marcan>
but ew
<marcan>
nicolas17: loading modules at all is unlikely to work, the way Apple does things, all the modules are pre-linked and all the text sections combined and made contiguous
<marcan>
you need something like that to get all the text regions to be continuous in physmem
* marcan
sleeps
<sven>
yeah, as much as I like the idea of KTRR I don't see that happening with linux :(
benpoulson has quit [Remote host closed the connection]
<nicolas17>
and no it doesn't prevent loading modules from userland, it requires them to be signed
<DmitrySharshakov[m]>
Lockdown is just signature verification and many other rules enforced
<DmitrySharshakov[m]>
x86 does not have hardware RO memory (well, maybe somewhere in the SMM...)
<DmitrySharshakov[m]>
So lockdown mode does not make kernel image immutable to itself
<nicolas17>
DmitrySharshakov[m]: I know, I just meant it would be a prerequisite
<DmitrySharshakov[m]>
Yes, but kernel has to write parts of its memory to link a module in
<nicolas17>
if you don't use lockdown mode and intend to allow root to load arbitrary modules, then you surely can't use KTRR anyway :)
<DmitrySharshakov[m]>
However I guess some parts of the kernel might be extra hardened, at least some code which is never touched while module loads
<DmitrySharshakov[m]>
This will lock us out of kexec and kpatch
<nicolas17>
lockdown mode disables kexec too
<DmitrySharshakov[m]>
Idk if we can lock some generally immutable parts and will it make any sense if something will have to be RO for modules to load
<DmitrySharshakov[m]>
nicolas17: It does restrict it to SecureBoot, doesn't it&
<DmitrySharshakov[m]>
s/&/?/
<marcan>
it doesn't make sense to lock only part of it. the whole thing only makes sense from the premise that *all* of the kernel is locked down and the CPU is locked down so it can *only* execute from that region.
<DmitrySharshakov[m]>
Well yes, since if something in between entrance and exit of higher EL is RW to evil forces, they can make it call outside of the secure area
<nicolas17>
DmitrySharshakov[m]: there was significant opposition from Torvalds and others against tying lockdown and secureboot, so the patch that was ultimately merged makes them independent
<nicolas17>
it's questionable if it's useful to have one and not the other, but you can
<marcan>
it isn't
<marcan>
they are different threat models
<marcan>
secureboot protects against physical attacks, lockdown protects against runtime attacks
<marcan>
they certainly complement each other, but they do make sense in isolation
<DmitrySharshakov[m]>
Well how does XNU load its kexts? Or doesn't it do that at all on aarch64?
<nicolas17>
the arguments were "lockdown without secure boot will instill a false sense of security, since the lockdown can be circumvented by attacking the boot chain" and "a kernel that supports secure boot without lockdown can be compromised after boot to run untrusted code in kernel mode"; that argument lost and they were made independent :)
<marcan>
DmitrySharshakov[m]: it doesn't
<nicolas17>
DmitrySharshakov[m]: afaik there's a monolithic "kernel cache" that is basically the kernel and the modules pre-linked, and it gets loaded as a single unit
<marcan>
exactly
<marcan>
and there is an "AuxKC" that contains all third-party kexts, which is also pre-provisioned and that must happen in recovery mode
<DmitrySharshakov[m]>
Yes, so all other devices are handled by userspace drivers since they aren't in kc?
<marcan>
so it's two text regions, one for the apple stuff, one for everyone else's
<DmitrySharshakov[m]>
marcan: Do end-users ever use this kind of thing?
<marcan>
yes
<nicolas17>
DmitrySharshakov[m]: in Apple's ideal world, all other devices are DriverKit (userspace), but kexts are "unfortunately" still a thing so there's the "AuxKC" as marcan said
<marcan>
there is automation to make it soooomewhat seamless to users
<marcan>
it involves a reboot through recovery mode that shows a progress bar then comex back
<marcan>
and a lot of really fiddly stuff to make it secure
<marcan>
*comes back
<nicolas17>
but Apple has been progressively making it more of a pain in the ass to load kexts for many years now
<DmitrySharshakov[m]>
Well, so looks like there's no practical use of mainlining such a feature. It could be done for special occasions though I guess
<nicolas17>
yeah, I hadn't realized modules were such a problem for this
<DmitrySharshakov[m]>
Building modules in to make a monolithic kc-like kernel without module support and then locking kernel memory into RO
<DmitrySharshakov[m]>
Might be useful for some people if internal parts + USB common classes are embedded this way. However, as I mentioned, that monolithization of the kernel would be certainly not upstreamable
<DmitrySharshakov[m]>
Well, and tun, and wireguard etc. Non-modular Linux is as possible as kext-free macOS is, but not really decent for most cases
<tpw_rules>
would it be possible to pre-load all modules into memory but not actually call them unless necessary?
<tpw_rules>
that sounds like what the kernel cache does anyway
<DmitrySharshakov[m]>
Possible, but not feasible
<tpw_rules>
why not?
<DmitrySharshakov[m]>
Just recalled Logitech input is also a kernel module on Linux (at least rich functions). Having tons of userspace drivers isn't great, so that's not a good way to go
<DmitrySharshakov[m]>
tpw_rules: Their size I guess
<tpw_rules>
"Yes, but kernel has to write parts of its [code] memory to link a module in" does this go beyond actually loading the module into kernel space?
<DmitrySharshakov[m]>
kernelcache has essential drivers (parts of the Mac itself and basic externals)
<DmitrySharshakov[m]>
tpw_rules: Probably not
<DmitrySharshakov[m]>
But I couldn't imagine having all the modules built in
<tpw_rules>
so you just wouldn't want to reserve the RAM required
<DmitrySharshakov[m]>
Imagine we only can have USB pluggable devices. There's just a ton of them
benpoulson has joined #asahi-dev
<DmitrySharshakov[m]>
However, somebody has to calculate that
<DmitrySharshakov[m]>
Well, `/lib/modules/<ver>/kernel` contains xz-ed modules, they could be counted (including un-xz-ing them)
<sven>
I don’t think size is a good point here
<sven>
i don’t know how exactly Linux module loading works but I’d expect that you’d need some major changes to make it put all text in a region it’ll never have to write to
bluetail21 has joined #asahi-dev
<DmitrySharshakov[m]>
Dumping a lot of drivers out of Fedora's aarch64 modules package yielded 160 MiB with not all drivers decompressed
<DmitrySharshakov[m]>
Why is contiguous text region necessary for this thing?
<DmitrySharshakov[m]>
I guess it can be achieved when linking modules in (config Y), which essentially produces the same thing as kernelcache
<sven>
because you can only protect a single contiguous region with KTRR
<DmitrySharshakov[m]>
cannot kernel executable code be protected as well?
<sven>
???
<nicolas17>
if you protect the kernel's core executable pages with KTRR, now you used up your single region, and modules are still writable
<DmitrySharshakov[m]>
I guess kernel will be around 150 MB if compiled with all modules for builtin devices and whatever can be hotplugged. Quite a lot for kernel image
<nicolas17>
and if you overwrite a module's code then you get that executed in kernel mode anyway
<DmitrySharshakov[m]>
Builtin modules should be in the same region
<nicolas17>
so you don't really win much security by protecting the kernel alone without modules
<DmitrySharshakov[m]>
nicolas17: I mean protecting the kernel _with_ modules
<DmitrySharshakov[m]>
With them being statically linked together
<nicolas17>
you mean not building them as modules to begin with, but inside the kernel? that may be possible yeah
<DmitrySharshakov[m]>
Exactly
<DmitrySharshakov[m]>
Just like kc, a single monolith
<DmitrySharshakov[m]>
What's the largest kernel image ever built and what could possibly stop it from working when tons of unused modules are linked in?
<nicolas17>
I guess the other problem is that putting "an attacker gets arbitrary write in kernel mode" into your threat model, that opens a big can of worms even if you protect code with KTRR :P
<DmitrySharshakov[m]>
Yes. So we're left with the only approach to enabling ktrr: evict everything from the kernel land and make them use VFIO to implement their PCIe card drivers in userspace and libusb for usb ofc
e1eph4nt has quit [Ping timeout: 480 seconds]
<DmitrySharshakov[m]>
Someone has to try building everything needed in and enable the thing
<DmitrySharshakov[m]>
Gentoo users will definitely enjoy the concept of building a moduleless kernel
e1eph4nt has joined #asahi-dev
bisko has joined #asahi-dev
<DmitrySharshakov[m]>
Well, if somebody cares, that could be a kernel build-time option, which implies nothing can be built as a module. This would open a way for some really special scenarios where people can easily do a custom monolithic kernel build
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
cuolin^ has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
benpoulson has quit [Remote host closed the connection]
e1eph4nt has joined #asahi-dev
benpoulson has joined #asahi-dev
cuolin^ has quit [Ping timeout: 480 seconds]
cuolin^ has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
benpoulson has quit [Remote host closed the connection]
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
chengsun has joined #asahi-dev
chengsun_ has quit [Ping timeout: 480 seconds]
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
jluthra_ has quit [Remote host closed the connection]