search

riscv-non-isa / riscv-server-platform

The RISC-V Server Platform specification defines a standardized set of hardware and sofware capabilities, that portable system software, such as operating systems and hypervisors, can rely on being present in a RISC-V server platform.
https://jira.riscv.org/browse/RVC-6
Creative Commons Attribution 4.0 International
8 stars 4 forks source link

Questions about security requiremements #18

Open andreabolognani opened 5 months ago

andreabolognani commented 5 months ago

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 commented 4 months ago

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 https://github.com/rhboot/shim/pull/641#issuecomment-2185830943, 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 commented 4 months ago

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 commented 4 months ago

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:

"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 commented 3 months ago

I reached out to uefisign@microsoft.com

andreabolognani commented 3 months ago

@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 commented 3 months ago

Merged https://github.com/riscv-non-isa/riscv-server-platform/pull/22

andreiw commented 2 weeks ago

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 commented 2 weeks ago

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

andreiw commented 2 weeks ago

Now waiting for their input...