Comment by bri3d

Comment by bri3d 4 days ago

> There is: corporate will fund this project and enforce its usage for their users not for the sake of the users and not for the sake of doing any good.

I'd really love to see this scenario actually explained. The only place I could really see client-side desktop Linux remote attestation gaining any foothold is to satisfy anti-cheat for gaming, which might actually be a win in many ways.

> What it will be used for is to bring you a walled garden into Linux and then slowly incentivize all software vendors to only support that variety of Linux.

What walled garden? Where is the wall? Who owns the garden? What is the actual concrete scenario here?

> LP has a vast, vast experience in locking down users' freedom and locking down Linux.

What? You can still use all of the Linuxes you used to use? systemd is open source, open-application, and generally useful?

Like, I guess I could twist my brain into a vision where each Ubuntu release becomes an immutable rootfs.img and everyone installs overlays over the top of that, and maybe there's a way to attest that you left the integrity protection on, but I don't really see where this goes past that. There's no incentive to keep you from turning the integrity protection off (and no means to do so on PC hardware), and the issues in Android-land with "typical" vendors wanting attestation to interact with you are going to have to come to MacOS and Windows years before they'll look at Linux.

egorfine 4 days ago

> client-side desktop Linux remote attestation gaining any foothold is to satisfy anti-cheat for gaming, which might actually be a win in many ways.

It will be, no doubt. As soon as it is successfully tested and deployed for games, it will be used for movies, government services, banks, etc. And before you know you do not have control of your own computer.

> Who owns the garden?

Not you.

> everyone installs overlays over the top of that

Except this breaks cryptography and your computer is denied multiple services. Because you are obviously a hacker, why else would anyone want to compile and run programs.

> turning the integrity protection off (and no means to do so on PC hardware)

It's a flip of a switch, really. Once Microsoft decides you have had enough, the switch is flipped and in a couple of years no new Intel computer will boot your kernel.

Reply View 4 replies

bri3d 4 days ago

> it will be used for movies, government services, banks
I really, really don't think these entities care enough about desktop Linux. I'd be way more worried about some kind of Windows web-based attestation appearing. If that happens I really do think there's a bit of an alarm to sound, because this will make using desktop Linux inconvenient in the way attestation has made using alternate Android ROMs inconvenient.
> Because you are obviously a hacker, why else would anyone want to compile and run programs.
People buy computers to run programs, it doesn't behoove anyone to prevent this. These things are driven by economics, not some weird arbitrary drive towards evil. Android strict attestation is popular because fraudulent cloned banking apps are a rampant problem for banks, not because they're trying to "stick it" to 200 GrapheneOS users.
> Once Microsoft decides you have had enough, the switch is flipped and in a couple of years no new Intel computer will boot your kernel.
Why does everyone land on this complete non sequitur? It's not the flip of a switch, that's not how UEFI Secure Boot works to start with and even then, UEFI Secure Boot is not the root of trust on x86.
This was indeed the big "Free Software" vs UEFI "Secure" Boot conspiracy theory 20+ years ago, but it didn't make sense then, doesn't make sense now, and sure enough, hasn't come to pass. First off, Microsoft aren't Intel, who own the root of trust on Intel CPUs. Second off, again, there's no incentive to do this. CPUs are a competitive market and people buy CPUs to run code. There is no reason for Intel to suddenly decide to exclusively enforce firmware verification in a way that only chained down to one vendor's keys; they're in the business of selling CPUs to people who want to run things. Also, the notion that some CPU vendor will suddenly lock down firmware keys has nothing to do with the article in question or the notion of an immutable or attestable Linux.

Reply View | 3 replies
- microtonal 4 days ago
  
  Android strict attestation is popular because fraudulent cloned banking apps are a rampant problem for banks, not because they're trying to "stick it" to 200 GrapheneOS users.
  Where I live in Europe, Fairphones are becoming fairly popular (as in, I encounter non-tech people using Fairphones). A subset of those users run /e/OS (anti-Google/big tech sentiment is growing pretty strong). This is increasingly becoming a risk for Google, because if /e/OS takes off big time in Europe, it would be easy to support a European app store besides Google Play and F-Droid (which the /e/OS App Lounge already support), leading to a loss of 30% on app spending.
  Google will abuse their remote attestation implementation to shut out competitors. If all they cared for was security, they would have worked with other Android-based operating system vendors that support bootloader locking to come with an industry-wide standard.
  
  Reply View | 2 replies
  
  bri3d 4 days ago
  
  > If all they cared for was security, they would have worked with other Android-based operating system vendors that support bootloader locking to come with an industry-wide standard.
  Google actually "gave" customers the choice here, although I agree with you that it's crappy and there was almost surely some monopolistic intent -
  There _is_ a standard implementation, the Hardware Attestation API. Unfortunately it is annoying to use in a practical way; it requires a fair amount of PKI-wrangling (although there's a Google library for it) and more importantly to allow non-Google trust chains but still enforce boot security, app developers need all of the verifiedBootKey hashes for the non-Google trust chains they want to trust. This makes sense, but unfortunately becomes a maintenance problem and turns app developers off of this.
  So, app developers choose the Play Integrity API instead because it's easy, even though they get the side effect that they verify that the device is a licensed Google Play device rather than just a "clean" Android device.
  All this is to say that if something like /e/OS were to actually take off, app developers could upgrade their apps to support attestation with the Hardware Attestation API with some extra effort - Google aren't really preventing them and the feature is there.
  Anyway, going all the way back to the original story again, I still can't buy into the hand-wringing. A verified, attestable Linux on the server (or for stuff like forward deployed devices) seems quite cool and useful to me, and while I respect the issues with client attestation and the negative effect it can have on hardware ownership, I both don't see it as a practical outcome from this company and don't see it as a practical threat on the desktop at this time.
  
  Reply View | 0 replies
  
  egorfine 3 days ago
  
  No worries here as EU is slowly pushing to ban OS-unlocked phones under the guise of "think of the children^Wradio spectrum".
  
  Reply View | 0 replies