Originally published at: https://boingboing.net/2024/07/08/windows-arm-laptops-benchmarked.html
…
How easy is it to scrape the Windows off, and install Linux?
Shouldn’t be that hard. And if it is, just means it won’t be that hard soon.
So, MacOS or Windows 11… A poke in the eye wih a sharp stick or a broken hand…
I’ll stick with a Chromebook running Linux for now.
You might want to wait for Tuxedo (the Linux sub-brand of Schenker) to come out with its Snapdragon X Elite laptop:
… which one overheats more often though
Aren’t bootladers on Windows ARM devices locked down to prevent it?
Dunno. Maybe? I just assume that some enterprising soul will take any attempt to stop Linux being installed on [$THING] as a personal insult, and break whatever shenanigans have been implemented. It’s usually a safe bet.
You are right. For example amount of reverse-engineering that was done to get Linux to run on Apple computers with ARM CPUs is absolutely impressive. They even have GPU acceleration now:
The old, Nvidia Tegra based, “Windows RT” devices were locked down tight(architecturally I think it was just UEFI secure boot; but exclusively with an MS key; no support for MOK or the key that MS signs the ‘SHIM’ component that basically everyone who isn’t windows or their own lockdown appliances uses for secure boot compatibility).
I’ve not been able to find a straight answer on the behavior of the newer, just ARM windows, devices. I’m pretty sure that you aren’t going to find a legacy CSM option in their firmware; but, if they follow x86 device conventions around supporting SHIM out of the box and MOK with only a little more fiddling, there wouldn’t be much lockdown at the bootloader level.
What I also don’t know(though this is hardly unique to ARM; looking at you Intel ME, anyone’s SMM, and AMD ‘PSP’); is how numerous and active the various non-OS cores are: on the cellphone side Qualcomm systems tend to have a fair amount going on away from the application processor: cell baseband does its own thing; “Hexagon” DSP(now rebranded as ‘NPU’ because glorious AI) running its own things signed to hell and back; ‘trustzone’ stuff running outside the scope of the OS, doing whatever it feels like, that sort of thing.
(edit: this is the most detailed layout of the boot process I’ve been able to find; it suggests that the UEFI secure boot stuff is modifiable in line with x86 systems; but apparently ending up at something that looks like a UEFI boot environment involves a slightly dizzying series of hops between various Qualcomm bootloaders, hypervisors, and trusted execution environments; all with signatures verified against keys efused into the hardware, which are going nowhere barring the discovery of some quite elegant exploit.)
This topic was automatically closed after 5 days. New replies are no longer allowed.