> Remote attestation has been possible since TPMs started shipping over two decades ago.
The difference now is that Microsoft are saying they will only support machines which have these TPMs, and therefore they can credibly argue in a few years that the only secure PCs (and thus the only PCs that ISPs should allow online) are ones which can produce a remote attestation to prove they are running the latest OS updates (from an OS vendor that is approved by the government).
> If Microsoft wanted to prevent users from being able to run arbitrary applications, they could just ship an update to Windows that enforced signing requirements.
The trap hasn't been sprung yet, but those are the teeth, yes. Then say goodbye to Tor, E2E encrypted messengers, unapproved VPN apps, and bittorrent clients that don't check a Content ID database.
> The difference now is that Microsoft are saying they will only support machines which have these TPMs
That's a reason to worry about Windows 11 requiring a TPM, rather than a reason to worry about Pluton specifically. But even so, I don't think it's an especially realistic one - outside extremely constrained setups, it's very hard to make remote attestation work in a way that gives you any meaningful guarantees (eg, simply forward the challenge on to a machine that is running the "approved" OS).
> The trap hasn't been sprung yet, but those are the teeth, yes.
Again, something they could just do today while zero people have Pluton.
If Microsoft want to lock-down the entire x86 market, they can do that now. They don't need to wait years for everyone to shift to new hardware that has Pluton in it.
> it's very hard to make remote attestation work in a way that gives you any meaningful guarantees (eg, simply forward the challenge on to a machine that is running the "approved" OS).
I was imagining something like that would be possible (for people with enough tech knowledge), but it's good to have it confirmed, thank you. There would presumably be a cat-and-mouse game of the "approved" OS trying to detect if it was being co-opted into such a scheme.
> They don't need to wait years for everyone to shift to new hardware that has Pluton in it.
As you say, I'm more worried about Windows 11 than Pluton, but presumably the "importance" of Pluton is part of Microsoft's excuse for not supporting non-TPM hardware any more. Once Windows 10 is out of security support (for home users at least), it will be easier for Microsoft to claim that non-TPM Windows devices are de facto insecure.
Look at Google safety net and you will get a clear idea what is happening. If you want to use some streaming apps, etc they will make sure you run an unmodified and up to date OS.
On a side note: Microsoft already starts patronising users e.g. by blocking access to security tokens from nonelevated processes. I hate it when my os starts messing with my freedom to develop sth on top. It all comes in the name of security but will in the end effect freedom.
There are way more android and apple devices online than PCs. No ISP would do anything for PCs alone and if they did, I could easily turn my PC into an "Android Tablet". So Microsoft would have to get Google and Apple behind the same plan and then phase out all existing devices and force all ISPs to implement this. This would yield a huge public outrage because the first states to follow would be China et. al., where remote attestation would enforce you to install the latest government, ahem, upgrade, to your device. Of course the US government and various European nations would very much like to follow suit, but they would be slower than China and then look like they follow the authoritarian path a bit too closely.
Remote attestation will be sold to streaming providers so they can extend their DRM to cover unpatched systems. Maybe multiplayer games will follow. This ain't gonna happen at the ISP level.
That scenario is already reality on Android, where many apps and services will not run unless you use a blessed OS and OS version, verified through remote attestation.
Let's be realistic here. The real competition to Microsoft, Chrome OS, already has a feature to prevent you from delaying updates. It's not a bug or a risk, it's a feature. And it does not require any sort of TPM to be enforced. Microsoft could force all its users to run the latest version, and to run only signed executables today. What Pluton does is it allows those two things to happen more securely.
I don't think this is plausible (government mandate of remote attestation for any kind of Internet access), but if this happens, then I just add smallest and cheapest PC possible (think Atomic Pi) with this remote attestation hardware capability (Proton/TPM/whatever) to the separate VLAN on my home network (so it can't access any other host on LAN side of the router) and forget about the little thing until it fails, e.g. for next 15 years or so. I wouldn't trust this device with my data, I wouldn't run any meaningful applications on it, heck I won't ever attach any monitor or human input devices to the damn thing.
As I explain[0] in response to a sibling comment, sadly it won't be enough (eventually) to have just one locked down device on your home network, they will all have to be individually locked down to access the internet.
No problem for me, as I'm on the verge to say goodbye to Windows anyway. But I'm pretty sure it would be a problem for most of the people using Windows.
Once the vast majority of devices are remote attestation capable (Windows 11 requiring TPM will accelerate this trend), content providers may refuse to serve you unless you attest that you are running a walled-garden OS that won't allow you to ad-block, capture content, run any sort of proxy server, etc.
At some point, even ISPs might require remote attestation to allow you to connect your device to the internet. The IETF is already working on standards for the attestation of network devices[0][1].
I speculate that there will temporarily (perhaps similarly to iOS jailbreaking, which is not available at this time for the newest devices/iOS version[2]) be exploits allowing you fool the attestation by e.g. redirecting it to another device as the author suggests, but the end effect will be that vast majority of people will be effectively confined to a walled garden and even determined hobbyists will only be able to use their general computation capable devices to access all content (or even connect them to the internet) some of the time.
The "not currently" in the title is very important foreshadowing.
This is merely another battle in the war on general-purpose computing.
They will build their kingdom piece-by-piece, and under innocuous-sounding adjectives such as "safety" and "security".
Each of these pieces may look innocuous and perhaps even helpful, but don't lose sight of their ultimate goal.
Once all the pieces are in place to achieve total lockdown, there will be no going back.
Articles like this that say "it hasn't happened yet" and try to spin a positive narrative are not showing the big picture. Arguably, Big Tech does not want you to see the big picture.
100% this. They call it fear mongering and paranoia for now because it's only something that could happen.
There used to be debates about whether face recognition should be allowed at all. In 2017 an executive order rolled it out at airports, where it's now used by the CBP and some airlines. The TSA is now considering using it. The debates are over, it's happening and there are now articles about how convenient it is to board without a boarding pass. The definition of normal continues to shift slowly towards universal surveillance. Every little increment is enabled by a few years of the previous increment being normalized and a morsel of security or convenience.
Exactly - I remember the warnings about how TPMs would eventually get normalized and how Windows would require one to run. Well, we've arrived at that point !
Soon even buying a PC without a TPM will become very hard - if we're not already at that point ? (What are our options these days ?)
Honestly I can't imagine any group of companies in the tech space being more resourceful than 10,000 neglected teenagers with nothing but a computer and a bad attitude. Especially after the former tells the latter that they can only do "approved" things with their computer.
Do you really think they'll be able to break the strong crypto which will ultimately be used to "secure" this?
Maybe they could exploit a buffer overflow or other such bug, but if our opponents are so keen on adopting "secure languages", that path to freedom is going to close too.
When governments were scared that encryption was going to be used against them and wanted to ban it, we should've realised that the same situation could apply to us. I'm not at all arguing in favour of such bans, but the underlying message was just as applicable.
The fact that there is no "user override"[0] feature in any of these security processors is blatantly obvious evidence that they are designed to control and restrict first and foremost. I have read mjg's other posts on the topic and have no reason to believe he is arguing in bad faith but I'm still not convinced one bit.
I wouldn't call it bad faith, but more like furthering the industry narrative.
Unfortunately a lot of intelligent individuals are perfectly content to help the corporations and governments tighten the nooses on everyone, including themselves, in return for $$$. They've convinced themselves that they are doing good.
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.
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.
> 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.
> 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.
That's been said for years, and hasn't held true. I can boot a Linux kernel on my M1 macbook. Apple could easily have locked it down in exactly the same manner as their iOS/iPadOS devices, yet chose not to. I can still install whatever I want. The default state of the system has a locked down root volume. And the default behaviour is not to install untrusted software, unless you jump through a couple of hoops. Those are good defaults. Those are damn good defaults for most people. If you're running untrusted code in your webbrowser all day long, you want your base system to be as unmalleable as possible, and as untrusting as possible to third party code. But I can still work around that with almost no hassle. Homebrew still installs software as easily as it used to nearly a decade ago; it just might need the occasional --no-quarantine flag for unsigned software.
Even recently they appeared to have actively assisted in the running on non-macOS operating systems on their hardware: removing the requirement for kernel images to be in mach-O format[1].
> 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.
> 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)
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.
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).
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.
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.
> 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).
>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?
> 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.
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.
>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.
>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?
> 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.
> 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.
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.
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.
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.
>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).
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.
Well my PC does NOT have any of those (AMD Bulldozer), so you can understand how I would be annoyed that this decision makes it ever less likely for me to be able to upgrade to another x86 in the future. (Thankfully, we're not in the nineties/oughties any more with computers becoming effectively obsolete in a year...)
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?
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.
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.
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.
> Secure platforms anchor on a hardware Root of Trust as the foundation. Given Intel’s diverse ecosystem, our vision is to offer multiple Root of Trust options that ensure isolation of resources, keys and security assets. The partnership with Microsoft to offer Pluton will further broaden the choices available to our mutual customers.
Hopefully a future Intel SoC will include an optional FPGA-based RoT where customer hardware owners can load the open-source firmware of their choice.
Edit: Pluton will be included in upcoming Arm laptops with SoCs from the Qualcomm-Nuvia (former Apple M1) team.
Take a look at the past 3 years of presentations at DARPA ERI, where every major US silicon vendor is participating. Much work is underway on heterogeneous systems, including Open FPGAs and OSS toolchains for EDA, to speed up (days, not months) the design-test-deploy cycle for specific applications.
AMD provided a custom (expensive) SoC and RoT to MS Xbox, now being generalized with MS Pluton in 2022 Ryzen CPUs (and some future Intel CPUs). Intel already offers custom CPUs to some large customers. If a security-sensitive automotive or robotics customer needed an FPGA RoT, and the market opportunity was sufficiently interesting, Intel has multiple options for meeting that requirement.
> This is sarcasm, right? It must be sarcasm.
Intel at least left open the possibility in their press announcement. AMD did not, but they have purchased Xilinx and TSMC is building a US-based fab in Arizona, with "secure supply chain" FPGAs high on the list of early product candidates. It's up to customers to bang on Intel/AMD doors and show demand for FPGA RoT chiplets that support OSS gateware.
Will this allow my computer, in the future, to be as locked as current smartphones? Will this allow software to refuse to run or services to refuse to work depending on third party software I have installed?
"Secure boot" and "remote attestation" are complementary features.
Specifically secure boot is what makes it so that "your" computer is unwilling to run software that has not been approved by the company that made it. This has existed for quite some time, and is responsible for the locked down mobile ecosystem as well as the inability to remove the Intel ME and AMD PSP embedded malware from recent PCs.
Remote attestation has not been widely implemented yet, but will make it so that remote services refuse to work unless you are running only software that the service approves of. I'm not sure how much Pluton moves the needle forward, but any amount is not good. If remote attestation comes into full effect, many websites will only be usable on newer computers and websites will be able to forcibly disable software the website finds objectionable, like say Adblock.
>I'm not sure how much Pluton moves the needle forward
A lot. They only need to wait for Pluton enabled PCs to reach critical mass. Compared to TPM's, Pluton is inside the chip thus not vulnerable to bus tampering and is not a standard but a "product", meaning Microsoft will have the ability to make changes without intervention from other companies.
We want there to be less ways of doing that. The fact that one way already exists doesn't mean that we should be okay with more. The desired end goal is that eventually there's zero ways to do this, and we'll never get there if we keep moving in the wrong direction and justify it by not already being there.
There's a huge difference between "exists" and "is now commonly available and made easier to use". The frog-boiling is slow, but an increasingly large number of us are becoming aware of this new rise of corporate authoritarianism, and we know how it will end if we do not fight it as hard as we can.
...no? How would MS force me to install an AGESA update that supposedly restricts me in booting unsigned code? That's where the newly announced remote attestation comes in.
On the other hand, on PCs with Pluton chips they can change their minds any second.
This has always been true and while it's better this iteration of the cycle, it's not great.
But have you actually used Windows in recent times? The UX has gotten infinitely worse since XP. Mac OS has changed about as much as the popular open source DEs, but Windows is infinitely worse. I can't stand using it. The taskbar is garbage, the menus are garbage, the discoverability of anything is the worst it has ever been.
I can't imagine they're ignorant to the fact that Desktop UX is no longer a differentiator for them. The only lock-in they have is in business environments, for which there is zero competition at their price point.
It's inevitable that the host OS gets locked down. The runtime has moved to the browser and cloud. It's just a matter of time.
Windows UX is ass, but it runs a lot of nice software. Runs it well too. Many things don't work as well in wine. I'm talking both slowdowns and glitches.
I've always thought this was just Microsoft's copy of Google Titan and Apple's T2. And as others have pointed out, there's a lot of overlap with what a TPM can already do.
The main thing that comes to mind for me is that since this is integrated into the CPU itself, now 'things' can be strongly and directly tied to the CPU instead of a separate TPM or some collection of hardware identifiers. Was this already possible on x86? My mind immediately went to "this will be used for tighter DRM"; I feel like content owners would like this a whole lot.
If you have an AMD system then there's a decent chance that it's already running a TPM stack on the on-die Platform Security Processor. Pluton isn't really any more tightly integrated, it just means the TPM stack isn't running on the same core as a bunch of other random platform things.
So basically "Why it's ok and you should be happy about Microsoft's hardware controlling the software on your PC".
I'm so unbelievably sick of this 'security by corporation, it's what's best for you so accept it bullshit.' I really am.
No I don't want proprietary internet enabled hardware on my PC monitoring my software, no it does not make me feel safe and secure, actually, go fuck yourself and whatever marketing bullshit you spew to make this desirable for consumers. I'm honestly so fucking done with this kind of shit.
A quick look at the author's credentials should clear any doubt about the motivations behind this article's intentions --- over the past few years, I have come to the conclusion that anyone who works in the "security" industry is almost certainly working against you and your freedom.
Even if that's true right this minute, an unauditable (:/) bit of hardware controlled by Microsoft (!) that can be force-updated by them (!!!) means this can change at any moment.
I liked TPM with my own keys. This just seems a bit 'extra' in all the wrong ways.
So we already have to trust the Intel ME crap, and now the MS crap too.
How is this similar to the status quo? _At best_ it increases the number of actors you have to trust, specially if you are not using Windows.
Don't forget that even recently Microsoft has pretended to be committed to open source, but consistently continues to make decisions that counter that. What may look friendly today like their switch to Edge, may end up being entirely hostile like Edge has become today.
in german we call stuff like pluton "politik der kleinen schritte" or "salamitaktik". which basically means that little step for little step, things change.
it is not CURRENTLY a threat, but it builds up to be a threat in the future if we do not stop and/or constrain it.
We should put an emphasis on currently, but also I think we should discuss how Microsoft is positioning itself as a gatekeeper and forcing all market players to adopt their tech.
If Microsoft says Windows will only support has with this tech enabled, and since almost every computer on the planet runs Windows, vendors must adopt this tech or go out of the market.
In other words, Microsoft is positioning itself to say to all market players to play by its rules or go out of business.
This is a perfect way to establish control over the market without establish itself as a monopoly, thus not attracting attention from regulators.
It sounds like they're using UEFI capsule updates for the firmware, so it'll actually be easy to perform the updates under other operating systems - Microsoft just won't have any mechanism to compel you to do so.
Though having a blob firmware from MS embedded into the CPU itself feels kind of weird. A better way to do it was some third party handling it or requiring that firmware to be open source for example.
I think this is about securing data/keys (AES, TLS, TPM..) vs securing code (Secure Boot, TEEs..). Neither is really a threat to software freedom as I see it, as long as it's user controlled or can be rendered effectively inactive.
The thorniest question I think is around TEEs. You either trust ME/PSP/mobile TEEs for their explicitly mentioned uses (fTPM, SVM, Remote attestation..) or you think they should be even more sandboxed or perhaps shouldn't exist at all. I'm all for the middle ground/option here where the user is in control, thought others may disagree. Remote attestation could be a case where the user is losing control, so preserving user control there is important.
Man, I was really enticed by the specs on these Z-series laptops by Lenovo and was looking at an upgrade. But I was reading about Pluton this afternoon, and now looking at this thread, I don't know how I feel about it. Why ruin a great new CPU with future spyware?
I don't like the edit at the bottom where the author's like: oh yea, of course this could be a massive issue against FOSS but we should just assume that vendors will think it's impractical. I've seen how banks react to rooted phones, even when rooted to heighten device security--and I've switched banks before because of it. They don't care.
I'm totally with you. Not using banking apps - just sites. Also stopped buying CPUs with DRM-on-chip. It's pretty crazy what they're doing now instead of just "computing machines" (
Unfortunately with the DRM situation, the benefits are much outweighing the cost. The speed gains and compatibility I'd get let me do a lot more things. I can use these better CPUs to compile a lot faster :|
The banks not much better. All banks in my country have dated late 90s-looking websites with not even UTF-8 encoding (so you can't send an email with a comma). They are barely usable on desktop. I'd have to make my own client or at least whip up a lot of magic CSS to get it to be mobile-friendly and would even still need to include QR code scanning as it is so ubiquitous that no one would let me fiddle with adding their account numbers.
With RISC-V at-least individual providers can spinoff their own versions of the architecture without having to ask for permission, from an entity like intel,amd or arm.
Unlike right now, where all x86 chipsets have backdoors, and all new ones have “Trusted” computing features which you cannot say No to.
There are a lot of security benefits to using a TPM. I wouldn't mind if I could use an open source one in Linux.
They ameliorate a lot of low entropy problems for passwords and can improve security. I can't imagine a proprietary one being mandatory. My banking app uses the mentioned remote attestation so I can't use it on my less-Googled Calyx ROM. I just think that's stupid instead of very strong warnings.
Meanwhile, hardware-level OS-ignostic rootkits like Computrace exist, and Intel ME has its own network stack, but Pluton being adopted as some kind of industry standard to lock down a platform in the name of "security" and what have you is a conspiracy.
Does Computrace even work if you're not running Windows? Does it have a Linux/MacOS/etc. payload now?
(Reversed much of it a long time ago --- and remembered it was specifically coded with Windows in mind, with certain assumptions about various things.)
It's not that they can't do security without going full authoritarian, I think they do it because they want to go authoritarian. The new security benefits are just a vehicle.
They're a lot like the common politician who smuggles horrible laws into relief bills or trade treaties. UEFI (especially on the ARM platform) and intel ME are to examples of this.
What worried me about pluton is essentially both the fact it might set a trend where drm locks out Linux devices and that remote exploits on pluton is a real nightmare scenario.
Despite the fact I in a way do think tpm like components are a good thing.
One great advantage of these separate silicons is that side channel attacks are greatly mitigated; it's everything else that worries me (closed platform, no transparency, unusable once vendor stops supporting it etc)
Chromebooks give you full flashing & serial console access for both AP (main CPU) and EC over an SBU cable, run open source firmware on both AP and EC (modulo FSP/AGESA), even run open source firmware on the root of trust (you can't replace that one with an unsigned build on a retail device but you can study it for sure).
Apple silicon Macs have the main CPU cores fully in control, with zero external peripherals having full DMA access to system RAM (everything goes through IOMMU), and have an interesting secureboot architecture that allows different security levels on different OS installations (you can run unsecured Linux side-by-side with a fully Netflix-ready macOS).
I have much worse news about the typical Intel BootGuard'ed PC laptop.
> Remote attestation has been possible since TPMs started shipping over two decades ago.
The difference now is that Microsoft are saying they will only support machines which have these TPMs, and therefore they can credibly argue in a few years that the only secure PCs (and thus the only PCs that ISPs should allow online) are ones which can produce a remote attestation to prove they are running the latest OS updates (from an OS vendor that is approved by the government).
> If Microsoft wanted to prevent users from being able to run arbitrary applications, they could just ship an update to Windows that enforced signing requirements.
The trap hasn't been sprung yet, but those are the teeth, yes. Then say goodbye to Tor, E2E encrypted messengers, unapproved VPN apps, and bittorrent clients that don't check a Content ID database.
> The difference now is that Microsoft are saying they will only support machines which have these TPMs
That's a reason to worry about Windows 11 requiring a TPM, rather than a reason to worry about Pluton specifically. But even so, I don't think it's an especially realistic one - outside extremely constrained setups, it's very hard to make remote attestation work in a way that gives you any meaningful guarantees (eg, simply forward the challenge on to a machine that is running the "approved" OS).
> The trap hasn't been sprung yet, but those are the teeth, yes.
Again, something they could just do today while zero people have Pluton.
If Microsoft want to lock-down the entire x86 market, they can do that now. They don't need to wait years for everyone to shift to new hardware that has Pluton in it.
> it's very hard to make remote attestation work in a way that gives you any meaningful guarantees (eg, simply forward the challenge on to a machine that is running the "approved" OS).
I was imagining something like that would be possible (for people with enough tech knowledge), but it's good to have it confirmed, thank you. There would presumably be a cat-and-mouse game of the "approved" OS trying to detect if it was being co-opted into such a scheme.
> They don't need to wait years for everyone to shift to new hardware that has Pluton in it.
As you say, I'm more worried about Windows 11 than Pluton, but presumably the "importance" of Pluton is part of Microsoft's excuse for not supporting non-TPM hardware any more. Once Windows 10 is out of security support (for home users at least), it will be easier for Microsoft to claim that non-TPM Windows devices are de facto insecure.
18 replies →
Look at Google safety net and you will get a clear idea what is happening. If you want to use some streaming apps, etc they will make sure you run an unmodified and up to date OS.
On a side note: Microsoft already starts patronising users e.g. by blocking access to security tokens from nonelevated processes. I hate it when my os starts messing with my freedom to develop sth on top. It all comes in the name of security but will in the end effect freedom.
That's a bullshit scenario.
There are way more android and apple devices online than PCs. No ISP would do anything for PCs alone and if they did, I could easily turn my PC into an "Android Tablet". So Microsoft would have to get Google and Apple behind the same plan and then phase out all existing devices and force all ISPs to implement this. This would yield a huge public outrage because the first states to follow would be China et. al., where remote attestation would enforce you to install the latest government, ahem, upgrade, to your device. Of course the US government and various European nations would very much like to follow suit, but they would be slower than China and then look like they follow the authoritarian path a bit too closely.
Remote attestation will be sold to streaming providers so they can extend their DRM to cover unpatched systems. Maybe multiplayer games will follow. This ain't gonna happen at the ISP level.
That scenario is already reality on Android, where many apps and services will not run unless you use a blessed OS and OS version, verified through remote attestation.
5 replies →
Let's be realistic here. The real competition to Microsoft, Chrome OS, already has a feature to prevent you from delaying updates. It's not a bug or a risk, it's a feature. And it does not require any sort of TPM to be enforced. Microsoft could force all its users to run the latest version, and to run only signed executables today. What Pluton does is it allows those two things to happen more securely.
I don't think this is plausible (government mandate of remote attestation for any kind of Internet access), but if this happens, then I just add smallest and cheapest PC possible (think Atomic Pi) with this remote attestation hardware capability (Proton/TPM/whatever) to the separate VLAN on my home network (so it can't access any other host on LAN side of the router) and forget about the little thing until it fails, e.g. for next 15 years or so. I wouldn't trust this device with my data, I wouldn't run any meaningful applications on it, heck I won't ever attach any monitor or human input devices to the damn thing.
As I explain[0] in response to a sibling comment, sadly it won't be enough (eventually) to have just one locked down device on your home network, they will all have to be individually locked down to access the internet.
[0] https://news.ycombinator.com/item?id=29866732
No problem for me, as I'm on the verge to say goodbye to Windows anyway. But I'm pretty sure it would be a problem for most of the people using Windows.
Once the vast majority of devices are remote attestation capable (Windows 11 requiring TPM will accelerate this trend), content providers may refuse to serve you unless you attest that you are running a walled-garden OS that won't allow you to ad-block, capture content, run any sort of proxy server, etc.
At some point, even ISPs might require remote attestation to allow you to connect your device to the internet. The IETF is already working on standards for the attestation of network devices[0][1].
I speculate that there will temporarily (perhaps similarly to iOS jailbreaking, which is not available at this time for the newest devices/iOS version[2]) be exploits allowing you fool the attestation by e.g. redirecting it to another device as the author suggests, but the end effect will be that vast majority of people will be effectively confined to a walled garden and even determined hobbyists will only be able to use their general computation capable devices to access all content (or even connect them to the internet) some of the time.
[0] https://archive.fo/uQULm
[1] https://datatracker.ietf.org/doc/draft-ietf-rats-tpm-based-n...
[2] https://en.wikipedia.org/w/index.php?title=IOS_jailbreaking&...
2 replies →
The "not currently" in the title is very important foreshadowing.
This is merely another battle in the war on general-purpose computing.
They will build their kingdom piece-by-piece, and under innocuous-sounding adjectives such as "safety" and "security".
Each of these pieces may look innocuous and perhaps even helpful, but don't lose sight of their ultimate goal.
Once all the pieces are in place to achieve total lockdown, there will be no going back.
Articles like this that say "it hasn't happened yet" and try to spin a positive narrative are not showing the big picture. Arguably, Big Tech does not want you to see the big picture.
100% this. They call it fear mongering and paranoia for now because it's only something that could happen.
There used to be debates about whether face recognition should be allowed at all. In 2017 an executive order rolled it out at airports, where it's now used by the CBP and some airlines. The TSA is now considering using it. The debates are over, it's happening and there are now articles about how convenient it is to board without a boarding pass. The definition of normal continues to shift slowly towards universal surveillance. Every little increment is enabled by a few years of the previous increment being normalized and a morsel of security or convenience.
Exactly - I remember the warnings about how TPMs would eventually get normalized and how Windows would require one to run. Well, we've arrived at that point !
Soon even buying a PC without a TPM will become very hard - if we're not already at that point ? (What are our options these days ?)
If you are interested about this topic (what OSes should do today) I can advise this talk: https://www.usenix.org/conference/osdi21/presentation/fri-ke...
A bit long but I didn't get bored
Honestly I can't imagine any group of companies in the tech space being more resourceful than 10,000 neglected teenagers with nothing but a computer and a bad attitude. Especially after the former tells the latter that they can only do "approved" things with their computer.
Do you really think they'll be able to break the strong crypto which will ultimately be used to "secure" this?
Maybe they could exploit a buffer overflow or other such bug, but if our opponents are so keen on adopting "secure languages", that path to freedom is going to close too.
When governments were scared that encryption was going to be used against them and wanted to ban it, we should've realised that the same situation could apply to us. I'm not at all arguing in favour of such bans, but the underlying message was just as applicable.
1 reply →
The fact that there is no "user override"[0] feature in any of these security processors is blatantly obvious evidence that they are designed to control and restrict first and foremost. I have read mjg's other posts on the topic and have no reason to believe he is arguing in bad faith but I'm still not convinced one bit.
[0]: https://www.eff.org/wp/trusted-computing-promise-and-risk
I wouldn't call it bad faith, but more like furthering the industry narrative.
Unfortunately a lot of intelligent individuals are perfectly content to help the corporations and governments tighten the nooses on everyone, including themselves, in return for $$$. They've convinced themselves that they are doing good.
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.
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.
> 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.
2 replies →
> 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.
That's been said for years, and hasn't held true. I can boot a Linux kernel on my M1 macbook. Apple could easily have locked it down in exactly the same manner as their iOS/iPadOS devices, yet chose not to. I can still install whatever I want. The default state of the system has a locked down root volume. And the default behaviour is not to install untrusted software, unless you jump through a couple of hoops. Those are good defaults. Those are damn good defaults for most people. If you're running untrusted code in your webbrowser all day long, you want your base system to be as unmalleable as possible, and as untrusting as possible to third party code. But I can still work around that with almost no hassle. Homebrew still installs software as easily as it used to nearly a decade ago; it just might need the occasional --no-quarantine flag for unsigned software.
Even recently they appeared to have actively assisted in the running on non-macOS operating systems on their hardware: removing the requirement for kernel images to be in mach-O format[1].
[1]: https://twitter.com/marcan42/status/1471799568807636994
19 replies →
> 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.
> 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)
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.
3 replies →
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).
8 replies →
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.
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.
> 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).
1 reply →
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.
>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?
2 replies →
> 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.
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.
3 replies →
>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.
4 replies →
>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?
> 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_extinguis...
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/
> 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.
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.
> 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-2...
[2] https://www.platformsecuritysummit.com/2019/speaker/chen/
[3] https://ieeexplore.ieee.org/abstract/document/9354509
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.
>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).
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.
Is your argument that things are bad, so who cares if they get worse?
3 replies →
Well my PC does NOT have any of those (AMD Bulldozer), so you can understand how I would be annoyed that this decision makes it ever less likely for me to be able to upgrade to another x86 in the future. (Thankfully, we're not in the nineties/oughties any more with computers becoming effectively obsolete in a year...)
> 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?
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.
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.
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 ?)
At least with the hardware I'm familiar with, you can turn off the TPM via the BIOS. IME/SGX/PSP, not so much.
2 replies →
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.
Background material on Pluton:
1. Xbox Security, https://www.platformsecuritysummit.com/2019/speaker/chen/
2. Azure Sphere (derived from Xbox) with Microsoft Linux kernel, OE/Yocto runtime and QEMU emulation of Pluton for CI/CD, https://www.platformsecuritysummit.com/2019/speaker/seay/
3. DMTF SPDM (PCI device firmware attestation to SoC/RoT), https://www.platformsecuritysummit.com/2019/speaker/plank/
Nov 2020 Intel announcement about Pluton, https://itpeernetwork.intel.com/intel-and-microsoft-plan-to-...
> Secure platforms anchor on a hardware Root of Trust as the foundation. Given Intel’s diverse ecosystem, our vision is to offer multiple Root of Trust options that ensure isolation of resources, keys and security assets. The partnership with Microsoft to offer Pluton will further broaden the choices available to our mutual customers.
Hopefully a future Intel SoC will include an optional FPGA-based RoT where customer hardware owners can load the open-source firmware of their choice.
Edit: Pluton will be included in upcoming Arm laptops with SoCs from the Qualcomm-Nuvia (former Apple M1) team.
> Hopefully Intel will offer an FPGA-based RoT where customer hardware owners can load the open-source firmware of their choice.
This is sarcasm, right? It must be sarcasm.
Maybe I'm out of the loop but I would guess that hell would freeze over before Intel releases something like this, let alone an FPGA Root of Trust.
Take a look at the past 3 years of presentations at DARPA ERI, where every major US silicon vendor is participating. Much work is underway on heterogeneous systems, including Open FPGAs and OSS toolchains for EDA, to speed up (days, not months) the design-test-deploy cycle for specific applications.
AMD provided a custom (expensive) SoC and RoT to MS Xbox, now being generalized with MS Pluton in 2022 Ryzen CPUs (and some future Intel CPUs). Intel already offers custom CPUs to some large customers. If a security-sensitive automotive or robotics customer needed an FPGA RoT, and the market opportunity was sufficiently interesting, Intel has multiple options for meeting that requirement.
> This is sarcasm, right? It must be sarcasm.
Intel at least left open the possibility in their press announcement. AMD did not, but they have purchased Xilinx and TSMC is building a US-based fab in Arizona, with "secure supply chain" FPGAs high on the list of early product candidates. It's up to customers to bang on Intel/AMD doors and show demand for FPGA RoT chiplets that support OSS gateware.
2 replies →
Will this allow my computer, in the future, to be as locked as current smartphones? Will this allow software to refuse to run or services to refuse to work depending on third party software I have installed?
"Secure boot" and "remote attestation" are complementary features.
Specifically secure boot is what makes it so that "your" computer is unwilling to run software that has not been approved by the company that made it. This has existed for quite some time, and is responsible for the locked down mobile ecosystem as well as the inability to remove the Intel ME and AMD PSP embedded malware from recent PCs.
Remote attestation has not been widely implemented yet, but will make it so that remote services refuse to work unless you are running only software that the service approves of. I'm not sure how much Pluton moves the needle forward, but any amount is not good. If remote attestation comes into full effect, many websites will only be usable on newer computers and websites will be able to forcibly disable software the website finds objectionable, like say Adblock.
>I'm not sure how much Pluton moves the needle forward
A lot. They only need to wait for Pluton enabled PCs to reach critical mass. Compared to TPM's, Pluton is inside the chip thus not vulnerable to bus tampering and is not a standard but a "product", meaning Microsoft will have the ability to make changes without intervention from other companies.
Everything needed to lock down your computer as much as a phone already exists, there's no need for a TPM or Pluton to do so.
We want there to be less ways of doing that. The fact that one way already exists doesn't mean that we should be okay with more. The desired end goal is that eventually there's zero ways to do this, and we'll never get there if we keep moving in the wrong direction and justify it by not already being there.
There's a huge difference between "exists" and "is now commonly available and made easier to use". The frog-boiling is slow, but an increasingly large number of us are becoming aware of this new rise of corporate authoritarianism, and we know how it will end if we do not fight it as hard as we can.
10 replies →
...no? How would MS force me to install an AGESA update that supposedly restricts me in booting unsigned code? That's where the newly announced remote attestation comes in.
On the other hand, on PCs with Pluton chips they can change their minds any second.
2 replies →
- Microsoft isn't going to fuck us over that hard <--- We are here
- Microsoft is fucking us over that hard
- Libre software FTW
- Libre software UX sucks
- Repeat
When will the cycle end?
> Libre software UX sucks
This has always been true and while it's better this iteration of the cycle, it's not great.
But have you actually used Windows in recent times? The UX has gotten infinitely worse since XP. Mac OS has changed about as much as the popular open source DEs, but Windows is infinitely worse. I can't stand using it. The taskbar is garbage, the menus are garbage, the discoverability of anything is the worst it has ever been.
I can't imagine they're ignorant to the fact that Desktop UX is no longer a differentiator for them. The only lock-in they have is in business environments, for which there is zero competition at their price point.
It's inevitable that the host OS gets locked down. The runtime has moved to the browser and cloud. It's just a matter of time.
Windows UX is ass, but it runs a lot of nice software. Runs it well too. Many things don't work as well in wine. I'm talking both slowdowns and glitches.
1 reply →
I've always thought this was just Microsoft's copy of Google Titan and Apple's T2. And as others have pointed out, there's a lot of overlap with what a TPM can already do.
The main thing that comes to mind for me is that since this is integrated into the CPU itself, now 'things' can be strongly and directly tied to the CPU instead of a separate TPM or some collection of hardware identifiers. Was this already possible on x86? My mind immediately went to "this will be used for tighter DRM"; I feel like content owners would like this a whole lot.
If you have an AMD system then there's a decent chance that it's already running a TPM stack on the on-die Platform Security Processor. Pluton isn't really any more tightly integrated, it just means the TPM stack isn't running on the same core as a bunch of other random platform things.
OK, thanks for pointing this out.
So basically "Why it's ok and you should be happy about Microsoft's hardware controlling the software on your PC".
I'm so unbelievably sick of this 'security by corporation, it's what's best for you so accept it bullshit.' I really am.
No I don't want proprietary internet enabled hardware on my PC monitoring my software, no it does not make me feel safe and secure, actually, go fuck yourself and whatever marketing bullshit you spew to make this desirable for consumers. I'm honestly so fucking done with this kind of shit.
A quick look at the author's credentials should clear any doubt about the motivations behind this article's intentions --- over the past few years, I have come to the conclusion that anyone who works in the "security" industry is almost certainly working against you and your freedom.
> I'm so unbelievably sick of this 'security by corporation, it's what's best for you so accept it bullshit.' I really am.
Then, consider supporting the alternative approaches to security: https://puri.sm/posts/the-future-of-computers-the-neighborho...
> No I don't want proprietary internet enabled hardware on my PC monitoring my software
Good news! Pluton is not internet enabled and can't monitor your software.
Even if that's true right this minute, an unauditable (:/) bit of hardware controlled by Microsoft (!) that can be force-updated by them (!!!) means this can change at any moment.
I liked TPM with my own keys. This just seems a bit 'extra' in all the wrong ways.
4 replies →
So we already have to trust the Intel ME crap, and now the MS crap too. How is this similar to the status quo? _At best_ it increases the number of actors you have to trust, specially if you are not using Windows.
Don't forget that even recently Microsoft has pretended to be committed to open source, but consistently continues to make decisions that counter that. What may look friendly today like their switch to Edge, may end up being entirely hostile like Edge has become today.
in german we call stuff like pluton "politik der kleinen schritte" or "salamitaktik". which basically means that little step for little step, things change.
it is not CURRENTLY a threat, but it builds up to be a threat in the future if we do not stop and/or constrain it.
Salami tactic is on the nose
"Wire fence is not a threat! "
( fine print: we haven't switched the electricity on yet)
edit: asterisks are somehow omitted
We should put an emphasis on currently, but also I think we should discuss how Microsoft is positioning itself as a gatekeeper and forcing all market players to adopt their tech.
If Microsoft says Windows will only support has with this tech enabled, and since almost every computer on the planet runs Windows, vendors must adopt this tech or go out of the market.
In other words, Microsoft is positioning itself to say to all market players to play by its rules or go out of business.
This is a perfect way to establish control over the market without establish itself as a monopoly, thus not attracting attention from regulators.
> if you're not running Windows Microsoft can't update the firmware on your TPM.
This seems to be the biggest issue - hardware locked into requiring Windows to be up to date.
MS can of course ship firmware that's independent of the OS, but knowing MS - they probably won't.
It sounds like they're using UEFI capsule updates for the firmware, so it'll actually be easy to perform the updates under other operating systems - Microsoft just won't have any mechanism to compel you to do so.
Then it won't be a big problem I guess.
Though having a blob firmware from MS embedded into the CPU itself feels kind of weird. A better way to do it was some third party handling it or requiring that firmware to be open source for example.
The "mechanism to compel you to do so" will be in the form of remote attestation, as some of the other comments here have mentioned.
1 reply →
I think this is about securing data/keys (AES, TLS, TPM..) vs securing code (Secure Boot, TEEs..). Neither is really a threat to software freedom as I see it, as long as it's user controlled or can be rendered effectively inactive.
The thorniest question I think is around TEEs. You either trust ME/PSP/mobile TEEs for their explicitly mentioned uses (fTPM, SVM, Remote attestation..) or you think they should be even more sandboxed or perhaps shouldn't exist at all. I'm all for the middle ground/option here where the user is in control, thought others may disagree. Remote attestation could be a case where the user is losing control, so preserving user control there is important.
Man, I was really enticed by the specs on these Z-series laptops by Lenovo and was looking at an upgrade. But I was reading about Pluton this afternoon, and now looking at this thread, I don't know how I feel about it. Why ruin a great new CPU with future spyware?
I don't like the edit at the bottom where the author's like: oh yea, of course this could be a massive issue against FOSS but we should just assume that vendors will think it's impractical. I've seen how banks react to rooted phones, even when rooted to heighten device security--and I've switched banks before because of it. They don't care.
I'm totally with you. Not using banking apps - just sites. Also stopped buying CPUs with DRM-on-chip. It's pretty crazy what they're doing now instead of just "computing machines" (
Unfortunately with the DRM situation, the benefits are much outweighing the cost. The speed gains and compatibility I'd get let me do a lot more things. I can use these better CPUs to compile a lot faster :|
The banks not much better. All banks in my country have dated late 90s-looking websites with not even UTF-8 encoding (so you can't send an email with a comma). They are barely usable on desktop. I'd have to make my own client or at least whip up a lot of magic CSS to get it to be mobile-friendly and would even still need to include QR code scanning as it is so ubiquitous that no one would let me fiddle with adding their account numbers.
Thank god for Berkeley and RISC-V.
"Trusted" computing is not something that's unique to x86.
With RISC-V at-least individual providers can spinoff their own versions of the architecture without having to ask for permission, from an entity like intel,amd or arm.
Unlike right now, where all x86 chipsets have backdoors, and all new ones have “Trusted” computing features which you cannot say No to.
There are a lot of security benefits to using a TPM. I wouldn't mind if I could use an open source one in Linux.
They ameliorate a lot of low entropy problems for passwords and can improve security. I can't imagine a proprietary one being mandatory. My banking app uses the mentioned remote attestation so I can't use it on my less-Googled Calyx ROM. I just think that's stupid instead of very strong warnings.
Meanwhile, hardware-level OS-ignostic rootkits like Computrace exist, and Intel ME has its own network stack, but Pluton being adopted as some kind of industry standard to lock down a platform in the name of "security" and what have you is a conspiracy.
Does Computrace even work if you're not running Windows? Does it have a Linux/MacOS/etc. payload now?
(Reversed much of it a long time ago --- and remembered it was specifically coded with Windows in mind, with certain assumptions about various things.)
It's funny how Microsoft seems unable to do "security" without veering into megalomanic authoritarian schemes. See also Palladium.
What about trying to secure your software without building the infrastructure for an oppressive dystopian future? Too much to ask?
They're used to have the desktop monopoly, and losing them makes them to literally lose sleep over the matter.
It's not a matter of security, it's a matter of monopoly. Since forever.
It's not that they can't do security without going full authoritarian, I think they do it because they want to go authoritarian. The new security benefits are just a vehicle.
They're a lot like the common politician who smuggles horrible laws into relief bills or trade treaties. UEFI (especially on the ARM platform) and intel ME are to examples of this.
Yes. Look at the zeroday clusterfuck that is Teams.
To Microsoft, security is an excuse for a land grab.
What worried me about pluton is essentially both the fact it might set a trend where drm locks out Linux devices and that remote exploits on pluton is a real nightmare scenario.
Despite the fact I in a way do think tpm like components are a good thing.
> the fact it might set a trend where drm locks out Linux devices
Fact? Based on what evidence?
If you re-read my statement you might notice "the fact" is used as a figure of speech.
One great advantage of these separate silicons is that side channel attacks are greatly mitigated; it's everything else that worries me (closed platform, no transparency, unusable once vendor stops supporting it etc)
windows? it's a dead OS anyways
people are either on macOS/android/iOS or chromium OS
But if you don't like Pluton, I have bad news for you about Macs, Chromebooks, and most Android phones.
Chromebooks give you full flashing & serial console access for both AP (main CPU) and EC over an SBU cable, run open source firmware on both AP and EC (modulo FSP/AGESA), even run open source firmware on the root of trust (you can't replace that one with an unsigned build on a retail device but you can study it for sure).
Apple silicon Macs have the main CPU cores fully in control, with zero external peripherals having full DMA access to system RAM (everything goes through IOMMU), and have an interesting secureboot architecture that allows different security levels on different OS installations (you can run unsecured Linux side-by-side with a fully Netflix-ready macOS).
I have much worse news about the typical Intel BootGuard'ed PC laptop.
that's the thing, it doesn't really matter
it's not YOUR OS, it's their product, you not forced to use any of their products
linux and voila, you got your freedom back
5 replies →
Did you forget the /s? Honestly can't tell...