Tag: AMD

RISC-V Raven processor talk at HotChips

~ hucktech ~ Leave a comment

HotChips 2015 is happening in Cupertino, California later this month, 23-25th. Today Krste Asanovic posted a message on the RISC-V blog:

RISC-V at HotChips: Analyst Kevin Krewell has posted a HotChips preview at EE Times, which mentions the RISC-V Raven-3 presentation to be made in the last session at HotChips by Yunsup Lee.  UC Berkeley will again be sponsoring a table at HotChips to promote RISC-V, so please drop by if you’ll be there and want to chat about RISC-V uptake.

Hot Chips is a symposium on High Performance Chips, sponsored by the IEEE Technical Committee on Microprocessors and Microcomputers, in cooperation with ACM SIGARCH. The RISC-V presentation is on the “Raven” processor:

Raven: A 28nm RISC-V Vector Processor with Integrated Switched-Capacitor DC-DC Converters and Adaptive Clocking
by: Yunsup Lee, Brian Zimmer, Andrew Waterman, Alberto Puggelli, Jaehwa Kwak, Ruzica Jevtic, Ben Keller, Stevo Bailey, Milovan Blagojevic, Pi-Feng Chiu, Henry Cook, Rimas Avizienis, Brian Richards, Elad Alon, Borivoje Nikolic and Krste Asanovic, University of Berkeley

The EE Times blog article, by Kevin Krewell of Tirias Research, gives a good overview of all the vendors presenting at HotChips, focusing on the traditional ones (Intel, ARM, AMD, etc.), and calls RISC-V an “odd duck”. 🙂

The last session on Tuesday is traditionally the main “big” processor session. […] The odd duck in the session is an implementation of UC Berkeley RISC-V Vector Processor. Last year the Berkeley contingent showed off RISC-V instruction set in the break area, but now with a real chip, they made it to inside the auditorium. It’s not too often you see a chip design of this integration and complexity coming from academia. What started as a project to give universities a royalty-free and extendable CPU architecture to build on, has gained traction, especially in India and Asia for development purposes.”

RISC-V and Open Hardware aside, there are many other interesting presentations at Hot Chips 2015, including talks from Intel, ARM, AMD, and others. There are a handful of other Open Hardware/Maker-related talks, eg: Adapteva is talking about their Kickstarted chip, and Univerisity of Wisconson’s MIAOW project, an OpenGL API-compatible GPGPU.

http://www.hotchips.org/
https://blog.riscv.org/
http://www.eetimes.com/author.asp?section_id=36&doc_id=1327424

AMD clarifies firmware strategy

~ hucktech ~ 1 Comment

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.

Recapping Marek’s Jan2015 AMD security vulnerability

AMD AGESA

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.

AMD releases clSPARSE library

~ hucktech ~ Leave a comment

Earlier this week, Kent Knox of AMD announced the beta release of a new library on their blog.

The clSPARSE library, created by AMD in partnership with Vratis Ltd., is an open source sparse linear algebra library that uses OpenCL(TM) to accelerate performance with GPU Compute. clSPARSE expands upon exiting the clMathLibraries offerings: dense clBLAS (Basic Linear Algebra Subprograms), clFFT (Fast Fourier Transform) and clRNG (random number generator), and adds new sparse operations:

* Sparse matrix – dense vector multiply (SpM-dV)
* Sparse matrix – dense matrix multiply
* Iterative conjugate gradient (CG) solver
* Iterative biconjugate gradient stabilized (BiCGStab) solver
* Dense to Compressed Sparse Row (CSR) conversions (and converse)
* Coordinate list (COO) to CSR conversions (and converse)
* Functions to read matrix market files

clSPARSE contains optimized kernels that compute on matrices represented in CSR (Compressed Sparse Row) format. The library provides conversion routines to and from the CSR compressed matrix format, and is the required sparse matrix format to use the SpM-dV multiply, CG or the BiCGStab solvers. clSPARSE exports a C interface which allows developers to build wrappers around clSPARSE in any language they need. This means users do not have to write sparse OpenCL kernels to gain the performance benefits of sparse GPU acceleration. OpenCL fluency is still required. The implementation is abstracted, allowing you to focus on memory placement and transport.

This new AMD open source library uses the ASFv2 (Apache Software Foundation) license, and uses the CMake build tool.

More Information:

http://developer.amd.com/community/blog/2015/08/05/clsparse-beta-released/

AMD AGESA

~ hucktech ~ Leave a comment

I’m learning about AMD firmware solutions, and AGESA is first acronym on the list. According to Wikipedia:

“AMD Generic Encapsulated Software Architecture (AGESA), is a bootstrap protocol by which system devices on AMD64-architecture mainboards are initialized. The AGESA software in the BIOS of such mainboards is responsible for the initialization of the processor cores, memory, and the HyperTransport controller. AGESA documentation was previously available only to AMD partners that had signed an NDA. AGESA source code was open sourced in early 2011 to gain track in coreboot.”

