8 ms·

The fearmongering about Pluton feels very similar to the criticism that was levied against UEFI Secure Boot when it was being debuted. In the end, x86 systems d

by messe 5y ago

The fearmongering about Pluton feels very similar to the criticism that was levied against UEFI Secure Boot when it was being debuted. In the end, x86 systems didn't become any more locked down. I predict that this will blow over, and won't be a big deal in a few years time once FOSS drivers for what is effectively just a new breed of TPM are released. If in five years, it turns out I was wrong, I'll eat my hat. Although defining "my hat" by then might be difficult, as it'll probably be subscription based.

jevoten 5y ago
> In the end, x86 systems didn't become any more locked down. And non-x86 systems? Wasn't there a line of MS Surface devices where secure boot could not be disabled, and users were stuck with Windows? It feels careless to only care about x86, especially as other platforms proliferate. In any case, lockdown is not the only threat that Trusted Computing presents. Remote attestation itself is dangerous. If we remove our x86 blinkers and look at the mobile world, we see it's already happening, with countless apps, including ones important to modern day life such as banking, refusing to run on rooted phones. You may say, "Oh, I will use my x86 desktop system at home for Free Computing, and allow phones, consoles, tablets, surface devices, etc etc, to become locked down." Like the old free speech zones, this is a toothless freedom, tamed and neutered. The user-empowering Free Software you will write will have no users - they will be on locked devices.
- messe 5y ago
  While that's true, with regard to some Surface devices, as I understand it, ARM systems have only become more open and interoperable over the past few years; although this holds true a lot more for the server side than desktop side. The main issue these days is driver support. The PC platform was an anomaly in backwards compatibility, at least historically. I'm not arguing that it's going to be easy for FOSS. It's going to be an uphill battle, regardless of how locked down they are (and I'm just arguing that they won't be that locked down—see the recent M1 Macs for an example; Apple could easily have locked down those systems in exactly the same manner as iOS/iPadOS devices, but chose not to).
  - lillecarl 5y ago
    It's just really sad that Apple doesn't help us with drivers for their hardware, I highly doubt the majority would switch anyways, and assisting with info could be done with less effort if people are already doing reverse engineering work.
    - messe 5y ago
      I suspect it's a mix of legal difficulties in releasing the documentation, and a lack of incentive to write it in the first place. The ideal scenario would be Apple pushing their hardware in the server space; that might create an internal incentive for apple to get Linux running decently (or at the very least make Darwin a new competitor in the datacenter).
    - astrange 5y ago
      The supported method is virtualization.
  - my123 5y ago
    For arm: anything that runs Windows on Arm64 uses UEFI + ACPI, making stuff easier on that front. Linux drivers for Qualcomm SoCs don't have extensive ACPI bindings at this point in time though, making the use of a separate devicetree necessary for full functionality. This will be mostly ironed out with time I suppose.
    - floatboth 5y ago
      Didn't Linux developers say that Qualcomm's ACPI tables are a horrific Windows-specific mess that has close to zero standard PNP* things?
      - my123 5y ago
        > Windows-specific mess that has close to zero standard PNP* things Those are hardware dependent platform devices. Qualcomm didn’t have another option. (Nor do other manufacturers really) On x86, a virtual PCIe bus abstraction is heavily used, which is not the case for those SoCs. (And well, if Linux wants to boycott full support of their SoCs, their choice. They just can’t blame Qualcomm anymore at that point.) Another thing of note is the use of a PEP (power management plug-in) in the OS instead of having power management done in AML. The ACPI spec allows a manufacturer to do this. It isn’t used only by Qualcomm, but is totally unsupported on Linux today.
- gruez 5y ago
  Your ARM smartphone and/or IOT device don't support UEFI or secureboot, yet they were still locked down and you couldn't flash third party OSes. The problem is locked bootloaders, not UEFI or secureboot. Fearmongering over a largely non-problematic implementation (secureboot explicitly allows you to load your own keys) is exactly OP's point.
  - jevoten 5y ago
    This sounds very much like "there are many ways to lock out users, why are you complaining about this specific method, when other platforms used a different one?"
    - shukantpal 5y ago
      No it’s more like “why complain about a method that isn’t being used to lock down devices instead ones that are actually being used for that purpose”
    - judge2020 5y ago
      We should be complaining when it happens, not that any of these methods exist - they're super useful to have in many applications, eg. access control door locks, keeping PKI HSMs locked down, etc.
- my123 5y ago
  > Wasn't there a line of MS Surface devices where secure boot could not be disabled, and users were stuck with Windows? All Windows RT devices (32-bit Arm desktop Windows). Not only Secure Boot was locked down there, but apps had to be signed by Microsoft. 64-bit Windows on Arm adopts the security policy of x86_64 Windows, which means that you can turn off Secure Boot on production hardware. (and run your regular apps too)
