Conversation

There are quite some discussion around Android 13 bumping the anti-rollback protection on Pixel 6, and people are shitting on Google for this. Not sure how much I'm allowed to disclose so I'll just say this: this decision is not made lightly; it's done because it's necessary.

38

68

845

@LukeDashjr@BitcoinHackers.org on Mastodon

Replying to

It's never necessary to tell the owner "no" Are you offering refunds beyond the 15 day window?

3

12

Replying to

You can only realistically get into this state if you unlock the bootloader. When you unlock the BL, you’ve voluntarily forfeit warranty (at least for software related issues like this one). I’m 100% sure that if your device bricked after a normal OTA, you’ll get a replacement.

2

5

@nottheengineer

Replying to

and

But those issues would not arise without the counter being incremented in the first place. With unlocked bootloaders, this should be a choice.

1

3

Replying to

@nottheengineer

and

Rollback is disabled before it updates the anti-rollback counter.

1

@nottheengineer

Replying to

and

It still hurts custom rom users. I already don't care about my safetynet state, why should I be locked to an android 13 bootloader for security issues that I choose to not care about?

1

3

Replying to

@nottheengineer

and

Rollback protection is part of verified boot. It has existed for the SoC boot chain, secure element and the OS itself for many years. Pixels have used it for the OS and secure element for years. It wasn't used in practice for SoC boot chain due to being a development annoyance.

1

2

Replying to

@nottheengineer

An important security feature not being fully implemented due to it being a development annoyance is problematic. GrapheneOS is an aftermarket OS focused on Pixels and we wanted this feature to start being used properly and complained about it not being done on the past devices.

2

1

Replying to

@nottheengineer

Not everyone using an aftermarket OS wants to roll back the security model and disable security features. Proper verified boot is a small part of what we expect potential hardware partners to implement. It's not proper verified boot if firmware bypasses aren't fixed like this.

1

@LukeDashjr@BitcoinHackers.org on Mastodon

Replying to

@nottheengineer

and

That's why it should be a _choice_. ;)

1

2

Replying to

@nottheengineer

and

You're welcome to use something other than GrapheneOS if you don't want the standard security model and hardware-based security features intact. Rollback protection is a basic security feature and has already been used for years, just not for the early SoC boot chain in practice.

2:41 AM · Aug 18, 2022Twitter Web App

Replying to

Pixels were in theory supposed to be doing this already but were not doing it in practice due to the conflict between them being secure devices and being development devices where someone might want to flash an obsolete, insecure OS version to test app compatibility with it, etc.

2

Replying to

Newer runs of the devices will shipped with updated firmware/OS. We consider it a problem that it takes us a couple weeks to move to new major OS versions we intend to solve that by getting partner access eventually such as via a hardware partner so that we can port earlier.

1

Show replies

@LukeDashjr@BitcoinHackers.org on Mastodon

Replying to

@nottheengineer

and

And ultimately, that's why I don't use GrapheneOS. But it could be a great OS if it didn't insist on denying owners control of their devices, so it's a shame. It's looking like this case wasn't even a security fix, just DRM.

1

Replying to

@nottheengineer

and

Verified boot is an important security feature primarily used to make privileged persistence much more difficult for an attacker. If they can simply write out a vulnerable SoC boot chain, it doesn't work. It's secondarily used for anti-tampering and the same thing applies to it.

2

Show replies