OpenPOWER port comments, and EFI creation story

A few weeks ago, I noticed a new Github project where someone at IBM had ported UEFI to OpenPOWER. Later that day, someone *ELSE* at IBM had *ALSO* ported UEFI to OpenPOWER — two ports! And they found out about each other because of my blog, too funny! Anyway, they’re actively conversing on the Comments thread on the blog:

Tianocore for OpenPOWER

In addition to OpenPOWER issues, the Comments section has MULTIPLE people posting comments, which is a first for this blog! There’s some good background on history of EFI, including a pointer to 2005-era message that includes the ‘creation saga’ of EFI! In the past, Apple used OpenFirmware on PowerPC-based Macs, and PC vendors used BIOS on x86-based PCs. When Windows NT started support for non-x86 systems, ARC was used for the RISC vendors. Then Intel Itanium needed a solution. They nearly used ARC or OpenFirmware, before going down the route for EFI for Itanium, which later grew into UEFI and is now on Apple and PC systems as well. Here’s an excerpt with Andrew Fish talking about how EFI was created:

“At that time, two firmware solutions were put on the table as
replacements for BIOS architectures for the Itanium: Alpha Reference
Console (ARC) and Open Firmware. It turned out that nobody really
owned the inellectual property to ARC, and in any case, it did not
have enough extensible properties to make it practical for a
horizontal industry. At this point, Open Firmware became the
frontrunner as Apple and Sun both used it. However, Open Firmware was
not without its own technical challenges. The PC had started down a
path of using the Advanced Configuration and Power Interface (ACPI) as
its runtime namespace to describe the platform to the operating
system. As I liked to say at the time, the only thing worse than one
namespace is keeping two namespaces in sync. The other problem was the
lack of third party support for Open Firmware. We invited the
FirmWorks guys to come visit us at Dupont (WA), and we had a great
talk. Given we had just gone through an exercise of inventing a
firmware base from scratch, I think we were uniquely qualified to
appreciate what Open Firmware had been able to achieve. Unfortunately,
it became clear that the infrastructure to support a transition to
Open Firmware did not exist. Given the namespace issue with Open
Firmware and the lack of industry enabling infrastructure, we decided
to go on and make EFI a reality.”

Full post:

http://beowulf.org/pipermail/beowulf/2009-November/026956.html

I thought ARC stood for “Advanced RISC Consortium”, but I can’t argue with Andrew, maybe it originally stood for “Alpha Reference Console”.  (During these years, I was doing “ring0′ work, not firmware, and my favorite box at the time was a DEC Alpha AXP with ARC-based firmware.) ARC is very similar to early EFI: a single firmware image with a FAT partition where additional firmware images are stored, using ‘variables’ to specify the boot loader to invoke. ARC died off, like all the RISC-based Windows NT platforms, a shame, IMO. The ARC spec is still archived by the NetBSD project, who still supports ARC:

https://www.netbsd.org/docs/Hardware/Machines/ARC/

I wonder how life would be today if Intel would have chosen ARC or OpenFirmware?

UEFI 2.5 Platform Recovery feature appearing in Tianocore

Ruiyu Ni of Intel has posted an 12-part patch addding UEFI 2.5’s Platform Recovery feature to the public Tianocore EDK2 trunk.

Amongst the features of UEFI 2.5, the last public release of UEFI from the UEFI Forum, was #1227 “UEFI.Next feature – Platform recovery“. Load up the multi-thousand page UEFI 2.5 specification, with a PDF viewer with good search abilities, to find all the locations in the spec which Platform Recovery impacts. A good place to start would be around page 119, the OsRecovery#### and PlatformRecovery#### variables that’re new to UEFI 2.5.

Given that the patch includes a question from Intel asked HP:  “Could you please check my patch to see whether it can meet your real requirement?“, it appears that HP already has an existing implementation of this, perhaps already publicly available, probably separate from the Tianocore implementation, like they did with HTTP Boot. I’m not sure of other vendors with existing UEFI 2.5 Platform Recovery support.