guerrilla 5y ago
> In the end, x86 systems didn't become any more locked down. This is not the end. They'll keep pushing, as slow as they need to, with Windows 11 being the next step. They didn't suddenly lose the incentive, they just met resistance.
- A4ET8a8uTh0 5y ago
  True, but some of the responsibility lies with the users. If they can't be bothered to care, then maybe some pain is warranted. In my particular case, I stopped upgrading Windows around 7. It is only last year that I decided to upgrade and that was also the year I moved to linux as my main driver. I am not an average user, but I am not kernel contributor either. I am just a guy, who wants some stuff done on a PC I own. And that might be part of the issue. People need to feel the pain from the devices they have been sold so that they can learn why freedom and ownership is important.
gruez 5y ago
>to the criticism that was levied against UEFI Secure Boot when it was being debuted ...or the fearmongering from up last year regarding TPM and windows 11. People were going hysterical over the thought that TPM might be used for DRM, not realizing that they're already running hardware that does exactly that (intel SGX, amd PSP).
- guerrilla 5y ago
  Is your argument that things are bad, so who cares if they get worse?
  - gruez 5y ago
    Well in this case it's not really getting worse. The hardware you bought is already backdoored/locked down. It's like closing the stable door after the horse ran away.
    - guerrilla 5y ago
      So two (or twenty) vulnerabilities in your software isn't worse than one?
      - gruez 5y ago
        That's not a good comparison because there are multiple bad guys wanting to hack into your computer, and more vulnerabilities mean higher chance that at least one succeeds. For this, we can assume that OEMs/microsoft is on the same side, so the better analogy would be: having 20 NSA root CAs installed on my system isn't worse than only one, at least if my threat model is "NSA hacking my communications".
- hermitdev 5y ago
  I was more concerned about the TPM requirement purely due to not having one in my desktop that's otherwise perfectly capable of running Win11 Pro (I know because I've been running Win11 for months on it via the Insiders Program). Yes, the desktop is 8 or 9 years old now, but it's still a 6 core I7 with 64GB Ram and a suitably fast SSD (not nvme, though). To me, it reeks of planned obsolescence in the name of pushing Windows Hello, that I don't need. I did look into what an upgrade to add a TPM would cost. I was looking at over $400 for a like motherboard to support TPM (without an actual TPM chip), but I'd also lose SATA channels I currently use. At the point of having to replace a motherboard, it starts looking attractive to do a full rebuild, but that's difficult with supply shortages and inflated costs currently.
heavyset_go 5y ago
Some x86 systems weren't completely locked down, but similar systems successfully lock down millions of phones, tablets and console devices (which are x86 systems these days). The trend for security in desktop computing that's pushed by these large companies is to, over time, approach similar levels of lock down that mobile devices currently have. Both Windows and macOS are approaching the iOS security model that depends on manufacturers blessing what software can run on their products, and banning software they don't want users to run. For example, with Defender on Windows and Gatekeeper on macOS, developers need to buy certificates from Microsoft and Apple's partners in order to distribute and run their software on users' desktop computers. If developers want their software to run on Windows or macOS, they need to remain in good standing with Microsoft or Apple. If Microsoft or Apple decides they don't like you or your app, all they need to do is to revoke your signing certificate, and Defender and Gatekeeper won't let your software run on Windows or macOS. That, or they can choose to no longer renew your certificates after they expire.
- gruez 5y ago
  > Some x86 systems weren't completely locked down, but similar systems successfully lock down millions of phones, tablets and console devices. so shouldn't we be protesting against the systems that are locked down, instead of protesting against largely non-problematic implementations? For instance, with secureboot you can load your own keys, and the TPM isn't some sort of coprocessor that has access to your entire system. >If Microsoft or Apple decides they don't like you or your app, all they need to do is to revoke your signing certificate, and Defender and Gatekeeper won't let your software run on Windows or macOS. I'm not sure about gatekeeper, but at least on windows smartscreen can be disabled. I understand how having a gatekeeper sucks, but I also understand the problem of malicious software, which gatekeeping partially mitigates. In the end the fact that you can disable makes it a non-issue for me.
  - im3w1l 5y ago
    It is not a non-issue. Because 95% of people will not disable it. This means that if Microsoft asks some company to make changes to their program, then they will have a lot of leverage behind that ask. Even if you personally disable the gatekeeping, you will be affected indirectly as the market for non-compliant programs will be unsustainable. Everything you run will be microsoft compliant, outside maybe one or two hyper-niche things. This is what Android has taught us.
userbinator 5y ago
In the end, x86 systems didn't become any more locked down. Oh hell yes they did. Look at Intel Boot Guard and all the stuff around that.
- gruez 5y ago
  >Look at Intel Boot Guard and all the stuff around that. what am I looking for? It looks like you couldn't load third party/modified firmware with that enabled? I suppose it's strictly more locked down than being able to flash whatever firmware you want, but was there a sprawling scene of modified firmware around at that time? Or did everybody essentially run the stock firmware?
  - userbinator 5y ago
    BIOS mods are not exactly common, but there's plenty of people doing it. Projects like coreboot are another example, and of course all the tools around removing as much of the ME as possible. Obviously the "fringe" gets slowly trimmed, and we should be looking out for those like we do canaries in a coalmine.
    - gruez 5y ago
      I'm not exactly sure how me_cleaner works, but AFAIK it still works even with intel bootguard? I believe the way it works is that intel ME are present in the bios as optional modules, and they can be removed without messing up the signature.
