marcan 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
rjeffman has quit [Ping timeout: 260 seconds]
luca020400 has quit [Ping timeout: 260 seconds]
Caloludr has joined #asahi
tomboy64 has quit [Ping timeout: 246 seconds]
riker77 has quit [Ping timeout: 245 seconds]
riker77 has joined #asahi
mxw39 has quit [Quit: Konversation terminated!]
raster has quit [Quit: Gettin' stinky!]
maknho has quit [Ping timeout: 252 seconds]
maknho has joined #asahi
phiologe has quit [Ping timeout: 250 seconds]
odmir has quit [Remote host closed the connection]
phiologe has joined #asahi
odmir has joined #asahi
odmir has quit [Remote host closed the connection]
KindOne has quit [Ping timeout: 240 seconds]
KindOne has joined #asahi
KindOne has quit [Ping timeout: 260 seconds]
KindOne has joined #asahi
odmir has joined #asahi
marvin24 has quit [Ping timeout: 250 seconds]
marvin24 has joined #asahi
odmir has quit [Ping timeout: 260 seconds]
Nazral has quit [Ping timeout: 265 seconds]
Nazral has joined #asahi
HeN has quit [Quit: Connection closed for inactivity]
VinDuv has joined #asahi
herbas has joined #asahi
herbas has quit [Client Quit]
karlyeurl has quit [Ping timeout: 245 seconds]
karlyeurl has joined #asahi
ephe_meral1 has joined #asahi
Bublik_ has joined #asahi
Bublik has quit [Ping timeout: 252 seconds]
luca020400 has joined #asahi
VinDuv has quit [Quit: Leaving.]
tomtastic has quit [Ping timeout: 245 seconds]
vimal has joined #asahi
tomtastic has joined #asahi
tomtastic has quit [Ping timeout: 245 seconds]
wicast has quit [Quit: WeeChat 3.1]
herbas has joined #asahi
herbas has quit [Client Quit]
klaus has joined #asahi
herbas has joined #asahi
herbas has quit [Client Quit]
HeN has joined #asahi
tomtastic has joined #asahi
maz| is now known as maz
konradybcio has quit [Ping timeout: 245 seconds]
konradybcio has joined #asahi
ephe_meral1 has quit [Ping timeout: 252 seconds]
raster has joined #asahi
choozy has joined #asahi
Bublik_ has quit [Ping timeout: 260 seconds]
Bublik_ has joined #asahi
nimroot[m] has joined #asahi
<nimroot[m]>
Is anyone aware what NIC is used for M1 MBA? All information I could get is that it's wifi-6 / bluetooth 5.0 compatible.
<arnd>
nimroot[m]: bcm4378
<arnd>
corellium have a fairly small patch for drivers/net/wireless/broadcom/brcm80211/brcmfmac/ to add support
<pipcet[m]>
(that's wifi, not bluetooth, iiuc)
<pipcet[m]>
their main hack is that the mac address is stored in the device tree rather than on the device
<pipcet[m]>
they have some horrible scheme to load the driver, figure out which firmware to use, then re-load the driver after setting the firmware path
<arnd>
the patch does a bunch of things, it also adds the PCI device ID (that part is probably fine), and some bits for interrupt handling that I didn't understand but that are probably needed in some form
kov has joined #asahi
<pipcet[m]>
I just wanted to point out there's a userspace hack as well. /usr/bin/wifistart in their ubuntu image or something like that.
<tmlind>
probably the wlan nvram mac address should be handled by a separate driver and the wlan driver could then ask for it?
<pipcet[m]>
probably, the firmware's a little trickier though, IIUC
<tmlind>
depending on what all the nvram is used for and assuming it's on some separate controller, syscon might be usable in the simple cases for handling the nvram. but only if no other real framework is around to deal with it i'd say :)
<pipcet[m]>
syscon?
<pipcet[m]>
it's not a simple memory-mapped device, I think that's limited to those cases?
<pipcet[m]>
or am I misreading that?
<tmlind>
yeah a proper driver for using some generic framework would be always better, in any case syscon is documented at Documentation/devicetree/bindings/mfd/syscon.yaml
<pipcet[m]>
thanks, I'll have a look
ephe_meral1 has joined #asahi
<pipcet[m]>
I don't consider the wifi bit in particular a major issue, but it might be a good place to start if people here insist on rewriting all the Corellium code since it's relatively self-contained.
rjeffman has joined #asahi
Nazral has quit [Ping timeout: 252 seconds]
Nazral has joined #asahi
Namidairo has quit [Read error: Connection reset by peer]
Namidairo has joined #asahi
<kettenis>
the mac address will be in the device tree, all the driver has to do is pick it up from there like the tg3 driver already does
<tmlind>
sounds good to me
taziden has quit [Ping timeout: 250 seconds]
taziden has joined #asahi
kettenis has quit [Ping timeout: 240 seconds]
kettenis1 has joined #asahi
VinDuv has joined #asahi
<marcan>
pipcet[m]: it wasn't the community reaction that got corellium to reconsider putting more resources into it; it was the opposite
<marcan>
the CTO had DMed me about them being working on this internally before; I asked for details and he said "oh actually it's not a priority any more"
<marcan>
then I heard nothing from them until around when the macOS beta with external kernel support was released; I tweeted something about not being able to use the old sandcastle kernel they had released (because it wasn't properly signed off nor had it been released with usable history / any kind of traceability)
<marcan>
the CTO got mad at me, went on a nonsensical tirade on DMs, while I tried to calmly explain what would be needed for the community to be able to use their code
<marcan>
then he stopped replying, and they announced "we've ported Linux to M1" the next day
<marcan>
then the next day they released a kernel blob (no source) that also contained the broadcom firmware embedded (taken from macOS, not legally redistributable)
<marcan>
I pointed that out, they removed the file from their server, then it came back without the blob
<marcan>
the whole thing was very clearly a reactionary thing to get some PR for them, because the CTO was mad at me because I said we couldn't use a vendordump-style kernel with no signoff
<marcan>
but after this PR stunt, they promised to upstream things and never did; never_released tried to upstream some bits and they never replied on the mailing list to any of that series
<marcan>
nor did they reply to any of my submissions, which were CCed to them
<marcan>
as far as I can tell, they have no real interest in upstreaming; given the lack of communication from them, and that they haven't even updated their kernel since february, it was 1) a background PR project they had, but with little interest in upstreaming, which 2) they hastily released to stick it to me, and then 3) made empty promises about upstreaming, but quickly 4) lost interest after realizing ...
<marcan>
... it takes real effort to do things right and get them upstreamed rather than just dump out a PoC on github
<marcan>
I have strong evidence that their drivers are developed by reverse engineering macOS drivers; that may or may not be legal depending on how they do it exactly, but without further assurances about their development process, I am not willing to risk things by working directly with their code as a base
<marcan>
either way, we clearly have very different development methodologies, and goals; if they want to help the community out, they can start by talking to us :-)
<marcan>
personally, given that they obviously have at least self-made hardware documentation (since their main product is a VM after all), if they want to gain some community goodwill I would suggest they start releasing that, rather than a PoC kernel :-)
<marcan>
but given some of what I've seen in their code, I have my doubts that they are as thorough as I try to be when understanding hardware; after all, to make a VM you just need to bullshit things enough for the one OS that matters (iOS) to run on it, not actually understand the hardware fully :-)
<svenpeter>
Less drama, more mmiotracer please :P
<marcan>
exactly.
<marcan>
so yeah, that's the story, and now I'm going to go to sleep and see if I can actually be productive tomorrow :P
KindTwo has quit [Remote host closed the connection]
Swant is now known as IKEA
IKEA has quit [Remote host closed the connection]
VinDuv has quit [Quit: Leaving.]
<jeffmiw>
about the mmiotracer, I've been trying to run some code in EL1 with HCR_EL2.VM bit set to get the stage 2 translation working for the hypervisor
Swant has joined #asahi
<jeffmiw>
I have failed so far :( but not giving up...
<jeffmiw>
I'm getting an instruction abort due to a level 0 translation at the first instruction after the ERET which means my VTCR_EL2 & VTTBR_EL2 settings are wrong
<jeffmiw>
so I'm going to check all bits again to at least get some instructions going in EL1 with stage2 translation active
<jeffmiw>
did anyone play with stage2 translation thanks to HCR_EL2.VM bit set ?
Swant is now known as IKEA
IKEA has quit [Remote host closed the connection]
Swant has joined #asahi
<pipcet[m]>
well, if it helps us get better code I'm perfectly okay with some drama :-)
<pipcet[m]>
what are the mmiotracer plans, actually? play hypervisor for MacOS using m1n1?
<sven>
pretty much
<sven>
and then at least intercept read32/write32 from macos to understand how the hardware works
<pipcet[m]>
can we actually boot macos yet?
<sven>
don't think so
<jeffmiw>
not tried yet
<pipcet[m]>
I very briefly tried to even find whatever macos boots instead of our macho binary
<jeffmiw>
but that should work if you just do chainloading without messing up with hypervisor stuff
<sven>
yeah, the xnu kernel should be able to run in both el1 and el2 without any changes
<sven>
probably needs some patches to the ADT but should be fine otherwise
<pipcet[m]>
so, uh, where is the xnu kernel, actually?
<sven>
it's complicated :-)
<sven>
there's a macho binary with just the kernel somewhere in /System
<sven>
but what gets actually booted is what apple calls kernelcache i think
<sven>
which is essentially the kernel + all kexts
<pipcet[m]>
and do we know that testing whether it's running under a hypervisor and bailing if there is one isn't the first thing that does?
<sven>
doesn't really matter, we could just patch those checks
<sven>
but as i said, the kernel looks like it'll run just fine in el1
<pipcet[m]>
I can think of relatively cheap ways for Apple to potentially have done this, so all I'm saying it might be a good idea to work out how to start MacOS in EL0 first, then worry about the mmiotracer if there's a chance it might work.
<pipcet[m]>
done this = prevented virtualization of their hardware
<sven>
okay, let me rephrase: i'm 99% sure the kernel will run just fine in EL1 on Apple Silicon hardware
<pipcet[m]>
that would be wonderful!
<sven>
it will fail fairly early on non-apple hw though once it tries to access apple specific MSRs or instruction set extensions
<nimroot[m]>
marcan: just read the story and that's just messed up. Wouldn't imagine that Corellium is such a Karen.
<pipcet[m]>
if it's that easy, I still think it might be worth it to try stealing a CPU core from macos and run our code on that in parallel to macos. We wouldn't see the MMIO accesses directly, but we could do some debugging nonetheless
<sven>
not sure what that would gain us compared to running it under a hypervisor
<pipcet[m]>
easier to do, higher likelihood of working, less valuable data.
<sven>
i disagree on all three points :D
<sven>
actually, no
<sven>
just on the first two
<pipcet[m]>
not the third one, hopefully :-)
<sven>
yeah :-)
<sven>
running xnu itself in el1 is really just a matter of maybe patching the ADT and loading the kernelcache correctly
<sven>
after that we can add the 2nd stage translation
<sven>
or if you still doubt that it'll even run in el1 just take a working kernel and patch _start to drop to el1 as early as possible
<pipcet[m]>
I might do that.
<sven>
iirc project zero did that stealing a cpu core thing to build an ios debugger. they abused some debug registers though to actually debug the other cores
<sven>
and i'd be surprised if these still exist on the m1 ;)
<nimroot[m]>
It might be a stupid question, but what's EL1 and what's EL2?
<pipcet[m]>
if there really is a macho binary that starts macos we should get that working ASAP and see what we can make it do
<sven>
nimroot[m]: "exception levels". i believe x86 calls these "rings"
<PthariensFlame[m>
nimroot: Architectural parts of (modern) Arm processors. Think of them like X86's "rings", if you're familiar with those.
<PthariensFlame[m>
nimroot: EL1 is where OSes generally run; EL2 is where hypervisors generally run.
<sven>
the m1 also has gl1 and gl2 (guarded levels apparently) on top of that which are the same as el1/2 but the meaning of some permission bits in the pagetables change
<sven>
but we can ignore those for linux
<PthariensFlame[m>
sven: Is that RE'd, or a documented part of Arm?
<sven>
PthariensFlame[m: it's apple-specific
<nimroot[m]>
I see, yeah, I'm as familiar with cpu architecture as what college taught me (so not very much), but now I get what you are talking about :D
<sven>
i've played around with those a little bit today. don't think they are documented anywhere yet
<PthariensFlame[m>
Vestiges of their preliminary attempt at BTI?
<PthariensFlame[m>
Or am I understanding "guarded" wrong?
<sven>
i don't know what BTI is
<j`ey>
branch target identification
<j`ey>
aka stops you branching to random places in code
<PthariensFlame[m>
Yeah.
<sven>
and i think the guarded name is misleading, it's essentially https://siguza.github.io/APRR/ with more custom extensions
<PthariensFlame[m>
It's a required part of Armv8.5, which M1 almost implements.
<PthariensFlame[m>
<sven "and i think the guarded name is "> Oh, okay!
<sven>
i believe it's meant to prevent most of kernel text to modify pagetables
<PthariensFlame[m>
That makes sense.
<sven>
i'll finish figuring out some details this week and document it then :)
<PthariensFlame[m>
Yay!
klaus has quit [Ping timeout: 252 seconds]
rjeffman has quit [Ping timeout: 260 seconds]
maknho has quit [Ping timeout: 252 seconds]
<pipcet[m]>
hmm, so it's not absolutely trivial to boot a macho kernel, it seems, but that doesn't mean much.