ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Chrome OS Trogdor Devices - Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630 - Lenovo ThinkPad X13s - and various other snapdragon laptops) - https://oftc.irclog.whitequark.org/aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<clover[m]>
steev: grats on the t14s
<steev>
don't grats me yet ;)
<steev>
the x13s arrived as a p14 or something and took them 2-3 more months to get me the x13s
chrisl has joined #aarch64-laptops
tobhe_ has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<clover[m]>
you got a new x13s?
<clover[m]>
or was that a typo
tobhe has quit [Ping timeout: 480 seconds]
<clover[m]>
push 6.12.9 to x13s arch repo. one thing i noticed is modemmanager is no longer working.
<clover[m]>
May 26 18:55:17 eos ModemManager[668]: <msg> [base-manager] couldn't check support for device '/sys/devices/platform/soc@0/1c00000.pcie/pci0006:00/0006:00:00.0/0006:01:00.0': not supported by any plugin
<steev>
clover[m]: no, my only x13s... when i ordered it, initially they shipped me the wrong laptop
<steev>
nice abby! congrats!
<clover[m]>
Nice abby
<bamse>
+1
<abby>
other mainline devices should work too, but those are the ones we could test :)
mbuhl has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
spawacz has quit [Quit: WeeChat 3.8]
chrisl has joined #aarch64-laptops
pbsds is now known as Guest7769
pbsds has joined #aarch64-laptops
Guest7769 has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
alfredo has quit [Read error: Connection reset by peer]
icecream95 has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<icecream95>
If I do eventually get Windows running under my hypervisor, I am a little worried about releasing it, since it's a rootkit.
<icecream95>
Even though it won't bypass Secure Boot or TPM-based encryption, Microsoft might not like it and could completely lock down EL2 on future SoCs...
<icecream95>
Then again, the secure-launch bug was probably never a deliberate feature, so they might just "fix" it anyway.
<JensGlathe[m]>
Huh. Don't let that hold you back. Every chance we get on probing this DSP (and other) stuff is a window of oportunity. Or do you want to work @ MSFT?
<icecream95>
Working at Microsoft might be fun, I could put in so many backdoors!
<icecream95>
(And I would use Copilot to write them so it looks like the LLM's fault)
<travmurav[m]>
> the secure-launch bug
<travmurav[m]>
I insist it's a feature
<travmurav[m]>
I'm using code that was very deliberately added into both tcblaunch and winload.exe
<JensGlathe[m]>
then that's a feature
alfredo has joined #aarch64-laptops
<travmurav[m]>
(tl;dr there is an error handler in tcblaunch that returns to winload if booting the next stage failed, and slbounce is just a very broken winload that only knows how to handle errors as far as tcblaunch is concerned)
<travmurav[m]>
pretty sure there are enough tpm measurements inbetween and merely running slbounce requires disabling SB that it's a non-issue from MS security model perspective
<icecream95>
But there's no fundamental reason that the error handler has to be in EL2 rather than EL1, is there?
<travmurav[m]>
well the error handlier /is/ in EL1 just that side effect we need happens at the very start of tcblaunch
<travmurav[m]>
i.e. tcblaunch boots in EL2 , sets vbar_el2 and immediately demotes to el1
<travmurav[m]>
but since setting vbar is the very first thing it has to do (if it wants to run in el1 later), we get it's vbar
<travmurav[m]>
so what they could do if they wanted to is to scrap the whole error handler stuff (which involves quite a bit of code and probably some special binary linking on winload side since there is a special PE .trans section for the return code)
<travmurav[m]>
so I'm hoping they don't care enough and it will stay xD
<travmurav[m]>
but well yes, obviously we're using an internal MS mechanism that could change any moment
<travmurav[m]>
the only thing I insist on is that it's not a bug :D
<icecream95>
I was using the term "bug" loosely, but as long as Microsoft don't think it's a bug then we're fine
<travmurav[m]>
I kinda want to avoid the word "bug" since it implies it "needs" to be fixed, and I believe (and we all want that) it doesn't xD
<travmurav[m]>
but also "bug" in a thing like this implies that I abuse a security issue that I haven't responsibly disclosed, though I've specifically checked MS guidelines and did a bit extra RE to make sure it's not
<travmurav[m]>
fwiw I'm pretty sure at least /some/ people in MS are aware of it and we didn't have it removed in latest windows on x1e yet ;P
<icecream95>
But just think how quickly I could get that changed with a few Cee-Vee-Ees!
<travmurav[m]>
speaking of cve, I wonder if sd-express on x1e works in uefi
* icecream95
looks sadly at internal USB card reader
<JensGlathe[m]>
Dnapdragon Dev Kit boots from sd as priority
<travmurav[m]>
that one should be connected to internal mmc2 I think
<JensGlathe[m]>
it is
<travmurav[m]>
but some laptops have realtek sd-express controller connected to pcie
<travmurav[m]>
and I'm pretty sure qhee just sets iommu to passthrough xD
<JensGlathe[m]>
this would show up on pcie bus, no?
<travmurav[m]>
I think so
<JensGlathe[m]>
pcie5 I guess?
<travmurav[m]>
idk, probably depends on how the OEM routed it
<travmurav[m]>
I think it was added for surfaces in mainline
<JensGlathe[m]>
there is pce3 (that odd x8 slot not populated) and pcie5 (where the LAN card is on the Dev Kit)
<travmurav[m]>
yeah and this is why high ranking LF members can officially spit in my face instead of saying that in the first place
<icecream95>
But maybe Microsoft will also spit in your face, by *not* "importing" your insights about Secure-Launch, thus keeping slbounce working? :)
<JensGlathe[m]>
I like the "whatever works" approach
<travmurav[m]>
icecream95: thanks for linking that, shame everyone moved this conversation from ethics plane to legal plane but well I've complained enough and I won't repeat myself
<travmurav[m]>
but lol apparently now the official recommendation is to basically not talk to me lol
<JensGlathe[m]>
The Outkast™️
<JensGlathe[m]>
shenanigans
kmeaw has quit [Remote host closed the connection]
<albsen[m]>
I need some tips how to debug a kernel freeze. I've been trying out 6.12 and 6.13 (ubuntu) on t14s. when transferring large amounts of data via wifi I get a kernel freeze that results in data loss and ends up corrupting the ssd so that the firmware can't be loaded anymore from initramfs. how do I see what triggered the kernel freeze?
<icecream95>
albsen[m]: Do you have 64 GB of RAM?
<albsen[m]>
icecream95: yes
<smoorgborg[m]>
albsen[m]: my quality of life improved immensely after disabling half of the RAM in grub - no more screen of death when doing usb transfers etc
<albsen[m]>
smoorgborg: so I could simply deactivate it for the transfer and then re-enable it after. I can try that. whats the grub entry I need to set?
SpieringsAE has joined #aarch64-laptops
SpieringsAE has quit []
SpieringsAE has joined #aarch64-laptops
<albsen[m]>
is this the line to deactivate the ram? GRUB_BADRAM=0x8800000000,0xf800000000 in /etc/default/grub ?
<albsen[m]>
or this one? "add cutmem 0x8800000000 0x8fffffffff` to your /boot/grub/grub.cfg" ?
<smoorgborg[m]>
albsen[m]: This is what I use
<SpieringsAE>
JensGlathe: checked your patch, but jeah it seems identical to what I had, I will do some messing around with the usbc ports today
alfredo has quit [Quit: alfredo]
SpieringsAE has quit [Remote host closed the connection]
chrisl has quit [Ping timeout: 480 seconds]
SpieringsAE has joined #aarch64-laptops
SpieringsAE has quit [Remote host closed the connection]
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
JensGlathe: just reapplied my old patches for dp-altmode on usbc and it works now for some reason
<SpieringsAE>
must have messed up something else back then, it did seem like ps883x was missing from the initramfs, maybe I didn't depmod or something
<SpieringsAE>
grrrr dtb check is messing with me again
<JensGlathe[m]>
venv
<SpieringsAE>
I had a working one, but that seems to have stopped now
<SpieringsAE>
ERROR: dtschema minimum version is v2023.9
<SpieringsAE>
but it is 2024.12 in the venv
<SpieringsAE>
:(
<SpieringsAE>
aaah I think I know
<SpieringsAE>
I've upgraded from python 3.12 to 3.13
<SpieringsAE>
6.14-rc1 drops this weekend?
<albsen[m]>
smoorgborg: thx, setting GRUB_BADRAM=0x8800000000,0xf800000000 in /etc/default/grub appears to have fixed it. for now it's been copying without any crash or panic.
<tobhe_>
albsen[m]: smoorgborg[m]: I guess it is time to enable that by default
icecream95 has quit [Ping timeout: 480 seconds]
neggles has quit [Quit: bye friends - ZNC - https://znc.in]
<smoorgborg[m]>
<tobhe_> "albsen: smoorgborg[m]: I guess..." <- Can anyone explain to me why this is a manufacturer firmware problem? Windows runs fine with all 64GB, and mostly Linux does as well. Isn't it some minor memory area that isn't mapped out correctly that gives this problem?
<smoorgborg[m]>
ELI5 :-)
<travmurav[m]>
have anyone confirmed that the same issues exist on el2 or not?
<travmurav[m]>
depending on that my guess would be that no one tested qhee on non-android devices that never had more than 32GiB so some iommu (for example) code is broken
<travmurav[m]>
but windows doesn't care since it kills qhee anyway
<tobhe_>
this is my current understanding too, also haven't heard of any el2 tests
shawnguo has joined #aarch64-laptops
SpieringsAE has quit [Remote host closed the connection]