There are two firmware ecosystems, coreboot and UEFI, where the former has a lot of Chrome OEMs, and the latter has a lot of Windows OEMs. UEFI and coreboot work on Intel and AMD (and ARM) systems. AMD makes both x86 and ARM systems, but I’m focusing on their x86 systems here.

For coreboot, Sage Engineering is main coreboot IBVs (Independent BIOS Vendors), AFAICT. Sage currently supports AMD systems, offering coreboot with AGESA.

https://www.se-eng.com/products/sagebios-bsp-for-amd-processors/

“Sage supports many modern x86 platforms from AMD. In early BSP releases,our source code license allowed us to directly modify and include AGESA source code. Later versions include the AGESA binary PI from AMD to initialize the CPU. SageBIOS(TM) Custom BSPs deliver full-featured firmware designed for AMD platforms.”

https://www.se-eng.com/firmware-solutions-for-intel-and-amd-x86-processor-systems/

“AMD was the first […] to support an open source boot solution with its support of the One Laptop Per Child program, which was immersed in the Linux open source community, and the Linux firmware boot solutions that would ultimately become coreboot. Sage Electronic Engineering founder Scott Hoot was heavily involved in that the children’s laptop project, as a firmware designer for AMD, and would soon embrace open source firmware solution as a foundation for his startup company. Sage would have distinct advantages over other open source firmware development companies in that Hoot already had a insight into AMD’s proprietary architecture, which he would cement with a agreements with AMD to help forge the way into expanded open source BIOS and firmware coding. Sage would continue to forge a trail in the community with its support of the coreboot(R) solution and the proprietary hybrid that Sage developed for more rapid deployment, SageBIOS. Open source development as a whole continue to progress with AMD’s AGESA  and Intel’s Firmware Support Package, essentially giving open source firmware designers a better look at the architecture than was previously allowed.”

Over in the UEFI Forum ecosystem, it appears that most of the ‘mainstream’ IBVs also support ARM via AGESA in their products as well. I see support from Insyde Software and AMI, at least.

http://www.insyde.com/press_news/press-releases/insyde-software-provides-framework-support-amd-processors

http://www.ami.com/news/press-releases/?PressReleaseID=135&/American%20Megatrends%20Extends%20Aptio%C2%AE%20Firmware%20Support%20for%20AMD%20AGESA%E2%84%A2/

I’m still not clear if TianoCore can use AGESA directly, or if an IBV is still needed to integrate the two.

More Information:

http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=src/vendorcode/amd
https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/a46a712610c130cdadfe1ebf6bec9ad22e474dac/src/cpu/amd/agesa

Click to access AGESA_Interface_specification_for_Arch2008.pdf

[I just realized that I’ve not written a blog on Intel Firmware Support Package (FSP) yet…. I’ll do one in a few days.]

Recapping Marek’s Jan2015 AMD security vulnerability

~ hucktech ~ Leave a comment

[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

AMD partners with ExactTrak to improve security

~ hucktech ~ Leave a comment

ExactTrak signs deal with AMD to secure mobile data. Press release:

28 May 2015, London: ExactTrak, the makers of Security Guardian, today announced it has signed a deal with AMD to allow its Security Guardian technology to be embedded in AMD processors to protect against the loss and theft of mobile data. Launched in the UK three years ago, Security Guardian by ExactTrak is the only USB key that allows users to turn on and off, or destroy data remotely without the USB being connected to a host device or the internet. With its battery, GPS, GSM and satellite functionality, users can track the location of Security Guardian and send instructions to the key via a cloud-based management console. Companies who equip their employees with Security Guardian USB keys can control them individually from the management console regardless of the mobile device they choose to use. This includes turning on, off or destroying the data irrevocably, limiting the times or locations in which the data can be accessed and monitoring when information on the key has been added, deleted, copied or printed. Roy Taylor, corporate VP of Alliances at AMD, commented, “In addition to the innovative technology, it was the commitment and determination of Norman and the ExactTrak team that sealed the deal for us. Data and the number of mobile devices are increasing every day which makes mobile data security a very real challenge for businesses and one that we’re happy to be working with ExactTrak to tackle head on.” Norman Shaw, Founder and CEO of ExactTrak, commented, “This deal with AMD represents a step-change in how organisations view mobile data and we believe it has the teeth to enable mobile data security on a global scale. We’re excited about providing an exclusive range of security modules for AMD’s highly advanced processors later this year. We’re also looking forward to working closely with AMD’s partners to make global data security a reality in the very near future.” ExactTrak and AMD expect to begin embedding Security Guardian mobile data security modules in AMD chips in the coming months with the view to devices hitting the market later this year.

More Information:

http://www.exacttrak.com/press-releases/exacttrak-signs-deal-with-amd-to-secure-mobile-data-globally/

Linux ACPI support for ARM-v8

~ hucktech ~ Leave a comment

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/

Linaro makes LUVos-live available for ARM64

~ hucktech ~ 1 Comment

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