Framework Desktop AMD Platform Secure Boot

Hello everyone,

Does Framework plan on releasing a firmware update to enable support for AMD Platform Secure Boot (PSB)? Having this feature enabled would benefit users who have an elevated threat model and require protection against potentially malicious firmware images. Additionally, it would help move the Framework Desktop closer to being able to support a fully verified boot chain. If you pair PSB with full-disk encryption and signed Unified Kernel Images, you now have much stronger boot integrity guarantees.

For anyone unfamiliar with this processor feature, it works by providing a hardware root of trust that can authenticate the initial firmware during the boot process. It helps improve platform integrity by better protecting the transition from low-level firmware to the operating system. However, this increased protection does come at the cost of vendor lock-in, but this should be completely reasonable for the Framework Desktop since the CPU is already soldered onto the motherboard anyway.

Thanks for taking the time to read my post. I look forward to any feedback or concerns that fellow community members may have. I know it is unlikely that I will get an official response either way, but it never hurts to try :slight_smile:.

What exactly do you mean by that? Are you installing firmware coming from shady sources instead of directly from Framework? In that case why would Framework work hard to implement a feature to protect you against your own actions?

I think it’s extremely hard for someone other than you get the proper access to tamper with the firmware of your machine without your knowledge.

PSB looks like a “feature” that we can do very well without.

I think the confusion stems from firmware being a generic term to describe a lot of different low-level software implementations that a typical device uses to complete its boot process. Having a feature like PSB enabled can help prevent malicious software from modifying such software and gaining strong persistence on the device. In many cases, this type of persistence is extremely difficult to detect and defend against. Therefore, having stronger boot integrity is really important as we see threats evolve.

If you would like to learn more about how AMD is implementing their platform security, especially in relation to boot integrity, please take a look at the following links:

The first link gives a good overview of the secure boot flow in general. The second link will provide information about AMD’s platform security. Specifically, page 7 on the second link discusses Platform Secure Boot.

I noticed in your last message that you said this is a feature Framework can do without. Why exactly do you think that? Can you please provide any specific reasoning as to why you are not a fan of this particular security feature?

Also, just to be more clear, you don’t need to go off and install a BIOS update from “shady sources” to benefit from this type of protection. It is entirely possible for malware to be dropped on a system at the OS level and persist itself by compromising components in the boot path (e.g., UEFI variables / boot policy, NVRAM state, SPI/ROM if writable, etc.). Sometimes, this type of malware can even persist on a system even if you reformat the drive and reinstall the OS. This is why strengthening boot integrity as much as possible is very important to some people.

I think the confusion stems from firmware being a generic term to describe a lot of different low-level software implementations that a typical device uses to complete its boot process. Having a feature like PSB enabled can help prevent malicious software from modifying such software and gaining strong persistence on the device. In many cases, this type of persistence is extremely difficult to detect and defend against. Therefore, having stronger boot integrity is really important as we see threats evolve.

If you would like to learn more about how AMD is implementing their platform security, especially in relation to boot integrity, please take a look at the following links:

The first link gives a good overview of the secure boot flow in general. The second link will provide information about AMD’s platform security. Specifically, page 7 on the second link discusses Platform Secure Boot.

I noticed in your last message that you said this is a feature Framework can do without. Why exactly do you think that? Can you please provide any specific reasoning as to why you are not a fan of this particular security feature?

Also, just to be more clear, you don’t need to go off and install a BIOS update from “shady sources” to benefit from this type of protection. It is entirely possible for malware to be dropped on a system at the OS level and persist itself by compromising components in the boot path (e.g., UEFI variables / boot policy, NVRAM state, SPI/ROM if writable, etc.). Sometimes, this type of malware can even persist on a system even if you reformat the drive and reinstall the OS. This is why strengthening boot integrity as much as possible is very important to some people.

That’s all theory and AMD trying to push something that probably a handful of users would be interested in.
Can you give me a single real life situation/case when what you mention happened, not “might” or “possibly” happen?
I know personally a lot of users who disable Secure Boot in BIOS as a first thing when dealing with a new machine.
I’m one of them and my machines work like a charm without this “feature” that you are trying to improve.

/e

You are well within your rights to set your own threat model, and @maelo is well within their rights to set their own as well.

However, by issuing this challenge you have established yourself as the sole arbiter of whether what they want is acceptable. Arguments that start with “give me one real example” usually end with “that one doesn’t count”.

You are not the arbiter of what platform security features myk can request.


Phrack 66: Persistent BIOS Infection is an excellent example establishing the vulnerability (yes, from 2009, yes, not against UEFI), and it looks like as recently as 2015 documentation suggests that HackingTeam successfully developed a bootkit (against InsydeH2O, even!).

In installation, three modules are first copied from an external source (this might be from a USB key with UEFI shell) to a file volume (FV) in the modified UEFI BIOS.

2 Likes

Correct, it’s a free world, everybody can establish their own priorities and stick to them.

I have two brand new SSDs that do not work in either of the M.2 slots and I was forced to use the internal PCIe slot to get one of them working. The USB4 ports do not work properly on this machine (confirmed by other users, see other threads in this forum). The 3.5 mm jack is reported to not work correctly.

When a machine has internal devices that do not work properly, don’t you think it’s an overkill to ask for new features instead of fixing the existing issues and a bit of lack of respect for those who paid good money to buy Framework’s product instead of a GMKtec, Geekom or Beelink?

I personally don’t believe that it is overkill to ask an OEM to expose additional platform security features that the hardware supports. Additionally, my goal isn’t to push my preferences on other people. In fact, it would be ideal if Framework could expose this feature to end-users, but keep it disabled by default.

