System76 and LVFS • Hacker News Board

Re: System76 and LVFS

#81

Post by amluto » Sat, May 12, 2018, 12:52 AM UTC

jackpot51 wrote: post #76

amluto wrote: post #75

Earlier quoted context omitted.

But, if your firmware cares about preventing flashable rootkits, then these registers should be locked such that you can only flash from SMM or during initial boot. The fact that AFUEFI works at all on a System76 laptop is a bad sign IMO.

It absolutely is locked, and needs to be unlocked and flashed while in EFI mode.

What do you mean “in EFI mode”? Do you mean EFI Boot Services or something else? I’m trying to understand what makes AFUEFI special that causes it to be able to write the SPI flash when regular software can’t. If I understand your blog post right, AFUEFI run like any other .efi program, which seems insufficiently locked down to me.

Re: System76 and LVFS

#82

Post by ggm » Sat, May 12, 2018, 1:42 AM UTC

basementcat wrote: post #20

ggm wrote: post #15

Earlier quoted context omitted.

To be fair, both sides are acting somewhat unprofessionally in this story. This. I think the whole "longer lever to move the boulder is to do this in public" is a very very bad trend. Posting stuff like this is inflammatory, on both sides.

Based on recent electoral trends from around the world, this sort of engaging spirited behavior may be exactly what consumers want.

Some consumers. I don't believe a majority, but enough that as a win-at-any-cost strategy it works. The majority actually loses in this situation. This is destroy the opposition not grow the market.

Re: System76 and LVFS

#83

Post by jackpot51 » Sat, May 12, 2018, 1:12 PM UTC

0x0 wrote: post #79

jackpot51 wrote: post #78

Earlier quoted context omitted.

Blockchain, however muddied it is today, does have legitimate uses. In this case, we use it to enforce a valid timeline of builds with cryptography.

I don't get it, do you allow adversary participants in on the network to vote on firmware consensus? What's wrong with regular vendor digital signatures, like everyone else does? :)

No. It is a blockchain, but is not distributed or mined. Firmware is built and signed with the signature of the previous build as part of the artifacts. This, in addition with a constraint that the timestamp can never move backwards, means builds must have a valid timeline and it becomes very difficult to hijack the publishing system.

Imagine you want to revert firmware for legitimate reasons. As the originator of the firmware, you could revert the source code and have a new build spawn that produces a valid artifact. With our system and with the typical system, this is possible.

Now imagine you are an attacker who wants to release an older firmware version, which potentially contains a vulnerability. You have access to the publishing system, but not the build system or signing key. With our system this is impossible, as consumers will not allow moving backwards to an older build. With the typical system, any signed firmware blob can be released at any time, meaning an older version can be made available without having to rebuild.

Our build system utilizes a firmware signing hardware device connected to the build server over serial with a strict protocol to ensure that leaking the key is not possible, even if the build server is compromised. In addition, the key is destroyed if this firmware signing device loses power (it does have a battery backup, but it disconnects if the case is opened), and we must deploy a new key in that event through software upgrades on client machines.

Re: System76 and LVFS

#84

Post by 0x0 » Sat, May 12, 2018, 1:35 PM UTC

jackpot51 wrote: post #83

0x0 wrote: post #79

Earlier quoted context omitted.

I don't get it, do you allow adversary participants in on the network to vote on firmware consensus? What's wrong with regular vendor digital signatures, like everyone else does? :)

No. It is a blockchain, but is not distributed or mined. Firmware is built and signed with the signature of the previous build as part of the artifacts. This, in addition with a constraint that the timestamp can never move backwards, means builds must have a valid timeline and it becomes very difficult to hijack the publishing system. Imagine you want to revert firmware for legitimate reasons. As the originator of th…

Sounds really complicated, couldn't you just replace all that blockchain verification code with an "if (firmwareToInstall.version < firmwareCurrentlyInstalled.version) return false" after the signature check?