Insyde is hiring BIOS engineers!

My company, Insyde Software is hiring, both for senior firmware engineer and sales engineer positions.

Insyde Software is hiring! We currently have open positions for Senior BIOS Firmware Engineers. If you are interested or know of potential applicants, please refer to the job posting on our website.

Insyde Software is hiring! We are looking for qualified applicants for a Field Sales Engineer position. If you are interested or know of any potential candidates, please refer to the job posting on our website:.

Resumés can be sent to jobs.us@insyde.com hashtag

20 Year Anniversary: The CIH Virus and the BIOS

As noted in this article, April 26th marked the anniversary when the CIH (or Chernobyl) virus would deliberately attack the contents of the flash chip containing the BIOS part on certain motherboards, making those systems inoperable. The write-protect line on the flash chip was easily disabled, if you knew the little-known access sequence. As the author correctly concludes, "Don't rely on security through obscurity." OEMs and BIOS vendors are sometimes guilty of assuming that BIOS code is so obscure that no one will bother. But in an era where the data on the computer is so much more valuable than the cost of disassembling (or purchasing!) the code, that is no longer a safe assumption. 

The Oft-Rumored Death of UEFI's CSM Prophesied Again by Intel

Sometimes I feel like discussions about the death of the CSM (and thus legacy OS support in BIOS) to be somewhat akin to prophesying the return of Christ.  This has been the promise of UEFI since it was just a gleam in Intel's Itanium eye. Now Intel has publicly stated that they will not provide the related silicon pieces needed for delivering CSM in BIOS, starting with platforms that ship in 2020. The CSM (Compatibility Support Module) is the portion of the UEFI BIOS that delivers support for older operating systems, including DOS  and (surprisingly), Windows 7. The 16-bit x86 assembly looks sort of like someone took a 90's era BIOS, gutted it and attached the limbs to the UEFI torso.

[1]

For those of you keeping track, that would be two chipset generations from the current Cannon Lake/Coffee Lake generation. This would include legacy option ROMs for devices like video, NIC, RAID and ME as well as various testing and manufacturing tools that run under DOS (which relies on the CSM).

Windows 7 is a big sticking point, since was the last version (before Windows 10) adopted by many companies as their standard install version. But DOS is a hidden requirement that few people know or talk about, because they don't use DOS, but the manufacturers do, when they are building, testing and shipping the box.  

Why DOS? First, it is a low-overhead environment, putting few barriers between a testing or diagnostic application and the hardware. Second, it is free, in its FreeDOS incarnation. Third, because they have years of experience using it, with scripts, test tools and processes all built around it. Changes in this area introduces risk on the manufacturing line, and computer makers are risk-averse.

