The Linux Foundation welcomes the Linux Vendor Firmware Service (LVFS) as a new project. LVFS is a secure website that allows hardware vendors to upload firmware updates. It’s used by all major Linux distributions to provide metadata for clients, such as fwupdmgr, GNOME Software and KDE Discover. To learn more about the project’s history and goals, we talked with Richard Hughes, upstream maintainer of LVFS and Principal Software Engineer at Red Hat.[…]
[…]IBM is providing their OpenBMC code base to The Linux Foundation, and this project will be supported by several organizations, including Facebook, Google, Intel, and Microsoft. The community is looking to expand and invites contributors from across the industry to come together in defining and creating the OpenBMC stack.[…]The Linux Foundation is pleased to welcome OpenBMC to our family of open source projects and to work with the community to support its growth.[…]
SOFProject: Sound Open Firmware is an open source audio DSP firmware and SDK that provides audio firmware infrastructure and development tools for developers who are interested in audio or signal processing on modern DSPs
ACRN: a flexible, lightweight reference hypervisor, built with real-time and safety-criticality in mind, optimized to streamline embedded development through an open source platform
Status of Embedded Linux, Tim Bird
Review of ELC Europe 2017, Tim Bird
mplementing state-of-the-art U-Boot port, 2017 edition, by Marek Vasut
Linux カーネルのメモリ管理の闇をめぐる戦い（協力者募集中, Tetsuo Handa (NTT Data)
Request for your suggestions: How to Protect Data in eMMC on Embedded Devices, Gou Nakatsuka (Daikin)
Fuego Status and Roadmap, Tim Bird
Multicast Video-Streaming on Embedded Linux environment, Daichi Fukui (TOSHIBA)
From 1 to many Implementing SMP on OpenRISC, Stafford Horne
Core Partitioning Technique on Multicore Linux systems, Kouta Okamoto (TOSHIBA)
Debian + YoctoProject Based Projects: Collaboration Status, Kazuhiro Hayashi (TOSHIBA)
See-also: Septemer 2017 Jamboree 62:
Status of Embedded Linux, Tim Bird
EdgeX Foundry: Introduction and demonstration of end to end IoT system, Victor Duan, Linaro
Lighting Talk: Integration between GitLab and Fuego, Tomohito Esaki, IGEL Co., Ltd.
DebConf17 Report, Kazuhiro Hayashi, TOSHIBA
Lightning Talk : About the LTS now, Shinsuke kato, Panasonic Corporation
Kernel Recipes 2015 – Linux Stable Release process, Greg KH
Lightning Talk: IPv6 Ready Logo Test for LTSI 4.9 and introduction about CVE-2016-5863 and CVE-2017-11164, Fan Xin, Fujitsu Computer Technologies Limited
[…]Now, before you even start with your operating system installation, there are a few things you should consider to ensure your pre-boot environment is up to snuff. You will want to make sure:
* UEFI boot mode is used (not legacy BIOS) (ESSENTIAL)
* A password is required to enter UEFI configuration (ESSENTIAL)
* SecureBoot is enabled (ESSENTIAL)
* A UEFI-level password is required to boot the system (NICE-to-HAVE)
Sounds interesting, but I don’t see any actual download link for this ebook. I guess I need some sleep.
Jan Lübbe of Pengutronix e.K. gave a talk at ELCE’16 (Embedded Linux Conference Europe 2016) called: “Long-Term Maintenance, or How to (Mis-)Manage Embedded Systems for 10+ Years”.
“Hardware vendors don’t care about security or maintenance.”
The Linux Foundation has started a new conference, the OpenIoT Summit, April 4-6 in San Diego, California. Call for Papers is open, closes in a few days, Feburary 5th.
OpenIoT Summit is a technical event created to serve the unique needs of system architects, firmware developers, software developers and application developers in this emerging IoT ecosystem.
Amongst the buzzwords in their CfP’s Suggested Topics were: “Device and Firmware Management“, so maybe something interesting at this event. 🙂
Their CfP list of IoT frameworks/OSes:
AllJoyn, IoTivity, Linux, Soletta, Weave, Yocto Project, and Small, real-time OSes (e.g. Contiki, FreeRTOS, RIoT).
Some irresponsible bloggers have been commenting about Matthew’s fork of Linux:
ZDNet has a story with comments from Matthew explaining things:
“I wouldn’t say I’m forking. I’d say that I’m doing my own development work away from LKML. Right now it’s got the securelevel work in it because that’s the only code I have that I feel is ready for public use, but it’ll pick up other bits of code that I’m working on as they become mature.”
I guess I look at Matthew’s fork is like the GRSecurity patch for Linux kernel: Matthew’s got the patchset that enables UEFI Secure Boot to be secure on Linux. I hope Tails, Qubes, and other security-minded distros use Matthew’s kernel, at least in builds for UEFI-based systems.
[One of the causes of the above issue is Linus having to deal with Microsoft as a CA. UEFI Forum could also deal with this by putting in place a CA that is not an OSV/OEM. OEMs could be making Linux-friendly sytsems, not just Windows- or Chrome boxes, where Linux is an afterthought second install, which is a lot harder to do with UEFI/Windows Secure Boot — and even Chrome Verified Boot. Linux Foundation could also be helping, by working with OEMs.]
A few days ago, the Linux Foundation released new guidance for securing Linux systems. Since the Linux Foundation has mostly remote workers, there are currently 2 documents: one on hardening Linux Workstations, and one for secure group communications, the latter something like a CryptoParty Handbook. Here’s an excerpt of the Hardware/Firmware/Pre-OS section from the Workstation document:
Choosing the right hardware
We do not mandate that our admins use a specific vendor or a specific model, so this section addresses core considerations when choosing a work system.
System supports SecureBoot (CRITICAL)
System has no firewire, thunderbolt or ExpressCard ports (MODERATE)
System has a TPM chip (LOW)
Despite its controversial nature, SecureBoot offers prevention against many attacks targeting workstations (Rootkits, “Evil Maid,” etc), without introducing too much extra hassle. It will not stop a truly dedicated attacker, plus there is a pretty high degree of certainty that state security agencies have ways to defeat it (probably by design), but having SecureBoot is better than having nothing at all. Alternatively, you may set up Anti Evil Maid which offers a more wholesome protection against the type of attacks that SecureBoot is supposed to prevent, but it will require more effort to set up and maintain.
Firewire, thunderbolt, and ExpressCard ports
Firewire is a standard that, by design, allows any connecting device full direct memory access to your system (see Wikipedia). Thunderbolt and ExpressCard are guilty of the same, though some later implementations of Thunderbolt attempt to limit the scope of memory access. It is best if the system you are getting has none of these ports, but it is not critical, as they usually can be turned off via UEFI or disabled in the kernel itself.
Trusted Platform Module (TPM) is a crypto chip bundled with the motherboard separately from the core processor, which can be used for additional platform security (such as to store full-disk encryption keys), but is not normally used for day-to-day workstation operation. At best, this is a nice-to-have, unless you have a specific need to use TPM for your workstation security.
This is a set of recommendations for your workstation before you even start with OS installation.
UEFI boot mode is used (not legacy BIOS) (CRITICAL)
Password is required to enter UEFI configuration (CRITICAL)
SecureBoot is enabled (CRITICAL)
UEFI-level password is required to boot the system (LOW)
UEFI and SecureBoot
UEFI, with all its warts, offers a lot of goodies that legacy BIOS doesn’t, such as SecureBoot. Most modern systems come with UEFI mode on by default.
Make sure a strong password is required to enter UEFI configuration mode. Pay attention, as many manufacturers quietly limit the length of the password you are allowed to use, so you may need to choose high-entropy short passwords vs. long passphrases (see below for more on passphrases).
Depending on the Linux distribution you decide to use, you may or may not have to jump through additional hoops in order to import your distribution’s SecureBoot key that would allow you to boot the distro. Many distributions have partnered with Microsoft to sign their released kernels with a key that is already recognized by most system manufacturers, therefore saving you the trouble of having to deal with key importing.
As an extra measure, before someone is allowed to even get to the boot partition and try some badness there, let’s make them enter a password. This password should be different from your UEFI management password, in order to prevent shoulder-surfing. If you shut down and start a lot, you may choose to not bother with this, as you will already have to enter a LUKS passphrase and this will save you a few extra keystrokes.
PS: The Linux Foundation also just started a Core Infrastructure Initiative, which has security implications, which I’ve got to find out more on, and will blog on later.
As part of LinuxCon North America, the Linux Security Summit recently finished, and presentations are now available (I omitted the few talks which had no presentations from below list):
* Keynote: Giant Bags of Mostly Water – Securing your IT Infrastructure by Securing your Team, Konstantin Ryabitsev, Linux Foundation
* CC3: An Identity Attested Linux Security Supervisor Architecture, Greg Wettstein, IDfusion
* SELinux in Android Lollipop and Android M, Stephen Smalley, NSA
* Discussion: Rethinking Audit, Paul Moore, Red Hat
* Assembling Secure OS Images, Elena Reshetova, Intel
* Linux and Mobile Device Encryption, Paul Lawrence, Mike Halcrow, Google
* Discussion: Core Infrastructure Initiative, Emily Ratliff, Linux Foundation
* Security Framework for Constraining Application Privileges, Lukasz Wojciechowski, Samsung
* IMA/EVM: Real Applications for Embedded Networking Systems, Petko Manolov, Konsulko Group, Mark Baushke, Juniper Networks
* Ioctl Command Whitelisting in SELinux, Jeffrey Vander Stoep, Google
* IMA/EVM on Android Device, Dmitry Kasatkin, Huawei Technologies
* Subsystem Update: Smack, Casey Schaufler, Intel
* Subsystem Update: AppArmor, John Johansen, Canonical
* Subsystem Update: Integrity, Mimi Zohar, IBM
* Subsystem Update: SELinux, Paul Moore, Red Hat
* Subsystem Update: Capabilities, Serge Hallyn, Canonical
* Subsystem Update: Seccomp, Kees Cook, Google
* Discussion: LSM Stacking Next Steps, Casey Schaufler, Intel
The Embedded Linux Conference Europe (ELCE) is happening in October. There’s a set of UEFI talks happening at the event:
UEFI Forum Update and Open Source Community Benefits, Mark Doran
Learn about the recent UEFI Forum activities and the continued adoption of UEFI technology. To ensure greater transparency and participation from the open source community, the Forum has decided to allow for public review of all specification drafts. Find out more about this new offering and other benefits to being involved in firmware standards development by attending this session.
What Linux Developers Need to Know About Recent UEFI Spec Advances, Jeff Bobzin
Users of modern client and server systems are demanding strong security and enhanced reliability. Many large distros have asked for automated installation of a local secure boot profile. The UEFI Forum has responded with the new Audit Mode specified in the UEFI specification, v2.5, offering new capabilities, enhanced system integrity, OS recovery and firmware update processes. Attend this session to find out more about the current plans and testing schedules of the new sample code and features.
LUV Shack: An automated Linux kernel and UEFI firmware testing infrastructure, Matt Fleming
The Linux UEFI Validation (LUV) Project was created out of necessity. Prior to it, there was no way to validate the interaction of the Linux kernel and UEFI firmware at all stages of the boot process and all levels of the software stack. At Intel, the LUV project is used to check for regressions and bugs in both eh Linux kernel and EDK2-based firmware. They affectionately refer to this testing farm as the LUV shack. This talk will cover the LUV shack architecture and validation processes.
The Move from iPXE to Boot from HTTP, Dong Wei
iPXE relies on Legacy BIOS which is currently is deployed by most of the world’s ISPs. As a result, the majority of x86 servers are unable to update and move to a more secure firmware platform using UEFI. Fortunately, there is a solution. Replacing iPXE with the new BOOT from HTTP mechanism will help us get there. Attend this session to learn more.
UEFI Development in an Open Source Ecosystem, Michael Krau, Vincent Zimmer
Open source development around UEFI technology continues to progress with improved community hosting, communications and source control methodologies. These community efforts create valuable opportunities to integrate firmware functions into distros. Most prevalent UEFI tools available today center on chain of trust security via Secure Boot and Intel® Platform Trust Technology (PTT) tools. This session will address the status of these and other tools. Attendees will have the opportunity to share feedback as well as recommendations for future open UEFI development resources and processes.
UEFI aside, there’s many other presentations that look interesting, for example:
Isn’t it Ironic? The Bare Metal Cloud – Devananda van der Veen, HP
Developing Electronics Using OSS Tools – Attila Kinali
How to Boot Linux in One Second – Jan Altenberg, linutronix GmbH
Reprogrammable Hardware Support for Linux – Alan Tull, Altera
Measuring and Reducing Crosstalk Between Virtual Machines – Alexander Komarov, Intel
Introducing the Industrial IO Subsystem: The Home of Sensor Drivers – Daniel Baluta, Intel
Order at Last: The New U-Boot Driver Model Architecture – Simon Glass, Google
Suspend/Resume at the Speed of Light – Len Brown, Intel
The Shiny New l2C Slave Framework – Wolfram Sang
Using seccomp to Limit the Kernel Attack Surface – Michael Kerrisk
Tracing Virtual Machines From the Host with trace-cmd virt-server – Steven Rostedt, Red Hat
Are today’s FOSS Security Practices Robust Enough in the Cloud Era – Lars Kurth, Citrix
Security within Iotivity – Sachin Agrawal, Intel
Creating Open Hardware Tools – David Anders, Intel
The Devil Wears RPM: Continuous Security Integration – Ikey Doherty, Intel
Building the J-Core CPU as Open Hardware: Disruptive Open Source Principles Applied to Hardware and Software – Jeff Dionne, Smart Energy Instruments
How Do Debuggers (Really) Work – Pawel Moll, ARM
Make your Own USB device and Driver with Ease! – Krzysztof Opasiak, Samsung
Debugging the Linux Kernel with GDB – Peter Griffin, Linaro
The CE Workgroup of the Linux Foundation occasionally does bids for research or work for related projects. One of the projects they’re interested in is supporting meta-Debian, a Yocto project that integrates with Debian. Earlier this week Tim Bird, Architecture Group Chair, CE Workgroup of the Linux Foundation, announced their proposals, exerpted here to focus on the Debian/Yocto project:
The CE Workgroup of the Linux Foundation occasionally solicits contractors for projects they are considering. The following projects is currently under consideration for funding this year, and the CE Workgroup would be interested in hearing from you if you would like to work on them (and be paid for it!) For a while now, CEWG has been studying the feasibility of combining the Yocto Project with Debian, to create a system for using the Debian distribution for embedded projects. The first proposal above, intends to solicit (paid) contributions to extending CEWGs project to more hardware and to include more libraries in the target distribution. If you are interested and are willing to get paid to work on this (producing or enhancing open source software to benefit the entire embedded industry), then please contact Tim Bird.
For the full announcement, see posting by Tim Bird. I’ve excerpting Tim’s announcement to only mention the meta-Debian project: he also mentioned two other projects, see the full announcement for details on those.
IMO, it would be nice to have Intel contributing to Debian in this way, providing Yocto-based vendors with more opportunities to use Debian, and helping Debian with embedded BSP (and hopefully some QA).
A bit of background on meta-debian, and some related projects:
Hey Linux/FreeBSD distros: it’s great that you’ve got UEFI support including Secure Boot certs. But that’s not enough, you need to join the UEFI Forum, and help evolve UEFI to be more Linux-friendly.
Right now, the last time I checked, the only Linux distros that had joined were: Canonical (Ubuntu), Red Hat, and SuSE. As well as Linaro. Excluding SuSE and Redhat’s commercial products, that means that Ubuntu, Fedora, and OpenSUSE are the community Linux distros that may have the best UEFI support.
UEFI Forum members have access to:
* member-only communications (web forums)
* member-only invites to meetings/events (including the 1-3 plugfests they do each year).
* member-only access to software and specs the public doesn’t have.
* access to file bugs/change requests, which the public cannot do.
I think you get access to their non-public trunk, a subset of which is exported to the public as TianoCore, but I’m not sure. (Hypocritically, I’m not a member yet, still working on it, blocking on some new company infrastructure.)
If you join, you can help evolve and improve UEFI, and have early access to UEFI resources so your distros can be ready for any changes. You can attend the plugfests and do interop testing with other UEFI products/projects, to find problems before your users have to see them.
If you don’t join, you’ll be constantly reacting to UEFI Forum releases, have less resources than UEFI Member distros have, and if there’s a problem all you can do is whine and blame Intel and/or Microsoft, when you should look into the mirror instead.
The Linux Foundation should help enable community distros, which don’t have large corporations to back their membership, to get involved as well. The Free Software Foundation should join and participate, instead of keeping their heads in the sand and wish everyone would stop using UEFI. Embrace and Extend.
In addition to Linux distros, FreeBSD also supports UEFI, and is not a UEFI Forum member. iX Systems and FreeBSD Foundation: this also applies to you.
You also need to register your distro with the UEFI Forum’s ESP Subdirectory Registry, so you can have some UEFI binaries (boot loader, etc.) in a well-known location. Ex, if Debian’s cbootstrap gets ported to a UEFI Application, then \EFI\Debian\cbootstrap.efi would be an example of where the file would be stored. Right now, Debian is registered, but not a member of the UEFI Forum!?
Intel, ARM, Linaro, Red Hat, SuSE, and Canonical have been doing a great job improving UEFI so it works better with non-Apple, non-Microsoft operating systems. IMO, more distros need to get involved and help.
While I’m on my soapbox, Linux distros should consider some UEFI-centric rescue options in their boot CDs. ALT Linux Rescue ISOs include rEFInd boot manager, and let you optionally jump into UEFI Shell. You could use UEFI-aware GRUB for this, instead of rEFInd. Additionally, it would be nice to also give access to running: FWTS (FirmWare Test Suite), Intel CHIPSEC to test the hardware/firmware for security. It would also be nice to include the UEFI port of CPython 2.7x, along with the UEFI Shell, for more powerful diagnostic abilities. Distro installers should also consider installing UEFI Shell and UEFI Python and CHIPSEC onto system’s ESP, in an advanced mode, not just let them access via install ISO. Of course, there are security issues by enabling extra Pre-OS tools, user would need to opt-into all of this. Intel’s LUV-live, which Linaro is porting to AArch64, contains BITS (BIOS Interface Test Suite), FWTS, CHIPSEC all in one convenient location. I hope other Linux distros emulate some of LUV-live’s diagnostic and rescue abilities.
LinuxCon North America is happening this August, in Seattle for the first time (I think). A quick look at their schedule shows a variety of interesting presentations related to firmware security:
* Extending the Secure Boot Certificate and Signature Chain of Trust in the OS – Fionnuala Gunter, Hypori
* Resurrecting Internet Booting – Boot Boot, Booting Over the Internet – John Hawley, Intel
* Demystifying ACPI and EFI via Python and BITS – Josh Triplett
* ACPI for Network Switches – Dustin Byford, Cumulus Networks
* Tying TPMs Throughout The Stack – Matthew Garrett, CoreOS
* Turtles All The Way: Running Linux on Open Hardware – Rob Landley
* ACPI 6 and Linux – Rafael J. Wysocki, Intel
* The Bare-Metal Hypervisor as a Platform for Innovation – Russell Pavlicek, Citrix
* Suspend/Resume at the Speed of Light – Len Brown, Intel
Josh Triplett on BIOS BITS sounds especially interesting. It’ll be interesting to see if the boot boot reboot will get integrated with UEFI HTTP Boot support.