Questions about security requiremements

[andreabolognani]

First, a simple clarification: the spec says

it is expected the high-level RoT / boot flow requirements

What is "RoT" in this context? I'm not familiar with the acronym and it's not defined in the glossary, nor was I able to quickly find an explanation online. It doesn't help that "rot" is a common word in the English language :)

More to the point, I see that SEC_010 mandates that UEFI Secure Boot is implemented. Is that actually feasible today?

I was recently discussing the RISC-V implementation of shim, which is a critical part of how Linux implements the Secure Boot trust chain, and a concern was raised that the necessary infrastructure/agreements might not be in place yet. Do we have additional information about that?

Or is the intention that the mechanisms for Secure Boot are implemented, with no expectation that Microsoft's (or anyone else's) key is actually enrolled out of the box? If so, would it be worth clarifying in the non-normative text?

[andreiw]

RoT in this context is "root of trust".

UEFI Secure Boot should be feasible, why not? Do you have indications to the contrary? For example, there are multiple explored mechanisms for implementing authenticated variables (the largest dependency, as I see it... some of this work has been done within RISE FW group). Of course, the proof is the pudding, which is why we have the SiP presence in the group.

Wrt rhboot/shim#641 (comment), why wouldn't MS sign it? There haven't been any indications with prior efforts that this could become a problem. If it becomes a problem, then it simply accelerates moving to a separate authority. This is something I can follow up with or clarification or at least a statement.

[andreabolognani]

RoT in this context is "root of trust".

Gotcha. I would expand the acronym for clarity but since it's in a paragraph marked "TBD" that might be seen as unnecessary churn, so I'm holding off for now.

UEFI Secure Boot should be feasible, why not? Do you have indications to the contrary? For example, there are multiple explored mechanisms for implementing authenticated variables (the largest dependency, as I see it... some of this work has been done within RISE FW group). Of course, the proof is the pudding, which is why we have the SiP presence in the group.

With SiP meaning... ? O:-)

I have no indication that Secure Boot can't be achieved, quite the contrary: I would consider lack of Secure Boot for a server platform a near fatal flaw. I'm just wondering whether one could ship an implementation today. The fact that you mention "multiple explored mechanisms" makes me think that it's not a solved problem. And so I wonder what that means for the Server Platform spec... Do we want to mandate something that we aren't 100% sure can actually be implemented?

Wrt rhboot/shim#641 (comment), why wouldn't MS sign it? There haven't been any indications with prior efforts that this could become a problem. If it becomes a problem, then it simply accelerates moving to a separate authority. This is something I can follow up with or clarification or at least a statement.

Same as above, I have no indication that Microsoft would refuse to sign riscv64 shims when they're already signing x86_64/aarch64 shims. But I have no indication that they definitely are going to sign them either. Do you?

I'm not overly familiar with the (massive) UEFI spec, so I'm not sure whether it actually contains any requirement to ship the Microsoft keys out of the box. Maybe it doesn't, and Microsoft being the de-facto gatekeeper for the Secure Boot ecosystem is more of a reflection of reality than something that's mandated by spec. If so, good! It means that we can require vendors to implement Secure Boot regardless of whether Microsoft is up for signing additional shims.

There's another thought that popped into my mind after I had filed this issue. There was a controversy a decade ago about Microsoft's certification program requiring that Arm devices are locked down in terms of Secure Boot, specifically preventing it from being turned off or (IIRC) enrolling custom keys.

It looks like Windows 10 further moved in the wrong direction by making it possible, even on x86_64, for vendors to ship hardware that doesn't provide a way for the user to turn Secure Boot off and doesn't include the Microsoft third-party key (the one used to sign shim).

I don't know if things have changed again in the meantime, but I wonder: would it make sense to make it an explicit requirement in the Server Platform spec that the user must be able to turn Secure Boot off and enroll their own keys? I feel like both are very desirable properties.

I would actually argue that such a requirement might belong in the BRS spec, but we could start by making it part of the Server Platform spec and try pushing it down the stack later.

[andreiw]

SiP -> Silicon Providers.

Authenticated variables definitely /can/ be implemented, but the actual underlying mechanism of isolating the MM kernel is SoC and possibly even vendor micro-architecture specific. Here are the three mechanisms that I am aware of:

• Running MM on a System Control Processor, microcontroller or non-"rich OS" capable hart, with UEFI RT and MM communicating via RPMI. The flash chip in this case belongs to the SCP/MCU running the MM kernel and is not accessible to normal "rich OS" harts.
• Running MM in a vendor-specific "secure enclave" on normal "rich OS" capable harts. The "security visor" protects the flash from the regular HS/S modes.
• Running MM in M mode.

"MM" is a special kernel that on x86 runs in SMM and on Arm runs in a TrustZone enclave or similar, and is used to implement authenticated NVRAM access in Tiano. MM stands for "management mode" and has been renamed from SMM when Arm support was added.

Regardless of how it is implemented, there would be no OS-observable differences in behavior.

As far as consumer Arm devices, yes some unfortunate history in devices that were an evolutionary dead end (Windows RT), but that hasn't leaked into server systems endorsed by MS nor even more recent client devices based on AArch64 and UEFI. I agree with the sentiment of requiring the ability to disable Secure Boot and to enroll own keys. Those are basically required for feature parity with Arm and x86.

[andreiw]

I reached out to uefisign@microsoft.com

[andreabolognani]

@andreiw thanks for reaching out to Microsoft.

In the meantime, I've looked at the Windows 11 "Hardware Compatibility Specification" and taken inspiration for our own requirements in terms of keeping Secure Boot fully manageable by users. We could go a lot more in depth if desired, but for now I've decided to keep things very simple.

[andreiw]

Merged #22

[andreiw]

Coming back here, I've heard nothing back from uefisign@microsoft.com, which (needless to say) is pretty disappointing. I would have expected some help to identifying the right party within Microsoft, oh well. Trying again, but if anyone has a contact - that would be awesome.

[andreiw]

Okay I've heard back from uefisign, apparently there was some reorgnanization and the earlier email fell through the seams.

[andreiw]

Now waiting for their input...

[jones-drew]

Now waiting for their input...

Hi Andrei, any word from MS?
Thanks, drew