Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Brave New Trusted Boot World

0pointer.net

Post reply on HN
Print view View original

51–60 of 178 posts

Re: Brave New Trusted Boot World

#51

Post by lproven »

endgame wrote: post #29
pilif wrote: post #12

Earlier quoted context omitted.

> you can't have one without the other, AFAIK, secure boot can be disabled, both in the BIOS and in the Kernel. In some machines that's not be the case due to contracts with Microsoft, but those already can't run Linux in the first place, so you probably won't buy them for the purpose of running Linux. The suggestions in the original post do not change anything about this.

> AFAIK, secure boot can be disabled, both in the BIOS and in the Kernel. For now.

Yup. E.g. on the MS Surface RT ARM devices it couldn't be, for instance.

I wrote about this nearly a decade ago:

https://www.theregister.com/2013/11/14/microsoft_surface_rt_...

AFAIK, rather than make the firmware unlockable, MS sent vast amounts of inventory to landfill.

Re: Brave New Trusted Boot World

#52

Post by recuter »

growse wrote: post #39
jart wrote: post #33

Earlier quoted context omitted.

I always thought this outcome was obvious. Systemd controls everything that happens before Linux boots. It controls everything that happens after Linux boots. Might as well call it GNU/Systemd at this point. It's the silent revolution no one wanted. The name itself implies a manifest destiny because System D is 100x greater than System V and they intentionally break POSIX compliance too. Now that the guy who owns the…

No-one's making you use it. Choose a distro that doesn't package it - there's plenty to choose from.

For now.

Re: Brave New Trusted Boot World

#54

Post by jnwatson »

TeMPOraL wrote: post #50
jnwatson wrote: post #14

Earlier quoted context omitted.

Many folks prioritize preventing practical in-the-wild blue pill attacks over preventing the theoretical DRM use case.

It's not a "theoretical DRM use case" if you stop thinking in terms of movie piracy for a moment, and consider what's happening with banking apps on mobile platforms. Thanks to remote attestation, the custom ROM scene for Android is pretty much dead now, because there's little point of customizing the OS when it automatically makes important services no longer accessible from the phone.

That's the entire point. Your bank doesn't want you to run their software on your potentially vulnerable hardware.

Re: Brave New Trusted Boot World

#55

Post by Arch-TK »

no_time wrote: post #13
Arch-TK wrote: post #8

Earlier quoted context omitted.

I know my reasons for feeling worried about it but I wonder why you also dislike the idea of end user operating systems making it trivial for applications to take advantage of remote attestation?

Because it can snowball from "you may not access Widevine content on an unapproved device", which is of little significance to "you may not connect to the internet on a non government approved device" which is extremely dangerous.

It's good to know that other people can see the writing on the wall too. I've told people that this is being made possible. While it is not a guarantee that the availability of the technology will lead to the use of the technology in such a manner, the fact that it will be possible means it's just a matter of time before someone insists on doing this under the pretext of security.

The saving grace is that attestations can be forwarded but I'm sure even this will eventually get solved. (And the sheer fact they can be forwarded doesn't diminish the dangers of this use of the technology.)

Re: Brave New Trusted Boot World

#56

Post by mid-kid »

growse wrote: post #39
jart wrote: post #33

Earlier quoted context omitted.

I always thought this outcome was obvious. Systemd controls everything that happens before Linux boots. It controls everything that happens after Linux boots. Might as well call it GNU/Systemd at this point. It's the silent revolution no one wanted. The name itself implies a manifest destiny because System D is 100x greater than System V and they intentionally break POSIX compliance too. Now that the guy who owns the…

No-one's making you use it. Choose a distro that doesn't package it - there's plenty to choose from.

This number diminishes every passing year, with only debian being a bastion of sanity on the "user friendly" side of the distro spectrum.

Re: Brave New Trusted Boot World

#57

Post by TeMPOraL »

no_time wrote: post #13
Arch-TK wrote: post #8

Earlier quoted context omitted.

I know my reasons for feeling worried about it but I wonder why you also dislike the idea of end user operating systems making it trivial for applications to take advantage of remote attestation?

Because it can snowball from "you may not access Widevine content on an unapproved device", which is of little significance to "you may not connect to the internet on a non government approved device" which is extremely dangerous.

To preempt the "but slippery slope!" counters, where we're currently at is "you may not use your bank's mobile app on a phone that isn't running genuine, unmodded, unrooted version of the hardware and OS it came with". This is the reality of modern Android devices. And it's not worse only because, like with any API, adoption of new-and-improved Safenet / Play $forgot-the-name APIs takes time.

The slippery slope is not a fallacy if the slope is, in fact, slippery.

Re: Brave New Trusted Boot World

#58

Post by Arch-TK »

qwerty456127 wrote: post #20
Arch-TK wrote: post #8

Earlier quoted context omitted.

I know my reasons for feeling worried about it but I wonder why you also dislike the idea of end user operating systems making it trivial for applications to take advantage of remote attestation?

What are, if any, "advantages of remote attestation" besides enforcing DRMs and preventing sideloading/jailbreaking? Preventing those who need access to proprietary systems from using any distro except 1-2 certified ones?

I mean I can see the advantages on a corporate network, or on just any network that you control. I may want to ensure that on my home network none of the devices have been deeply compromised so I may want to take advantage of the technology. But I feel like making this technology a normal part a user facing operating system risks normalising it to the point that companies will start abusing it to e.g. lock access to online resources to windows/mac only (potentially even leading to ISPs using it to require you to use approved operating systems to connect to the internet under the pretext of improved security).

Re: Brave New Trusted Boot World

#59

Post by Arch-TK »

TeMPOraL wrote: post #57
no_time wrote: post #13

Earlier quoted context omitted.

Because it can snowball from "you may not access Widevine content on an unapproved device", which is of little significance to "you may not connect to the internet on a non government approved device" which is extremely dangerous.

To preempt the "but slippery slope!" counters, where we're currently at is "you may not use your bank's mobile app on a phone that isn't running genuine, unmodded, unrooted version of the hardware and OS it came with". This is the reality of modern Android devices. And it's not worse only because, like with any API, adoption of new-and-improved Safenet / Play $forgot-the-name APIs takes time. The slippery slope is no…

At least so far my bank hasn't prevented me from using my web browser on linux to access the banking website. But I am certain they will once Windows 11 gets enough traction in a few years.

Re: Brave New Trusted Boot World

#60

Post by Foxboron »

hdjjhhvvhga wrote: post #46
growse wrote: post #43

Earlier quoted context omitted.

> This is exactly NOT the way to do things in open source. Someone made a decision, others didn't like it so forked. Sounds like open source is working exactly as it should?

For applications, tools, even most libraries - yes. But this was one of the critical elements of the system and they had to fork the entire distro because the way it was done actually made the choice more limited.

>But this was one of the critical elements of the system and they had to fork the entire distro because the way it was done actually made the choice more limited.

This isn't very accurate. When Debian decided to switch to systemd, they also agreed to support other inits in the distribution.

This wasn't good enough, so Devuan itself was forked before this decision was made. The end result is that Debian had less people to support the init script alternatives. It became a self-fulfilling prophecy.

I'm confident Debian could support other inits if there was more Debian devs available to work on it. But because people left for Devuan the pool becomes smaller.

Even the last decision on inits from Debian says that the focus should not solely be on systemd.

https://lwn.net/Articles/808217/

Post reply on HN