Remix.run Logo
perching_aix 2 days ago

Didn't we backslide hard enough at this point that it is now architecturally ensured that there is a security downside to rooting? Prevents verified boot for example, since the attestation is tied to said corporations, and not you.

fc417fc802 a day ago | parent | next [-]

AFAIK that's true for many vendors but for example Pixels (and IIRC also OnePlus at least a few years ago) you can relock the bootloader with other keys.

The crazy thing is that on all the devices I've had AVB is implemented on top of secureboot. Being able to set your own secureboot keys is bog standard on corporate laptops. The entire situation makes absolutely no sense.

Also for the record I think it's a silly attack vector for the average person to worry about. A normal person does not have secret agents attempting to flash malicious images to his phone while he's in the shower.

acdha a day ago | parent | next [-]

> A normal person does not have secret agents attempting to flash malicious images to his phone while he's in the shower.

No, but millions of women have controlling partners or friends who betray their trust and, for example, many people going through U.S. Customs are being asked to surrender control of their devices so they can be used without their knowledge. There’s a well-funded malware industry with a lot of customers now.

perching_aix a day ago | parent | prev [-]

> AFAIK that's true for many vendors but for example [on] Pixels you can relock the bootloader with other keys

Oh that's pretty cool, wasn't aware.

> The crazy thing is that on all the devices I've had AVB is implemented on top of secureboot. Being able to set your own secureboot keys is bog standard on corporate laptops. The entire situation makes absolutely no sense.

Hold on, could you elaborate a bit on this? I thought it was an either/or type deal cause they do the same thing.

fc417fc802 a day ago | parent [-]

Many devices if you load up fastboot mode (is that the right name?) it will give you chipset and other information and it will have secureboot info there. It's permanently locked to chain into the AVB image. AVB is a much more complicated beast that specifies the existence of multiple partitions including (IIRC) one for storing authorized keys, one for the recovery, and a bunch of other stuff.

It's possible this has changed or was never widespread in the first place. I have a very limited (and historic) sample size.

franga2000 a day ago | parent | prev | next [-]

Not having verified boot is not a security downside for most people. Unless your threat model includes the evil maid attack, which it doesn't for thr vaaaaaast majority of people, verified boot is just another DRM anti-feature.

ignoramous a day ago | parent [-]

Verified Boot isn't merely to thwart Evil Maids, but by and large provide what's known as "Trusted Computing Base". And yes, given the proliferation of smartphones and the nature of sensitive applications built on top, most people, even if they don't realise it, need it.

userbinator a day ago | parent [-]

but by and large provide what's known as "Trusted Computing Base".

In other words, DRM.

https://en.wikipedia.org/wiki/Trusted_Computing#Criticism

(I knew from the beginning that this was known as the Palladium project, and until recently, a search for "Palladium TCG" would find plenty of information about that history, yet now references to that group and its origins in DRM have seemingly disappeared from Google. Make of that what you will...)

cam_l a day ago | parent | next [-]

Are you saying that someone is using yugiyoh trading cards to cover up incriminating historical details of Microsoft's long term plan to purge general purpose computing from the world?

https://www.tcgplayer.com/product/593140/yugioh-quarter-cent...

Bizarre, I did find it on bing though..

https://www.cl.cam.ac.uk/archive/rja14/tcpa-faq-1.0.html

perching_aix a day ago | parent | prev [-]

This should not be a surprise. Mechanistically enforced trust (like in trusted computing), and even better, mechanistically assured trust (like in verifiable computing), will be relied upon by anyone seeking trust. This means both consumers and producers, and anyone else in-between.

If I want my device to be secure, I want this trust. If I want to sell a copy of my virtual asset to only be used in ways I approve of, I want this trust. You can't have only one of these at the same time, either your device can provide this trust or it cannot. That's not the battle in my view. The battle is to implement this appropriately, such that e.g. if we're representing access control, identity, and ownership, then that representation should match reality. So if I'm said to own a device, the device can and will attest so, and behave accordingly. It's just that instead of that, I'm always somehow just being loaned these things, only have some specified amount of control over these things, and am just a temporary user somehow. That's the issue. And that these systems are not reimplementable, and as such entitlements do not carry around.

torginus a day ago | parent | prev [-]

I don't follow the reasoning behind this - even in a verified boot scenario you can just choose to not load the offending kernel module without compromising security.