1. 37
  1. 11

    Now imagine if there was a motherboard vendor that shipped these, instead of the usual crap.

    1. 3

      Can someone offer a rundown of why this is interesting and whether the coreboot config that lets it boot also lets FOSS things boot?

      I’d have expected Windows 11 to boot with Coreboot just fine. The rub would seem to be getting other things to boot with the same config.

      1. 15

        To me the most interesting part of this link is the author’s bio:

        MSFT Director of OS Security.

        1. 5

          Among other things, David is the person who has been driving the effort to have CPU vendors adopt Pluton as their hardware root of trust. I think this project speaks a lot to his motivation: he wants a trustworthy boot chain, from the hardware up to whatever OS you choose to run. That’s why he’s interested in CoreBoot and it’s why he wants everyone to ship Pluton: they both provide parts of this story. This is why all of the ‘Microsoft is trying to take control of all of the things!!!l1111eleventyone’ articles about Pluton make me a bit sad.

          1. 5

            Once bitten, twice shy. Microsoft’s never apologized for their 90s attitude and business approach, nor have they demonstrably changed since then. They were found to be monopolists in both the USA and EU, and did the bare minimum to appease the courts and regulators. The original secure-boot proposals were along the lines of the illegal Wintel trust between Microsoft and Intel, and aimed to exclude other vendors from multiple end-user markets.

            1. 2

              CPU vendors adopt Pluton as their hardware root of trust

              Do you perhaps know what is the difference between Pluton and good old regular fTPM (firmware TPM implemented in the secure enclave of the CPU)? Most of the material about Pluton I found sadly doesn’t go into technical details.

              (Btw nice to see someone from Microsoft Research here, I’m continuously amazed by the work you all do!)

              1. 4

                There are three ways of implementing a TPM:

                • A fTPM is implemented firmware in a separate security level (e.g. TrustZone on Arm, SMM on Intel). This is a problem because it is often vulnerable to side channels and sometimes to things like power-glitching attacks that let untrusted code run in the secure mode.
                • A separate chip. These are often just plain unreliable but even with a good implementation they are problematic because there’s no secure communication path between them and the CPU. A physical attacker can record the measurements that the CPU sends to the TPM and then fake them and request that the TPM signs things on behalf of malicious hardware / software.
                • An on-chip (or on-package) separate core with isolated memory. There are a bunch of corner cases that can make this kind of thing difficult to get right (is the untrusted core able to attack it by adjusting power? What about timing-based attacks from an attacker on the untrusted core with a cycle-accurate view of time?)

                Pluton is basically a good implementation of the last form. It is hardened against various kinds of attacks and it’s had people with physical access attacking the version shipped in the Xbox One for several years without success (most of them probably weren’t willing to pop the top off the SoC and directly probe individual components, but if an attacker is willing to spend that much on a targeted attack on me then I’m probably screwed anyway). It provides the key-management, signing, encryption, and random-number generation functionality that’s necessary to implement the TPM spec (it could also be used to implement other interfaces to the same underlying functionality).

                I don’t really know why we don’t publish more docs on Pluton. My guess is that it’s because people are expected to communicate with it via some higher-level interface (such as the TPM spec or the APIs in Azure Sphere) and so they shouldn’t be exposed to the implementation details. The docs I’ve read are all marked Microsoft-super-duper-secret (or whatever the official term for this is) but they didn’t contain anything that looked like it actually was commercially sensitive: Pluton provides the set of features that I’d hope for (though, sadly, not always get) from an off-the-shelf hardware root of trust. I believe Google’s Titan core provides a very similar set of features (though I’ve not seen any detailed docs about it, so that’s largely conjecture). The exact hardware mitigations that it deploys are probably sensitive because they might help an attacker (even knowing that a particular category of attacks definitely won’t work can significantly reduce work factor).

            2. 1

              Wow. I completely missed that. Yep… that wins.

            3. 4

              I’d have expected Windows 11 to boot with Coreboot just fine.

              Honestly, based on what I’ve seen, I wouldn’t expect anything other than Linux to boot with Coreboot. It seems very much the people who’d explicitly use Coreboot only care about that.

              1. 2

                Maybe the “11” part deserves more emphasis than I’m giving it, but I’ve never found it challenging to boot Windows. If you can make your thing look more-or-less like BIOS and handle x86 instructions, Windows gonna boot. So while we’re in violent agreement that those who go to the trouble to put Coreboot on a thing likely only care that Linux boots on the thing, “Windows boots on PC” feels very “dog bites man” even with coreboot in place. I guess it changes a bit if windows is still willing to do that handful of things it’ll only do with measured boots…

                And I guess that’s the kernel of my question: is a Coreboot config that leaves Windows comfortable doing those things it only wants to do after it likes all the measurements also able to boot Linux?