New HardenedBSD release

A new release of HardenedBSD is available: v28 version of 10-STABLE as well as 11-CURRENT.

HardenedBSD is a security-enhanced fork of FreeBSD, created in 2014 by Oliver Pinter and Shawn Webb. HardenedBSD aims to implement innovative exploit mitigation and security solutions for FreeBSD. The project works with upstream FreeBSD and any other FreeBSD-based project to include any security improvements. NanoBSD is the embedded subset of FreeBSD. FreeBSD — at least the last time I checked — was the only BSD distro that supports UEFI. Recently, HardenedBSD 11-CURRENT was released:
https://hardenedbsd.org/article/oliver-pinter/2015-07-24/hardenedbsd-11-current-amd64-x86-64-installers
https://github.com/HardenedBSD/hardenedBSD

The AArch64 port of FreeBSD has been progressing well. I’ve not built HardenedBSD for AArch64 myself yet, but it appears that someone can, there’s a VM version at least:
https://twitter.com/lattera/status/628701851286962177

Genode OS v15.05

Found on Joanna’s Twitter feed:
https://twitter.com/rootkovska/status/629256162706329601

Genode is new to me. Genode Labs makes the “Genode OS Framework”. Genode is a new OS, not a new Linux distribution. It is “a GPLv2-licensed construction kit for building specialized operating systems out of small building blocks including different kernels, device drivers, protocol stacks, and applications”. This current release is a major release for Genode. The new documentation is a large 472 page PDF. The current release adds “rudimentary GPT” support. GPT aside, I don’t see any other UEFI-related technology support, only “BIOS” references to firmware.

Version 15.05 represents the most substantial release in the history of Genode. It is packed with profound architectural improvements, new device drivers, the extension of the supported base platforms, and a brand new documentation.

We understand the complexity of code and policy as the most fundamental security problem shared by modern general-purpose operating systems. Because of high functional demands and dynamic workloads, however, this complexity cannot be avoided. But it can be organized. Genode is a novel OS architecture that is able to master complexity by applying a strict organizational structure to all software components including device drivers, system services, and applications.”

“The current implementation can be compiled for 8 different kernels: Linux, L4ka::Pistachio, L4/Fiasco, OKL4, NOVA, Fiasco.OC, Codezero, and a custom kernel for running Genode directly on ARM-based hardware. Whereas the Linux version serves us as development vehicle and enables us to rapidly develop the generic parts of the system, the actual target platforms of the framework are microkernels. There is no ‘perfect’ microkernel – and neither should there be one. If a microkernel pretended to be fit for all use cases, it wouldn’t be ‘micro’. Hence, all microkernels differ in terms of their respective features, complexity, and supported hardware architectures.

Genode allows the use of each of the kernels listed above with a rich set of device drivers, protocol stacks, libraries, and applications in a uniform way. For developers, the framework provides an easy way to target multiple different kernels instead of tying the development to a particular kernel technology. For kernel developers, Genode contributes advanced workloads, stress-testing their kernel, and enabling a variety of application use cases that would not be possible otherwise. For users and system integrators, it enables the choice of the kernel that fits best with the requirements at hand for the particular usage scenario.

Inverse Path’s USB Armoury supports Genode as of 15.02:  “The Genode OS Framework supports the USB armory since version 15.02 implementing a TrustZone Secure virtual-machine monitor (VMM) supervising Linux running in the Normal world. Support is in the very early stages. The Linux kernel requires minimal patching to be executed in the Normal world, at the moment Martin Stein from Genode Labs provides a repository with a patched kernel.

http://genode.org/documentation/release-notes/15.05
https://github.com/genodelabs/genode
http://sourceforge.net/projects/genode/files/

TrustZone TEE vulnerability for Huawei Mate 7

Found on @ABazhaniuk’s Twitter feed:

https://twitter.com/_jsoo_/status/627436330918658048

Security Advisory – Two Privilege Escalation Vulnerabilities in Huawei Mate 7 Smartphones

