TrustZone in AMD Pro APUs

Bruno Ferreira has a story in TechReport on TrustZone support in new AMD Pro APUs:

AMD goes Pro with TrustZone-enabled APUs

AMD has released a Pro family of APUs and management tools targeted at business environments. These APUs hail from the Godavari and Carrizo families, and come in both mobile and desktop flavors. According to AMD, its new Pro A12 mobile APU is “the first [HSA-compliant] commercial processor in the industry.” It’s also the first APU with support for ARM’s TrustZone, for system-wide separation of software execution environments. The mobile Pro A12 packs in four CPU cores with a 3.4 GHz Turbo clock, alongside an R7-series GPU with 512 compute units clocked at 800 MHz. The inclusion of an HEVC decoder is also a nice bonus. A similar part exists in the Pro-series desktop APU lineup, with four cores and Turbo speeds of 4.1 GHz. Along with the hardware, AMD has released its companion Pro Control Center software, which offers centralized system management features like system health monitoring, traffic shaping, and USB port blocking. If this whole thing sounds similar to Intel’s vPro, you’re probably right. Still, AMD’s take has a few unique features. AMD already has a few partners on board. HP is using Pro APUs in  its “AMD Elite” family of products, and Lenovo is building around these chips with its M79 Tower. More AMD Pro products should be coming soon.

Full story:

http://techreport.com/news/29121/amd-goes-pro-with-trustzone-enabled-apus

Recapping Marek’s Jan2015 AMD security vulnerability

[I’m pretty dumb when it comes to AMD systems. 😦 I am just catching up to what most of the rest of the world knows about their technology, and security. I asked on the EDK2-devel mailing list for a clue on AMD’s firmware strategy, and Gary Simpson of AMD was kind enough to answer my questions. I’ll post a version of his answers in an upcoming blog, in the mean time look on the edk2-devel archives on 7/31 for his message. I’m still trying to understand some of the answers from AMD, from firmware development perspective, mainly AGSEA and how it works. Much more on this in future blog posts. In the mean time, I’m also catching up to AMD silicon/firmware security, and the most recent public story appears to be from January:]

Back in January of this year, there were a few stories on one AMD firmware vulnerability, reported last April, fixed last November, reported at December’s Chaos Communications Congress. At 31C3, Rudolf Marek, a Czech programmer, gave a presentation about a security vulnerability on AMD’s x86 chips, insufficient security checks before execution allows malware injection. AMD’s Mullins, Beema, Temash, Trinity, Richland, Kaveri, and Kabini chips are impacted. AMD released new free firmware update to resolve things.

It is nice to hear that “AMD responded quickly” and that this vulnerability was resolved in a “timely” manner!

If you have AMD systems, make sure you have this recent update!

Some quotes from stories on this vulnerability:

“The problem is caused by a vulnerability in the AMD SMU (System Management Unit) Unit APU / SoC mentioned, which does not perform pre-implementation code ‘appropriate checks’. AMD responded quickly, closing this security gap with a firmware update to your AGESA (AMD Generic Encapsulated Software Architecture), which is available for manufacturers of motherboards for PCs, notebooks and tablets, based on these APU / SoC AMD. The developer recommends users, requiring manufacturers of compatible motherboards with the APU / SoC affected, the release of new versions of BIOS with the new version of AGESA incorporated; since some motherboard manufacturers might not feel obliged to publish BIOS updates for older products such as stem socket FM2 cards (compatible with Trinity and Richland).”

“Marek told an audience at the Chaos Communications Congress that he worked with AMD for a year to fix the security flaw. He recommended that users contact their motherboard vendors to push the fix to their computers. “[Ask] your vendors for a fixed AGESA [AMD Generic Encapsulated Software Architecture],” Marek said. “This is the only way to push vendors to update BIOSes for older platforms,” he added.”

“As pointed out by Marek firmware insufficiently correctly checks the signature code that allows an attacker to insert your own code and execute it. This is done via the System Management Unit (SMU), which is also responsible for the power saving function. But he was also deeply involved in the configuration. The firmware on 32-bit controller LatticeMicro32 (LM32) from Lattice Semiconductor. Rudolf Marek broke the key used to sign the code hash SHA1. He took the code from SMU update BIOS, and then run the code on an emulator. After breaking the code Rudolph was able to add their own team in SMU and execute them.”

“The firmware is available as part of AMD AGESA (AMD Generic Encapsulated Software Architecture). It has already been updated AMD in late November, the request was sent to manufacturers of motherboards, notebooks and complete systems. They should implement AGESA in your BIOS and UEFI. Updates should already be implemented for most systems, but manufacturers do not disclose relevant information.”

“Back in April last year, Rudolf Marek informed of its existence AMD, who has confirmed the vulnerability in the summer, and it was fixed at the end of November. Hopefully, manufacturers have responded to this problem in a timely manner, and added in a modified AGESA updating the BIOS.”

More Information:

http://www.theregister.co.uk/2015/01/14/amd_plugs_chip_firmware_holes/
http://www.fierceitsecurity.com/story/research-uncovers-security-hole-amd-chips-enable-attack-inject-malware/2015-01-20
https://lenzfire.wordpress.com/2015/01/17/amd-releases-new-free-firmware-for-vulnerabilities-in-their-fm2-fm2-am1-apu-
http://www.hardwareluxx.ru/index.php/news/hardware/prozessoren/33090-amd-firmware-apu.html
http://www.heise.de/newsticker/meldung/Sicherheitsluecke-in-Firmware-von-AMD-Prozessoren-2512960.html
https://events.ccc.de/congress/2014/Fahrplan/events/6103.html
https://media.ccc.de/browse/congress/2014/31c3_-_6103_-_en_-_saal_2_-_201412272145_-_amd_x86_smu_firmware_analysis_-_rudolf_marek.html#video

Click to access ccc-final.pdf