shmerl 5y ago
Knowing history of MS I wouldn't call it fear mongering but rather very reasonable concerns. They ended up not materializing as a problem, which is good. But they were very reasonable nevertheless.
zucker42 5y ago
> The fearmongering about Pluton Part of the reason for this "fearmongering" (if it's fair to call it that) is that Microsoft has released little information about Pluton, besides a press release. Plus, it's not like the fears are completely unfounded based on Microsoft's messaging; Microsoft's press release says Pluton is based off the Xbox[1] (and this paywalled article mentions the same thing[3]), and they've previous said the major goal of the Xbox security system is piracy prevention [2], i.e. DRM. However, I agree with the overall conclusion of the main article that it's probably not much worse that what already exists. [1] https://blogs.windows.com/windowsexperience/2022/01/04/ces-2022-chip-to-cloud-security-pluton-powered-windows-11-pcs-are-coming/ https://blogs.windows.com/windowsexperience/2022/01/04/ces-2... [2] https://www.platformsecuritysummit.com/2019/speaker/chen/ https://www.platformsecuritysummit.com/2019/speaker/chen/ [3] https://ieeexplore.ieee.org/abstract/document/9354509 https://ieeexplore.ieee.org/abstract/document/9354509
dataflow 5y ago
> In the end, x86 systems didn't become any more locked down. I realize it was only introduced as of ~2012 and it's been 10 years, but I'm not sure we can draw a conclusion on this one just yet. Windows 11 took a huge leap in that direction so for all I know it might take another decade; it certainly doesn't look like they've given up on the idea of locking down the desktop just yet.
- messe 5y ago
  They attempted to lock down the boot process with 32-bit ARM, but backtracked with 64-bit ARM. If the intention was to keep eventually lock it down, why backtrack and open it back up? It's not as if Linux on ARM was a major selling point for their ARM devices.
  - dataflow 5y ago
    I actually don't have knowledge of that. Do you know what the reason for the backtracking was?
    - messe 5y ago
      To be quite honest, I'd be interested myself to find out. I can't see the motivation for changing it, other than they found it not to be beneficial. It seems like opening it up again would just create more problems in the long run if they intended to close it down eventually. I might look into it, as it sounds like an interesting rabbit hole.
    - mjg59 5y ago
      Microsoft's 32-bit ARM devices were being sold as appliances, their 64-bit ones are being sold as general purpose computers.
- gruez 5y ago
  >it's been 10 years, but I'm not sure we can draw a conclusion on this one just yet. seriously? 10 years is an eternity in tech, and if they really did lock down the desktop a few years from now with some new system (eg. pluton), I'm not really sure that you could say "I told you so" or "TPM caused the platform to be more locked down". It'd be like predicting some sort of smallpox attack by china in 2010, then claiming you got it right in 2020 because of corona. The only plausible scenario where you could plausibly blame TPM/UEFI is if OEMs suddenly decided to remove the ability to add user keys and/or disable secureboot.
Veserv 5y ago
If they are not going to do it then they can just have their lawyers draft and issue a public, legally binding statement that they will not. Since they are not going to do it anyways, they are no worse off, and the customers get a legally binding guarantee resolving their concerns, and it provides just cause to the good actors in Microsoft management to head off or remove any elements besmirching Microsoft’s reputation. Sounds like all wins to me and it is what any B2B contract with Microsoft would do (well in the contract rather than publicly) if they wanted that guarantee so it is not even a particularly novel legal request.
nescioquid 5y ago
Were I to grant what you say, it is /still/ a load of anti-social, dystopian shit flung against the wall for FOSS devs to scrap off (if ever they may), keeping them from doing something more advantageous. You only condone the poisoning of the well because you take for granted the pro-socially minded developers willing to sacrifice their time and effort to draw clean water for you. Think of where we'd be if we didn't need to run to stand still.
- messe 5y ago
  > Were I to grant what you say, it is /still/ a load of anti-social, dystopian shit flung against the wall for FOSS devs to scrap off (if ever they may), keeping them from doing something more advantageous. > You only condone the poisoning of the well because you take for granted the pro-socially minded developers willing to sacrifice their time and effort to draw clean water for you. If you're referring to my comment about drivers, then I'd like to remind you that a large amount of work done on the Linux kernel is paid, and isn't performed by volunteers. And as for those that are volunteers, I don't take them for granted. I regularly donate to various FOSS projects. Related to this context, I'm currently a patreon supporter of marcan42's port of Linux to the M1 Mac, and have donated several hundred euro to OpenBSD over the past two years (not including donations from my hosting provider openbsd.amsterdam, which I'll plug here).
  - nescioquid 5y ago
    You seem to have not understood what I've said. Whatever good will you may extend, the attitude betrays the complacency of an alms-giver. I merely wish to point out how FOSS can be manipulated by such an attitude to provide a fig leaf -- in "a few years time" -- for the rent-seeking behavior I'd hope you condemn. Let me also apologize for my manner. I'm inept at expressing what I think is important without alienating those that might be most receptive to it. Truly, I wish I could have said what I needed more gracefully. I didn't mean to give offense.
mindslight 5y ago
Characterizing informed discussion about the implications of technology as "fearmongering" or "hysteria" is essentially ignorant. The specific functionality of remote attestation is so that a remote party can demand you prove what software you are running, and make it so that you cannot lie. Right now you're free to answer whatever you'd like, while running whatever actual software you choose, as long as you stick to the protocol. Protocols (especially well-defined open ones) are our traditional way of mediating between parties with mutually diverging interests. Remote attestation throws away such neutral mediation, making it so that the more powerful party can dictate what software the less powerful party is running. One implication of a usable implementation of remote attestation is that a website could insist that you are running a certain OS, web browser, etc, and become unavailable to you otherwise. For example, banking websites have a clear path to doing this in the quest for their elusive "security". They already do similarly invasive things that alienate a small portion of users (eg complain about a device being "rooted", blocking VPN/datacenter IP ranges), and so it's a reasonable assumption that they'll adopt such technology for the same regressive goals. And once it starts being a de facto requirement for users to have such functionality and it becomes easy for developers to use, it will trickle down to lower stakes websites - think anything that currently sees fit to harass you with a CAPTCHA. It's not simply Big Bad Microsoft that will push this onto us, but rather the entire market will gradually shift for "security" (ie corporate whims). Will Free Software and the Open Internet still exist? Of course! Remote attestation does not prevent you from running whatever software you like on your local computer. But it will further bifurcate the Free user-representing world and proprietary WebTV land - imagine not being able to do online banking or shopping from your ergonomic desktop system, and having to do it from your phone that you also have to upgrade every two years. And the idea that some day ISPs will mandate this type of technology to connect to their network is far fetched, but still within the realm of possibility. One caveat here is that if the remote attestation is only over the contents of the Pluton chip itself, then it cannot be used to dictate what software is running on the main system. I have no idea if this is the case here or not, but either way the integration of the chip onto the same die as the processor does not bode well for future development. Furthermore, I do not believe the claim elsewhere in this thread that you could proxy such requests, as a secure remote attestation design involves the attestation result being used to generate a decryption key (eg a TLS session key) that does not leave the trusted software environment. So the system performing the attestation is unable to simply relay back what it has learned. There might be design shortcomings that or implementation bugs that allow for doing so, but the straightforward goal is to close those over time as for any vulnerability.
josephcsible 5y ago
> x86 systems didn't become any more locked down. But ARM systems sure did. Remember the whole "OEMs are required to make their ARM Windows devices only trust Microsoft's signing key, and not let the end-user turn off Secure Boot or trust any other keys" scandal?
- floatboth 5y ago
  These 32-bit SurfaceRT/etc. devices were a complete failure; this has nothing to do with current Surface Pro X etc. which do allow everyone to easily turn Secure Boot off.
AshamedCaptain 5y ago
MS literally has to sign and approve the bootloaders from any distribution, or you basically risk your distribution not booting on a majority of x86 systems. And there is always the push by MS to make these bootloaders as restrictive as possible, to prevent the situation where you use one of them to boot some software that will break Windows' FDE. So as a result we end up with e.g. automatic lockdown mode in Linux when booted from a secure boot system. How did x86 not become more locked down as a consequence of this? You can disable all of it (on some devices only!) but the war is already lost: most people are not going to do it, so distros have to pass through these hoops.
no_time 5y ago
>If in five years, it turns out I was wrong, I'll eat my hat. Although defining "my hat" by then might be difficult, as it'll probably be subscription based. Wanna bet that by 2030 there will be atleast one major commercial bank that enforces attestation on it's E-Banking features even on desktops?
tentacleuno 5y ago
> once FOSS drivers for what is effectively just a new breed of TPM are released. I genuinely wonder if Microsoft will put any people on this for Linux. They purport to 'love it', but aside from a few Embrace Extend and Extinguish[0] strategies like Edge, WSL, VS Code etc. I haven't seen anything that made me jump out of my chair in amazement. Maybe they'll surprise me. [0]: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
- transpute 5y ago
  Pluton has been supported by Microsoft Linux for several years and their Azure Sphere support contract promises Liunx security updates for 10+ years, https://www.platformsecuritysummit.com/2019/speaker/seay/ https://www.platformsecuritysummit.com/2019/speaker/seay/
BlueTemplar 5y ago
AFAIK I can easily disable Secure Boot in the UEFI. Is there an easy way to disable TPM / Intel IME / Intel SGX / AMD PSP ? (I'm only aware that Dell can disable Intel IME on request... but only if you're a company buying a large amount of PCs ?)
- heavyset_go 5y ago
  At least with the hardware I'm familiar with, you can turn off the TPM via the BIOS. IME/SGX/PSP, not so much.
  - josephcsible 5y ago
    > you can turn off the TPM via the BIOS In theory you can. In practice, programs will refuse to run if you do this: https://www.techspot.com/news/91138-valorant-anti-cheat-system-requires-tpm-20-secure.html https://www.techspot.com/news/91138-valorant-anti-cheat-syst... That goes for Secure Boot too, btw.
    - BlueTemplar 5y ago
      Yeah, hence the normalization (or lack thereof) of those features being critically important to the discussion.

by messe 5y ago

jevoten 5y ago

> In the end, x86 systems didn't become any more locked down. And non-x86 systems? Wasn't there a line of MS Surface devices where secure boot could not be disabled, and users were stuck with Windows? It feels careless to only care about x86, especially as other platforms proliferate. In any case, lockdown is not the only threat that Trusted Computing presents. Remote attestation itself is dangerous. If we remove our x86 blinkers and look at the mobile world, we see it's already happening, with countless apps, including ones important to modern day life such as banking, refusing to run on rooted phones. You may say, "Oh, I will use my x86 desktop system at home for Free Computing, and allow phones, consoles, tablets, surface devices, etc etc, to become locked down." Like the old free speech zones, this is a toothless freedom, tamed and neutered. The user-empowering Free Software you will write will have no users - they will be on locked devices.

messe 5y ago
While that's true, with regard to some Surface devices, as I understand it, ARM systems have only become more open and interoperable over the past few years; although this holds true a lot more for the server side than desktop side. The main issue these days is driver support. The PC platform was an anomaly in backwards compatibility, at least historically. I'm not arguing that it's going to be easy for FOSS. It's going to be an uphill battle, regardless of how locked down they are (and I'm just arguing that they won't be that locked down—see the recent M1 Macs for an example; Apple could easily have locked down those systems in exactly the same manner as iOS/iPadOS devices, but chose not to).
- lillecarl 5y ago
  It's just really sad that Apple doesn't help us with drivers for their hardware, I highly doubt the majority would switch anyways, and assisting with info could be done with less effort if people are already doing reverse engineering work.
  - messe 5y ago
    I suspect it's a mix of legal difficulties in releasing the documentation, and a lack of incentive to write it in the first place. The ideal scenario would be Apple pushing their hardware in the server space; that might create an internal incentive for apple to get Linux running decently (or at the very least make Darwin a new competitor in the datacenter).
  - astrange 5y ago
    The supported method is virtualization.
- my123 5y ago
  For arm: anything that runs Windows on Arm64 uses UEFI + ACPI, making stuff easier on that front. Linux drivers for Qualcomm SoCs don't have extensive ACPI bindings at this point in time though, making the use of a separate devicetree necessary for full functionality. This will be mostly ironed out with time I suppose.
  - floatboth 5y ago
    Didn't Linux developers say that Qualcomm's ACPI tables are a horrific Windows-specific mess that has close to zero standard PNP* things?
    - my123 5y ago
      > Windows-specific mess that has close to zero standard PNP* things Those are hardware dependent platform devices. Qualcomm didn’t have another option. (Nor do other manufacturers really) On x86, a virtual PCIe bus abstraction is heavily used, which is not the case for those SoCs. (And well, if Linux wants to boycott full support of their SoCs, their choice. They just can’t blame Qualcomm anymore at that point.) Another thing of note is the use of a PEP (power management plug-in) in the OS instead of having power management done in AML. The ACPI spec allows a manufacturer to do this. It isn’t used only by Qualcomm, but is totally unsupported on Linux today.
gruez 5y ago
Your ARM smartphone and/or IOT device don't support UEFI or secureboot, yet they were still locked down and you couldn't flash third party OSes. The problem is locked bootloaders, not UEFI or secureboot. Fearmongering over a largely non-problematic implementation (secureboot explicitly allows you to load your own keys) is exactly OP's point.
- jevoten 5y ago
  This sounds very much like "there are many ways to lock out users, why are you complaining about this specific method, when other platforms used a different one?"
  - shukantpal 5y ago
    No it’s more like “why complain about a method that isn’t being used to lock down devices instead ones that are actually being used for that purpose”
  - judge2020 5y ago
    We should be complaining when it happens, not that any of these methods exist - they're super useful to have in many applications, eg. access control door locks, keeping PKI HSMs locked down, etc.
my123 5y ago
> Wasn't there a line of MS Surface devices where secure boot could not be disabled, and users were stuck with Windows? All Windows RT devices (32-bit Arm desktop Windows). Not only Secure Boot was locked down there, but apps had to be signed by Microsoft. 64-bit Windows on Arm adopts the security policy of x86_64 Windows, which means that you can turn off Secure Boot on production hardware. (and run your regular apps too)

guerrilla 5y ago

> In the end, x86 systems didn't become any more locked down. This is not the end. They'll keep pushing, as slow as they need to, with Windows 11 being the next step. They didn't suddenly lose the incentive, they just met resistance.

A4ET8a8uTh0 5y ago
True, but some of the responsibility lies with the users. If they can't be bothered to care, then maybe some pain is warranted. In my particular case, I stopped upgrading Windows around 7. It is only last year that I decided to upgrade and that was also the year I moved to linux as my main driver. I am not an average user, but I am not kernel contributor either. I am just a guy, who wants some stuff done on a PC I own. And that might be part of the issue. People need to feel the pain from the devices they have been sold so that they can learn why freedom and ownership is important.

gruez 5y ago

>to the criticism that was levied against UEFI Secure Boot when it was being debuted ...or the fearmongering from up last year regarding TPM and windows 11. People were going hysterical over the thought that TPM might be used for DRM, not realizing that they're already running hardware that does exactly that (intel SGX, amd PSP).

guerrilla 5y ago
Is your argument that things are bad, so who cares if they get worse?
- gruez 5y ago
  Well in this case it's not really getting worse. The hardware you bought is already backdoored/locked down. It's like closing the stable door after the horse ran away.
  - guerrilla 5y ago
    So two (or twenty) vulnerabilities in your software isn't worse than one?
    - gruez 5y ago
      That's not a good comparison because there are multiple bad guys wanting to hack into your computer, and more vulnerabilities mean higher chance that at least one succeeds. For this, we can assume that OEMs/microsoft is on the same side, so the better analogy would be: having 20 NSA root CAs installed on my system isn't worse than only one, at least if my threat model is "NSA hacking my communications".
hermitdev 5y ago
I was more concerned about the TPM requirement purely due to not having one in my desktop that's otherwise perfectly capable of running Win11 Pro (I know because I've been running Win11 for months on it via the Insiders Program). Yes, the desktop is 8 or 9 years old now, but it's still a 6 core I7 with 64GB Ram and a suitably fast SSD (not nvme, though). To me, it reeks of planned obsolescence in the name of pushing Windows Hello, that I don't need. I did look into what an upgrade to add a TPM would cost. I was looking at over $400 for a like motherboard to support TPM (without an actual TPM chip), but I'd also lose SATA channels I currently use. At the point of having to replace a motherboard, it starts looking attractive to do a full rebuild, but that's difficult with supply shortages and inflated costs currently.

heavyset_go 5y ago

Some x86 systems weren't completely locked down, but similar systems successfully lock down millions of phones, tablets and console devices (which are x86 systems these days). The trend for security in desktop computing that's pushed by these large companies is to, over time, approach similar levels of lock down that mobile devices currently have. Both Windows and macOS are approaching the iOS security model that depends on manufacturers blessing what software can run on their products, and banning software they don't want users to run. For example, with Defender on Windows and Gatekeeper on macOS, developers need to buy certificates from Microsoft and Apple's partners in order to distribute and run their software on users' desktop computers. If developers want their software to run on Windows or macOS, they need to remain in good standing with Microsoft or Apple. If Microsoft or Apple decides they don't like you or your app, all they need to do is to revoke your signing certificate, and Defender and Gatekeeper won't let your software run on Windows or macOS. That, or they can choose to no longer renew your certificates after they expire.

gruez 5y ago
> Some x86 systems weren't completely locked down, but similar systems successfully lock down millions of phones, tablets and console devices. so shouldn't we be protesting against the systems that are locked down, instead of protesting against largely non-problematic implementations? For instance, with secureboot you can load your own keys, and the TPM isn't some sort of coprocessor that has access to your entire system. >If Microsoft or Apple decides they don't like you or your app, all they need to do is to revoke your signing certificate, and Defender and Gatekeeper won't let your software run on Windows or macOS. I'm not sure about gatekeeper, but at least on windows smartscreen can be disabled. I understand how having a gatekeeper sucks, but I also understand the problem of malicious software, which gatekeeping partially mitigates. In the end the fact that you can disable makes it a non-issue for me.
- im3w1l 5y ago
  It is not a non-issue. Because 95% of people will not disable it. This means that if Microsoft asks some company to make changes to their program, then they will have a lot of leverage behind that ask. Even if you personally disable the gatekeeping, you will be affected indirectly as the market for non-compliant programs will be unsustainable. Everything you run will be microsoft compliant, outside maybe one or two hyper-niche things. This is what Android has taught us.

userbinator 5y ago

In the end, x86 systems didn't become any more locked down. Oh hell yes they did. Look at Intel Boot Guard and all the stuff around that.

gruez 5y ago
>Look at Intel Boot Guard and all the stuff around that. what am I looking for? It looks like you couldn't load third party/modified firmware with that enabled? I suppose it's strictly more locked down than being able to flash whatever firmware you want, but was there a sprawling scene of modified firmware around at that time? Or did everybody essentially run the stock firmware?
- userbinator 5y ago
  BIOS mods are not exactly common, but there's plenty of people doing it. Projects like coreboot are another example, and of course all the tools around removing as much of the ME as possible. Obviously the "fringe" gets slowly trimmed, and we should be looking out for those like we do canaries in a coalmine.
  - gruez 5y ago
    I'm not exactly sure how me_cleaner works, but AFAIK it still works even with intel bootguard? I believe the way it works is that intel ME are present in the bios as optional modules, and they can be removed without messing up the signature.

shmerl 5y ago

Knowing history of MS I wouldn't call it fear mongering but rather very reasonable concerns. They ended up not materializing as a problem, which is good. But they were very reasonable nevertheless.

zucker42 5y ago

> The fearmongering about Pluton Part of the reason for this "fearmongering" (if it's fair to call it that) is that Microsoft has released little information about Pluton, besides a press release. Plus, it's not like the fears are completely unfounded based on Microsoft's messaging; Microsoft's press release says Pluton is based off the Xbox[1] (and this paywalled article mentions the same thing[3]), and they've previous said the major goal of the Xbox security system is piracy prevention [2], i.e. DRM. However, I agree with the overall conclusion of the main article that it's probably not much worse that what already exists. [1] https://blogs.windows.com/windowsexperience/2022/01/04/ces-2022-chip-to-cloud-security-pluton-powered-windows-11-pcs-are-coming/ https://blogs.windows.com/windowsexperience/2022/01/04/ces-2... [2] https://www.platformsecuritysummit.com/2019/speaker/chen/ https://www.platformsecuritysummit.com/2019/speaker/chen/ [3] https://ieeexplore.ieee.org/abstract/document/9354509 https://ieeexplore.ieee.org/abstract/document/9354509

dataflow 5y ago

> In the end, x86 systems didn't become any more locked down. I realize it was only introduced as of ~2012 and it's been 10 years, but I'm not sure we can draw a conclusion on this one just yet. Windows 11 took a huge leap in that direction so for all I know it might take another decade; it certainly doesn't look like they've given up on the idea of locking down the desktop just yet.

messe 5y ago
They attempted to lock down the boot process with 32-bit ARM, but backtracked with 64-bit ARM. If the intention was to keep eventually lock it down, why backtrack and open it back up? It's not as if Linux on ARM was a major selling point for their ARM devices.
- dataflow 5y ago
  I actually don't have knowledge of that. Do you know what the reason for the backtracking was?
  - messe 5y ago
    To be quite honest, I'd be interested myself to find out. I can't see the motivation for changing it, other than they found it not to be beneficial. It seems like opening it up again would just create more problems in the long run if they intended to close it down eventually. I might look into it, as it sounds like an interesting rabbit hole.
  - mjg59 5y ago
    Microsoft's 32-bit ARM devices were being sold as appliances, their 64-bit ones are being sold as general purpose computers.
gruez 5y ago
>it's been 10 years, but I'm not sure we can draw a conclusion on this one just yet. seriously? 10 years is an eternity in tech, and if they really did lock down the desktop a few years from now with some new system (eg. pluton), I'm not really sure that you could say "I told you so" or "TPM caused the platform to be more locked down". It'd be like predicting some sort of smallpox attack by china in 2010, then claiming you got it right in 2020 because of corona. The only plausible scenario where you could plausibly blame TPM/UEFI is if OEMs suddenly decided to remove the ability to add user keys and/or disable secureboot.

Veserv 5y ago

If they are not going to do it then they can just have their lawyers draft and issue a public, legally binding statement that they will not. Since they are not going to do it anyways, they are no worse off, and the customers get a legally binding guarantee resolving their concerns, and it provides just cause to the good actors in Microsoft management to head off or remove any elements besmirching Microsoft’s reputation. Sounds like all wins to me and it is what any B2B contract with Microsoft would do (well in the contract rather than publicly) if they wanted that guarantee so it is not even a particularly novel legal request.

nescioquid 5y ago

Were I to grant what you say, it is /still/ a load of anti-social, dystopian shit flung against the wall for FOSS devs to scrap off (if ever they may), keeping them from doing something more advantageous. You only condone the poisoning of the well because you take for granted the pro-socially minded developers willing to sacrifice their time and effort to draw clean water for you. Think of where we'd be if we didn't need to run to stand still.

messe 5y ago
> Were I to grant what you say, it is /still/ a load of anti-social, dystopian shit flung against the wall for FOSS devs to scrap off (if ever they may), keeping them from doing something more advantageous. > You only condone the poisoning of the well because you take for granted the pro-socially minded developers willing to sacrifice their time and effort to draw clean water for you. If you're referring to my comment about drivers, then I'd like to remind you that a large amount of work done on the Linux kernel is paid, and isn't performed by volunteers. And as for those that are volunteers, I don't take them for granted. I regularly donate to various FOSS projects. Related to this context, I'm currently a patreon supporter of marcan42's port of Linux to the M1 Mac, and have donated several hundred euro to OpenBSD over the past two years (not including donations from my hosting provider openbsd.amsterdam, which I'll plug here).
- nescioquid 5y ago
  You seem to have not understood what I've said. Whatever good will you may extend, the attitude betrays the complacency of an alms-giver. I merely wish to point out how FOSS can be manipulated by such an attitude to provide a fig leaf -- in "a few years time" -- for the rent-seeking behavior I'd hope you condemn. Let me also apologize for my manner. I'm inept at expressing what I think is important without alienating those that might be most receptive to it. Truly, I wish I could have said what I needed more gracefully. I didn't mean to give offense.

mindslight 5y ago

Characterizing informed discussion about the implications of technology as "fearmongering" or "hysteria" is essentially ignorant. The specific functionality of remote attestation is so that a remote party can demand you prove what software you are running, and make it so that you cannot lie. Right now you're free to answer whatever you'd like, while running whatever actual software you choose, as long as you stick to the protocol. Protocols (especially well-defined open ones) are our traditional way of mediating between parties with mutually diverging interests. Remote attestation throws away such neutral mediation, making it so that the more powerful party can dictate what software the less powerful party is running. One implication of a usable implementation of remote attestation is that a website could insist that you are running a certain OS, web browser, etc, and become unavailable to you otherwise. For example, banking websites have a clear path to doing this in the quest for their elusive "security". They already do similarly invasive things that alienate a small portion of users (eg complain about a device being "rooted", blocking VPN/datacenter IP ranges), and so it's a reasonable assumption that they'll adopt such technology for the same regressive goals. And once it starts being a de facto requirement for users to have such functionality and it becomes easy for developers to use, it will trickle down to lower stakes websites - think anything that currently sees fit to harass you with a CAPTCHA. It's not simply Big Bad Microsoft that will push this onto us, but rather the entire market will gradually shift for "security" (ie corporate whims). Will Free Software and the Open Internet still exist? Of course! Remote attestation does not prevent you from running whatever software you like on your local computer. But it will further bifurcate the Free user-representing world and proprietary WebTV land - imagine not being able to do online banking or shopping from your ergonomic desktop system, and having to do it from your phone that you also have to upgrade every two years. And the idea that some day ISPs will mandate this type of technology to connect to their network is far fetched, but still within the realm of possibility. One caveat here is that if the remote attestation is only over the contents of the Pluton chip itself, then it cannot be used to dictate what software is running on the main system. I have no idea if this is the case here or not, but either way the integration of the chip onto the same die as the processor does not bode well for future development. Furthermore, I do not believe the claim elsewhere in this thread that you could proxy such requests, as a secure remote attestation design involves the attestation result being used to generate a decryption key (eg a TLS session key) that does not leave the trusted software environment. So the system performing the attestation is unable to simply relay back what it has learned. There might be design shortcomings that or implementation bugs that allow for doing so, but the straightforward goal is to close those over time as for any vulnerability.

josephcsible 5y ago

> x86 systems didn't become any more locked down. But ARM systems sure did. Remember the whole "OEMs are required to make their ARM Windows devices only trust Microsoft's signing key, and not let the end-user turn off Secure Boot or trust any other keys" scandal?

floatboth 5y ago
These 32-bit SurfaceRT/etc. devices were a complete failure; this has nothing to do with current Surface Pro X etc. which do allow everyone to easily turn Secure Boot off.

AshamedCaptain 5y ago

MS literally has to sign and approve the bootloaders from any distribution, or you basically risk your distribution not booting on a majority of x86 systems. And there is always the push by MS to make these bootloaders as restrictive as possible, to prevent the situation where you use one of them to boot some software that will break Windows' FDE. So as a result we end up with e.g. automatic lockdown mode in Linux when booted from a secure boot system. How did x86 not become more locked down as a consequence of this? You can disable all of it (on some devices only!) but the war is already lost: most people are not going to do it, so distros have to pass through these hoops.

no_time 5y ago

>If in five years, it turns out I was wrong, I'll eat my hat. Although defining "my hat" by then might be difficult, as it'll probably be subscription based. Wanna bet that by 2030 there will be atleast one major commercial bank that enforces attestation on it's E-Banking features even on desktops?

tentacleuno 5y ago

> once FOSS drivers for what is effectively just a new breed of TPM are released. I genuinely wonder if Microsoft will put any people on this for Linux. They purport to 'love it', but aside from a few Embrace Extend and Extinguish[0] strategies like Edge, WSL, VS Code etc. I haven't seen anything that made me jump out of my chair in amazement. Maybe they'll surprise me. [0]: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

transpute 5y ago
Pluton has been supported by Microsoft Linux for several years and their Azure Sphere support contract promises Liunx security updates for 10+ years, https://www.platformsecuritysummit.com/2019/speaker/seay/ https://www.platformsecuritysummit.com/2019/speaker/seay/

BlueTemplar 5y ago

AFAIK I can easily disable Secure Boot in the UEFI. Is there an easy way to disable TPM / Intel IME / Intel SGX / AMD PSP ? (I'm only aware that Dell can disable Intel IME on request... but only if you're a company buying a large amount of PCs ?)

heavyset_go 5y ago
At least with the hardware I'm familiar with, you can turn off the TPM via the BIOS. IME/SGX/PSP, not so much.
- josephcsible 5y ago
  > you can turn off the TPM via the BIOS In theory you can. In practice, programs will refuse to run if you do this: https://www.techspot.com/news/91138-valorant-anti-cheat-system-requires-tpm-20-secure.html https://www.techspot.com/news/91138-valorant-anti-cheat-syst... That goes for Secure Boot too, btw.
  - BlueTemplar 5y ago
    Yeah, hence the normalization (or lack thereof) of those features being critically important to the discussion.