Given UEFI capsule updates can add new features, your next firmware update may include this feature; is your organization ready to deal with UEFI 2.5 Platform Recovery support appearing in the near future? I’m not ready. I don’t understand what this feature really means, in terms of system impact. Earlier (not in this patch), there was a LOT of new code dealing with recovery in drivers. I don’t now know how to test this feature yet in Tianocore. Are there any new tools involved with this feature, for sysadmins to use? How do I test if this feature is working in a specific driver, or in the entire system? Where are some test scripts that exercise the feature? If someone has any more pointers to using this new feature, please add a Comment to this post (see left), thanks!

Subject: [Patch 00/11] Add Platform Recovery support

OS Recovery will be added later.

Ruiyu Ni (11):
  MdePkg: Add Platform Recovery definitions.
  MdeModulePkg: Add Bm prefix for internal functions
  MdeModulePkg: Use BmCharToUint in BmIsKeyOptionVariable
  MdeModulePkg: Use BM_OPTION_NAME_LEN instead of sizeof L”Boot####”
  MdeModulePkg: Use BmForEachVariable to collect all key options
  MdeModulePkg: Support to expand File device path
  MdeModulePkg: Add Platform recovery support
  MdeModulePkg: Add missing PrintLib to BdsDxe.inf
  MdeModulePkg: Use UefiSpec.h defined macro to replace L”xxx” string
  MdeModulePkg: Add PlatformRecovery#### pointing to default file path
  MdeModulePkg: Enable PlatformRecovery in BdsDxe driver

 MdeModulePkg/Include/Library/UefiBootManagerLib.h  |   1 +
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c   |  76 ++++
 MdeModulePkg/Library/UefiBootManagerLib/BmHotkey.c | 181 +++++—-
 …/Library/UefiBootManagerLib/BmLoadOption.c      | 155 +++++–
 MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c   |  26 ++
 …/Library/UefiBootManagerLib/InternalBm.h        |  30 +-
 …/UefiBootManagerLib/UefiBootManagerLib.inf      |   1 +
 MdeModulePkg/Universal/BdsDxe/Bds.h                |   3 –
 MdeModulePkg/Universal/BdsDxe/BdsDxe.inf           |   1 +
 MdeModulePkg/Universal/BdsDxe/BdsEntry.c           | 447 ++++++—————
 MdePkg/Include/Uefi/UefiSpec.h                     |   1 +
 11 files changed, 474 insertions(+), 448 deletions(-)

More Information:
https://lists.01.org/mailman/listinfo/edk2-devel

tlsfuzzer announced

Hubert Kario of Red Hat announced a new tool on the OSS-security list today. The tool, ‘tlsfuzzer’, is for reproducing, testing and (in the future) automatically finding issues in TLS implementations.

I’m looking forward to seeing if this can help test Tianocore’s HTTPS support, when TLS is added. 🙂

Click to access ruxcon2015-kario-slides.pdf

https://github.com/tomato42/tlsfuzzer

For more information, see the full post on the OSS-security list.

ExtremeGTX’s Win32 UEFI Library

ExtremeGTX has created a new ‘hello world’ sample for UEFI developers on github. It is currently is centered around boot manager features. If you are new to UEFI application development, and want to learn how to do Windows-centric ‘OS-present’ code to talk to UEFI, this is another sample you may want to look at. It is new, so perhaps give the author some more time to add more to the library.

ExtemeGTX: If you are reading this, please consider upgrading to a newer version of Microsoft Visual C++, I think you’re still using something from a pre-Y2K era, which generates ugly template code, not to mention decades of bugs and newer features to help you write better code, the whole point of an IDE. And fewer conversion pain for others that try to compile your code with a copy of Visual Studio 201x. Thank you!

https://github.com/ExtremeGTX/Win32-UEFILibrary

coreboot 4.2 released

Patrick Georgi posted the announcement of coreboot 4.2 to the coreboot blog today. Below is excerpt of announcement, see blog post for full details:

“Halloween 2015 release – just as scary as that sounds”