Intel would like to replace DOS with the UEFI Shell. It has many of the same intrinsic features (free, low hardware requirements). My feeling is that the UEFI shell is a great idea, but a lot of recent effort has ignored improving the built-in shell commands in favor of trying to support Python (see, AppPkg's Python port or more recent efforts to support MicroPython). Python is great, but I think that a little more work to port some command-prompt standards like printf and diskpart or ?.

What will it mean for BIOS manufacturers if the CSM and support for legacy OSes is removed? Certainly the fact that we don't have to test and validate tons of older, out-of-support OSes. Also, there is a lot of code for handling the "dual-boot" options that appear in setup. That is, we permit the user to choose legacy boot, UEFI boot, or auto-detect.  This adds a lot of complexity throughout the boot code.  Get rid of that and we can simplify. The other big area is hardware support. Even as new hardware standards, like USB-3 and NVMe have come along, support for these devices had to be added to the CSM, even though the CSM was never designed to support this. Oh, and we don't want to duplicate code, which has often caused code to be pushed into SMM so that it can be shared between legacy and UEFI OS. All of these to a simplification of the BIOS code and the effort required to validate it.

On the other hand, BIOS has always been the last bastion of compatibility with older standards. As I've often said, BIOS is where industry standards go to die...and then they stink. Anyone remember EISA, QEMM (not QEMU!) and using Flight Simulator as a BIOS test? The CSM was one of the pieces of firmware that was hard to reproduce in BIOS-something that forced people to talk to us, because there are few software companies with the necessary 30 year histories to remember why we did certain things. What will we do now?

That is the question, isn't it? What will we do now? Dang, now that we don't need to do CSM, we actually have time to do some more innovation! So, go on, let it die.

[1] "Last Mile" Barriers to Removing Legacy BIOS Fall 2017 UEFI Plugfest (October 2017), Brian Richardson (Intel Corporation) retrieved from http://www.uefi.org/sites/default/files/resources/Brian_Richardson_Intel_Final.pdf on 4/21/2018.

Spring 2018 UEFI Plugfest Presentations Now Available

Head here to get the latest UEFI plugfest presentations on a variety of topics, although security dominates the topic list, with top notch presentations by Insyde, Intel (and here), ARM, Phoenix and Microsoft. The presentation by Microsoft is a redacted version of what was presented live because it contained details about unreleased versions of the Windows operating systems.

After security, it was programming languages, with presentations by Intel for ACPI Source Language (ASL) and MicroPython. 

My presentation focused on adapting Microsoft's Security Development Lifecycle to UEFI and firmware, based on our ongoing experience at Insyde. Conversations afterward showed a great level of interest in introducing these processes into an industry that has traditionally not worried about this level of discipline in security.

Rounding out the topic list was the state of UEFI (the illustrious Mark Doran, Intel), SMBIOS and ACPI table construction (ARM), EDK2 platforms (Linaro), UEFI capsule update (Microsoft), and NVMe (AMI).

Repository for the Misc. UEFI Code Posted Here

Just as a reminder, all of the code that's been posted here over time is checked in over at SourceForge here. No guarantees.

UEFI Notes: CS2AI, UEFI Plugfest and the Zimmer Anniversary Post

After some gentle ribbing from colleagues at the UEFI plug-fest in Bellevue, WA, I've decided to try to keep track of recent trends in UEFI here again.

My collaborator on the UEFI shell book, Vincent Zimmer has posted some thoughts on open source and open platforms in his anniversary blog post here. He has a long history within the UEFI community and is currently working to lower the barrier of entry to server firmware design. And for the record, it is U-E-F-I (not YOO-FI or micro-EFI) and A-C-P-I (not AK-PIE). On a side note about competing acronym pronunciations, in the early days of the EISA (Extended ISA) bus architecture, it was pointed out that while English speakers naturally pronounced EISA as EEE-SA and ISA as AY-SA, other European languages had would naturally pronounce it exactly opposite (EISA as AY-SA and ISA as EE-SA).

Meanwhile, on the firmware security front, some focused industry organizations are doing a great job of bring the reality of these issues to professionals and college students. For example, CS2AI (with more than 15 chapters worldwide) zeroes in on control systems and how they present unique challenges for security, as well as the recent impacts of the Meltdown and Spectre with excellent Q&A afterwards.

The UEFI plugfest in Seattle this past week brought a host of security related presentations. I presented on "UEFI and the Security Development Lifecycle". Many of the same process disciplines are becoming a requirement in the BIOS world because of the attention BIOS security is now getting from hackers, academics and professionals. This is also raising interesting business issues for a low-margin industry that has traditionally assumed its obscurity made it a low-priority target.

Intel's CHIPSEC team had a great presentation on how their threat models have now expanded to include attackers who have physical access to the hardware. There was a lot of other good stuff, which I'll talk about when the presentations become publicly available.

So What Does Security In IoT With UEFI Really Look Like?

As usual, security continues to dominate the news about UEFI. DEFCON had several presentations related to firmware security. There is a good overview of the hardware and firmware attacks discussed over at Dark Reading. This included one by my friend Vincent Zimmer and his colleagues at Intel analyzing over 90 reported firmware vulnerabilities over the past 3 years. He discusses his experience on his blog. Another, by security researcher Alex Matrosov described exploits and called out specific computer models. Then there was some stuff on using CHIPSEC to detect improperly configured chipsets.

As often as I deal with security issues in firmware, I am still ignorant of how the types of exploits that are available and the tools that are used by cyber-security professionals. There are always new kits coming out, with new features. But where do you get them and how do you use them safely without making you and your computer system a target-rich environment? Recently the CS2AI of Sacramento hosted two lectures. The first lecture focused on giving the nuts and bolts (step-by-step) of setting up your own environment, including virtual machines, TOR and Kali and even configuring a cheap Raspberry Pi as an analysis tool. The second lecture focused on the tools available under Kali, such as password hash crackers (with an up-close hack that used it), Sparta and Wireshark for network analysis and then an introduction to using Tor to venture onto the dark net with Tor. Why the dark net? So that you can see how much it costs to buy a hack of your company or a company that you care about!

Next month will be wireless attacks and the tools that sniff out vulnerabilities. Good stuff.

Security today has a lifespan-in hours, or maybe in months or years. My firmware job is to keep your system secure for the duration of one boot.

UEFI Releases New Specifications and Adds ARM to the Board

For anyone who has been working on the UEFI specification, for the past few years, it should be no surprise to hear that UEFI has decided to welcome ARM onto the board of directors. This shows the growth of interest in firmware standards by the non-x86 world and also recognizes ARM's outstanding level of effort to improving the specifications. Dong Wei, who was the vice president of UEFI while at HP, now returns to the same role but now from ARM, where he is the senior director platform architecture. This seems like a smart move on both sides.

This announcement came on the heels of the release of a spate of new spec and test tool revisions. There are a whole bunch of goodies in here, from wifi and BlueTooth to new SMM (now called MM) models (including TrustZone!).

• UEFI Spec v2.7  - http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf 
• PI v1.6 - http://www.uefi.org/sites/default/files/resources/PI_Spec_1_6.pdf 
• ACPI v6.2 - http://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf 
• SCT v2.5A - http://www.uefi.org/testtools

There are rumblings about another UEFI plugfest in the works. More on what's changes in the specs and other industry happenings later.