On 12/06/2025 15:22, Jan Beulich wrote:
> On 12.06.2025 15:15, Tu Dinh wrote:
>> On 12/06/2025 02:03, Andrew Cooper wrote:
>>> +Secure Boot Advanced Targeting
>>> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> +
>>> +SBAT is a recovation scheme for Secure Boot enabled components, using a
>>> +generation based scheme.  See `Shim SBAT.md
>>> +<https://github.com/rhboot/shim/blob/main/SBAT.md>`_ for full details.
>>> +
>>> +Upstream Xen provides the infrastructure to embed SBAT metadata in
>>> +``xen.efi``, but does not maintain a generation number itself.  Downstreams
>>> +are expected to maintain their own generation numbers.
>>> +
>>
>> Why would Xen not maintain its own SBAT generation? An upstream SBAT
>> incremented for every Secure Boot bypass XSA would make it far easier to
>> block vulnerable variants and help downstreams coordinate fixes.
> 
> Quoting from the SBAT patch that was submitted a little while ago:
> 
> "The SBAT section provides a way for the binary to declare a generation
>   id for its upstream source and any vendor changes applied."
> 
> That is, the generation ID is per-vendor. Upstream incrementing whatever
> ID would be meaningless to downstreams then. Hence we can as well not do
> so in the first place.
> 
> Jan

Don't Shim, Grub and Linux all have their own upstream SBAT generation? 
The Shim SBAT documentation explicitly pointed this out:

 > Each component is assigned a minimum global generation number. 
Vendors signing component binary artifacts with a specific global 
generation number are required to include fixes for any public or 
pre-disclosed issue required for that generation. Additionally, in the 
event that a bypass only manifests in a specific product's component, 
vendors may ask for a product-specific generation number to be published 
for one of their product's components. This avoids triggering an 
industry wide re-publishing of otherwise safe components.

IOW Xen should have its own upstream generation ID for any vulnerability 
that leads to a Secure Boot bypass. Any vendor that patches such a 
vulnerability can simply increase the upstream generation ID it carries 
in its SBAT to that of the latest Xen. Then any inferior upstream 
generation can simply be revoked to cover all vendors at once.

Best regards,


Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


Reply via email to