There’s an article by ARM in EE Times on vehicle security. This provides a non-TPM-centric perspective, which many of these articles focus on.
http://www.eetimes.com/author.asp?section_id=36&doc_id=1331248
Tag: ARM Ltd
OpenSynergy hypervisor for ARM Cortex-R52
Quoting the press release:
Automotive safety hypervisor announced for ARM Cortex-R52
OpenSynergy paves way for next-generation autonomous devices with virtualization for ARM’s most advanced real-time processor
Berlin, Germany and Cambridge, UK, January 18, 2017. OpenSynergy is developing the industry’s first software hypervisor for the ARM® Cortex®-R52 processor, ARM’s most advanced real-time safety processor. The hypervisor turns any chip based on the Cortex-R52 into several virtual machines capable of simultaneously executing separate software tasks. To address increasing software complexity in devices such as autonomous vehicles and industrial control systems, this approach allows for the isolation of safety-critical functions from those that require less stringent control. In addition, it enables the consolidation of applications onto fewer electronic control units (ECUs) to both manage complexity and reduce cost. “Mass-market autonomous vehicles will be engineered with greatly enhanced ECU compute capabilities and the ability to safely manage far more complex software stacks,” said Richard York, vice president of embedded marketing, ARM. “The Cortex-R52 was purpose-built for this task, with hypervisor-enabled software separation protecting critical safety features while ensuring fast task execution. This will enable highly performant vehicles that can be fully trusted to take over from the driver.” “The ARM Cortex-R52 processor will bring virtualization technology to a much wider set of devices in the automotive market,” said Stefaan Sonck Thiebaut, CEO, OpenSynergy. “In doing so, we look forward to enabling the next generation of vehicle architecture.” The Cortex-R52 introduces hardware support for virtualization to the Cortex-R family of processors while maintaining all the functionality required for hard real-time systems. The ability to maintain deterministic execution within a hypervisor provides an ideal solution to the challenge of concurrent real-time systems in a wide array of robotic applications. OpenSynergy’s software architecture targets microcontrollers such as domain controllers. The hypervisor technology enables several real-time operating systems and AUTOSAR systems at different ASIL levels to run in parallel on the Cortex-R52.
Full PR:
https://www.arm.com/about/newsroom/automotive-safety-hypervisor-announced-for-arm-cortex-r52.php
Leif on QEMU and USB host device pass-through
Leif has a new blog post on using UEFI with USB pass-through.
[…]”One thing that is unsurprising, but very cool and useful, is that this works well cross-architecture. So you can test that your drivers are truly portable by building (and testing) them for AARCH64, EBC and X64 without having to move around between physical machines. ”
http://blog.eciton.net/uefi/qemu-usb-passthrough.html
Checkout his previous blog post, on UEFI driver development, as well as older posts on Linaro/ARM/UEFI history.
Writing secure C code for ARM
new AArch64 vm-spec validation tools
Riku Voipio of Linaro has announced the release of some new tools that validate the VM to the Linux cross-distro list.
Some time ago we drafted a specification[1] for AArch64 virtual machines. Now we are launching verification tools that let everyone verify that the whole stack (host hypervisor, guest firmware and guest OS image) implements the spec 2[]. For some extra background see the blog post on vmspec [3]. From the cross-distro point of view, we are interested in finding out if
– QEMU shipped is new enough (2.6+)
– a compatible EFI for arm64 guests is available
– a vmspec compatible cloud guest image is available
If the image comes with cloud-init, vmspec-boot can be used directly to verify compliance. Without cloud-init, one can run vmspec-verify inside the guest to verify manually. The tools are still under development, for example the ACPI test returns a failure even if the guest would support ACPI if forced. Feedback and patches are always welcome. The README.md lists a handful of guest images that have been used in testing. I’d be most happy to add more links to the list!
[1] http://www.linaro.org/app/resources/WhitePaper/VMSystemSpecificationForARM-v2.0.pdf
[2] https://github.com/linaro/vmspec-tools
[3] http://www.linaro.org/blog/core-dump/ensuring-bootable-arm-vm-images/
Full message:
https://lists.linaro.org/mailman/listinfo/cross-distro
ARM gets Pointer Authentication Code (PAC)
ARM’s new PAC seems like it’ll be giving ROP some work…
https://community.arm.com/groups/processors/blog/2016/10/27/armv8-a-architecture-2016-additions
CHIPSEC ported to ARM??
screenshot: https://pbs.twimg.com/media/CubkpMsVIAAIrQT.jpg:large
Intel CHIPSEC is — or at least was — Intel-specific. Actually it may be called McAfee CHIPSEC now? Anyway, it did not work on ARM. Via Linaro, ARM Ltd. was in the process of porting LUV (Linux UEFI Validation) distro to AArch64, and LUV includes CHIPSEC, so that was on the list, but AFAIK Linaro had not yet started to port CHIPSEC to ARM yet.
So the above screenshot is news to me, and very exciting. I hope we get more news about this soon!! AND a source check-in (currently nothing in repo)… 🙂
ARM Trusted Firmware issue on Amlogic S905?
https://plus.google.com/+JeroenPluimers/posts/VfAYwFMj58s
“Amlogic S905 processor used in many Android TV boxes and ODROID-C2 development board implements ARM TrustZone security extensions to run a Trusted Execution Environment (TEE) used for DRM & other security features. However, Frédéric Basse, a security engineer, worked with others and managed to bypass secure boot in one Amlogic S905 powered Android TV box, namely Inphic i7, but any other device based on the processor would have made the same thing possible. […]”
http://www.cnx-software.com/2016/10/06/hacking-arm-trustzone-secure-boot-on-amlogic-s905-soc/
video of Brian’s Tianocore Linaro Connect presentation
Brian Richardson of Intel recently gave a presentation at ARM Ltd’s Linaro Connect on the subject of UEFI. Intel started UEFI but in recent years ARM is also using UEFI.
Linaro Connect
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. 🙂
Open Trust Protocol (OTrP) gets revised
As Marc Canel of EETimes points out the 1st revision of the Open Trust Protocol is out. Open Trust Procotol is an IETF submission by multiple vendors, the companies Symantec, Intercede, Solacia, and ARM Ltd are the employers of the editors of the I-D.
Abstract: This document specifies the Open Trust Protocol (OTrP), a protocol to install, update, and delete applications and to manage security configuration in a Trusted Execution Environment (TEE). TEEs are used in environments where security services should be isolated from a regular operating system (often called rich OS). This form of compartmentlization grants a smaller codebase access to security sensitive services and restricts communication from the rich OS to those security services via mediated access.
http://www.eetimes.com/author.asp?section_id=36&doc_id=1330455&
https://www.ietf.org/id/draft-pei-opentrustprotocol-01.txt
https://tools.ietf.org/html/draft-pei-opentrustprotocol-01
https://datatracker.ietf.org/doc/draft-pei-opentrustprotocol/
https://www.ietf.org/mail-archive/web/saag/current/msg07206.html
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/
AMD clarifies firmware strategy
A while ago, I asked on the UEFI development list for someone to clarify AMD’s UEFI strategy. I’m unfortunately, not that strong on AMD64 technology, and was a bit confused by the available documentation as to a few things. Gary Simpson, Firmware Architect at AMD, was kind enough to reply to my questions, with verbose reponses. I’ve slightly edited the message, cleaning up the email intro and simplifying my questions, but did not alter any text responses from AMD. Below, lines beginning with “Q:” are questions from me to AMD, and the bold lines with “A:” are Gary’s replies.
Q: Can anyone explain AMD’s strategy w/r/t UEFI and BIOS, UEFI and coreboot?
A: Here’s some quick background: AMD is a founding Board member (i.e. Promoter) of the UEFI Forum and an active member in most of the work groups. We are proponents of the UEFI and ACPI interfaces (because they provide standardized firmware API’s, allowing shrink-wrapped OS distributions, without customized drivers, enabling end-user OS flexibility and choice). Also, despite some birthing pains with individual implementations, UEFI is enormously more secure than legacy BIOS was. AMD’s evolution from legacy BIOS to UEFI has happened over the last ten years in sync with the schedules of our industry partners (IBV’s, OEM’s) and their code bases. We’re not seeing any demand for legacy BIOS enablement anymore, so we no longer focus any effort there. Coreboot is the only remaining legacy code base we enable. Coreboot enablement is provided by AMD’s embedded group for a market-appropriate subset of our chips.
By the way, you may be assuming that the traditional competitiveness between companies persists in the UEFI Forum and the spec work groups that it oversees. But there is actually very little of that (especially compared with a lot of other industry-standards bodies). The general attitude within UEFI is that the firmware layer should be unified, interoperable, well-specified and secure. There is no room for competition or company-specific advantage in the firmware layer. (Then, of course, we all go home to our individual companies and work to create competitive advantage at other layers, such as hardware or higher-level software.) I just want to make sure you understand the atmosphere of cooperation and common-cause that exists between the various OEM’s, Silicon Vendors, OS Vendors, IBV’s, and others that make up the UEFI Forum. That cooperative atmosphere pervades the UEFI work groups, as well as the UEFI Board of Directors.
Q: What AMD X64 models use UEFI, what models use BIOS, what models use coreboot?
A: We don’t specify or control this. Our customers can implement whatever platform firmware solution they choose. However, the firmware components AMD provides focus primarily on UEFI solutions. As mentioned, our embedded group also enables coreboot for a selected subset of our chips. Coreboot is the only legacy code base we still target. For coreboot, we maintain wrappers and a centralized function dispatcher, but our core code is natively targeted at the various UEFI-style code bases used by our IBV partners, our OEM customers, and Tianocore (e.g. EDKII).
Q: I’m unclear if current/upcoming AMD X64 models are still using BIOS on most or only some of their systems, as well as coreboot -vs- UEFI usage and future plans.
A: Internally, we create Customer Reference Boards (CRB’s) and build platform firmware in-house to support them. These in-house BIOS’s, which we use to bring-up and validate our new silicon designs, are all UEFI-based. These are almost always based on our AGESA firmware (see below) combined with a platform code base from one of the IBV’s. Additionally, AMD’s embedded team ports coreboot to their versions of the CRB’s.
Q: Are there different goals for UEFI/BIOS/coreboot for consumer desktop/laptop models -vs- server models? I’ve heard one person speculate that servers are focusing on BIOS, laptops are focusing on GPUs/DirectX [and perhaps UEFI].
A: AMD’s goal is simply to provide what our customers want and need. Server manufacturers were, in general, slower to transition from legacy to UEFI, but we are no longer seeing any demand from them for legacy BIOS.
Q: I’m really unclear how they can get Win8 logos if they’re using BIOS. If they’re getting logos for those systems. Do AMD systems have less Win8 technical restrictions than Intel systems in this regard?
A: In combination with the BIOS Vendors and/or the OEM’s, AMD makes UEFI solutions (supporting Secure Boot, etc.) available for all our chips. We qualify for our Win8 and Win10 logo certifications the old fashioned way – by passing the tests. We make sure that all of our CRB’s pass the certifications tests, and we assist our OEM customers as needed to make sure that their production systems pass as well.
Q: What is AMD equivalent of Intel FSP, for closed-source blobs need alongside Tianocore open source?
A: Our deliverable is called AGESA (AMD Generic Encapsulated SW Architecture). It plugs into the IBV and OEM code bases and does initialization and configuration of the AMD silicon (CPU, GPU, FCH (southbridge), GNB (Graphics North Bridge), etc.). We private-license AGESA source (for free) to our IBV and OEM partners. For coreboot, AGESA is currently provided as a binary module. We did previously publish AGESA open-source in the coreboot repository for a few of our chips over the last several years. You can have a look at those if you’re interested.
Q: How do I debug UEFI on AMD systems, like I can use Intel WinDbg/GDB-based solution for debugging Tianocore with Tunnel Mountain box?
A: AMD does not have an equivalent to Tunnel Mountain. There aren’t any motherboard manufacturers willing to produce and sell such a board, since our volumes would be smaller than Tunnel Mountain. We do design and build Customer Reference Boards for each new chip. The CRB volumes are small and the cost is high, so they mostly go to larger customers. Even inside AMD, these are usually in short supply.
Q: Are you going to port LUVos (and LUV-live) — including it’s new and bundled various tests, especially CHIPSEC — to your systems? CHIPSEC won’t work on AMD64 systems, only Intel systems, implementations are different.
A: We don’t have any current plans to do this, but your question may cause us to do more investigation in this area.
Q: For AMD’s new ARM Ltd.-based systems, are they going to use UEFI on all of them, or just some? What will be used on others, U-Boot or something else?
A: This is an area where we are feeling our way forward. Different customers will want different things. We will try to accommodate them all as well as we can. We plan to offer AGESA for UEFI code bases only, so we won’t support U-Boot directly, but we will enable a UEFI solution that creates a Flattened Device Tree, which should boot any OS’s that normally sit on top of U-Boot.
Q: Are you using Linaro for UEFI bits and making your own ARM firmware, our outsourcing to IBV, if so which?
A: We are working with IBV’s, replicating the traditional firmware-development process from the x86 PC world, but we recognize that traditional ARM-embedded customers may be looking for a free-source stack from us, so we are working to prepare for that possibility as well.
Q: Are you going to help Linaro with their AArch64 port of LUV-live and CHIPSEC, especially including AMD-specific AArch64 implementation issues?
A: No plans yet, but we will investigate.
—- [End of ‘interview’.]
Thanks, Gary, for the detailed answers to my many ignorant questions! For more information, see the email thread on the edk2-devel mailing list, mainly see Gary’s response on July 31st:
https://lists.01.org/mailman/listinfo/edk2-devel
It is especially good to hear about AGESA being open source! I hope Intel can match that bar, with FSP…
Since the responses from Gary, I’ve done two AMD64-centric blog posts, one on the most recent (?) vulnerability, and one on ASESA.
Some additional questions I should’ve asked but didn’t think of until now:
Q: Has AMD or any AGESA licensee (IBV, OEM) ever hired an security audit of the AGESA sources, and published the results?
Q: Does the AMD’s SimNow, either Public or Partner release, support OVMF (the public release appears to not), or is there any other emulator/simulator accurate enough to facilitate porting of CHIPSEC to AMD64 systems?
Q: Can you clarify use of TrustZone on AMD64 — not ARM Ltd.-based AArch32/AArch64 systems? Does TrustZone even work on non-ARM systems as-is, or was this a new port? Are there any more technical details you can point us to for this?
Again, thanks Gary! For the sake of enterprise security, I hope AMD helps with and AMD64 port of CHIPSEC, or at least helps document the issues that need to be removed and added to and AMD64 port, so the open source community can help with the port.
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/
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/
Firmware Security 
