lenovo t14s 64gb fix: cutmem=0x880000000,0x900000000

tested with stress-ng for 20 minutes, seems stable enough...

now i can use all of the RAM i paid for

minus a 512MB hole so that Linux doesn't trample on Gunyah anyway.

technically 128MB was enough to boot, but stress-ng made it crash immediately. so there is a second mapping somewhere inside 34GB

@ariadne wohoo!! :D nice

@ariadne Why do you always end up finding the most cursed shit? :[

At least you have the patience to figure it out and deal with it.

@chris this one was a known issue but everyone was saying "boot with mem=31g" or "here is a cutmem setting that masks everything above 31g"

i just made an educated guess based on the DTB for where the memory hole should actually be placed

lenovo firmware 2.23 and later *may* have a fix for this (the DTB has changed a bit), but I have no way of updating my firmware at the moment, short of buying an NVMe here in France and installing Windows to it

@ariadne ffs, cut everything above 31G? Did it just never occur to them that someone might want to use more of their memory?

Maybe if you're bored enough you can scan that range somehow and tighten the holes a bit. :/

Or just call it a win that you're getting over 90% and move on with life.

@chris i am getting all 64GB minus a 512MB hole I manually placed. I am happy.

@ariadne Wait wtf, I didn't know you were traveling. Is it possibly a permanent arrangement to beat it out of this dodge?

@chris idk. I need to look at the DTB I extracted from the firmware image more. I could probably update from UEFI shell, but I don't feel like risking it when I can just update the firmware image when I am home in a few weeks.

@ariadne You could install windows on a usb stick using rufus in the windows to go mode. That is assuming you can just boot a regular windows arm image on that laptop with whatever partition stuff qualcomm tends to do.
You also need a system already running windows to run rufus ofc.

@ariadne Not worth messing with for now, then. Sorry if I stirred up plans for further time that could be spent doing other things.

@chris at this point, I have a fix that is solid enough that I have added it to my systemd-boot config. i refused to accept mem=31g as a fix.

@ariadne Good. That's victory enough.

@chris though i could probably tighten the hole a little. gunyah has a similar mapping at 2GB. that's where my educated guess of 34GB came from.

hmm, i wonder if what is happening is that all of the qualcomm crap at 2G...2.5G are shadowed at 34G...34.5G

my guess is: probably

which means i could probably regain more memory with smaller cutmem= reservations

and this is maybe also a security bug as hypervisor resources aren't being protected against writes to the shadowed region?

no ariadne, we are not going down the CVE rabbit hole

i wonder if these addresses are wired on T14s with <64G RAM. but i do not wonder enough to spend money on another T14s.

if we can scribble on hypervisor memory in the 34GB shadowed region, then we can make the hypervisor crash (this is why I think this is actually a CVE-worthy bug).

however, if we can install a crash handler instead of having a triple-fault (actually the hypervisor gets into a really glitched state (!) and the only way to recover is to physically reset the machine), then we can escape the hypervisor entirely without needing signed Microsoft binaries (like sl2bounce does).

i wonder if there is enough shadowed at 34GB to allow us to do this

@ariadne do not stare into the abyss (too much)

i suspect this is lenovo's fuckup and not qualcomm's, i don't see why qualcomm would be so incompetent that they leave mailboxes writable from EL1 without enforcing a hypercall to gunyah.

@ariadne how similar is the t14s to a p14s? My p14s has weird firmware issues too and I suspect they are of the “oops you can do crashy things in userspace” variety

@ZiggyTheHamster t14s is snapdragon...

@ariadne when I got further down your thread I realized that my reply was stupid but I already made everyone’s Sidekiq busy so I figured why delete it

Maybe Lenovo just sucks at firmware

@ariadne like

FreeBSD won’t boot because it gets stuck on PCI enumeration and hangs somewhere in ACPI land

Unless you have certain keyboards plugged in

Then it works fine

@ariadne I may have a fix for it but I need to play with it some more

found another mapping slightly above 34.5G that is EL2-writable but *not* at the -32G offset.

i have added that to my cutmem= ranges...

@ariadne Had to boot Windows for that purpose recently, I used Windows-to-Go on an SD card.
Just in case that helps 😉

@domi

Don't worry, at this point even the abyss is scared of @ariadne crashing and escaping it.

working on translating this to DTB fixes but stepping away for a bit to meet with friends 🙃

@ariadne Typically a write to protected memory results in a crash, so I don't think it is a security bug, it's working as intended.

(this should also be the case for reads)

@ariadne Do some writes crash and others not? Or all writes cause a crash?

@fun the hypervisor itself crashes and the machine gets into a weird state where the only solution is to reset the management controller

@ariadne Could this be used on purpose to gain code execution in Gunyah and replace it with KVM?

@ariadne What about using a memory corruption exploit without a crash handler?

@ariadne aha, now that's different

@ariadne what can I say, if you can compromise it, could be fosdem-worthy :D

@ariadne you can use UEFI update capsules just fine. I update my X13s that way.

Btw if you're booting at EL2 with slbounce all of this goes away - and that's pretty much at feature parity by now

@never_released slbounce requires non-free software (tcblaunch.exe) :(

@ariadne the hypervisor on Snapdragon X (1st gen) is a remnant not really intended to boot an OS

The ACPI tables on the thing have a bit telling Windows to _never_ boot without Hyper-V no matter what

@ariadne

A "funny" thing about it learnt when I was trying to address Linux booting at EL2 at Qualcomm is that there is no Qualcomm key in the TCB launcher trust store. Just that lone MS one.

@never_released it's okay, i have a PoC which puts the hypervisor into a weird state where I have to physically unplug the battery in order to recover the machine. I am sure this tcblaunch.exe problem will get solved soon 🙃

@never_released like i have no present clue how to leverage this to crash the hypervisor in a more "controlled" manner, but it seems possible to me anyway