Since 4.1, 936 commits by 90 authors, increasing the code base by approximately 17000 lines of code, 35 new contributors, more than 34 active developers. […] There was some limited testing to make sure that the code is usable, and it boots on some devices. A structured test plan will only become part of the release procedure of future versions. […]  This is also the first release that will be followed by the removal of old, unused code. There will be a policy on how to announce deprecation and removal of mainboard and chipset code for future releases. Changes since 4.1:

Build system:
– Store a minimized coreboot config file in cbfs instead of the full config
– Store the payload config and revision in CBFS when that info is available
– Add -compression option for cbfs-files-y. Valid entries are now -file, -type, -align, and -compression
– Change Microcode inclusion method from building .h files to pre-built binaries
– Update Builder tests for each commit to test utilities and run lint tools
– Many other small makefile and build changes and fixes
– Remove expert mode as a Kconfig option

Utilities:
– Many fixes and updates to many utilities (158 total commits)
– ifdtool: Update for skylake, handle region masks correctly
– crossgcc: Update to gcc 5.2.0
– kconfig: Add strict mode to fail on kconfig errors and warnings
– vgabios: Significant fixes to remove issues in linking into coreboot code
– Add script to parse MAINTAINERS file
– Add Kconfig lint tool
– Create a common library to share coreboot routines with utilities
– Significant changes and cleanup to cbfstool (81 commits). Major changes:
– Update cbfstool to change the internal location of FSP binaries when adding them
– Decompress stage files on extraction and turn them into ELF binaries
– Header sizes are now variable, containing extended attributes
– Add compression tags to all cbfs headers so all cbfs files can be compressed
– Add and align CBFS components in one pass instead of two
– Add XIP support for X86 to relocate the romstage when it’s added
– Removed locate command as it’s no longer needed
– Add bootblock and cbfs_header file types so the master header knows about them
– Prefer FMAP data to CBFS master header if FMAP data exists
– Add hashes to cbfs file metadata for verification of images

Payloads:
– SeaBIOS: update stable release from 1.7.5 to 1.8.2
– Libpayload had some significant changes (61 commits). Major changes:
– Add support for fmap tables
– Add support for SuperSpeed (3.0) USB hubs
– Updates and bugfixes for DesignWare OTG controller (DWC2)
– Add video_printf to print text with specified foreground and background colors
– Updates to match changes to cbfs/cbfstool
– Add cbgfx, a library to show graphics and text on a display
– Read cbfs offset and size from sysinfo when available

Vendorcode:
– fsp_baytrail: Support Baytrail FSP Gold 4 release
– AMD binary PI: add support for fan control
– Work to get AMD AGESA to compile correctly as 64-bit code
– Add standalone (XIP) verstage support for x86 to verify romstage

Mainboards:
– New Mainboards:
– apple/macbookair4_2 – Sandy/Ivy Bridge with Panther / Cougar point chipset
– asus/kgpe-d16 – AMD Family 10, SB700/SR5650 platform
– emulation/spike-riscv – RISCV virtualized platform
– google/chell – Intel Skylake chrome platform
– google/cyan – Intel Braswell chrome platform
– google/glados – Intel Skylake chrome platform
– google/lars – Intel Skylake chrome platform
– intel/kunimitsu – Intel Skylake chrome platform
– intel/sklrvp – Intel Skylake reference platform
– intel/strago – Intel Braswell chrome platform
– Cleanups of many mainboards – several patches each for:
– amd/bettong
– getac/p470
– google/auron, google/smaug and google/veyron_rialto
– pcengines/apu1
– siemens/mc_tcu3
– Combine the google/veyron_(jerry, mighty, minnie, pinkie, shark and speedy) mainboards into the single google/veyron mainboard directory

Console:
– Add EM100 ‘hyper term’ spi console support in ramstage and smm
– Add console support for verstage

ARM:
– armv7: use asm coded memory operations for 32/16 bit read/write
– Many cleanups to the nvidia tegra chips (40 patches)

RISC-V:
– Add trap handling
– Add virtual Memory setup

