Debian to vote on its firmware path
Debian to vote on its firmware path
Posted Sep 1, 2022 8:48 UTC (Thu) by brunowolff (guest, #71160)In reply to: Debian to vote on its firmware path by khim
Parent article: Debian to vote on its firmware path
From a security and owner control perspective, you can mitigate hostile mass storage devices by encrypting data on the cpu before storing it on the device. This is pretty common these days in order to protect data at rest. This limits attacks on the stored data to denial of service. The devices are also well positioned to do side channel attacks, but without access to a network the attacker is going to need to get physically close to retrieve the data or the device is going to need a built in radio and try to keep that secret. This makes mass surveillance attacks hard. If you are worried about being targeted specifically by very well resourced organizations, then your problem is going to be much larger in scope, because you might not even be running (just) the hardware you think you are.
Posted Sep 1, 2022 9:59 UTC (Thu)
by bluca (subscriber, #118303)
[Link] (2 responses)
Posted Sep 1, 2022 11:23 UTC (Thu)
by brunowolff (guest, #71160)
[Link] (1 responses)
Posted Sep 1, 2022 15:39 UTC (Thu)
by khim (subscriber, #9252)
[Link]
And firmware in a WiFi card or sound card would? With a firmware provided to Debian via official channels? Really? We know people planted backdoors into firmware of storage. Can you show me something similar about firmware delivered via official OS distributor? How is that “hostile”? Any layman would say it's a good thing. Because it means such GPU would be cheaper and would still be perfectly usable to play games. Show me how I can watch Netflix in full resolution with free firmware. Then you would have a case. And I don't know of any DRM software which may forbid me to watch high-resolution video which have no protection. That market would always provide slow, inefficient and/or expensive devices. Usually all three at the same time. Simply because you can not have you cake and eat it, too: if you demand the ability to tinker with firmware you have to pay. There is nothing wrong with that desire, but please stop trying to make others pay for your desires. I don't want an iPhone because I don't like the level of control Apple imposes on iPhone owners. But I don't try to, somehow, cripple the code I write to make it impossible to use on iPhones. That would be stupid and wrong. If people like to be left out without online banking when their country does something uncle Sam does't like… who am I to lecture them? Who gave me that right? Sure. And easy way to help such people is to make sure firmware is not stored in the bowels of the hardware, but can be effectively loaded from OS distribution media. That's what people like Richard Hughes enable. FSF does the exact opposite: instead of making it easier to make firmware free it makes it hard to touch it in the first place. FSF have different rules. Accordring to FSF it's absolutely fine to have password-stealing firmware in your keyboard, spyware in your web cam and computer-hijacking malware in bowels of your SSD — as long as you don't make it possible to study it that POS it, somehow respects your freedom. How the hell that stance is useful for anyone?
Posted Sep 1, 2022 10:59 UTC (Thu)
by khim (subscriber, #9252)
[Link] (23 responses)
The same can be said about Windows in case when you use it to run Linux in WSL. But then you have to trust that your CPU does what it says it does. Including SMM mode. There are always code which executes before your beloved free software has a chance to do something with CPU and it comes from storage controlled by updatable firmware. Hard for whom? Maker of the hardware? Don't make me laugh. Modern hardware is so complex that maker of such hardware can embed significant part of library of congress and nobody would ever notice. Yet — and giving you tampered hardware would be easier that attacking you via firmware which comes from official source and is distributed via thousands of Linux distributions. I'm not saying such attacks are impossible. But before it becomes feasible you have to make sure all other venues of attack are closed. Today FSFs stance sounds crazy: it debates whether you need to replace a steel door with a door made from adamantium in a house where walls are made from paper.
Posted Sep 1, 2022 11:47 UTC (Thu)
by brunowolff (guest, #71160)
[Link] (22 responses)
> The same can be said about Windows in case when you use it to run Linux in WSL.
Sorry, in my opinion running anything on a recent version of Windows is insane (at least the versions available to consumers).
>> From a security and owner control perspective, you can mitigate hostile mass storage devices by encrypting data on the cpu before storing it on the device.
> But then you have to trust that your CPU does what it says it does. Including SMM mode. There are always code which executes before your beloved free software has a chance to do something with CPU and it comes from storage controlled by updatable firmware.
That's why I bought a Blackbird. I agree that you don't want to use modern AMD, Intel or ARM CPUs if you can avoid them. The initial code can come from ROMs (or updatable variants) and code from mass storage before encryption support is available can still be checked using hashes.
>> This makes mass surveillance attacks hard.
> Hard for whom? Maker of the hardware? Don't make me laugh. Modern hardware is so complex that maker of such hardware can embed significant part of library of congress and nobody would ever notice.
You don't think that national security agencies don't talk to hardware and software companies about making changes to make the agencies jobs easier?
>> If you are worried about being targeted specifically by very well resourced organizations, then your problem is going to be much larger in scope, because you might not even be running (just) the hardware you think you are.
> Yet — and giving you tampered hardware would be easier that attacking you via firmware which comes from official source and is distributed via thousands of Linux distributions.
That's what I implied. In this case hostile firmware is a minor issue compared to other attack avenues.
> I'm not saying such attacks are impossible. But before it becomes feasible you have to make sure all other venues of attack are closed.
> Today FSFs stance sounds crazy: it debates whether you need to replace a steel door with a door made from adamantium in a house where walls are made from paper.
I don't think that security is a major part of FSF's stance. However, I think people who care about security have common interest with the FSF in avoiding hardware with proprietary firmware. The two groups are going to have different opinions on the tradeoffs and mitigations when dealing with proprietary firmware, though.
I think that the FSF should modify their stance on updatable firmware slightly. In my opinion unfairness derived from the end users' lack of knowledge about the firmware, should not trigger a hard line against firmware upgrades. Though in current practice there are other kinds of unfairness in much of the updatable firmware used now, and the change in stance wouldn't necessarily change much right at this time.
Posted Sep 1, 2022 16:16 UTC (Thu)
by khim (subscriber, #9252)
[Link] (21 responses)
If you run Windows software… maybe. Here we are talking about using Windows as WSL-backbox for Linux. Was there ever any evidence that it doesn't work according to specs? Not because of bugs (bugs happen with real hardware, too, even without any firmware), but on purpose? Is it a joke or stupidity? ROM on these old platforms would happily loads any random crap from the first sector of storage and then execute that. There are no checksums. And we are talking about firmware here. It can easily stop presenting malware content to the host system after initial bootup. You may try to attach that device to computer as non-bootable device, but this wouldn't save you since firmware is not obliged to provide you with hostile payload unconditionally in that case. And since firmware is not available for scrutiny but can be different on different HDDs or SSDs you can not even rely on work of others for your safety (like you can in cases where firmware is included in Debian or any other OS and thus is available for dissemination of security information). I don't know if they talk or not. But even if they do they would, naturally, do what is easier for them and would alter storage system firmware on select few devices. In fact we know they did that. What they wouldn't do is to pass “firmware with surprise” via official channels where it exposes these “surprises” to millions of people and thousands of security researchers. That's just crazy thing for them to do and we have no evidence they ever have done that. Except you couldn't. Not if you want to use modern hardware. If you are really paranoid you may buy obsolete or exotic hardware which can be used without proprietary firmware, but it's stupid to make general-purpose distribution which you can only use on some rare and expensive hardware. I think WSL (and other virtual machines) actually justify existence of firmware-free version (because you don't need firmware if you are running on virtual machine), but that shouldn't be the default version you give to newbies. I don't know about upgradable firmware, but I think they should reverse their stance on “transient firmware” which is loaded from host system before you can use the device. Today it's regarded as awful, crazy, don't touch, don't tell kind of software while umodifyable firmware is treated like a gold standard. In reality these things should be reversed: umodifyable firmware means you would never be able to update it. The notorius printer driver embedded in umodifyable firmware would forever be broken. Even if someone would develop free firmware it would still be broken. On the other hard firmware which is loaded on each boot from host system can never be worse than umodifyable firmware: if it's signed and you couldn't alter it — for all intents and purposes it's now works as hardware, if you can alter it — you can try to develop free version.
Posted Sep 1, 2022 17:06 UTC (Thu)
by brunowolff (guest, #71160)
[Link] (20 responses)
> If you run Windows software… maybe. Here we are talking about using Windows as WSL-backbox for Linux. Was there ever any evidence that it doesn't work according to specs? Not because of bugs (bugs happen with real hardware, too, even without any firmware), but on purpose?
I was talking about the OS itself, not the applications. Telemetry is a privacy nightmare. You don't get to control updates.
Also going back to the API discussion, the risk of using WSL is a lot different than using say a mass storage device you don't full trust. Mass storage devices don't have an easy way to communicate data back to an opponent. WSL is going to be in regular communication with Microsoft and if you don't trust it, that makes it a much bigger deal.
>> The initial code can come from ROMs (or updatable variants) and code from mass storage before encryption support is available can still be checked using hashes.
> Is it a joke or stupidity? ROM on these old platforms would happily loads any random crap from the first sector of storage and then execute that. There are no checksums. And we are talking about firmware here. It can easily stop presenting malware content to the host system after initial bootup. You may try to attach that device to computer as non-bootable device, but this wouldn't save you since firmware is not obliged to provide you with hostile payload unconditionally in that case.
I wasn't talking about old systems. I was talking about trying to design a current system that could boot up without having to trust firmware on a mass storage device fully. (You can't prevent denial of service attacks.)
I suspect you are mixing this up with the argument others are having about non-free firmware being better fixed in ROM rather than being upgradable. That is not what I was talking about here.
>And since firmware is not available for scrutiny but can be different on different HDDs or SSDs you can not even rely on work of others for your safety (like you can in cases where firmware is included in Debian or any other OS and thus is available for dissemination of security information).
Sure you can. The device can be set up so that you give it encrypted blobs and it returns the encrypted blobs later or nothing or garbage blobs which can easily be detected. This limits the device to denial of service attacks and some side channel attacks that will be low bandwidth and/or require the attacker to have resources physically present nearby.
>> You don't think that national security agencies don't talk to hardware and software companies about making changes to make the agencies jobs easier?
> I don't know if they talk or not. But even if they do they would, naturally, do what is easier for them and would alter storage system firmware on select few devices. In fact we know they did that.
> What they wouldn't do is to pass “firmware with surprise” via official channels where it exposes these “surprises” to millions of people and thousands of security researchers. That's just crazy thing for them to do and we have no evidence they ever have done that.
Well it was pretty widely reported the FBI talked to Microsoft about making sure bitlocker didn't cause them problems. They do care about compromising systems at scale. The NSA also cares about this and have compromised NIST standards in the past.
>> However, I think people who care about security have common interest with the FSF in avoiding hardware with proprietary firmware.
> Except you couldn't. Not if you want to use modern hardware. If you are really paranoid you may buy obsolete or exotic hardware which can be used without proprietary firmware, but it's stupid to make general-purpose distribution which you can only use on some rare and expensive hardware.
You are wrong. It is possible to buy modern hardware now that uses free firmware. You can't build a complete system yet, but you can do things to mitigate what the non-free firmware can do. If people want more hardware covered and/or better pricing in the future, they need vote with their wallets.
> I think WSL (and other virtual machines) actually justify existence of firmware-free version (because you don't need firmware if you are running on virtual machine), but that shouldn't be the default version you give to newbies.
Except that WSL is a bigger threat than most non-free firmware.
>> I think that the FSF should modify their stance on updatable firmware slightly.
> I don't know about upgradable firmware, but I think they should reverse their stance on “transient firmware” which is loaded from host system before you can use the device.
I agree that some change is in order, but not to the extent you do.
> Today it's regarded as awful, crazy, don't touch, don't tell kind of software while umodifyable firmware is treated like a gold standard. In reality these things should be reversed: umodifyable firmware means you would never be able to update it. The notorius printer driver embedded in umodifyable firmware would forever be broken. Even if someone would develop free firmware it would still be broken.
> On the other hard firmware which is loaded on each boot from host system can never be worse than umodifyable firmware: if it's signed and you couldn't alter it — for all intents and purposes it's now works as hardware, if you can alter it — you can try to develop free version.
It is possible for it to be worse. It allows for provider of the firmware to change it. If they have leverage over you (e.g. bluray where access to new discs can be restricted), then it is possible make you choose between suffering from the leverage or suffering from an intentional regression in the new firmware. This couldn't be done if the firmware was fixed in the hardware. It also allows for some other attack modes on your systems, but that isn't normally going to be a big deal. For much hardware, the leverage issue isn't going to be a significant risk, so it probably should be treated similarly. While there is an unfairness that only some people can generate updates (at least easily) in many cases this is no worse than no updates.
Posted Sep 1, 2022 18:18 UTC (Thu)
by khim (subscriber, #9252)
[Link] (17 responses)
Of course it could be done! Not only it could be done, it's actually done rountinely right now, today! Wake up! This or this are just tip of the iceberg! Companies regularly sell silicone where certain features can be disabled and enabled. Market diversification, you see. And they don't need upgradeable firmware for that. Upgradeable firmware just makes it a bit more convenient. Then why are we pushing people in that direction? Most newbies, the people who care about default choices Debian makes most are not in position of picking hardware. They already have a hardware. They can only pick what to install on it. And if Debian on bare metal doesn't work while WSL works… they would go with WSL. If they want to vote with their wallets they would do that. But you are trying to force everyone to pick that vote even if they are not even thinking about firmware or hardware. They just need Linux to do their corsework in college. I've asked my friend who is studying in college to ask about what they did. 9 our 10 picked WSL. The remaining 1 couldn't use WSL, but they don't need to because macOS is close enough to Linux for their course. Is that what FSF wanted? IDK, but that was inevitable thus I would assume the answer is “yes”. Who would give it encrypted blobs? OS? Where would that OS come from? And I'm talking about devices that FSF actually recommends. Old crippled ThinkPads with no boot verification, mostly. But firmware does control the space where your code lives! That's precisely my point! If you want to ensure that your CPU wouldn't be under control of NSA then you first need to design something which doesn't depend on binary blobs to, you know, access the RAM.
Posted Sep 1, 2022 18:59 UTC (Thu)
by brunowolff (guest, #71160)
[Link] (4 responses)
> Of course it could be done! Not only it could be done, it's actually done rountinely right now, today! Wake up! This or this are just tip of the iceberg!
No it isn't. Sure you can sell people crippled chips for a discount, but without a way to update them you don't have a way to leverage them to update firmware.
>> Except that WSL is a bigger threat than most non-free firmware.
What we? If anyone asks me I tell them don't use modern windows for anything on the consumer side. Enterprises have some ability to disable some of the crap, but I'm not sure how much.
> They already have a hardware. They can only pick what to install on it. And if Debian on bare metal doesn't work while WSL works… they would go with WSL.
If they already bought hardware, then they have to make do with what they have. But I'd still never tell anyone to use WSL. If their hardware is so bad that that is the only option, I suggest replacing what they need to after they are sure they want to run linux. (Only stuff that won't work, not solely because non-free firmware is needed to make it work.) But you can get most stuff working under Linux, so there shouldn't be much that needs to be replaced even in the worst case.
>> If people want more hardware covered and/or better pricing in the future, they need vote with their wallets.
> If they want to vote with their wallets they would do that. But you are trying to force everyone to pick that vote even if they are not even thinking about firmware or hardware.
How the heck do you come to that conclusion about my actions? I'm encouraging people to support people who are spending money and/or time to make hardware that works without proprietary firmware more available for people that want it. I recommend people avoid non-free firmware where they can, but I don't advocate banning it from existence. Though it might make sense to require source to be escrowed for some consumer devices to make sure support is available if a company goes out of business, in line with right to repair initiatives.
> They just need Linux to do their corsework in college. I've asked my friend who is studying in college to ask about what they did. 9 our 10 picked WSL. The remaining 1 couldn't use WSL, but they don't need to because macOS is close enough to Linux for their course.
A university should not be requiring students to install invasive software on their personal machines (including Linux) whether it is free or not. They should be providing the environment to run that stuff, with remote access available where it makes sense.
> Is that what FSF wanted? IDK, but that was inevitable thus I would assume the answer is “yes”.
> Who would give it encrypted blobs? OS? Where would that OS come from?
From the encrypted file system on your mass storage device. I think you misunderstood the context of this part of the discussion as your replies have frequently been nonsensical with the intended context.
>> I was talking about trying to design a current system that could boot up without having to trust firmware on a mass storage device fully.
> And I'm talking about devices that FSF actually recommends. Old crippled ThinkPads with no boot verification, mostly.
Why? That isn't what this thread was about.
>> It is a place to store code that you don't want firmware to mess with.
> But firmware does control the space where your code lives! That's precisely my point!
There are machines where the very early boot firmware is free. I'm not talking about using machines that require an IME, PSP or TrustZone (or whatever ARM calls their crap). In that case you can pull the code needed
> If you want to ensure that your CPU wouldn't be under control of NSA then you first need to design something which doesn't depend on binary blobs to, you know, access the RAM.
Well that is an interesting topic. Currently there are modern machines where you can do that. Power 9 for example. However there have been some changes in order to provide more powerful memory lately and for Power 10 IBM decide to use proprietary firmware in order to access main memory. This has made Power 10 undesireable for some purposes. There were some impacts on sales and PR because of this decision. And there is speculation that a time crunch might have been partially responsible for the change. Also there is another move to CXL coming. At this point it isn't clear how things are going to go for Power 11. And to some extent that's why wallets matter. The hit on Power 10 sales were probably small relative to IBM's total sales. The more people buying hardware that doesn't need non-free firmware, the more incentive there is to produce such hardware.
Posted Sep 1, 2022 19:20 UTC (Thu)
by pizza (subscriber, #46)
[Link]
There's a massive chasm between this "should" and the real world of what most students are forced to accept. And yes, it is _forced_ because the alternative is to fail the course and possibly even the program.
We can lobby all we want to improve the baseline for the future, but we still have to work with (and within) what we have _today_.
Posted Sep 1, 2022 19:27 UTC (Thu)
by pizza (subscriber, #46)
[Link] (2 responses)
What I strongly suspect is that it's not "Free" firmware that these organizations need, in of itself -- instead, they need a way to attest/confirm that said firmware has not been modified from what the manufacturer intended to ship. Sufficiently powerful organizations can also force the manufacturer to supply the complete source code so it can be validated independently. The point here is to validate and trust their supply chain. "Free" firmware is (part of) one potential path to that goal, but hardly the only one.
Posted Sep 1, 2022 19:34 UTC (Thu)
by brunowolff (guest, #71160)
[Link]
Posted Sep 1, 2022 19:42 UTC (Thu)
by brunowolff (guest, #71160)
[Link]
Posted Sep 6, 2022 10:59 UTC (Tue)
by ras (subscriber, #33059)
[Link] (11 responses)
Accessing the RAM securely isn't an insurmountable problem. To wit: AMD-SEV. Used in the right way your VM is then secure from the host OS. Or at least I think so - I haven't looked closely enough to be 100% positive. Currently my mental model of what it does is if you have a host running on AMD-SEV in Russia, the NSA should be able to able to run a VM this totally Russian controlled OS safely (bugs, side channels, and god knows what else notwithstanding). It works because the NSA should be able to secure a rock solid trust relationship with TPM in the AMD CPU that bypasses the host. All the host sees is an encrypted blob of data, and presumably secure network comms flowing in and out.
So no, even if you are swimming in an ocean of non-free firmware you don't trust, in principle it doesn't have to be allowed access and total control of the space you live in. I'll grant you it does right now. But that's at loggerheads with security concerns. Just as I can't see NSA or the military being happy with WiFi controller with DMA access to RAM and getting it's firmware from China, I imagine China feels the same way about Windows. So there are forces pushing towards isolation of the components. Whether it happens is an interesting question, but a commoditized WiFi controller you don't have to trust even though it receives non-free firmware updates is probably attractive to the people AMD-SEV is being sold to.
Posted Sep 6, 2022 11:43 UTC (Tue)
by khim (subscriber, #9252)
[Link]
I don't think you understand what I wrote. Please read again. The problem is not that you can not trust memory. The problem is that to even access that memory in a modern system you have to execute a binary blob (large one, megabytes-sized!) on the host cpu! I don't fear for NSA. If they control AMD, IBM, Intel… they probably can safely run that OS in Russia. But would Russians be able to do the opposite? I'm not so sure. And normal Debian users have much less resources than Russia. Pretending that this refusal to include loadable firmware helps anyone is sanctimony: you give something which can not be ever used without binary blobs (because old system which could be used without binary blobs are fast becoming history and it's not even clear how long Debian would be usable on them) to people yet refuse to support much more benign firmware in WiFi or Sound cards because it's supposed to protect someone… who would that protect and from which disease?
Posted Sep 6, 2022 14:11 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (9 responses)
IIUC, AMD-SEV is later in the process; the "binary blob" khim refers to is the firmware blob that runs on a CPU that's just booted up, and first enables "cache-as-RAM" then sets up the DRAM controllers. Without running this firmware blob on your CPU, you have no DRAM, and no cache either.
Now, chances are that this blob is not hugely interesting - it'll be doing the sorts of things needed to do DDR4 training, which aren't scary, but are a decent amount of code (all to handle the fact that real world devices don't stay at a perfectly fixed setting after manufacture, but rather change in behaviour when in the field) - but it's an ideal hiding place for malicious code since it runs first, and sets up the "known good" state for this CPU.
Posted Sep 7, 2022 1:03 UTC (Wed)
by ras (subscriber, #33059)
[Link] (8 responses)
That probably doesn't matter. This "trust relationship" really means setting up a set of keys the the host doesn't know about. It's the same in principle as the DRM running in the browser. Provided no one can crack the DRM module, the content being sent is safe - despite it being handled by a huge pile of untrusted code. The browser DRM is just software of course, so anyone believing it can't be cracked is in a state of sin. And the "analogue hole" still remains wide open, although it's no so analogue because it's passing through the kernel.
Since the AES keys are in principle a secret tightly held between on CPU TPM, the owner of the VM, and the memory channel doing the encrypting they should be safe from anything that can't see into those things. But this is all provided by AMD. If you don't trust AMD to do it right then it's all over, as they could sabotage the whole thing in a zillion different ways you have no hope of discovering. So 100% trust is a given. The point is you can get away with just trusting AMD, but not the Russian's, despite the Russian's having physical custody of the CPU, and total control of the host OS running the VM - and total access to the memory.
That also applies in reverse. If the Russian's trust AMD 100%, they should be able to run a VM on a AMD-SEV machine controlled by the NSA. But the Russian's trusting a US company who is presumably subservient to the NSA would be quite a stretch, as you say.
Posted Sep 7, 2022 9:11 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (7 responses)
The challenging part is that the binary blob is what brings up the memory channel, which is in the trust path. It's entirely plausible that there's debug modes in the memory channel that break your assumptions, and that the binary blob is responsible for locking out into the "production" config. That makes the binary blob running on the CPU during early boot (before UEFI starts up in a traditional firmware) a part of the trusted base for AMD-SEV, and yet it's software-modifiable (stored in the machine's reflashable firmware store).
Further, you have to take updates to this code from your motherboard vendor on trust - you have no easy way to tell whether a given update is direct from AMD, or has been altered by the motherboard vendor on the request of a dodgy agency. This means that your trusted base is not just AMD, but also your motherboard vendor (since they are in a position to install a signing key into the system as a whole that results in the early firmware being trusted) - and potentially everyone who had access to the motherboard before it arrives in your datacentre.
This is why open-source firmware is interesting: you can confirm that the firmware you're running is the firmware you expect and not backdoored by the motherboard vendor (or in transit) since you can replace the flash storage (wiping out old on-CPU TPM keys in the process, since those live in the flash) on arrival, and you know what the firmware you're putting on there does. Your trust base is thus reduced from "is the binary blob the motherboard vendor supplied actually AMD's blob, and does it do what AMD promise" to "does the hardware AMD sold me contain hidden storage, and does it work as promised".
Posted Sep 7, 2022 10:28 UTC (Wed)
by ras (subscriber, #33059)
[Link] (6 responses)
The encryption is done on the CPU die, so I presume the binary blob comes from AMD. As I said, trusting AMD is assumed - and that includes trusting all binary blobs that come from them.
> Further, you have to take updates to this code from your motherboard vendor on trust - you have no easy way to tell whether a given update is direct from AMD, or has been altered by the motherboard vendor on the request of a dodgy agency.
I haven't checked, but surely AMD digital signs their CPU firmware, and the chip only accepts something signed appropriately?
> It's entirely plausible that there's debug modes in the memory channel that break your assumptions,
It doesn't sound too plausible to me. There has been some research into attacks against AMD-SEV already, which have found weaknesses. (I don't know whether they were fatal.) IIRC, they involve modifying the encrypted memory (which of course then yields junk when de-encrypted), and observing what happens when it is used. Repeat that until you see a pattern. It just doesn't sound reasonable they would miss something as obvious as using debug mode to spy on a memory channel.
> This is why open-source firmware is interesting
It is why a totally open source solution is interesting. If the chip is RISC-V, and the VHDL is open source, and you have a "reproducible build" (I have no idea what that would look like for hardware), then there is no need to trust AMD. You can verify it yourself. Of course the firmware must be open source too, because you have to trust the entire stack, just as you say.
But if you don't trust he hardware, all bets are off. It doesn't matter if the firmware is open source or not. There will be non upgradeable ROM firmware on the CPU - even if it's just to load the uploadable RAM replacement. It could be doing anything, including loading your open source firmware then throwing it away. This is why open source firmware alone is not so interesting if you are looking at it from just a security standpoint. It has to be turtles all the way down.
Posted Sep 7, 2022 12:23 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (5 responses)
The binary blob that sets up the memory channel is supplied to you by the motherboard manufacturer - and at least the last time I had this level of access, the motherboard manufacturer has the ability to rebuild that blob with changes, because you do want to be able to do things like rule out specific settings that, while legitimate for the CPU, will cause EMC issues because of the specific length of motherboard traces, and to rearrange the order in which different options are tested to increase the chances of finding the right training settings first attempt. That includes the ability for the motherboard manufacturer to sign the blob that goes onto their motherboards, so that the CPU will run it.
And debug modes that are controlled by a one-way disable are not uncommon in hardware design - once the debug mode has been disabled (and the AMD-supplied code will do this for you), it can never be re-enabled at runtime, which makes it useless for researchers (since the normal AMD blob will turn off debug modes before training DRAM, so you have no ability to turn them back on). As there's no visibility into this process, you can't tell if this is going on - you're taking it on trust that AMD either has no ability to debug AMD-SEV silicon bugs (sounds unlikely to me) or has correctly written the binary blob such that it disables debug options before training DRAM, and that no-one who is in a position to tamper with the blob has done so.
With open-source firmware, you would not have to trust that the blob you are running is unmodified from AMD's version and could look for mistakes in the very early bring-up code. It seems unlikely given the research into breaking AMD-SEV that they have badly implemented debug options (it's trivial in ASIC design to design a write-only register that starts up in the "enabled" state, and switches to a hard disabled state on any write, and I would expect AMD to be competent enough to not have debug features turned on when the debug control register is set to a hard disabled state), but that doesn't protect you if the motherboard manufacturer can change the code you run.
Posted Sep 8, 2022 5:52 UTC (Thu)
by ras (subscriber, #33059)
[Link] (4 responses)
Yes, of course. But none of that will allow the firmware blob to see what is in memory. If it did, AMD-SEV would be a lost cause.
The point I was trying to make is this statement by khim is too broad:
> If you want to ensure that your CPU wouldn't be under control of NSA then you first need to design something which doesn't depend on binary blobs to, you know, access the RAM.
Untrusted binary blobs running in any card with DMA may well have access to the RAM. Hell, the untrusted drivers in the host OS will probably have access to all of RAM. But we don't need to "first design something" to fix that. AMD-SEV fixes it, and it's available now.
The point khim is making about it being easier to run Windows than it is to run Linux on consumer hardware still stands, of course. I wasn't try to argue against it - it's always been true. And yes that means most people, even college IT students, if forced to use Linux will take the easiest path and just run it under Windows. It's a new(ish) phenomenon. It sounds ominous but it's actually a huge win, because being forced to become familiar with Linux is new. I doubt it was altruistic motives that caused Microsoft to release WSL - it was fear of losing those users, users who will be making corporate IT decisions in the future. And in the meantime the true believers will continue fight tooth and nail to run only open source on bare metal just as they've been doing for the last 25 years. I suspect khim loses sight of the fact that while as a proportion of the "IT industry" the number of true believers is being diluted, I strongly suspect in absolute terms their numbers they have always been growing, and are consequently a much larger force to be reckoned with than 25 years ago. They may never win their fight completely, but I doubt they will ever lose it either.
Posted Sep 8, 2022 12:57 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (3 responses)
You are, however, taking it on trust that the version of the blob supplied to AMD's partners only lets them change link training parameters, and can't be modified to run before AMD's part of the blob locks out low-level debug registers (or that AMD's registers for debugging AMD-SEV cannot be misused to compromise AMD-SEV).
While a fully open end-to-end verified system would definitely be nicer, it's still not possible to be 100% confident that AMD-SEV only requires you to trust AMD, and not your motherboard manufacturer with the current setup; in theory, AMD could separate out the part of the blob that does cache-as-RAM setup and also takes responsibility for locking out debug registers from the part that does DRAM link training, and allow you to confirm that the AMD blob is signed separately to the motherboard vendor blob, but that's not how it works today - instead, the early boot code is a single blob, and you can't tell if it's AMD's blob or not.
As it is, though, it's not implausible that AMD has debug registers that can be locked out with a single MSR write, and that cause AMD-SEV to make the encryption key visible to a debugging system (either via software, or to external hardware attached to the CPU under test). In normal operation, those registers would be locked out before DRAM training happens (hence before AMD-SEV is relevant), but a modified blob would be able to leave those registers exposed.
And this is the deep-seated trouble with completely closed firmware like the DRAM training firmware for Intel + AMD CPUs; we don't know what it actually does, and therefore whether there's a trust boundary between AMD/Intel and the motherboard vendor, or whether the actual design merges them together for the purposes of trust.
Posted Sep 9, 2022 5:41 UTC (Fri)
by ras (subscriber, #33059)
[Link] (2 responses)
You are saying because there may be bugs / mistakes in AMD's implementation, it's not possible to be 100% confident AMD-SEV works as advertised. That is totally correct. In fact if someone offered me a bet that someone will find a way past it in the next decade years, I'd take it. (If it was Intel SGX, I'd be happy to reduce the period to months.)
But it's an impossible standard. Flip the argument. Lets say it was all open source. Would it be possible to be 100% confident and say there are no bugs and thus 100% trustworthy? Of course not. I'd be happy to take the same bet.
I'll let you ruminate on where that leaves us, but clearly it isn't: Security is complex. All complex technology has bugs. Ergo we can't 100% trust the security of our systems. (I hold those statements as self-evident.) Therefore we should give up on security.
And no, open source does not solve that problem.
Posted Sep 9, 2022 8:44 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (1 responses)
No - I'm making a much more subtle argument than that, relating to the size of my trust base.
I have to trust AMD's designs, and AMD's manufacturing partner for silicon, when using AMD CPUs. That's just a fact of life as it is at the moment; if I used Intel CPUs, I'd just change the word AMD for Intel in that sentence, and it'd still hold true (albeit that Intel current manufacture their own chips). Same applies for any CPU vendor - I trust that vendor's designs, and I trust that their manufacturing will implement the design as created by the vendor, not a modified version to target me.
That is the core trust base I have when using any CPU - I can't avoid trusting the designer and the manufacturer of the silicon. Beyond that, my trust base can be extended by design decisions - for example, in a traditional cloud system (without AMD-SEV), I must also trust the motherboard manufacturer, the BIOS vendor, the DIMM manufacturer, the DRAM chip maker, the hypervisor vendor, the hypervisor operator, and the datacenter owner.
The promise of AMD-SEV is that I no longer need to trust as large a trust base, because AMD-SEV uses cryptography to remove all but AMD from the trust base. I still have to trust AMD and whoever made the CPU, but I no longer have to trust all the other parties involved, since they can only see encrypted data, and cannot get the key. The value of this promise is, however, weakened by the fact that we can't see into the memory controller startup blob - because it is entirely opaque, there is a reasonable possibility that AMD used the startup blob to disable AMD-SEV debug features that break the promises of AMD-SEV (and I would consider having these features that can be disabled in a one-way operation to be entirely reasonable on AMD's part - they need to be able to debug things if their chips misbehave in their labs). And because there is one combined blob that contains both AMD-supplied code and motherboard vendor code, the effect of this is to widen my trust base for AMD-SEV from "just AMD" to "AMD and the motherboard vendor".
There's at least two routes AMD could take to reduce the size of the trust base back down to that promised by AMD-SEV:
Both work - you will notice that one of them doesn't even involve opening up the blob. But unless AMD do one of the two options, I have no way of telling whether or not the blob expands my trust domain to include the motherboard vendor, or whether it in fact limits me to just trusting AMD because the motherboard vendor modifications aren't able to affect AMD-SEV.
Posted Sep 9, 2022 9:41 UTC (Fri)
by paulj (subscriber, #341)
[Link]
Not sure if that will be true for much longer, least universally. E.g., the information on the new Ponte Vecchio HPC chips is that some of the tiles in the package will be produced by TSMC. The same sources that broke this (now confirmed) also say Intel has plans to have TSMC produce some CPUs.
Posted Sep 2, 2022 10:56 UTC (Fri)
by paulj (subscriber, #341)
[Link] (1 responses)
Wasn't there an NSA key found in BitLocker, or some other encryption facility within Windows?
Posted Sep 13, 2022 21:12 UTC (Tue)
by brunowolff (guest, #71160)
[Link]
Debian to vote on its firmware path
Debian to vote on its firmware path
Different people are going to care more about different parts of the system and might find it useful to allow non-free firmware in some parts in order to save money or get better performance, but require free firmware in other parts.
If everyone ignores the issue, things aren't likely to change. To get to a better place people need to preferentially by hardware that uses free firmware, demonstrate that there is a market for devices that use free firmware. One way to do that is to support people who are reverse engineering or developing free firmware for devices that come with proprietary firmware. Such as Raptor's bounty for the BCM5719 which encouraged a couple of people to do a lot of work that has resulted in free firmware for that device. At some point a competitor might decide to provide a chip that comes with free firmware, because they see that there are people that will prefer theirs over Broadcom's.
Personally, I don't find much difference in whether the firmware is upgradeable or not with regard to freedom as long as I'm in control of the upgrades. That control needs to include not being blackmailed into forced firmware upgrades (such as with bluray), allow for me to use my own firmware (without an OEM or manufacturer signature) if somehow I were to get some and should in general allow a way to downgrade as well (in case there is an issue with an upgrade).
The FSF seems to include an objection to cases where lack of knowledge creates an unfairness with being able to update firmware (as opposed to limitations based on signatures) and I don't think that circumstance is something they should be taking a hard line against.
> Firmware in mass storage generally isn't going to limit what you want to do if you pass it encrypted data.
Debian to vote on its firmware path
> Mass storage can be considered a black box from a freedom perspective in that they support an API and you don't effectively program them so that the internal implementation does impact your freedom.
Debian to vote on its firmware path
Debian to vote on its firmware path
> Sorry, in my opinion running anything on a recent version of Windows is insane (at least the versions available to consumers).
Debian to vote on its firmware path
Debian to vote on its firmware path
ROM doesn't load anything. The code on the ROM is going to load stuff, but it is under your control how that is done. It is a place to store code that you don't want firmware to mess with.
> This couldn't be done if the firmware was fixed in the hardware.
Debian to vote on its firmware path
Debian to vote on its firmware path
.
> Then why are we pushing people in that direction? Most newbies, the people who care about default choices Debian makes most are not in position of picking hardware.
>> The device can be set up so that you give it encrypted blobs and it returns the encrypted blobs later or nothing or garbage blobs which can easily be detected.
for early boot without out accessing a mass storage device to avoid pulling data under control of untrusted firmware until you are at the point where you can verify the authenticity of the data returned by mass storage.
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
For the current thread, I don't think just having powerful organizations get access to the source is good enough. Other people want to be able to make changes to firmware without have to beg the manufacturer for permission to make a change. This might be for research, bug fixes, adding or removing functionality.
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path
Debian to vote on its firmware path