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

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

[segaloco via COFF]

[TUHS bcc, moved to COFF]

On Thursday, January 4th, 2024 at 10:26 AM, Kevin Bowling <kevin.bowling@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.

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

[Dan Cross]

On Thu, Jan 4, 2024 at 2:20 PM segaloco via COFF <coff@tuhs.org> wrote:
> [TUHS bcc, moved to COFF]
>
> On Thursday, January 4th, 2024 at 10:26 AM, Kevin Bowling <kevin.bowling@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.

We've been there for a while.

I've been swimming in these waters for a couple of years now, and it
_is_ an issue. That said, I can kind of sympathize with the vendors to
an extent; they're between a rock and a hard place in a lot of ways.

Starting up a modern CPU (even one in an end-user device like a phone
or a laptop) is, I imagine, a bit like starting the engines on a
container ship. You don't just press a switch and have massive
two-story diesel pistons start firing in enormous cylinders; instead,
you push a switch which starts an electric motor which turns on
something like a V8 engine, which starts up a larger engine that
starts the process of compressing the big pistons so the thing can
start; it's a slow, multi-stage process out of physical necessity.

Modern CPUs follow a similar process: you apply power to a board and
it's going to do all sorts of stuff like power sequencing for DIMM
sockets, asking them what's there, whether they're working properly,
etc. Then there's turning on thermal sensors, the IO bus, flash, etc.
A slew of internal diagnostics are going to run across a number of
components. And all of this is happening before you even begin
bringing the CPU socket online, let alone allowing the CPUs to come
out of reset. And most of this is going to be done with FPGAs or
little rinky-dink microcontrollers embedded in various places (an
interesting exercise might be trying to count the number of CPUs on a
modern mainboard): and that's not even counting the CPUs on IO
devices. Most of those aren't just hidden, they're invisible to anyone
other than the device manufacturer. Even if I had the documentation
and the means to replace the images in those disparate components,
it'd be a daunting task from a time/reward perspective. Most of the
time, it's just not possible.

How did we get here? Well, in part because systems are a lot more
complex now than they were in the past, and that has reflected itself
back onto software. The reality is that, for most users, even those
who care about what software they run, most of this stuff just isn't
that _interesting_. We care what runs on the x86 CPU (or whatever)
sure, but how many people even _know_ about the little CPU embedded in
their USB flash stick? So there's little incentive for the software
vendors to put a lot of effort into supporting this stuff, and so it
falls on board vendors, who just do what they've got to do to ship a
product.

I've mentioned the Oxide architecture before: we have no UEFI and we
have no BIOS. We also designed our own custom boards.
At Oxide, we build a service processor board based on an ARM Cortex-M
profile microcontroller that runs its own OS that we built in-house
most of the pre-CPU-poweron tasks. And yet, there are still some
things that we can't get away from (firmware on peripherals, and the
aforementioned PSP). The PSP is an interesting case in point; even if
we _wanted_ to bypass it entirely, we can't; it's built into the CPU
SoC complex and it's just how the thing works. And we build the
computers! Imagine the situation for a user of a commodity COTS
system.

> 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...

I think most people just want a computer (or phone, tablet, whatever)
at all and the entire system has congealed (again, to use Roscoe's
term) around the way that things are now. Even for those of us who
don't like it, it's damned hard to change the status quo.

        - Dan C.

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

[Nevin Liber]

[-- Attachment #1: Type: text/plain, Size: 4071 bytes --]

On Thu, Jan 4, 2024 at 1:10 PM segaloco via TUHS <tuhs@tuhs.org> wrote:

> 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.
>

Except for a lot of devices, you haven't "fully paid for" it, because the
price most people pay up front takes into account other revenue streams.
Take smart TVs for example: <
https://www.businessinsider.com/smart-tv-data-collection-advertising-2019-1
>.

That being said, of course they want to keep those revenue streams going as
long as possible, and once done, they aren't going to pay for any
engineering effort to remove it.

How much more are you willing to pay up front for that same TV (2x?  3x?
 4x?), and are there enough of you for a manufacturer to offer it?

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.


Now scale it.  How do you keep bad actors from bricking *my* device,
especially if my device is on the internet?  Then scale it to all the
security threats besides DoS.  You can disagree with the solutions to these
threats, but please don't minimize that these are very real threats.

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.


That is a pretty arrogant statement.  It is far more likely that, instead
of the rest of us not being as educated as you, we just value different
things.

Traditional Unix systems have, at best, focused on the developer
experience, and have been dwarfed for decades by systems companies focusing
on the *user* experience.   I'm old enough to remember the decades
when Unix was always just a year away from doing better than being a
distant third behind Windows and Mac OS on the desktop.

I want devices that are easy to get things done, don't require much
futzing, and isn't a nightmare for my life (due to my data that it can
access) if I happen to break it, lose it or it gets stolen.

For example:  last year when I was hiking in the AZ desert, I got an email
about winning a lottery that I had entered for inexpensive show tickets for
the next day, and I bought tickets securely with Apple Pay before the
deadline expired.  All of that was performed confidently and securely with
my iPhone (well, I possibly got the email notification on my watch).  While
it may not be the world you want to participate in or care about, that is
the kind of amazing experience that I value, and it seems the kind of
experience that lots of people value, as evidenced by the size of the
smartphone market compared with the size of the computer market.