X86:
– Remove and re-add Rangeley and Ivy Bridge / panther point FSP platforms
– Update microcode update parser to use stock AMD microcode blobs from CBFS
– ACPI: Align FACS to 64 byte boundary. Fixes FWTS error
– AMD/SB700: Init devices in early boot, restore power state after power failure. Add IDE/SATA asl code
– Add initial support for AMD Socket G34 processors
– Add tick frequency to timestamp table to calculate boot times more accurately
– Unify X86 romstage / ramstage linking to match other platforms
– Start preparing X86 bootblock for non-memory-mapped BIOS media
– cpu/amd/car: Add Suspend to RAM (S3) support
– Native VGA init fixes on several platforms
– Significant updates to FSP 1.1 code for cleanup and cbfstool changes
– SMMhandler: on i945..nehalem, crash if LAPIC overlaps with ASEG to prevent the memory sinkhole smm hack
Drivers:
– Add native text mode support for the Aspeed AST2050
– w83795: Add support for for fan control and voltage monitoring
– Intel GMA ACPI consolidation and improvements
– Set up the 8254 timer before running option ROMs
– Resource allocator: Page align memory mapped PCI resources

Lib:
– Derive fmap name from offset/size
– Several edid fixes
– Updates to cbfs matching changes in cbfstool

Submodules:

3rdparty/blobs:
– AMD Merlin Falcon: Update to CarrizoPI 1.1.0.0 (Binary PI 1.4)
– AMD Steppe Eagle: Update to MullinsPI 1.0.0.A (Binary PI 1.1)
– Update microcode to binary blobs. Remove old .h microcode files

3rdparty/vboot:
– Update the code to determine the write protect line gpio value
– Several updates to futility and image_signing scripts
– Update crossystem to accommodate Android mosys location
– Support reboot requested by secdata
– Add NV flag to default boot legacy OS

More information:

Announcing coreboot 4.2


http://www.coreboot.org/releases/

Android IoT: Google Brillo and Weave

Google has began an invite program for their Brillo/Weave IoT project, which they announced earlier this year at Google I/O:

Brillo:

“Since May, we’ve opened up the Brillo operating system (OS) and Weave communication platform to early access partners. Today, we’re extending this to the broader developer community as part of our invite program. Read on to find out how you can receive an invitation. Brillo brings the simplicity and speed of software development to hardware by offering you a lightweight embedded OS based on Android, core services, a developer kit, and a developer console. You can choose from a variety of hardware capabilities and customization options, quickly move from prototype to production, and manage at scale with over the air (OTA) updates, metrics, and crash reporting.”

Weave:

“Once you’ve built your connected device, you’ll need to find a way for it to communicate with other devices and allow users to interact with it. That’s where Weave comes in. With Weave, you can build interoperable communications directly into your devices. Weave provides a messaging service that enables phones and devices to talk to each other locally and remotely through the cloud. The Weave cloud server handles remote communication and access to your web-connected device, safely and at scale. With Weave you also get a set of services to securely set up the device and provide controlled access. Additionally, Weave works seamlessly with, and is actually built right into, Brillo; but, you can also use Weave libraries with your existing Linux-based OS.”

Intel already has their Edison board ready for Brillo:

http://newsroom.intel.com/community/intel_newsroom/blog/2015/10/27/intel-edison-module-offers-brillo-support-at-launch
https://software.intel.com/en-us/blogs/2015/10/27/intel-edison-board-and-brillo

“The Intel Edison compute module is one of the first platforms to support Brillo, which Google released source code for today via an invitation program. Newegg will be offering a Brillo-compliant solution built upon the Intel Edison kit for Arduino. Intel expects to support Brillo on additional SoCs (system-on-chip) and IoT maker boards in the future.”

More Information:

http://www.forbes.com/sites/janakirammsv/2015/10/29/google-brillo-vs-apple-homekit-the-battleground-shifts-to-iot/
http://liliputing.com/2015/10/google-launches-android-based-brillo-os-for-internet-of-things.html
http://www.androidauthority.com/imaginations-new-ci40-creator-iot-board-will-run-brillo-from-google-651920/

Android-based "Brillo" IoT OS arrives with hacker SBC support

Google invites developers to its Brillo IoT platform

IoT cancelled, film at 11

