ARM’s Linaro Connect is happening. Click on their web page for live streaming.
In addition to all of the ARM topics, Brian Richardson, an Intel evangelist will be speaking about UEFI at this event. 🙂
Tag: Linaro
Linaro FW-Summit list migrates to UEFI Forum’s FWOS Forum
Al Stone of Red Hat announced on the Linaro Firmware Summit mailing list that the list would transition over to the new UEFI Forum’s FW/OS list. Excerpt of announcement:
Since the fw-summit mailing list was only meant as a holding place until we could set up a forum like this, we will soon be disabling the mailing list. Any and all of the discussions we would have had on fw-summit should now be held on the FW/OS Forum mailing list instead. […] I would like to thank Dong Wei of UEFI especially, but also Michael Krau and the rest of the board of the UEFI Forum for all of their hard work and effort to make this public forum possible. It was a bit of a stretch for everyone, but it got done. Thanks!
Full announcement:
https://lists.linaro.org/pipermail/fw-summit/2015-November/000184.html
http://www.uefi.org/FWOSForum
https://lists.linaro.org/pipermail/fw-summit/
https://lists.linaro.org/mailman/listinfo/fw-summit
Firmware Summit results
Al Stone of Red Hat posted a summary of the recent Firmware Summit that took place at the recent Linaro Connect event.
There’s a discussion on the state of ACPI on ARMv8, and Linux support. “So, please tell Linaro if there is something needed from the ACPI spec. Call, write or send carrier pigeons, just let us know.”
There is a discussion on ACPI’s _DSD and Device Properties. A new dsd@acpica.org mailing list has been setup to help. A new repo of information — on how to submit, approve, and use device properties in a community approved manner:
https://github.com/ahs3/dsd/tree/v-next/documentation
https://lists.acpica.org/mailman/listinfo/dsd
Matthew Garret wrote a document on Secure Boot:
https://lists.linaro.org/pipermail/fw-summit/2015-September/000170.html
I omitted a few items from the workshop’s notes. Read the full status here:
https://lists.linaro.org/pipermail/fw-summit/2015-October/000173.html
Linaro LAVA changes
LAVA is a Continuous Integration tool for testing firmware, pre-OS environment, and embedded OSes, including QEMU-based systems as well as live hardware. Linaro is refactoring the code, which will impact test code and their running validation service, as well as renaming Linaro-Validation to lava-devel. The lava-users and lava-announce lists still exist. Neil Williams of Linaro announced some changes to LAVA, after discussing things at last week’s Linaro Connect. Excerpts of anouncement:
The LAVA dispatcher is being refactored and this had led to advancements and modifications in the lava-server as well as a completely re-written job submission format. LAVA is retaining compatibility *only* with the Lava Test Shell Definitions (the YAML files people are currently using) and there can be no automated way of converting existing JSON job submissions to the new job submission format (which uses YAML to allow for comments, amongst other improvements). The refactoring introduces a lot of benefits, including much more robust communication between the workers and the master, removal of configuration on the workers so that admins only change things in one place, a lot of new methods within the dispatcher to support new types of test and a much cleaner, more modular, codebase for future development. The timetable for these changes is expected to cover most of 2016.
The LAVA developers would ask that everyone running LAVA would subscribe to at least the lava-announce mailing list, to help with the migration to the new support.
Full announcement:
https://lists.linaro.org/pipermail/lava-announce/2015-September/000000.html
More information:
https://sfo15.pathable.com/meetings/302656
https://sfo15.pathable.com/meetings/303074
https://validation.linaro.org/
https://lists.linaro.org/mailman/listinfo/lava-users
https://lists.linaro.org/mailman/listinfo/linaro-validation
Linaro Connect presentations online
Linaro Connect is happening in San Francisco. They’ve got their presentations online, including a few firmware-related and security-related talks. I like the “Advanced Toolchain Usage” series.
http://www.linaro.org/blog/linaro-connect-2015-kicks-off-in-san-francisco/
http://www.linaro.org/blog/day-2-of-linaro-connect-sfo15/
https://www.linaro.org/blog/day-3-of-linaro-connect-sfo15/
https://www.linaro.org/blog/day-4-of-linaro-connect-sfo15/
LITE, Linaro IoT group
At Linaro Connect, ARM’s CEO announced a new Linaro IoT group, LITE. More details here, including the video of the announcement:
https://www.linaro.org/blog/linaro-connect-2015-kicks-off-in-san-francisco/
In Youtube video of announcement, it ironic to see ARM exec keynote interrupted by an attendee’s smartphone, which was likely ARM-based.
Many other things are in keynote video, not just LITE, since this week’s Linaro Connect is “security-themed”.
“Security is starting to become important for everything we do.” –ARM CEO
http://connect.linaro.org/program/
Mentor improves Sourcery toolchain
Mentor Graphics is adding support for AArch64 and AMD x86 in their freeware eLinux toolchains:
Mentor Embedded Linux for AMD x86 G-Series and R-Series Processors and Sourcery CodeBench Tools for AMD x86 and ARM
Linux Development for Next-Generation Embedded Systems
Mentor Embedded and AMD have joined forces to announce several software enablement products for the AMD Embedded G-Series and R-Series families of processors: Mentor Embedded Linux and Sourcery CodeBench IDE tools. To complement the offer, free versions of the Mentor Embedded Linux-Lite and Sourcery CodeBench Lite are available for customers to download. The combination of AMD’s breadth of embedded processors and Mentor Embedded’s software solutions will enable developers to build robust and powerful applications in industries such as digital gaming, industrial control & automation, retail Point-of-Sale (POS), networking equipment and storage.
http://www.mentor.com/company/news/mentor-amd-armv8-a-linux
Linaro’s 96Boards initiative
Earlier this year, ARM’s Linaro created 96Boards.org.
The 96Boards initiative is designed to offer a single software and hardware community across multiple vendor boards supporting a range of different features. A fixed set of minimum functions including USB, SD, HDMI and standardized low speed and high speed peripheral connectors are provided. Vendors may add customized hardware and feature sets provided the minimum functions are available. We expect this to extend the platform life, increase the market for add-on hardware, and accelerate open source upstreaming of support for new SoC features. The 96Boards standard specification and this website are maintained by the Linaro Community Board Group (LCG). Linaro is a collaborative software engineering organization focused on the ARM architecture. Corporate members of Linaro provide funding and engineers plus direction through various steering committees and resources are split into semi-autonomous groups with their own members.
There are currently two 96Boards specifications for low-cost ARMv7-A and ARMv8-A development boards:
* The Consumer Edition (CE) targets the mobile, embedded and digital home segments.
* The Enterprise Edition (EE) targets the networking and server segments.
They have 3 boards listed currently:
* DragonBoard 410c: Board based on Qualcomm Snapdragon™ 410 processor
* The HiKey Board: Board based on HiSilicon Kirin 6220 processor
* 96Boards UART Serial Adapter: a USB to UART interface to be used with any 96Boards Consumer or Enterprise Edition board.
https://www.96boards.org/ce-specification
https://www.96boards.org/ee-specification
https://www.96boards.org/products/
Marcin Juszkiewicz has a good blog post on 96boards as well:
http://marcin.juszkiewicz.com.pl/2015/06/26/96boards-goes-enterprise/
ARM Devices has a video discussing adding 96boards hardware targets to LAVA, the CI server by Linaro for embedded device testing.
Security focus of next Linaro Connect
Linaro Connect is happening in 4 days in San Francisco.
“The theme for the week is security.”
The security track:
* Security requirements on ARMv8-A boot architecture
* Linux kernel generic TEE driver
* OP-TEE Content Decryption with Microsoft PlayReady on ARM
* Expanding security choices: DRM & CA interoperability
* Expanding security choices panel
* Secure storage in OP-TEE
* Lessons learned on migrating open source Chromium-OPTEE to 96Boards
* TBD
* TBD
More Information:
https://www.linaro.org/news/keynote-speakers-lined-up-for-linaro-connect-sfo15/
http://connect.linaro.org/sfo15/
ARM article on U-Boot
A few weeks ago Linus Walleij of Linaro wrote an article talking about boot loader technology options for AArch32 and AArch64. Besides going into detail on U-Boot, the blog mentions some boot loaders from Qualcomm and elsewhere:
https://www.linaro.org/blog/core-dump/u-boot-on-arm32-aarch64-and-beyond/
Microsoft and ARM collaborate on DRM/secure media solutions
ARM and Microsoft have announced support of integration of technologies that enable DERM on ARM systems, using Microsoft PlayReady and W3C Encrypted Media Extensions (EME):
Press release excerpt:
The major development in this solution is the integration of Microsoft’s PlayReady DRM with W3C EME, OpenCDM, Chromium and Linaro’s Open Portable Trusted Execution Environment (OP-TEE) on ARM TrustZone® technology. The secure media solution has been implemented on an STMicroelectronics STiH410 SoC with an ARM Cortex®-A9 processor at its core. The new solution integrates the following key components: W3C EME, Microsoft PlayReady DRM Porting Kit v3.0, OP-TEE, OpenCDM, and Chromium v43.
“The Linaro Digital Home Group is extremely pleased to deliver this open source secure media solution to the embedded developer community” said Mark Gregotski, Director of the Linaro Digital Home Group. “This collaboration demonstrates how a commercial DRM, such as Microsoft’s PlayReady, can be integrated into a security framework comprised of open-source components, including the Linaro Open Portable TEE running on ARM TrustZone. We hope this will be the catalyst to accelerate the deployment of secure DRM solutions employing open source software.”
“This is a key milestone that showcases how Microsoft PlayReady DRM works cross-platform in a standard way. We are excited about the collaboration with Linaro, ARM, OP-TEE and OpenCDM. This reference implementation simplifies and accelerates the ability of partners to build rich experiences to deliver secure media solutions, while providing market leading content protection using Microsoft PlayReady” said Dave Bossio, Group Program Manager, Windows Devices Group, Security at Microsoft Corporation.
“Trust is key to future media business models, as valuable content must be protected from server to screen,” said Shiv Ramamurthi, Director, Home Segment Marketing, ARM. “The pay TV ecosystem will see immediate content security benefits from the integration of ARM TrustZone and Microsoft PlayReady DRM technology. This latest open source initiative led by the Linaro Home Group is a milestone in the enablement of next-generation secure content and media experiences for consumers.”
“ST has been a strong contributor to the Open Portable Trusted Execution Environment (OP-TEE) in open source, a key enabler for this integration. As a natural step forward, ST is pleased its STiH410 platform is being used as a vehicle for this effort and for an exciting demo at IBC 2015,” said Yingchih Yang, Advanced System and Security Officer of the Consumer Product Division in STMicroelectronics. “Such Linaro contributions will facilitate premium content consumption across various devices including smartphones, tablets, and set-top-boxes, meeting strong market expectations.”
http://www.linaro.org/news/linaro-and-microsoft-collaborate-on-secure-media-solutions-for-arm-based-socs/?sf40842573=1
http://www.microsoft.com/playready/
https://github.com/fraunhoferfokus/open-content-decryption-module
https://github.com/w3c/encrypted-media/
http://www.w3.org/TR/encrypted-media/
https://github.com/OP-TEE
new ARM Image Generator tool for Linaro
There’s a new tool from Shadeslayer to help with Linaro ARM image creation, an alternative to Linaro’s HWPack, and it includes firmware generation:
Linaro Firmware mini-Summit next month
Today on the Linaro Firmware Summit mailing list, Al Stone of Red Hat just announced the next Firmware Summit
What: Linaro Firmware mini-Sumit (at Linaro Connect)
When: Tuesday, September 22th, 2015, 2-6pm
Where: Hyatt Regency San Francisco Airport Hotel, Burlingame, CA
Initial agenda topics include:
1) Current state of ACPI on ARM
2) Support/backing for a longer term organization (i.e., mailing lists, web sites, further meetings…)
3) Use of _DSD device properties
4) Follow-up on others items from the last meeting (mostly promised documents)
Other topics are being solicited. See the full posting on the fw-summit list archives.
https://lists.linaro.org/mailman/listinfo/fw-summit
http://sanfranciscoairport.hyatt.com/en/hotel/home.html
http://connect.linaro.org
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/
GlobalPlatform’s TEE Developers Workshop
Next month is the GlobalPlatform TEE conference in California; they’re also hosting a 1-day developer workshop on October 12th. GlobalPlatform, Trustonic, Intel, and Linaro are presenting; the agenda looks interesting:
1) GlobalPlatform
Kevin Gillick, GlobalPlatform Exec. Director
Gil Bernabeu, GlobalPlatform Technical Director
Christophe Colas, VP of Product Marketing at Trustonic and GlobalPlatform Device Committee Chair
2) Trustonic: Scaling Fast and Simply Across Trustonic TEE-based Devices
Rob Dyke, Senior Field Application Engineer, Trustonic
3) Intel: Open-TEE – A Virtual TEE and SDK
Brian McGillion, Security Engineer, Intel
Tanel Dettenborn, Security Engineer, Intel
Thomas Nyman, Doctoral Candidate, Aalto University, Finland
Valentin Manea, Security Engineer, Huawei
4) Linaro: TEE and TA Development the Easy Way
Joakim Bech, Technical Lead, Security Working Group, Linaro
http://www.teeseminar.org/about_the_workshop.asp
https://github.com/Open-TEE
https://wiki.linaro.org/WorkingGroups/Security/OP-TEE
http://www.globalplatform.org/TEEevent/about_the_workshop.asp
Early bird pricing is $199 USD before 30 August 2015. $299 USD after. There is no price distinction between GlobalPlatform members and non-members for this workshop. Organizations sending two or more people will receive $50 discount per student.
Intel ITS
Intel has a device to help with UEFI testing, the Intelligent Test System (ITS). ITS may have been around for a while, but I just noticed it on the Intel firmware web site. I’m presuming for now that it’s new from IDF, but I may be wrong about that. If you do UEFI testing, you might want to look at this device.
https://firmware.intel.com/learn/its/intel-its
https://designintools.intel.com/product_p/q6ujitshub001.htm
I wonder how it compares to Linaro’s LAVA. LAVA does mostly target ARM devices, but does also target Intel via QEMU, perhaps there are direct Intel targets these days.
AArch64 support for ACPI BERT in Linux
ACPI is not only in the firmware of Intel-based systems, but it’s also now inside ARM-based systems. Today on the Linaro-ACPI mailing list, there was a patch for ACPI BERT support for AArch64. I think support had already been in for Intel already, unclear how long.
APEI Boot Error Record Table (BERT) support
Under normal circumstances, when a hardware error occurs, kernel will be notified via NMI, MCE or some other method, then kernel will process the error condition, report it, and recover it if possible. But sometime, the situation is so bad, so that firmware may choose to reset directly without notifying Linux kernel. Linux kernel can use the Boot Error Record Table (BERT) to get the un-notified hardware errors that occurred in a previous boot. In this patch, the error information is reported via printk. Once error log is printed out clear error status so it would not be print during next boot again.
ACPI/APEI is designed to verifiy/report H/W errors, like Corrected Error(CE) and Uncorrected Error(UC). It contains four tables: HEST, ERST, EINJ and BERT. The first three tables have been merged for a long time, but because of lacking BIOS support for BERT, the support for BERT is pending until now. Recently on ARM 64 platform it is has been supported. So here we come. The following log is a BERT record after system reboot because of hitting a fatal error.
BERT: Obtained BERT iomem region <00000000fe801000-00000000fe802000> for BERT.
[Hardware Error]: Error record from previous boot:
[Hardware Error]: event severity: fatal
[Hardware Error]: Error 0, type: fatal
[Hardware Error]: section_type: memory error
[Hardware Error]: physical_address: 0x00000000fe800000
[Hardware Error]: physical_address_mask: 0x0000000000000fff
[Hardware Error]: card: 0 module: 1 bank: 0 device: 1 row: 1 column: 1 bit_pos
For more information about BERT, please refer to ACPI Specification version 6.0, section 18.3.1.
For more information about this patch, see this thread:
https://lists.linaro.org/pipermail/linaro-acpi/2015-August/005611.html
For more on BERT, also see /src/acpi/bert/bert.c in the FirmWareTestSuite (FWTS).
http://www.spinics.net/lists/linux-acpi/msg57384.html
https://lists.linaro.org/mailman/listinfo/linaro-acpi
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/
Linaro update on TEE kernel driver
Today Joakim Bech posted a new entry in the Linaro blog, “Evolution of a generic TEE kernel driver“. This is a good introduction to ARM Trusted Execution Environment (TEE) and it’s integration to the Linux kernel.
More Information:
https://www.linaro.org/blog/evolution-of-a-generic-tee-kernel-driver/
https://git.linaro.org/bsp/st-ericsson/linux-2.6.34-ux500.git/tree/HEAD:/drivers/tee
Firmware Security 
You must be logged in to post a comment.