[TUHS] [COFF] Intel ME, UEFI, User Control was Re: Question about BSD disklabel history

[segaloco via TUHS]

[TUHS bcc, moved to COFF]

On Thursday, January 4th, 2024 at 10:26 AM, Kevin Bowling <kevin.bowling at kev009.com> wrote:

> For whatever reason, intel makes it difficult to impossible to remove
> the ME in later generations.

Part of me wonders if the general computing industry is starting to cheat off of the smartphone sector's homework, this phenomenon where whole critical components of a hardware device you literally own are still heavily controlled and provisioned by the vendor unless you do a whole bunch of tinkering to break through their stuff and "root" your device.  That I can fully pay for and own a "computer" and I am not granted full root control over that device is one of the key things that keeps "smart" devices besides my work issued mobile at arms length.

For me this smells of the same stuff, they've gotten outside of the lane of *essential to function* design decisions and instead have now put in a "feature" that you are only guaranteed to opt out of by purchasing an entirely different product.  In other words, the only guaranteed recourse if a CPU has something like this going on is to not use that CPU, rather than as the device owner having leeway to do what you want.  Depends on the vendor really, some give more control than others, but IMO there is only one level of control you give to someone who has bought and paid for a complete device: unlimited.  Anything else suggests they do not own the device, it is a permanently leased product that just stops requiring payments after a while, but if I don't get the keys, I don't consider myself to own it, I'm just borrowing it, kinda like how the Bell System used to own your telephone no matter how many decades it had been sitting on your desk.

My two cents, much of this can also be said of BIOS, UEFI, anything else that gets between you and the CPUs reset vector.  Is it a nice option to have some vendor provided blob to do your DRAM training, possibly transition out of real mode, enumerate devices, whatever.  Absolutely, but it's nice as an *option* that can be turned off should I want to study and commit to doing those things myself.  I fear we are approaching an age where the only way you get reset vector is by breadboarding your own thing.  I get wanting to protect users from say bricking the most basic firmware on a board, but if I want to risk that, I should be completely free to do so on a device I've fully paid for.  For me the key point of contention is choice and consent.  I'm fine having this as a selectable option.  I'm not fine with it becoming an endemic "requirement."  Are we there yet?  Can't say, I don't run anything serious on x86-family stuff, not that ARM and RISC-V don't also have weird stuff like this going on.  SBI and all that are their own wonderful kettle of fish.

BTW sorry that's pretty rambly, the lack of intimate user control over especially smart devices these days is one of the pillars of my gripes with modern tech.  Only time will tell how this plays out.  Unfortunately the general public just isn't educated enough (by design, not their own fault) on their rights to really get a big push on a societal scale to change this.  People just want I push button I get Netflix, they'll happily throw all their rights in the garbage over bread and circuses....but that ain't new...

- Matt G.