A part of me also believes that you might not be discussing this in good faith. You don’t seem very interested in sticking to the technical merits of the request or showing a concrete example of how this change would negatively impact your ability to use your device. Instead, you seem to be taking an entirely emotional stance that simply isn’t grounded in logic.

Lastly, I am sorry that you are having trouble with your device. I sincerely do hope that Framework is able to correct these issues so you can enjoy your device the way you want to. However, you really shouldn’t try to frame my request as disrespectful to you or anyone else because you made the choice to purchase a Framework over something else. In fact, this argument completely ignores the fact that I am also a paying customer. My requests are not any less valid than yours.

As it was raised in this thread and I agreed with, everybody is free to adopt whatever security model he/she believes suitable. I’m an avid consumer of IT related news from a variety of sources and try to keep up to date on the subject. Unless you are a security related person who frequents dedicated websites to such things, the mainstream media, in whatever form, rarely publishes news on such compromised systems that warrant the application of what is requested here, even less so of mass events of this type. That’s why I asked for a single real life example and I was not given one. The vectors for propagating such BIOS malware are rarely, if ever, the normal phishing, email or infections due to visiting shady websites. They most always require physical access to the device, which any normal, self-aware computer user would never give to somebody who would do such a thing. And if they would, then they deserve what they get. I don’t have exact numbers, but from what I see around me, about half of computer users disable Secure Boot in their systems and most of those that keep it enabled do it not as being aware of that, but because their machines came with Windows and Secure Boot enabled and they do not know any different. So again, look in this forum and see how many issues people report with the hardware not working properly or, latest news, even a bricked FD because of the latest BIOS upgrade and tell me why should not Framework dedicate their resources to fixing those problems and instead spend time and money for the whims of a few security biased people. Possibility and probability should apply in anything we do and although security is and will remain important aspect of our daily computer life, please let’s keep it real guys and adapted to the very, insignificantly low numbers of events that you want to protect yourselves against. And remember what Linus said a few years ago about the influence of such people on the Linux kernel and how it must be toned down. The technical merits are irrelevant when put in probabilities and cost perspective. There are technical proposals that may have merit for establishing bases on the Moon or Mars, but we are not there yet, mainly because of money/resources and because we have better things to do than spend effort on those endeavors.

I am glad that we could find some common ground and agree that everyone is free to determine their own values and discuss them. I definitely agree with that sentiment. However, you don’t appear to be providing a real, concrete reason explaining why Framework shouldn’t expose Platform Secure Boot to its end-users, giving them the option to enable the extra security if they want to.

You asked for real-world examples of threats that PSB could help defend against and DHowett provided you with some sources. Yet, you claim you were never given any examples at all. Do the sources have to come from me to be credible? Is it possible that DHowett was correct when they stated:

Arguments that start with “give me one real example” usually end with “that one doesn’t count”.

Just because you have not seen these types of attacks in the mainstream media doesn’t mean they aren’t real threats. Additionally, there is a huge difference between what is acceptable for Linux kernel development and an optional platform security feature, which already exists, being exposed to end-users. This appeal to authority is a bit misplaced and it doesn’t even explain why you feel like this security feature (again, which already exists and should be supported by the platform) shouldn’t be exposed to give people the freedom to use it or not.

It is also kind of selfish to say:

They most always require physical access to the device, which any normal, self-aware computer user would never give to somebody who would do such a thing. And if they would, then they deserve what they get.

People can’t always prevent someone from having physical access to their device. It may be difficult for you to understand this, but some people simply have higher threat models than others. It is entirely possible that they work with classified information, live in high risk areas, are an activist or investigative journalist. There are many valid reasons why someone could reasonably expect that their device may unknowingly fall into the hands of a skilled adversary through no fault of their own. In these situations, it would be really great to know that there is at least some trust in the firmware running on your system.

You’re absolutely correct when you say that I am security biased though. I am very open about that and fully admit that I am extremely security focused. However, as much as I require a higher level of security, I would happily accept Framework rejecting the idea to improve platform security if it meant forcing that change on anyone, even if it is one single user, who doesn’t want it. Like I said in my previous post, I don’t want to impose my needs on anyone else. I’d just really like for users to have the option to opt into PSB if it is something they would like to use.

Once again, I am also sorry that you and others seem to be having a difficult time with your devices. I truly do hope they are able to promptly address the issues. However, just because someone is asking them to expose a feature, which already exists, doesn’t mean they won’t fix the things you care about too. We can both happily coexist and there is no need for our personal interests to compete here. It isn’t an all-or-nothing proposition.

I’ll just end my side of the conversation here because I feel like I have said everything that I really needed to. In the end, you and I have no real say over what Framework as an OEM chooses to work on or not. If they see merit in my request, maybe it will be considered. If not, they will disregard it and move on. I was honestly hoping to have a more interesting discussion about this, but I don’t really think that is going to happen.

Good luck with your Framework device(s) and I hope you get all of your problems sorted out soon.

1 Like

The answer is: risk, probability, possibility and cost. Any well led company pursues goals and avenues based on that. Also, instinctively, humans choose their actions based on threat probability and those that don’t often pay the price, one way or another.

And anyway, I think that any security measure can be bypassed by a person with intent and resources. The data that would be sought off doesn’t reside in BIOS or software. If it would be me and I would have access to your machine, I would simply remove the SSD from that ultra secured laptop, decrypt it if it’s encrypted, and get everything I’d want.

This looks like an interesting post - wouldja add some para breaks? I struggle with a single dense blob of text, unfortunately. (In case it is not clear, a double-Enter produces a break in this forum).