Tag: System76

fwupd / LVFS and user privacy

~ hucktech ~ Leave a comment

There’s been a few blog posts from the LVFS project and the System76 team regarding firmware updates.

https://firmwaresecurity.com/2018/05/10/dont-buy-system76-hardware-and-expect-to-get-firmware-updates-from-the-lvfs/

https://firmwaresecurity.com/2018/05/11/system76-system76-and-lvfs-what-really-happened/

The latest article is from FOSSpost.org by M.Hanny Sabbagh, which focuses on privacy issues of LVFS, from the last System76 article. While privacy issues are important, don’t forget that firmware update privacy issues exist with ALL other OSes, and LVFS team mentions transition to Linux Foundation for hosting. Most firmware updates come from OEM, so each will have their own CDN/privacy/security issues. I’m hoping the LVFS project gets picked up by the Qubes/TAILS/Subgraph/GNUHardenedLinux or some other privacy/security-centric distro, and can integrate with latest security and privacy techniques, making it Tor-friendly, etc.

See threads here and comments in fosspost.org blog post, and in Twitter feed:

https://lists.debian.org/debian-efi/2018/05/threads.html

https://fosspost.org/analytics/privacy-security-concern-regarding-gnome-software

System76: System76 and LVFS – what really happened

~ hucktech ~ 1 Comment

Re: https://firmwaresecurity.com/2018/05/10/dont-buy-system76-hardware-and-expect-to-get-firmware-updates-from-the-lvfs/ this is the Sytem76 side of the story:

The Future of Firmware

LVFS and UpdateCapsule might be okay for companies mostly focused on a proprietary future (Logitech, Dell, etc.). UpdateCapsule is not the technique companies will use in a future of open source firmware—the future we’re working toward. Liberating firmware is going to be a long and challenging process. Much like Free Software has replaced proprietary software over time, we must chip away at the proprietary firmware pieces within the hardware supply chain. Manufacturing is the first step. This year we’ll manufacture open source desktop designs in our Denver plant. The CAD will be free to download, change, and produce. There will be a separate, open source electrical design and open source firmware daughter board to control functions within the desktop. On a mainboard there is the BIOS chip and one or more embedded controllers that manage fans, keyboard, LEDs, hotkeys and other critical functions. It’s all proprietary. Our strategy is to move this functionality from the proprietary mainboard to the open source daughter board. Then anyone can create a PCB with basic computer functionality, understand how it works, and improve upon the work. One could have this PCB made at Osh Park, install it in their desktop, tune it, and replace a bunch of proprietary firmware instantly. We’ll grow from there. Slowly we’ll chip away at more and more of the mainboard functions until what’s left is Intel and AMD bits. Then there’s the challenge of convincing them to go open. There’s room for cautious optimism.[…]

http://blog.system76.com/post/173801677358/system76-and-lvfs-what-really-happened

Who is working to fix (unify) Linux firmware solutions? UEFI Forum? Linux Foundation? I don’t see a single OEM (eg, System76) driving any such standardization. … 😦

Don’t buy System76 hardware and expect to get firmware updates from the LVFS

~ hucktech ~ 2 Comments

Re: https://firmwaresecurity.com/2018/01/29/linux-oems-support-fwupd-org/

This is a good example of how vendors have vendor-centric tools. Windows Update supports updating firmware, but most Windows OEMs don’t use it. LVFS supports updating firmware on Linux, but most Linux OEMs don’t use it. Sad for users. It seems a bit worse now that UEFI supposedly has a common interface to update firmware, there’s still a problem with UEFI firmware updates. 😦

tl;dr: Don’t buy System76 hardware and expect to get firmware updates from the LVFS

https://blogs.gnome.org/hughsie/2018/05/09/system76-and-the-lvfs/

 

 

kernelstub

~ hucktech ~ 2 Comments

Ian Santopietro of System76 has a Python-based tool called kernelstub, which boots Linux using the Linux Stub bootloader instead of an external bootloader.

Kernelstub is a basic program enabling booting from the kernel’s built-in EFI Stub bootloader. It keeps the ESP and NVRAM up to date automatically when the kernel updates and allows for modifying and setting the boot parameters/kernel options stored in NVRAM. Kernelstub is a basic program enabling booting from the kernel’s built-in EFI Stub bootloader. It keeps the ESP and NVRAM up to date automatically when the kernel updates and allows for modifying and setting the boot parameters/kernel options stored in NVRAM. It works by detecting certain information about the running OS, kernel, storage devices, and options, then combines all of that together into a unified entity, then calls efibootmgr to register the kernel with the NVRAM. It also copies the latest kernel, initrd.img to the EFI System Partition so that UEFI can find it. It will also store a copy of the kernel’s command line (/proc/cmdline) on the ESP in case of necessary recovery from an EFI shell.

https://launchpad.net/kernelstub

He just gave a talk/demo of it at SeaGL:

https://osem.seagl.org/conferences/seagl2017/program/proposals/326

His presentation mentioned this blog in the ‘more info’ slide! 🙂

UEFI at SeaGL

~ hucktech ~ Leave a comment

If you are the Seattle area, the Seattle GNU Linux Conference (SeaGL, pronounced “Seagull”) is happening shortly. There’re two UEFI talks, one by PreOS Security, and one by System76.

https://osem.seagl.org/conferences/seagl2017/program/proposals/374

http://seagl.org/news/2017/09/28/QA-penglish.html

https://preossec.com/

https://system76.com/

https://osem.seagl.org/conferences/seagl2017/program/proposals/326

Linux OEMs/VARs: use FwUpd

~ hucktech ~ Leave a comment

If you build a Linux-based system, you should be putting your firmware updates on fwupd. Dell is the only vendor currently doing this.

What about: System76, ThinkPenguin, Purism, HP, etc??

Hmm, it looks like System76 might be working on it!