The open source world and hackable hardware world don't offer this kind of
experience.


>   People just want I push button I get Netflix,


Why wouldn't you??  While Netflix isn't perfect, are you seriously arguing
people should *want* a far worse user experience?


> they'll happily throw all their rights in the garbage over bread and
> circuses....but that ain't new...
>

It isn't about happily throwing away "rights" (whatever that means).  It's
about we aren't willing to *pay* for it.  It's a tradeoff, and those who
want everything hackable haven't shown much value to the rest of us, and
there are very real concerns about the costs both in terms of security
threats and monetary costs.
-- 
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

[-- Attachment #2: Type: text/html, Size: 5802 bytes --]

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

[segaloco via COFF]

[-- Attachment #1: Type: text/plain, Size: 902 bytes --]

On Thursday, January 4th, 2024 at 2:14 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

> It isn't about happily throwing away "rights" (whatever that means). It's about we aren't willing to pay for it. It's a tradeoff, and those who want everything hackable haven't shown much value to the rest of us, and there are very real concerns about the costs both in terms of security threats and monetary costs.--
>
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404

I've tried (and failed) at a thoughtful response a few times now, so I think I need to at least accept that yeah, I'm in the extreme minority in not preferring convenience over autonomy.

Good luck with this conversation, I don't think I have anything else to contribute, I think I'm on a different world than the prevailing opinions on this stuff...but such is life. Better than an echo chamber that's for sure.

- Matt G.

[-- Attachment #2: Type: text/html, Size: 2345 bytes --]

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

[Dan Cross]

On Thu, Jan 4, 2024 at 5:15 PM Nevin Liber <nevin@eviloverlord.com> wrote:
>[snip]
>> 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.
>
> Now scale it.  How do you keep bad actors from bricking *my* device, especially if my device is on the internet?

The obvious answer is, "by preventing bad actors from getting access
to the means to manipulate your firmware."

> Then scale it to all the security threats besides DoS.  You can disagree with the solutions to these threats, but please don't minimize that these are very real threats.

This is a false dichotomy, as one must bear in mind that the
_existing_ firmware may already be vulnerable. We saw this with the
infamous `strncmp` bug on the Intel ME a few years ago, and we saw it
again just the other day with the JPEG parser bug in a number of UEFI
installations in the wild. _An_ issue with closed and hidden firmware
blobs is that you just don't know; that is, it's not just about
abstract notions of freedom but also about transparency.

>> 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.
>
> That is a pretty arrogant statement.  It is far more likely that, instead of the rest of us not being as educated as you, we just value different things.
>
> Traditional Unix systems have, at best, focused on the developer experience, and have been dwarfed for decades by systems companies focusing on the *user* experience.   I'm old enough to remember the decades when Unix was always just a year away from doing better than being a distant third behind Windows and Mac OS on the desktop.
>
> I want devices that are easy to get things done, don't require much futzing, and isn't a nightmare for my life (due to my data that it can access) if I happen to break it, lose it or it gets stolen.

One of the reasons I use a Mac is because macOS _is_ Unix on the desktop. :-)

> For example:  last year when I was hiking in the AZ desert, I got an email about winning a lottery that I had entered for inexpensive show tickets for the next day, and I bought tickets securely with Apple Pay before the deadline expired.  All of that was performed confidently and securely with my iPhone (well, I possibly got the email notification on my watch).  While it may not be the world you want to participate in or care about, that is the kind of amazing experience that I value, and it seems the kind of experience that lots of people value, as evidenced by the size of the smartphone market compared with the size of the computer market.
>
> The open source world and hackable hardware world don't offer this kind of experience.

Ironically, the systems you mentioned are built on Unix and open
source software as a foundation.

>>   People just want I push button I get Netflix,
>
> Why wouldn't you??  While Netflix isn't perfect, are you seriously arguing people should want a far worse user experience?
>
>>
>> they'll happily throw all their rights in the garbage over bread and circuses....but that ain't new...
>
> It isn't about happily throwing away "rights" (whatever that means).  It's about we aren't willing to pay for it.  It's a tradeoff, and those who want everything hackable haven't shown much value to the rest of us, and there are very real concerns about the costs both in terms of security threats and monetary costs.

I get the whole "different strokes for different folks" argument, but
I think you may be underestimating the impact that the whole hackable
thing has had.

The whole industry seems to be over a barrel with the way that things
have evolved.  In many respects, we have amazing technology that lets
us do really cool things (cf your examples above) and that's both
valuable and important. On the other hand, in a lot of ways, it feels
like we're just waiting for the other shoe to drop with something
going really wrong in a hurry because we've undervalued investment in
the foundations for too long. UEFI is a train wreck; ACPI is a train
wreck; a lot of binary-only firmware is of dubious (at best) quality
and provenance, but the industry writ large doesn't have a better
solution to the real problems with these specific technologies. It's a
real problem waiting to happen, and it does us as engineers,
researchers, computer scientists, etc, no good to minimize that.

        - Dan C.