1. 50
  1.  

  2. 10

    Seems terrible for trusted boot and DRM.

    But pretty good for users and for the open source firmware efforts.

    1. 3

      Yup, DRM and trusted boot are atrocities that turn things you purchase into rentals where the company gets to decide how you’re able to use the hardware.

      1. 3

        I hope that RISC-V matures enough (and keeps being open enough) that it becomes possible to manufacture small batches of non-backdoored CPUs as an individual. My happiness would increase greatly.

        1. 4

          Oh man. Imagine being able to order a custom RISC-V CPU for whatever purpose with your own root of trust.

      2. 2

        This.. seems bad? There’s a lot missing here presumably due to embargo but I really wish they had at least discussed threat model more extensively. The ending:

        Therefore, there is a period when SRAM is susceptible to external DMA writes (from DMA to CSME, not to the processor main memory), and initialized page tables for Intel CSME are already in the SRAM. 3. MISA IOMMU parameters are reset when Intel CSME is reset. After Intel CSME is reset, it again starts execution with the boot ROM. Therefore, any platform device capable of performing DMA to Intel CSME static memory and resetting Intel CSME (or simply waiting for Intel CSME to come out of sleep mode) can modify system tables for Intel CSME pages, thereby seizing execution flow.

        Speaks to this a little. Seems there needs to be compromised kernel/bootloader or potentially restricted to compromised platform firmware in order to exploit this.

        1. 2

          Yes, info I’ve read so far is annoyingly light. Mild hints/suggestions that things like MS Bitlocker could be broken, or is it just me? Not sure of it’s key model other than knowing there are multiple ways to unlock.

          Seems there needs to be compromised kernel/bootloader or potentially restricted to compromised platform firmware in order to exploit this.

          I read it similarly, but I don’t know exactly when these processes occur. Perhaps they occur in the background a few mins in? Otherwise it sounds like you need physical access to be able to change boot firmware/bios; which would still be greatly useful if it can be used to defeat secureboot/Bitlocker/etc.

          1. 5

            Might be very bad if you rely on the TPM.

            Should be about as good or bad as usual if you don’t.

            On principle, I disable the TPM. Puts it on the same ballpark as LUKS, as long as you don’t do something stupid like backup the key to your Microsoft account. Still, ultimately, you’re still trusting there’s no backdoors in Windows.

            1. 2

              Why is backing up the keys to Microsoft Account a stupid thing for an ordinary user? I think the common user’s threat model (machine is lost or stolen by some small time crooks) having keys in the MS Account is not a bit vulnerability.

              That is also true, that small time crooks won’t attack the TMP or the management engine either…

              1. 2

                Why is backing up the keys to Microsoft Account a stupid thing for an ordinary user?

                This is akin to key eschew, except you’re opting in to give up your keys, often with no awareness of the implications.

                These keys could be requested from Microsoft by law enforcement, then used to decrypt your data and use it as evidence against you in court. As laws change, something that was totally okay today might get you in trouble tomorrow.

              2. 2

                Out of curiosity, what do you have against TPMs?

                1. 2

                  They give control of our systems to a third party.

                  If we’re lucky, that third party is just a corporation (or a project beholden to a corporation).

                  As this latest news shows, we’re not lucky.

                  1. 1

                    They give control of our systems to a third party.

                    Your system is made of dozens of components all made by third parties, some of which are substantial (e.g. disk controllers, input devices/controllers, network controllers, ME [on intel] or PSP [on amd], etc). It seems odd to single out the TPM as being untrustworthy among all that.

                  2. 1

                    Nothing fundamental. I just don’t trust the implementations.

                    I’m not even talking about the possibility of backdoors, but that I doubt they don’t have security bugs and stupid design choices, like e.g. trusting mitigations against hardware attacks and actually storing your keys/etc unencrypted, hidden only behind some authentication.