The tzdriver module of Huawei Mate 7 smartphone has an input check error, which allows the user-mode application to modify kernel-mode memory data and maybe make system break down or application elevate privilege. (Vulnerability ID: HWPSIRT-2015-03011) These Vulnerabilities have been assigned Common Vulnerabilities and Exposures (CVE) ID: CVE-2015-4421. The TEEOS module of Huawei Mate 7 smartphone which is used to realize the function of fingerprint identification has an input check error, which enables the attackers with the root permission to modify kernel-mode memory data of TEEOS module, which could make system break down, TEEOS be tampered or malicious code execution. (Vulnerability ID: HWPSIRT-2015-03012) These Vulnerabilities have been assigned Common Vulnerabilities and Exposures (CVE) ID: CVE-2015-4422.

HWPSIRT-2015-03011: Attackers can write data into an invalid address to crash the system or elevate their privileges through elaborate applications.

HWPSIRT-2015-03012: After privilege escalation, attackers can craft malicious applications to crash the TEEOS or execute arbitrary code on the TEEOS.

Temporary Fix: None

See the Huawei Security Advisory for full details:

http://www.huawei.com/en/security/psirt/security-bulletins/security-advisories/hw-432799.htm

There’s also a Github sample:

“With two vulnerabilities,any installed application is able to execute arbitrary code in TEE of Huawei Mate7 . This source code is a PoC which may read fingerprint image from sensor(FPC1020) on Mate 7.”

https://github.com/retme7/mate7_TZ_exploit

ARM acquires Sansa Security for IoT security

Yesterday ARM Ltd announced acquisition of Sansa Security, the acquisition will offer hardware and software-based security features, boosting protection for sensitive data and content on any connected device. Press release:

ARM has acquired Israel-based Sansa Security, a provider of hardware security IP and software for advanced system-on-chip components deployed in IoT and mobile devices. The company currently enables security in more than 150 million products a year and Sansa Security technology is deployed across a range of smart connected devices and enterprise systems. The deal complements the ARM security portfolio, including ARM(R) TrustZone(R) technology and SecurCore(R) processor IP. Terms have not been disclosed.

“Any connected device could be a target for a malicious attack so we must embed security at every potential attack point,” said Mike Muller, CTO, ARM. “Protection against hackers works best when it is multi-layered, so we are extending our security technology capability into hardware subsystems and trusted software. This means our partners will be able to license a comprehensive security suite from a single source.”

Sansa Security technology makes it easier for manufacturers to build secure products by offering a complete hardware subsystem that adds additional isolation of security operations from the main application processor. This is complemented by software components operating on top of trusted execution environments to perform security-sensitive operations. The acquisition builds upon ARM’s embedded TrustZone technology, creating extra protection against malware and malicious software. It is a system-wide approach that underpins security-related chipset and trusted software needs. This enables the protection of any connected device and management of sensitive data and content.

“Our technology is already being used to protect data gathered and transmitted by a multitude of IoT and mobile devices,” said Coby Sella, CEO, Sansa Security. “Joining ARM will enable us to scale the business by helping ARM’s global technology partners to address their most pressing security needs. Aligning what we do with the world’s leading IP company, allows us to develop our products and capability to new levels.”

Security forms one of the main pillars of ARM’s business. The company offers the world’s most comprehensive IP security portfolio for smart connected devices. The acquisition of Sansa Security is the latest in a series of acquisitions and product launches aimed at simplifying the development and deployment of secure connected devices. Other activity in the development of ARM’s IoT business during the last 12 months includes:

    June 1, 2015: Launched a IoT sub-system IP package to de-risk the design cycle for IoT chips
    April 16, 2015: Launched ARM Cordio(R), the IT industry’s first sub-one-volt self-contained radio block and related firmware to simplify radio deployment in IoT devices
    Feb. 24, 2015: Launch the ARM mbed(TM) IoT starter kit to simplify the process of adding IoT capabilities and secure cloud connectivity for device manufacturers
    Feb. 9, 2015: Announced the acquisition of Offspark to integrate the world’s most pervasive embedded Transport Layer Security (TLS) solution in to the ARM mbed portfolio
    Oct. 1, 2014: Launched ARM mbed, a new software platform and free operating system to simplify and speed up the creation and deployment of Internet of Things (IoT) products.

