4 ms·

I expected to like this talk much more than I actually did. Basically what they did is do a reverse engineering and replay attack on a boot sequence that is al

by fefe23 4y ago

I expected to like this talk much more than I actually did. Basically what they did is do a reverse engineering and replay attack on a boot sequence that is already so convoluted that the company that built it didn't think that would be possible. Good for them but all this work will be wasted if the next hardware version comes around and needs a different boot sequence. They basically nailed themselves to a specific version of a specific hardware platform that AMD is replacing as we speak (the next iterations are called Genoa and Bergamo and are expected this and next year respectively. I was hoping this would feel like a breath of freedom, but it really feels like a few rebellious nerds trying to prove something, but not actually proving it. The talk feels to me like they actually proved the opposite. We are already too far down the path. You will never be able to, say, boot Windows on this hardware. Can you boot a stock Linux on this hardware, or will you be dependent on patches from them? As a Linux user I love the idea. As a PC user I never asked for UEFI or the Management Engine. I should be all for this. But somehow I'm not.

panick21_ 4y ago
You expected a startup to solve all problems all ADM/Intel have created? That seems like expectation going out of hand. As he says in the video, what is important is documentation. Their code will serve as open documentation for a lot of those details. Sure with the next version there will be some changes, but likely much of it will still be the same. And when they upgrade their product they will have to integrate those changes. For 'stock Linux' to boot like that it would need to add those same low level drivers and I don't know if there is a reason the phased approach shouldn't work on linux. The hope is for many companies to do this and demand this documentation so that with each new version these things will quickly find their way into the open source software. This is now happening with coreboot where multiple companies collaborate on new CPU generations to get it in before the hardware is even released. But with fireware there is never this amazing solution anybody can do unless the manufacture simply does it. Its sad but its the reality.
raxxorraxor 4y ago
Easy and sensible why you might be against this. The simple reality is that BIOS did not prevent you to run anything you wanted on your machine. Recent developments are usually to restrict the user, so any change would very likely be bad. Extrapolated experience does not need to be true, but it very well can be. UEFI secure boot is an example. Yes, it can increase security (although I think the threat is specific or outdated), but it can well be used to limit the user practically. And if such a mechanism is established, there will be a class system of trusted and untrusted devices. This is not a development that is hard to predict. So UEFI already failed to a large degree, at least regarding the openness of systems. It is no accident that some companies push these developments enthusiastically. It is not for user security, it is simply for market dominance.
bcantrill 4y ago
I'm not sure what gave you this impression: > Basically what they did is do a reverse engineering and replay attack on a boot sequence that is already so convoluted that the company that built it didn't think that would be possible. That is not at all what was done here, and my apologies if I implied that it is. Indeed, quite the opposite was done: we determined how it actually worked and what the part actually needed -- discarding much of the needless gunk and repeated initialization. So it's not a "boot sequence" per se, it is initialization of various on-die components. Is this AMD-specific? Yes. Is it likely to change in Genoa, Bergamo and beyond? To a degree, yes -- but in broad strokes, unlikely. And because we have the OS (and importantly, its tooling) available where this enablement is taking place, we believe that we will be able to make the necessary changes for Genoa and beyond relatively faster than the extant approach of waiting for a proprietary BIOS.
- fefe23 4y ago
  Hi Bryan, thanks for the talk. I think we are saying the same thing just from a different point of view. Your approach is very laudable and I have in fact been fanboying it for a while. I wish you the best of luck and profits for your company. I sure hope this approach is more sustainable than my gut feeling told me after viewing your talk. One question, if I may: How sure are you that AMD won't sue you at some point over this? Your ought to be in their best interest but that has rarely stopped legal departments in the past. Where you see an "this is an awesome opportunity for a company, I'll found one", I see an "would I really want to base my business on something that AMD may at any time decide voids the warranty"?
  - bcantrill 4y ago
    We have worked very closely with AMD, and they have broadly been very supportive of what we're doing here. As for the more general point of the peril of tightly integrating with partners (AMD is not the only one that we have gone very deep with): yes, it's a risk. But we have consciously decided that we would rather make deliberate decisions and deeply integrate than build a system composed of the lowest common denominators. Relationships are always a gamble (which is why it's important to enter them carefully!) but our belief is that the upside of a tight partnership more than compensates for the risk.

by fefe23 4y ago

panick21_ 4y ago

You expected a startup to solve all problems all ADM/Intel have created? That seems like expectation going out of hand. As he says in the video, what is important is documentation. Their code will serve as open documentation for a lot of those details. Sure with the next version there will be some changes, but likely much of it will still be the same. And when they upgrade their product they will have to integrate those changes. For 'stock Linux' to boot like that it would need to add those same low level drivers and I don't know if there is a reason the phased approach shouldn't work on linux. The hope is for many companies to do this and demand this documentation so that with each new version these things will quickly find their way into the open source software. This is now happening with coreboot where multiple companies collaborate on new CPU generations to get it in before the hardware is even released. But with fireware there is never this amazing solution anybody can do unless the manufacture simply does it. Its sad but its the reality.

raxxorraxor 4y ago

Easy and sensible why you might be against this. The simple reality is that BIOS did not prevent you to run anything you wanted on your machine. Recent developments are usually to restrict the user, so any change would very likely be bad. Extrapolated experience does not need to be true, but it very well can be. UEFI secure boot is an example. Yes, it can increase security (although I think the threat is specific or outdated), but it can well be used to limit the user practically. And if such a mechanism is established, there will be a class system of trusted and untrusted devices. This is not a development that is hard to predict. So UEFI already failed to a large degree, at least regarding the openness of systems. It is no accident that some companies push these developments enthusiastically. It is not for user security, it is simply for market dominance.

bcantrill 4y ago

I'm not sure what gave you this impression: > Basically what they did is do a reverse engineering and replay attack on a boot sequence that is already so convoluted that the company that built it didn't think that would be possible. That is not at all what was done here, and my apologies if I implied that it is. Indeed, quite the opposite was done: we determined how it actually worked and what the part actually needed -- discarding much of the needless gunk and repeated initialization. So it's not a "boot sequence" per se, it is initialization of various on-die components. Is this AMD-specific? Yes. Is it likely to change in Genoa, Bergamo and beyond? To a degree, yes -- but in broad strokes, unlikely. And because we have the OS (and importantly, its tooling) available where this enablement is taking place, we believe that we will be able to make the necessary changes for Genoa and beyond relatively faster than the extant approach of waiting for a proprietary BIOS.

fefe23 4y ago
Hi Bryan, thanks for the talk. I think we are saying the same thing just from a different point of view. Your approach is very laudable and I have in fact been fanboying it for a while. I wish you the best of luck and profits for your company. I sure hope this approach is more sustainable than my gut feeling told me after viewing your talk. One question, if I may: How sure are you that AMD won't sue you at some point over this? Your ought to be in their best interest but that has rarely stopped legal departments in the past. Where you see an "this is an awesome opportunity for a company, I'll found one", I see an "would I really want to base my business on something that AMD may at any time decide voids the warranty"?
- bcantrill 4y ago
  We have worked very closely with AMD, and they have broadly been very supportive of what we're doing here. As for the more general point of the peril of tightly integrating with partners (AMD is not the only one that we have gone very deep with): yes, it's a risk. But we have consciously decided that we would rather make deliberate decisions and deeply integrate than build a system composed of the lowest common denominators. Relationships are always a gamble (which is why it's important to enter them carefully!) but our belief is that the upside of a tight partnership more than compensates for the risk.