Much ado about SBAT

Posted Jul 21, 2023 10:13 UTC (Fri) by gray_-_wolf (subscriber, #131074)
In reply to: Much ado about SBAT by juliank
Parent article: Much ado about SBAT

What if fedora decides to fix a bug A as 3 while linux bug B as the same 3? They might very well do it by accident. How is this going to be prevented? Or, how (if ever) will the numbers be reconciled (there are many distributions, so I assume it will happen sooner or later)?

Much ado about SBAT

Posted Jul 21, 2023 10:36 UTC (Fri) by bluca (subscriber, #118303) [Link] (5 responses)

That's why revocations are centralized, and managing generation IDs also needs to be centralized, rather than have everyone do it on their own

Much ado about SBAT

Posted Jul 21, 2023 13:11 UTC (Fri) by zdzichu (subscriber, #17118) [Link] (4 responses)

How exactly would centralisation solve the problem presented by gray_-_wolf?

Much ado about SBAT

Posted Jul 21, 2023 15:39 UTC (Fri) by bluca (subscriber, #118303) [Link] (3 responses)

Because everybody will know what the upstream product gen ID is

Much ado about SBAT

Posted Jul 22, 2023 16:32 UTC (Sat) by zdzichu (subscriber, #17118) [Link] (2 responses)

Ok, so let's assume everybody is at gen 42. Now, two new vulnerabilities gets published, CVE-2025-001 and CVE-2025-002.
Fedora backports the fix for 001 in their kernel. Arch backports fix for 002. They need to get new generation ID for their patched kernels, so they ask central authority.

What gen numbers they will get in answer?

Much ado about SBAT

Posted Jul 22, 2023 16:53 UTC (Sat) by excors (subscriber, #95769) [Link] (1 responses)

That sounds easy: the central authority decides on a total order for vulnerabilities. If they pick 001<002, then they say you can sign as gen 43 if you're not vulnerable to 001, and you can sign as gen 44 if you're vulnerable to neither 001 nor 002. Arch will need to fix 001 (or determine they were never vulnerable to it, e.g. if it was a Fedora-specific issue) so they can sign as a new generation, before gen 42 gets revoked.

Much ado about SBAT

Posted Aug 4, 2023 8:43 UTC (Fri) by ghane (guest, #1805) [Link]

My understanding is that Google does this, releasing two checkpoints every month for certified Android.

Assume there are two sets of exploits, set A (which Google feels Handset OEMs can fix by themselves quickly) and set B (which need blobs from Qualcomm, etc). These are called (eg) 01 July 2023 and 05 July 2023 (the 1 and 5 are constant).

If you fix set A, you roll out the update, and claim "1 July 2023". You then have time to talk to upstream chip manufacturors, and at some time roll out "5 July 2023".

You cannot claim 1 Aug 2023, (or any future version) however, till 5 July 2023 has been included.

So from a user (and app developer) point of view, any "1" date means you are no more than 1 month behind that month, and a "5" means that you are current till that month.