If you use Dell hardware and Microsoft Windows OS software, you should read the
blog post by Mike Terrill of 1E:
Tag: UEFI
ReactOS adds UEFI support
Excerpting Wikipedia, ReactOS is: an open-source operating system intended to be binary-compatible with computer programs and device drivers made for Windows. ReactOS is primarily written in C. The project has been ported to the ARM and AMD64 processor architectures, and partially implements Windows API functionality. The latter is assisted by including parts from the Wine compatibility layer. The main goal of the ReactOS project is to provide an operating system which is binary compatible with Windows … such that people accustomed to the familiar user interface of Windows would find using ReactOS straightforward. The ultimate goal of ReactOS is to allow you to remove Windows and install ReactOS without the end user noticing the change.
UEFITool 0.21.0 released
Nikolaj Schlej has released UEFITool v0.21.0.
Features improved Skylake support, among other things:
– added support for new Intel descriptor type, based on [this](http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=1f7fd720c81755144423f2d4062c39cc651adc0a) coreboot commit, thanks to lordkag for issue #32
– solved a bug with incorrect volume free space item placement during volume replace, now works as expected
– solved an issue with incorrect Aptio capsule parsing introduced in 0.20.8
https://github.com/LongSoft/UEFITool
https://firmwaresecurity.com/tag/uefitool/
Rust and UEFI
Rust is a relatively new programming language.
Back in 2013, Eric Holk started adding UEFI support in Rust:
http://blog.theincredibleholk.org/blog/2013/11/18/booting-to-rust/
https://github.com/eholk/Boot2Rust
There’s also a 2014 UEFI Rust library by “project kernel”, which includes a UEFI boot loader, among other things:
https://github.com/project-kernel/uefi-lib
https://github.com/project-kernel/kernel
Starting last month, there’s another Rust UEFI library, by William Kunkel:
https://github.com/wkunkel/libuefi
I don’t know how to program in Rust yet, so I can’t say how usable Rust is with UEFI yet. The last library looks promising, perhaps more general-purpose than the previous projects, as far as I can tell. I guess I am going to have to learn Rust…
More Information:
https://www.rust-lang.org/
Dediprog releases Linux tools
“Dediprog has just released Linux software for SF100, SF600 and SF600 Plus to support the Linux users.”
http://www.dediprog.com/news/91?url=/
As far as I understand it, for these models, there was Windows-only support, so this is exciting if you use Linux: you don’t have to have a Windows box to update your firmware!
Intel porting KGT to UEFI
The other day I learned about Intel KGT:
Then I noticed Matthew Garrett’s twitter feed, saying that it didn’ t work with UEFI… But today I note that Vincent Zimmer of Intel has a new Twitter post, saying that Intel is working on porting KGT to work with UEFI:
Looking forward to UEFI-enabled iKGT!
fwupd and Linux Vendor Firmware Service
I haven’t been covering LVFS and fwupd much. Luckily, Michael Larabel of Phoronix.com has been doing a good job. Richard Hughes has built a Firmware Update for GNOME-based Linux systems. Excerpting from some of Richard’s posts, including his asking for help getting word out to vendors to support it:
fwupd is a simple daemon to allow session software to update device firmware on your local machine. It’s designed for desktops, but this project is also usable on phones, tablets and on headless servers. You can either use a GUI software manager like GNOME Software to view and apply updates, the command-line tool or the system D-Bus interface directly.
I’ve spent the last couple of months talking with various Red Hat partners and other OpenHardware vendors that produce firmware updates. These include most of the laptop vendors that you know and love, along with a few more companies making very specialized hardware. We’ve now got a process, fwupd, that is capable of taking the packaged update and applying it to the hardware using various forms of upload mechanism. We’ve got a specification, AppStream, which is used to describe the updates and provide metadata for what firmware updates are available to be installed. What we were missing was to “close the circle” and provide a web service for small and medium size vendors to use to upload new firmware and make it available to Linux users. Microsoft already provides such a thing for vendors to use, and it’s part of the Microsoft Update service. From the vendors I’ve talked to, the majority don’t want to run any tools on their firmware to generate metadata. Most of them don’t even want to commit to hosting the metadata or firmware files in the same place forever, and with a couple of exceptions actually like the Microsoft Update model. I’ve created a simple web service that’s being called Linux Vendor Firmware Service (perhaps not the final name). You can see the site in action here, although it’s not terribly useful or exciting if you’re not a hardware vendor. If you are vendor that produces firmware and want an access key for the beta site, please let me know. All firmware uploaded will be transferred to the final site, although I’m still waiting to hear back from Red Hat legal about a longer version of the redistribution agreement.
Over the last couple of months I’ve been emailing various tech companies trying to get hold of the right people to implement this. So far the reaction from companies has been enthusiastic and apathetic in equal measures. I’ve had a few vendors testing the process, but I can’t share those names just yet as most companies have been testing with unreleased hardware. This is where you come in. On your Linux computer right now, think about what hardware you own that works in Linux that you know has user-flashable firmware? What about your BIOS, your mouse, or your USB3 hub? Your network card, your RAID card, or your video card? Things I want you to do:
* Find the vendor on the internet, and either raise a support case or send an email. Try and find a technical contact, not just some sales or marketing person
* Tell the vendor that you would like firmware updates when using Linux, and that you’re not able to update the firmware booting to Windows or OS-X
* Tell the vendor that you’re more likely to buy from them again if firmware updates work on Linux
* Inform the vendor about the LVFS project : https://beta-lvfs.rhcloud.com/
At all times I need you to be polite and courteous, after all we’re asking the vendor to spend time (money) on doing something extra for a small fraction of their userbase. Ignoring one email from me is easy, but getting tens or hundreds of support tickets about the same issue is a great way to get an issue escalated up to the people that can actually make changes. So please, spend 15 minutes opening a support ticket or sending an email to a vendor now.
If you know of any vendors, please try to help Richard out with his above request. I hope Richard has contacts at the USB and UEFI trade groups, to directly get word out to their member-vendors.
http://www.fwupd.org/
https://beta-lvfs.rhcloud.com/
https://github.com/hughsie/fwupd
http://www.freedesktop.org/software/appstream/docs/
http://www.phoronix.com/scan.php?page=news_item&px=Linux-LVFS-Embargoed
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Vendor-Firmware-S
http://www.phoronix.com/scan.php?page=news_item&px=linux-lvfs-embargoed
Linux Foundation IT Security Policies: firmware guidance
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.
Checklist
System supports SecureBoot (CRITICAL)
System has no firewire, thunderbolt or ExpressCard ports (MODERATE)
System has a TPM chip (LOW)
Considerations
SecureBoot
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.
TPM Chip
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.
Pre-boot environment
This is a set of recommendations for your workstation before you even start with OS installation.
Checklist
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)
Considerations
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.
Full information:
https://github.com/lfit/itpol/blob/master/linux-workstation-security.md
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.
EFIDroid
I just learned about EFIDroid, “a multiboot solution for mobile devices”. It is not new, EFIDroid was announced Feburary 2014 on the Xiaomi.eu mailing lists:
“Opensource (multiboot) Bootloader: Efidroid (formerly Grub4android):
This is the successor of GRUB4Android – a project to bring multiboot to Android. Even though most people hate UEFI on computers(users because of secureboot and devs because it doesn’t change many problems of BIOS afaik), Intel’s implementation (“EDKII”) actually is quite good and perfectly fits our needs. Also, it still allows you to boot GRUB – just in case you wanna do that.”
It is a Google+-based community, with over a hundred members. There’s been a lot of recent Github activity for the project, including an interesting Linux kernel module.
https://github.com/efidroid
https://plus.google.com/communities/114053643671219382368
http://xiaomi.eu/community/threads/dev-opensource-multiboot-bootloader-efidroid-formerly-grub4android.23615/
https://plus.google.com/u/0/MichaelZimmermann
http://mzimmermann.info/
UEFITool 0.20.8 released
Nikolaj Schlej has released a new version of UEFITool:
https://github.com/LongSoft/UEFITool/releases/tag/0.20.8
159 additions and 61 deletions:
https://github.com/LongSoft/UEFITool/commit/9c4ddbec6218302e86955cfc53e7dfcc8f858eca
Features:
– data after the latest region of Intel image is in tree now
– added Intel, Lenovo and Toshiba-specific capsule GUIDs to the list of known GUIDs
– fixed bogus “File with invalid size” message while working on almost full volumes
– pressing Cancel on “Open in new window” dialog now works as expected
Project ONIE: UEFI support, and Firmware Update Mechanism
Yesterday Curt Brune of Cumulus Networks announced the latest release of Project ONIE, by the Open Compute Project:
This release contains a number of new hardware platforms, along with the usual enhancements and bug fixes. Some firmware excerpts from the announcement:
Documentation:
Updated x86 design specification to cover UEFI support:
https://github.com/opencomputeproject/onie/wiki/Design-Spec-x86-UEFI
Support for UEFI firmware machines:
42c7448 UEFI: initial support for ONIE on UEFI
a16e630 kvm_x86_64 vm: Update INSTALL instructions for UEFI
Firmware Update Mechanism:
a8e712b pending firmware update discovery mechanism
477cd47 x86 firmware update: add onie-fwpkg CLI tool
More Information:
https://github.com/opencomputeproject/onie/releases/tag/2015.08
http://lists.opencompute.org/pipermail/opencompute-onie/2015-August/000840.html
Using FreeBSD, ZFS, and UEFI
Jashank Jeremy wrote an article on using FreeBSD, ZFS, GPT, and UEFI, on a 64-bit system.
Apparently, the trick to is to use GRUB’s kFreeBSD mode. Full information here:
Hmm, WordPress imbeds the entire source file listing of a Git.Github URL. So I’m splitting this URL, you’ll have to combine it yourself:
https://
gist.github.com/jashank
/9ec2f72126552068434c
Also check out the reply from Felix Khrohn on Jashank’s Twitter post, with an URL to alternative method by Ganael Laplanche.
UEFI doc suggestion for Debian
Eddy Jansson suggested an improvement to the Debian installer documentation regarding UEFI systems, GRUB, and the ESP.
I’m not sure if the right Debian writers are reading Twitter. In the off chance that any are reading this blog, here it is. 🙂
new EFI-based operating systems
EFI started as a boot loader solution for Intel Itanium systems. It has grown into UEFI, a boot loader solution for multiple architectures.
However, in my opinion, UEFI is an operating system. It has driver, service, and app models. If you don’t load another OS (eg, Windows, Linux) , and stay in UEFI, the UEFI Shell is pretty much like early MS-DOS: a shell, a bunch of command line tools, and a handful of full-screen tools (edit, hexedit). UEFI is called “the new DOS” for a reason… MS-DOS didn’t have Python either. The main thing missing is an EFI equivalent to DEBUG.COM. 🙂
Now there are a handful of new UEFI-centric OSes being created. It appears they’re mostly hobbyist, educational projects. There may be others, these are the only ones I know of so far:
https://github.com/kmmoore/mosquitos
https://github.com/whisper-bye/LuminOS
https://github.com/nerdshark/simplix
https://github.com/segfo/myOSwithUEFI
https://github.com/skylerseverns/elementary-os-freya-uefi
I look forward to future academic research in this area. I am wondering if there are any existing hardware vendors who’re using UEFI as the only software stack, not using other embedded OSes? Someone needs to do some performance testing to see how it compares to eLinux/Android/NanoBSD/etc.
Phoenix quiet these years
A quick personal note to Phoenix, one of the big IBVs:
Is everything ok at Phoenix? Or is it that you’re doing so good these days you don’t need to keep the public informed of your company’s activities? It is nice to see talks at UEFI Forum meeetings, but please get someone to update your blogs and press release pages. Your press release and event pages haven’t been updated since 2013. Your blog hasn’t been updated since 2010. Even Tim Lewis’ of Phoenix’s personal blog hasn’t been updated since 2014. If this kind of interactivity with the public is an indication, I’m worried about the next firmware security update that impacts Phoenix systems, if nobody is updating things there anymore. Thanks!
http://www.phoenix.com/pages/news-events/
http://www.phoenix.com/pages/upcoming-events
http://blogs.phoenix.com/
Intel’s new Innovation Engine
Last week at IDF, a few UEFI Forum ecosystem vendors announced support for Intel’s new Innovation Engine (IE). But I still don’t know what it is. All I know so far is that the “Innovation Engine is a small Intel(R) architecture processor and I/O sub-system that will be embedded into future Intel data center platforms“, and that it’s roughly like an integrated service process or base board management controller (BMC). I presume everyone from Intel is taking post-IDF “comp-time” Summer vacation, and haven’t uploaded the IE data sheets to intel.com yet. 😦 So far, this is all I can find is this blog post by Jesse Schrater from last week:
Intel’s New Innovation Engine Enables Differentiated Firmware
Historically, platform embedded firmware limits the ways system-builders can customize, innovate, and differentiate their offerings. Today, Intel is streamlining the route for implementing new features with the creation of an “open engine” for system-builders to run firmware of their own creation or choosing.
This important advance in platform architecture is known as the Innovation Engine. It was introduced this week at the Intel Developer Forum in San Francisco.
The Innovation Engine is a small Intel® architecture processor and I/O sub-system that will be embedded into future Intel data center platforms. The Innovation Engine enables system builders to create their own unique, differentiating firmware for server, storage, and networking markets.
Some possible uses include hosting lightweight manageability features in order to reduce overall system cost, improving server performance by offloading BIOS and BMC routines, or augmenting the Intel® Management Engine for such things as telemetry and trusted boot.
These are just a few of the countless possibilities for the use of this new path into the heart of Intel processors. Truthfully, the uses for the Innovation Engine are limited only by the feature’s capability framework and the developer’s imagination.
It’s worth noting that the Innovation Engine is reserved for system-builder’s code, and not Intel firmware. Intel supplies only the hardware, and the system builder can tailor things from there. And as for security, the Innovation Engine code is cryptographically bound to the system-builder. Code not authenticated by the system-builder will not load.
As the name suggests, the Innovation Engine will drive a lot of great benefits for OEMs and, ultimately, end users. This embedded core in future Intel processors will foster creativity, innovation, and differentiation, while creating a simplified path for system-builders implementing new features and enabling full customer visibility into code and engine behavior.
Read the full blog post here:
https://communities.intel.com/community/itpeernetwork/datastack/blog/2015/08/19/intel-s-new-innovation-engine-enables-differentiated-firmware
Looking forward to some actual specs… Wondering if ‘open engine’ may imply Open Hardware, or at least Open Source code to interface with device. 🙂
TCG releases specs for public review
There are Opal specs, and UEFI/TPMv2 specs in public review, amongst a few others:
http://www.trustedcomputinggroup.org/resources/specifications_in_public_review
Also see some TCG talks at the Flash Summit, proceedings are now available (free, but email required). There are hundreds of PDFs, a few security and firmware related, in addition to TCG stuff.
http://www.flashmemorysummit.com/cgi-bin/start.cgi/HTMLOS_Pages/Entrance_Proceedings.html
U-Boot AArch64 and ARM Trusted Boot support
This week Linus Walleij of Linaro posted a long blog article on U-Boot this week, with good background on U-Boot on ARM, as well as current AArch64 support, including integration with ARM Trusted Firmware (ARM TF). Excerpting the concluding paragraphs of the blog:
We now have pieced together a system that will start U-Boot from ARM Trusted Firmware and then have U-Boot load the Linux kernel and a device tree and start it. Are there problems remaining?
* One of the big outstanding issues are those where things are fragile because memory references need be hard-coded in U-Boot or ARM Trusted Firmware. For example U-Boot currently assumes that ARM TF will use 16MB of the DRAM memory. If the ARM TF change things around and use more or less memory, U-Boot needs to be reconfigured and recompiled. U-Boot on the other hand, will then pass whatever knowledge it has about the memory to the Linux kernel by augmenting the device tree. So if ARM TF could communicate the memory available to U-Boot and the OS this would be great.
* U-Boot relies on prior boot stages such as ARM Trusted Firmware to install PSCI handlers, while on ARMv7 this was usually done by augmenting U-Boot to do the same. Letting U-Boot install PSCI handlers is a bit bogus, since it is a piece of resident code left in memory after U-Boot has executed and not really “boot loader” code. U-Boot was augmented to compile these into a special memory area, copy them there and leave them around for the operating system to use later. Still there are people who might like to do this on ARMv8 U-Boot, especially those not using ARM Trusted Firmware.
* People apparently toy with the idea of booting U-Boot on bare metal, using a very small or no ROM nor ARM Trusted Firmware, letting U-Boot just execute immediately on the system. As U-Boot relies on something else to set up main memory and providing PSCI, this currently does not work. Doing this would require U-Boot to initialize memory and install PSCI handlers. It would also need to be small enough to execute from on-chip RAM.
* Chain of trust booting with signed boot levels, signed U-Boot and a signed kernel image and a signed device tree, making an example of a totally locked-down system. The Flattened Image Tree (FIT) supported by U-Boot is likely the best way forward here, but requires U-Boot to access public key infrastructure to verify images unless you want to compile the public key directly into U-Boot, which is often not a good idea.
* Fastboot – the Android boot protocol used by the Little Kernel, exists in U-Boot but has not been tested or verified. It can use USB or Ethernet alike.
* More hardware support – such as booting from the USB stick or MMC/SD card found in the Juno board. This was not covered by the experimental port.
Read the full article here:
https://www.linaro.org/blog/core-dump/u-boot-on-arm32-aarch64-and-beyond/
Insyde updates InsydeH2O and Supervyse
This week at Intel Developer Forum (IDF), Insyde Software announced support of Intel’s new “Innovation Engine”. Insyde has a Supervyse Systems Management product, as well as their InsydeH2O UEFI BIOS. Insyde announced that both of these products will fully-leverage Intel’s Innovation Engine, a newly-announced new processor and IO subsystem targeting data center platforms. Excerpting their press release:
“The Innovation Engine gives us tremendous opportunity to extend our BIOS and BMC product offerings,” said Stephen Gentile, Sr. Vice President, Strategy at Insyde Software. “More importantly, this powerful and open resource gives us a new framework for products targeted at next-generation data center servers,” added Gentile.
“The Innovation Engine is a new way that developers can tap Intel technology to improve the capabilities of data center solutions,” said Lisa Spelman, General Manager of Data Center Marketing at Intel. “Through working with our ecosystem partners like Insyde, our data center customers will have comprehensive hardware and software solutions that will drive new innovations and platform differentiation,” added Spelman.
More information:
UEFI at ELCE
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
http://events.linuxfoundation.org/events/embedded-linux-conference-europe/program/schedule
Firmware Security 
You must be logged in to post a comment.