Sansa Security is a world-leading provider of system-wide security operating from the silicon chipset level to provisioning security in the enterprise cloud. Its technology enables the creation of secure devices through hardware security IP that complements ARM TrustZone. The company’s trusted software security IP, running in TrustZone-based Trusted Execution Environments, also protects code and data assets. Sansa Security’s IP will be integrated in to ARM’s TrustZone and IoT portfolios.

More Information:
https://www.sansasecurity.com/

http://www.arm.com/about/newsroom/arm-expands-iot-security-capability-with-acquisition-of-sansa-security.php?utm_content=sf39691877&utm_medium=spredfast&utm_source=twitter&utm_campaign=ARM+Social+Media&sf39691877=1

Joe Fitzpatrick joins Xipiter

I didn’t know about this company until today. It looks like Joe Fitzpatrick of SecuringHardware is or soon will be joining them:

https://twitter.com/XipiterSec/status/616275086652235776

It appears Xipiter does security training, including Intel- and ARM-based hardware-level courses, including at upcoming DEF CON. They appear to have an upcoming Android course in the works, related to the Wiley Android Hacker’s Handbook, which has a nice chapter on ARM firmware hacking. They have other services besides training, and some hardware products as well.

http://www.xipiter.com/
http://www.xipiter.com/team.html
http://www.xipiter.com/training.html

http://securinghardware.com/

‘Silicon autopsy’ tools for ARM

Earlier this week Eoin McCann posted a new article in the ARM Processors blog about ‘silicon autopsy’: dealing with silicon errors on ARM systems. Of course it’s a bit of a product pitch for ARM’s CoreSight and related products, but product pitch aside the blog give a good description of the various problems and tools available for those performing ARM-based silicon autopsies. ARM has a free Community Edition as well as an expensive Ultimate Edition of DS-5, ARM’s Eclipse-based Developer Studio IDE for firmware.

Excerpt:
Silicon autopsy: Understanding when chips fail: In a lot of ways debug is similar to being a medical doctor. A patient comes in with some complaints and lists their symptoms, but you need to run tests in order to properly diagnose the issue before focusing the mind on how to fix it. A lot has been written and discussed in the past about debugging hardware, but most of the attention is dedicated to the pre-silicon stage when issues can be identified close to the source and rectified before it is too late. These bugs are similar to performing an autopsy on a body, sifting through all of the potential clues to narrow down what has gone wrong, and how it can be rectified. Bugs that are found in the silicon itself are typically much more difficult to identify, and can drain an enormous amount of time and resources to fix properly. Today I will speak about silicon debug, the challenges associated with it and what can be done to improve it.

More Information:
http://ds.arm.com/
http://community.arm.com/groups/processors/blog/2015/07/20/silicon-autopsy-understanding-when-chips-fail

Linux distros (and FreeBSD): join the UEFI Forum

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.

More Information:

http://uefi.org/members
http://uefi.org/join
http://uefi.org/registry

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.

ARM’s EDK-II maintainer leaves ARM Ltd for Labapart.com

Today, Oliver Martin, the TianoCore EDK2 maintainer for the ARM packages for the last 4 years, is leaving ARM, this is his last week. Oliver didn’t give many details on his new project:

Unfortunately, it is still too early to share more details about my future product, so I created a quick website (and found a neutral name) last week-end to allow people to follow the adventure: http://labapart.com/ (can either be pronounced as “Lab apart” or “Lab à Part”).

Given his background with ARM and UEFI, I’ll be curious to see if this new product is at all related…

