Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

System76 and LVFS

blog.system76.com

Post reply on HN
Print view View original

71–80 of 84 posts

Re: System76 and LVFS

#71

Post by confiq »

ams6110 wrote: post #53
BadassFractal wrote: post #42

I personally dislike their hardware (I've owned Clevo / Sager for close to 15 years now, they've always felt cheap and plasticky), but I think their PPA and support are great. The problem is that it's not clear what exactly is better out there for Linux enthusiasts who want a MacBook Pro-like experience out of the box. They're the least worst solution on the market as far as I can tell.

> Linux enthusiasts who want a MacBook Pro-like experience out of the box. How big a group is this? Most enthusiasts like the ceremony of installing and configuring their favorite distros to their likings. Or am I misunderstanding what you mean by "enthusiast?"

probably big. Sometimes I just want to code and not to mess with OS all the time...

Re: System76 and LVFS

#72

Post by amluto »

jackpot51 wrote: post #10
verbatim wrote: post #2

This article doesn't seem to explain why they have a hard dependency on a proprietary tool to flash the firmware. There are no alternatives to AFUEFI?

I am the engineer at System76 that has been working on the low-level firmware update procedure. The only alternative is to reverse engineer the SPI flashing method. We have switched to using FPT, the Intel Flash Programming tool, on new models. This means that we need to reverse engineer the SPI update method, which is something the flashrom project has had success in doing for older Intel chipsets.

Can’t you add a bit of code to your firmware to accept a special EFI capsule that’s really just an EFI program (or a firmware volume containing an AFUEFI and the payload)? This wouldn’t work for UpdateCapsule, but it should work as a UEFI 2.4+ capsule-on-disk.

If fwupd won’t support a capsule-on-disk, I personally volunteer to nudge them. But I bet they already support it or would be very willing to add support.

Re: System76 and LVFS

#73

Post by 0x0 »

When a vendor talks about adding a "unique blockchain security infrastructure" for firmware updates... I don't even

Re: System76 and LVFS

#75

Post by amluto »

monocasa wrote: post #65
jackpot51 wrote: post #62

Earlier quoted context omitted.

Kaby Lake and Kaby Lake R, for example

OK, neat, it looks like they haven't changed it in eons. It's PCI device 00:1f.5 and is documented in all of the PCH docs (so Vol 1 for overview, Vol 2 for registers). Sometimes it's disabled by firmware as a sort of 'security' mechanism. Yeah, there's not a whole lot there in the docs, but it's PIO SPI that handles most of the flash addressing for you, so it's not the most complex thing in the world to begin with. M…

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.

Re: System76 and LVFS

#76

Post by jackpot51 »

amluto wrote: post #75
monocasa wrote: post #65

Earlier quoted context omitted.

OK, neat, it looks like they haven't changed it in eons. It's PCI device 00:1f.5 and is documented in all of the PCH docs (so Vol 1 for overview, Vol 2 for registers). Sometimes it's disabled by firmware as a sort of 'security' mechanism. Yeah, there's not a whole lot there in the docs, but it's PIO SPI that handles most of the flash addressing for you, so it's not the most complex thing in the world to begin with. M…

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.

Re: System76 and LVFS

#77

Post by jackpot51 »

monocasa wrote: post #65
jackpot51 wrote: post #62

Earlier quoted context omitted.

Kaby Lake and Kaby Lake R, for example

OK, neat, it looks like they haven't changed it in eons. It's PCI device 00:1f.5 and is documented in all of the PCH docs (so Vol 1 for overview, Vol 2 for registers). Sometimes it's disabled by firmware as a sort of 'security' mechanism. Yeah, there's not a whole lot there in the docs, but it's PIO SPI that handles most of the flash addressing for you, so it's not the most complex thing in the world to begin with. M…

That is good to know. We will also need to unlock the flash descriptor, which is more proprietary code to reverse engineer.

Re: System76 and LVFS

#78

Post by jackpot51 »

0x0 wrote: post #73

When a vendor talks about adding a "unique blockchain security infrastructure" for firmware updates... I don't even

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.

Re: System76 and LVFS

#79

Post by 0x0 »

jackpot51 wrote: post #78
0x0 wrote: post #73

When a vendor talks about adding a "unique blockchain security infrastructure" for firmware updates... I don't even

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? :)

Re: System76 and LVFS

#80

Post by monocasa »

jackpot51 wrote: post #77
monocasa wrote: post #65

Earlier quoted context omitted.

OK, neat, it looks like they haven't changed it in eons. It's PCI device 00:1f.5 and is documented in all of the PCH docs (so Vol 1 for overview, Vol 2 for registers). Sometimes it's disabled by firmware as a sort of 'security' mechanism. Yeah, there's not a whole lot there in the docs, but it's PIO SPI that handles most of the flash addressing for you, so it's not the most complex thing in the world to begin with. M…

That is good to know. We will also need to unlock the flash descriptor, which is more proprietary code to reverse engineer.

For just doing updates, you shouldn't have to (or be able to) touch the flash descriptor, AFAIK. It's fixed at manufacturing time (without touching the flash with an external programmer of course).
Post reply on HN