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
<marcan> bloom: feel free to set +M if we get another attack
<bloom> ack
Emantor has quit [Quit: ZNC - http://znc.in]
Emantor has joined #asahi
skipwich has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
skipwich has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
<amw> I am seeing 1TR access different from https://www.youtube.com/watch?v=ilnfvkgzVvg - now have to select partition and then login to get to Utilities/Terminal
<amw> I believe it is the 1TR as I can run csrutil disable in there - perhaps new in latest Mac upgrade?
bgb_ has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi
<amw> marcan: Have added a basic help command to shell.py which I think is useful - see https://paste.debian.net/1201723/
<amw> Can update it some more and submit a pull request if your interested - it's quite small change
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
bgb_ has quit [Ping timeout: 480 seconds]
TheJollyRoger has quit [Remote host closed the connection]
TheJollyRoger has joined #asahi
VinDuv has joined #asahi
<amw> Question: Can I run linux under m1n1? The run_guest.py tool requires a Mach-O payload
<amw> When I run the linux.py tool on Linux my USB devices appear to disappear? i.e. m1n1 dis-appears but I am using marcan/dart/dev branch which tries to use dwc3 USB driver ? - See https://paste.debian.net/1201729/
bgb_ has joined #asahi
<VinDuv> I’m pretty sure the m1n1 USB devices will always disappear if you start Linux directly with linux.py; if Linux itselfs starts emulating a USB serial port it will reappear, but the transition won’t be seamless
<VinDuv> You should be able to run Linux under the hypervisor though; for this I think you need to run m1n1 under the hypervisor, then start linux.py with the hypervised m1n1
<amw> VinDuv: Ok - run_guest.py with m1n1.macho and then try linux.py?
<VinDuv> M1N1DEVICE=/the/secondary/virtual/usb/port linux.py …
<amw> ok - otherwise according to https://github.com/AsahiLinux/m1n1#payloads you can concatnate additional payloads to m1n1 and then perhaps chainload that new m1n1?
<VinDuv> yes, I was thinking about that, you should be able to run_guest a m1n1 with concatened payloads and the payload will run under HV
<VinDuv> might be easier
bgb_ has quit [Ping timeout: 480 seconds]
<amw> Hmm plain chainload.py boots up the kernel which boots up to init, but the script times out waiting for serial port to appear. I guess kernel is run at EL2 not under m1n1
<amw> Hmm: Some success with original suggestion run_guest.py -S m1n1-payload.macho - I get a shell, kernel loaded, but all CPUs are started and I don't know where to jump to with kboot_boot?
<amw> Oops I missed the start command - starts up the kernel ...
<VinDuv> you should run a picocom on the secondary m1n1 USB device to see the boot logs
<marcan> amw: do you have FileVault enabled?
<amw> VinDuv: Yes that works (no CRs on linux console messages but initrd is good)!
<amw> marcan: Don't think so. Never used FileVault as far as I know - presume it's a MacOS thingie
<marcan> encryption
<marcan> I believe the security model is that if you have FileVault enabled, you need to authenticate before being allowed to run your own code
<marcan> unless they changed it in 11.4, which they might have
<amw> Aaah - your referencing my original 1TR questions! - I would have to boot back to MacOS and work out how to check if FileVault is set up to answer
<marcan> System Preferences > Security & Privacy > FileVault I believe
<marcan> VinDuv: the problem with running m1n1/linux under the HV is there is no vUART input support yet; been meaning to add that...
<marcan> amw: re run_guest.py, open up a picocom on the secondary USB CDC-ACM device
<marcan> you should see m1n1 boot and at least linux earlycon output
<marcan> but I expect the linux UART driver to really hate my lame vuart
<marcan> (once it loads)
<marcan> also, if the devicetree is instantiating the USB device that the HV is using, that will go very wrong; there is no logic in m1n1 to disable that in the devtree if it's missing in the ADT, maybe that should be added
<marcan> at least I guess I should make the HV unmap that from the guest :-)
<amw> See https://paste.debian.net/1201733/ to see the run_guest.py output ttyACM0 followed by the linux kernel console serial output on ttyACM1
<marcan> kind of impressed it got to a shell, heh
<marcan> no kernel debug args though I guess
<amw> marcan: It's just a initrd that prints in a loop for ever till it locked up at 100?
<marcan> I guess? I didn't write that initrd
<amw> No it's some rubbish debug one I had from months back - just to prove I can run something (with out any input)
<amw> Now I have linux under the HV I need a way to dump the registers and see where it is executing et cetera.
<marcan> yup
<marcan> I've wanted to add a concat thing to set kernel commandlines more easily, something like just 'cmdline:' + commandline + '\0' as a payload format
<amw> It says all the CPUs are running.... Is that right?
<marcan> but for now you can stick it directly in the devicetree
<marcan> no, it shouldn't
<marcan> FDT: CPU 1 is not alive, disabling... etc
<marcan> only CPU 0 should be alive when running under the HV
<marcan> unless you mean the beginning bit
<marcan> the HV *does* start all CPUs
<marcan> then only uses CPU0 except it puts the watchdog on CPU1 (or was it 7?)
<marcan> so technically all CPUs are up but only CPU0 is usable
<amw> The run_guest.py prints out "starting secondary CPUs..." and then 1 ...7 started...
<marcan> yes
<marcan> but the guest only sees CPU0
<marcan> that's just because the m1n1 smp support is initialized with a one shot function that starts all CPUs
<marcan> and the HV wants to use one of the secondaries for the watchdog
<amw> ok - got me excited (and confused :-)
<marcan> it shouldn't be too hard to make the HV support SMP
<marcan> but I need spinlock primitives and some trivial emulation of the cpustart hardware :)
<amw> Is there a command to read a register from the CPU0 ? I'm thinking the PC
<marcan> from the shell? the shell runs on cpu0, you're in that context
<marcan> hv.ctx.elr is the guest return address (i.e. next instruction to be executed after returning)
<marcan> hv.ctx.regs[0] etc will give you the GPRs
<marcan> you can get a backtrace with `bt`
<marcan> I should add more proper debug-friendly commands, like a "show regs" thing :)
<marcan> right now it only does that on exceptions
TheJollyRoger has quit [Remote host closed the connection]
<amw> Wow! That stuff all works great
<marcan> honestly it should just expose a gdb stub at some point, so you can just use standard tools to load symbols etc
TheJollyRoger has joined #asahi
<amw> I'll try to map it by hand to symbols - it looks like it has the same stack trace all the time - halt loop?
<marcan> quite likely the idle loop, yeah
<marcan> you can also do a disasm thing, sec
<marcan> disassemble_at(p.hv_translate(hv.ctx.elr, True) - 32, 64)
<marcan> try that
<marcan> (you need to have gcc/binutils for aarch64 installed)
<marcan> I should make that use keystone/capstone instead of that hideous shell-out hack
<amw> I'm blown away by the power of this - all your commands work great : See https://paste.debian.net/1201734/
<marcan> glad you like it :)
<marcan> and yeah, wfi, so idle loop :)
<marcan> needs a lot more work to make it an ergonomic debugger, but the primitives are there
<marcan> well, except breakpoints and single-stepping
<marcan> that's a big missing thing
<marcan> though there is `step` which is a funny hack that just runs the guest for a few cycles (driven by a timer interrupt)
<marcan> (it should eventually be a real single-step but I haven't gotten around to using the debug hardware yet)
<amw> I can't seem to match up the stack trace addresses to System.map addresses - Perhaps they are all mapped up as it is the guest...
<marcan> you probably have kASLR
<marcan> the stack trace addresses are guest addresses (virtual)
<amw> # CONFIG_RANDOMIZE_BASE is not set
<marcan> hm
<marcan> maybe there's an offset anyway?
<marcan> can you upload the System.map somewhere?
<amw> Have you got a spot? I don't have any servers running on the internet
<marcan> PMed
<amw> Not seeing anything on my weechat = but I'm very newbie...
<amw> I can send an e-mail
<marcan> you should have a separate query window
<marcan> or just /query marcan
<amw> ok - yep - uploaded.
<marcan> ffff8000102fdc30 T cpu_do_idle
<marcan> Stack trace:
<marcan> - 0xfffff000102fdc3c
<marcan> that checks out
<amw> ok - Offset by a little - thanks
<marcan> yeah, because the addresses are the *call* addresses
<marcan> there's no System.map support but.... it should be a one-liner
<marcan> let's see
<marcan> amw: try: hv.symbols = sorted((int(i[0], 16), i[2]) for i in (i.split() for i in open("System.map").readlines()))
<marcan> then `bt` again
<marcan> oh wait, I just noticed the 0xfffff000102fdc3c vs ffff8000102fdc30 - f vs 8
<marcan> huh, wonder what that's about
<amw> I had to put the full path to System.map but bt is unchanged.
<marcan> pauth?
<marcan> ohh the opposite
<marcan> masking is set up for macos, no linux
<marcan> amw: git pull, then run these commands (without restarting the hv!)
<marcan> hv._reloadme()
<marcan> load_system_map("/path/to/System.map")
<marcan> fixed the pac mask thing :-)
<marcan> I guess I should make the pac mask automatic by inspecting the pac registers at some point
<amw> Sorry - had to go drive some one - that didn't do anything though - https://paste.debian.net/?show=1201738;lines=0
<VinDuv> amw: just a guess, but try setting hv.pac_mask = 0xffff000000000000
<VinDuv> (not really sure if it’s the right way to do it, but that should give you more correct addresses I think)
<amw> VinDuv: Nope :-(
<VinDuv> did you get 0xffff8000102fdc3c (four f, one 8) at the top of the stack trace this time?
<amw> Yep: 0xffff8000102fdc3c
<VinDuv> can you get the values of hv.sym_offset , hv.tba.virt_base , and hv.macho.vmin ?
<amw> hv.sym_offset=-0xa110000 , hv.tba.virt_base=0xfffffe001005c000 hv.macho.vmin=0xfffffe0007004000
aleasto has joined #asahi
<amw> Woops just crashed my hv ... disassemble_at(0xffff8000102fdc3c, 8) -> it just rebooted...
<VinDuv> this is definitely not the right way to do it, but if you set hv.sym_offset = hv.tba.virt_base = hv.macho.vmin = 0 and hv.pac_mask = 0xffff000000000000 I think you should get your symbols…
m42uko has quit [Ping timeout: 480 seconds]
<amw> VinDuv: Too many values to unpack Exception.... - see https://paste.debian.net/?show=1201741;lines=0
<VinDuv> did you reload system.map?
m42uko has joined #asahi
<amw> Got this - https://paste.debian.net/1201742/ - how am I reloading the Sysmap?
<amw> Yep - that did it !
<VinDuv> If I’m not mistaken your patch to addr() should not be needed now that you have symbols — if you revert it and hv._reloadme() it you should have a nicer output
<VinDuv> (The bug is in sym(), it should always return a tuple — https://github.com/AsahiLinux/m1n1/blob/main/proxyclient/m1n1/hv.py#L426 should be return None, None)
choozy has joined #asahi
Andalu30 has joined #asahi
crabbedhaloablut has quit []
crabbedhaloablut has joined #asahi
crabbedhaloablut has quit []
crabbedhaloablut has joined #asahi
VinDuv has quit [Quit: Leaving.]
bgb_ has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
VinDuv has joined #asahi
VinDuv has left #asahi [#asahi]
VinDuv has joined #asahi
choozy has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
VinDuv has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
VinDuv has joined #asahi
bgb_ has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
Andalu30 has quit [Ping timeout: 480 seconds]
<marcan> amw: pushed a fix
<marcan> ah, fixed the bug now too
<marcan> (force push)
minecrell has quit [Quit: :( ]
minecrell has joined #asahi
minecrell has quit []
minecrell has joined #asahi
bgb_ has joined #asahi
yuyichao has quit [Quit: Konversation terminated!]
Andalu30 has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
TheJollyRoger has quit [Ping timeout: 480 seconds]
roxfan has quit [Remote host closed the connection]
bgb_ has joined #asahi
<bloom> eyes
roxfan has joined #asahi
bgb_ has quit [Quit: WeeChat 3.0.1]
bps has quit [Ping timeout: 480 seconds]
berryRed has joined #asahi
Andalu30 has quit [Ping timeout: 480 seconds]
Andalu30 has joined #asahi
eta has quit [Quit: Gateway shutdown]
eta has joined #asahi
berryRed has quit [Quit: Leaving]
TheJollyRoger has joined #asahi
aleasto has quit [Remote host closed the connection]
<amw> marcan: Not quite - See https://paste.debian.net/1201788/
<amw> Even using the load_system_map command it's still not working - https://paste.debian.net/1201789/
ml00 has joined #asahi
peaklight__ has quit [Read error: Connection reset by peer]
<ml00> hi, shouldn't these be just if read: and if write:? because False does nothing - https://github.com/AsahiLinux/m1n1/blob/7c19dcc33fbc26dc0def1d1df3f6dad529bf08d4/proxyclient/m1n1/hv.py#L187
<j_ey> yeah that looks weird
<j_ey> marcan: ^
ml00 has quit [Remote host closed the connection]
bps has joined #asahi
Andalu30 has quit []
bps has quit [Ping timeout: 480 seconds]
bps has joined #asahi
choozy has joined #asahi
bps has quit [Remote host closed the connection]
aleasto has joined #asahi
choozy has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
aleasto has quit [Quit: Konversation terminated!]