As I understand it, Leif Lindholm of ARM will take over as new EDK2 ARM role; he has been co-maintainer for the last few months, is experienced with open source, Linux, and has been working on UEFI for Linaro for the last few years.

More Information:
edk2-devel mailing list archives (Subject: Farewell – last days at ARM Ltd)
http://labapart.com/

coreboot 4.1 released

It has been 5 years since coreboot 4.0, so coreboot 4.1 is a big deal! Excerpting the coreboot blog:

“There have been as many significant original developments, such as support for many new architectures (ARM, ARM64, MIPS, RISC-V), and related architectural changes like access to non-memory mapped SPI flash, or better insight about the internals of coreboot at runtime through the cbmem console, timestamp collection, or code coverage support.”

In addition to new features, it appears coreboot will get on a more regular release cycle:

“Future releases will happen more frequently, and with more guarantees about the state of the release, like having a cool down phase where boards can be tested and so on. I plan to create a release every three months, so the changes between any two release don’t become too overwhelming. Starting with coreboot 4.1, we will maintain a high level changelog and ‘flag days’ document. The latter will provide a concise list of changes which went into coreboot that require chipset or mainboard code to change to keep it working with the latest upstream coreboot.”

I am looking forward to seeing how this release works with the UEFI CoreBootPkg…

More Information:

Announcing coreboot 4.1


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

LinuxCon North America this August in Seattle

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.

More information:
http://events.linuxfoundation.org/events/linuxcon-north-america
http://events.linuxfoundation.org/events/linuxcon-north-america/program/schedule

Replicant on mobile device security

The Replicant project is a Free Software-specific fork of Android, which focuses on users’ freedoms, and privacy/security. They try to get Android running without any firmware- or OS-level “blobs”, which gives them technical perspectives that most don’t have. They have a document which gives a decent introduction to mobile device security, including hardware, firmware, OS, and app issues, and about security issues of mobile baseband chips.. The advice is focused for someone using Replicant, but the app advice is applicable to most Android users.

More Information:

http://www.replicant.us/freedom-privacy-security-issues.php

ARM update on GCC and Clang compilers

A few days ago, the ARM Software Dev Tools blog posted their 2015Q2 update on their use of Open Source Toolchains. The post talks about ARM changes in GNU GCC as well as LLVM. It appears they’re getting ready to present at GNU Cauldron in August. Look at their blog for more information. They’ve got some YouTube video and presentation slides, as well.

One thing this blog post clarified to me was what codebase ARM’s C compiler was based on: LLVM Clang:

“The commercial toolchain we offer to our customers, ARM Compiler 6, is in fact based on open source clang.”

More Information:
http://community.arm.com/groups/tools/blog/2015/06/30/open-source-toolchains–arm-status-update-q2-2015

Rasberry Pi firmware revised to use Linux 4.0

As reported by Michael Larabel in Phoronix, the Raspberry Pi firmware has been changed, it now uses the Linux 4.0 kernel.

As Michael says, “For this low-cost ARM single board computers, the newer kernel is beneficial for new features, file-system improvements, and new device support like when it comes to USB peripherals and adapters.”

More information:
http://www.phoronix.com/scan.php?page=news_item&px=Raspberry-Pi-Linux-4.0
https://www.raspberrypi.org/forums/viewtopic.php?t=113753&p=778141

Spring Plugfest presentations uploaded

The PDFs of the presentations from last months’ UEFI Forum plugfest have been uploaded to uefi.org.

http://www.uefi.org/learning_center/presentationsandvideos
(scroll about half-way through the page, after the Youtube videos…)