It seems that when I read the main news sites these days looking for IoT stories, half of them are asking for the IoT to stop. Or there is yet-another cloud/IoT security group creating another standard that nobody seems to be reading.

http://www.engadget.com/2015/10/29/the-coming-smart-thing-apocalypse/

http://arstechnica.com/unite/2015/10/fight-the-future-ars-readers-say-no-to-the-internet-of-things/

https://twitter.com/internetofshit/

Microsoft publishes PDF file format

Microsoft executables have a format for symbols that has not been publicly documented, it was kept close to the C/C++ compiler team.

https://github.com/Microsoft/microsoft-pdb

Microsoft symbols can be included inside the image, or a separate “sidecar” file. This spec will help tool developers understand the symbols of the code. Microsoft does not ship symbols to all of it’s code, much are stripped before shipping them. Once LLVM clang or GCC supports proper Windows symbols, those compilers can finally become “first-class citizens” on the Windows platform, where the Windows system debugger will recognize their symbols, and the outdated C89-centric Microsoft C will not longer be needed to do Windows development!  It also means reverse-engeering tools now have the potential to find more information about Windows apps/drivers, if they haven’t already reversed the format earlier.

UEFI uses the Microsoft executable tools, up until the last second, when PE images are converted to TE images, Terse Executables are a slight variation to PE images, more suited for firmware. I am not sure how this new symbol spec will impact UEFI, if at all.

Rapi7 restores Metaspoit to Kali

An update to this older post:

Kali 2.0 ships …without Metasploit

Metasploit is back in Kali!

https://community.rapid7.com/community/metasploit/blog/2015/10/20/kali-2-new-operating-systems-support

Great news, thanks Rapid7!

Now if you could just rewrite it in Python. 🙂

 

Subgraph creates Secure Desktops list

Subgraph has created a new mailing list for Secure Desktop discussions.

Excerpt from initial post:

This forum is the product of a meeting between Subgraph, Qubes OS and Tails, in which it was agreed that we need a place for ongoing discussion of ideas and collaboration in our efforts towards the common goal of building secure open source desktop computing environments. We therefore invite participation from any developers and contributors for these and related projects, including applications, as well as anyone else interested.

https://secure-os.org/pipermail/desktops/2015-October/000000.html

In case you have only looked at TAILS or Qubes, Subgraph OS is  a VERY interesting OS design:

https://subgraph.com/

https://subgraph.com/sgos/index.en.html

Ben Layer’s Router Firmware Exploit Kit

https://twitter.com/benlayer/status/659723800624414720

Better Late Than Never – A Router Exploit Kit
Ben Layer @benlayer

Presenting RouterRux, a proof of concept router exploit kit which flashes custom malicious firmware on home routers. In this talk we follow the journey of creating a new attack vector, and the problems along the way. Including bits and pieces such as metasploit, web application security, procrastination, and the internet of things.

There are demo videos and slides on the DC4420 site, and Ruby source and slides on the Github site.

https://github.com/tdzmont/routerrux

https://dc4420.org/2015/10/27/

CrowdStrike on building secure burner laptops

Morgan Marquis-Boire posted a pointer to this advise from CrowdStrike on how to build a ‘burner laptop’, for hostile environments. The Arch Linux-based system uses a very interesting configuration, such as embedding GRUB onto the SPI FLash, for the root of trust.

Excerpt from introduction of readme:

A Reasonably Secure Travel Laptop Setup

This repository contains auxiliary scripts and configurations around building a reasonably secure travel laptop using coreboot with a GRUB2 payload. The scripts and configurations have been tested with an ArchLinux setup but should be adaptable to other distributions easily. A reasonably secure travel laptop following the approach laid out here will boot only a signed kernel and initrd and assure user-space integrity with a dm-verity protected root filesystem. If you require confidentiality, it is additionally recommended encrypted the entire filesystem or use a separate, encrypted /home partition. Building coreboot and GRUB2 for your target laptop and flashing the appropriate image is out of the scope of this repository’s contents and documentation. You can find more information on the coreboot Wiki.

[…]

Full article:
https://github.com/CrowdStrike/travel-laptop