* System Prep Applications – Powerful New Feature in UEFI 2.5 – Kevin Davis (Insyde Software)
* Filling UEFI/FW Gaps in the Cloud – Mallik Bulusu (Microsoft) and Vincent Zimmer (Intel)
* PreBoot Provisioning Solutions with UEFI – Zachary Bobroff (AMI)
* An Overview of ACPICA Userspace Tools – David Box (Intel)
* UEFI Firmware – Securing SMM – Dick Wilkins (Phoenix Technologies)
* Overview of Windows 10 Requirements for TPM, HVCI and SecureBoot – Gabe Stocco, Scott Anderson and Suhas Manangi (Microsoft)
* Porting a PCI Driver to ARM AArch64 Platforms – Olivier Martin (ARM)
* Firmware in the Data Center: Goodbye PXE and IPMI. Welcome HTTP Boot and Redfish! – Samer El-Haj-Mahmoud (Hewlett Packard)
* A Common Platforms Tree – Leif Lindholm (Linaro)

This’ll be a very short blog, as I’m busy reading 9 new PDFs… 🙂 I’ll do blogs on some these specific presentations in the coming days.

 

 

coreboot and Chrome OS upstreaming

I mainly work with UEFI technology, and don’t know much about coreboot, nor Chrome OS. I’m new to these tech, and learning them… 🙂

For a while, I thought coreboot was pretty inactive, but I now realize much of the coreboot activity has been taking place in Chrome OS. It appears that some of this work is now being upstreamed to the main coreboot.

From the coreboot blog:

“In the last months there was lots of activity in the coreboot repository due to upstreaming the work that was done in Chrome OS’ branch. We’re happy to announce that both code bases are again relatively close to each other. In the last 7 months, about 1500 commits that landed in coreboot originated in Chrome OS’ repository (of about 2600 total). Those came from 20 domains, which represent pretty much every part of the coreboot community: well known private and commercial coreboot contributors, but also BIOS and silicon developers as well as device manufacturers. Significant contributions that went into the tree recently were written with active support by Broadcom, Imagination Technologies, Intel, Marvell, Nvidia, Qualcomm, and RockChip.”

“In the future, Chrome OS will move over to a new branch point from upstream, and work on strategies to avoid diverging for two long years again. Instead, we’re looking for ways to keep the trees closer while also avoiding flooding the coreboot.org developer base with hundreds of patches. More on that as it is implemented.”

Some features that’ve been recently added include:
* new MIPS support
* improved ARM support, for SoCs by Broadcom, Marvell, Qualcomm, and RockChip
* an improved, safer method to declare the memory map on devices
* effort to get Chrome OS’ verified boot support
* update the flash image format to allow for safer incremental updates

This looks like great news for coreboot! I’ll have more blog entries about coreboot and Chrome OS in the near future.

More Information:

Report on Chrome OS upstreaming


http://coreboot.org/
http://www.chromium.org/chromium-os/2014-firmware-summit
https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot

Linux ACPI support for ARM-v8

Earlier this month, Linaro announced their effort to upstream the Linux patches to enable ACPI on ARMv8. It appears the patch may make it in Linux 4.1, but it is not done yet.

The Linaro blog post credits a large list of people who helped: UEFI Forums’ ACPI Working Group, Linaro, ARM, Red Hat, Huwaei, Qualcomm, AMD, AMD, APM, HP, other Linaro LEG members, and Linux kernel maintainers, including Linus.

As part of this effort, on March 26th, ARM hosted a Firmware Summit focused on ARMv8 and ACPI, with dozens attending, including SoC vendors, BIOS vendors, firmware and kernel developers, ODMs and OEMs.

The Linux kernel checking comment for this patchset includes this description:

‘This series introduces preliminary ACPI 5.1 support to the arm64 kernel using the “hardware reduced” profile. We don’t support any peripherals yet, so it’s fairly limited in scope:
– MEMORY init (UEFI)
– ACPI discovery (RSDP via UEFI)
– CPU init (FADT)
– GIC init (MADT)
– SMP boot (MADT + PSCI)
– ACPI Kconfig options (dependent on EXPERT)
ACPI for arm64 has been in development for a while now and hardware has been available that can boot with either FDT or ACPI tables. This has been made possible by both changes to the ACPI spec to cater for ARM-based machines (known as “hardware-reduced” in ACPI parlance) but also a Linaro-driven effort to get this supported on top of the Linux kernel. This pull request is the result of that work. These changes allow us to initialise the CPUs, interrupt controller, and timers via ACPI tables, with memory information and cmdline coming from EFI. We don’t support a hybrid ACPI/FDT scheme. Of course, there is still plenty of work to do (a serial console would be nice!) but I expect that to happen on a per-driver basis after this core series has been merged.’

Upon accepting the patch, Linus said:

‘No earth-shattering new features come to mind, even if initial support for ACPI on arm64 looks funny. Depending on what you care about, your notion of “big new feature” may differ from mine, of course. There’s a lot of work all over, and some of it might just make a big difference to your use cases.’

This *is* big new feature, if you care about firmware and Linux.
More Information:

https://www.linaro.org/blog/collaborative-effort-to-upstream-acpi/

ARM Trusted Firmware

Starting around 2013, ARM started to release “ARM Trusted Firmware” as a BSD-licensed Github-hosted open source project.  ARM Trusted Firmware is the trusted execution environment that runs behinds the scenes of the OS on AArch64 platforms. It works in conjunction with UEFI, including Secure Boot.

In upcoming blog posts, I’ll be writing some articles with more details about this project. For now, I’ll suggest reading their Firmware Design Guide and watching the below Youtube-hosted Linaro intro video.

More Information:

https://github.com/ARM-software/arm-trusted-firmware
https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/change-log.md
https://github.com/ARM-software/tf-issues/issues
https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/user-guide.md
https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/firmware-design.md
https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/porting-guide.md
https://lists.linaro.org/pipermail/boot-architecture/
https://lists.linaro.org/pipermail/linaro-uefi/

Spring UEFI Forum agenda announced

The UEFI Forum Spring event is happening in Tacoma.WA.US this coming week. They just announced the presentations for the event:

* Zachary Bobroff, AMI – PreBoot Provisioning solution with UEFI
* Kevin Davis, Insyde – System Prep Applications, A Powerful New Feature in UEFI 2.5
* Olivier Martin, ARM – Porting a PCI driver to ARM AArch64 platforms
* Lief Lindholm, ARM – Demonstrating a common EDK2 pltforms & drivers tree
* Dick Wilkins, Phoenix – UEFI FIrmware – Securing SMM
* Gabe Stocco and Scott Anderson, Microsoft – Windows Requirements for TPM, HVCI and Secure Boot
* Jeremiah Cox
* Vincent Zimmer, Intel – Filling UEFI/FW Gaps in the Cloud
* David Box, Intel – An overview of ACPICA userspace tools
* Samer El-Haj-Mahmoud, HP – Firmware in the Datacenter: Goodbye PXE and IPMI. Welcome Http

Typically, the UEFI Forum makes slides for these presentations available on their web site a few weeks later…

More information:
http://www.uefi.org/node/887

 

Linaro makes LUVos-live available for ARM64

LUVos (Linux UEFI Validation — aka luvOS or LUVos, is a Yocto-based Linux distro that helps diagnose UEFI firmware. LUV-live is a liveimage boot version of LUVos. LUV-live also includes other hardware/firmware tools, such as BITS, FWTS, and CHIPSEC.

Intel-based LUV was initially only targeting Intel platforms. But LUV is an open source project, with a healthy community of contributors.

Recently Linaro has been porting LUV to ARM64. Thanks, Linaro! This is great news for ARM64 Linux enterprise hardware. Once Linaro ports CHIPSEC to ARM, it’ll be a very good day for ARM64 firmware defensive security tools.

It would be nice to consider an ARM32 port, as well as ARM64. All devices need bootkit detection tools, not just enterprise-class systems. 🙂

[Someone please wake up AMD. Right now, AFAICT, their platform now has the worst defensive tools. They need a LUV-live with a CHIPSEC that works on ARM systems.]

https://wiki.linaro.org/LEG/Engineering/luvOS

https://01.org/linux-uefi-validation