Click on tweet for video of event:

AMD Demonstrates Breakthrough Performance of Next-Generation “Zen” Processor Core

[…] At an event last night in San Francisco, AMD (NASDAQ: AMD) provided additional architectural details and a first look at the performance of its next-generation, high-performance “Zen” processor core. AMD demonstrated the “Zen” core achieving a 40% generational improvement in instructions per clock, delivering a landmark increase in processor performance. During the event, AMD demonstrated an 8-core, 16-thread “Summit Ridge” desktop processor (featuring AMD’s “Zen” core) outperforming a similarly configured 8-core, 16-thread Intel “Broadwell-E” processor1 when running the multi-threaded Blender rendering software with both CPUs set to the same clock speed. AMD also conducted the first public demonstration of its upcoming 32-core, 64-thread “Zen”-based server processor, codenamed “Naples,” in a dual processor server running the Windows® Server operating system. […]


updated AMD DASH tools

AMD uses DMTF DASH and SMASH on some of it’s systems. It appears the Windows System Center download is newly-updated.

GPU security analysis from POSTECH

Stealing Webpages Rendered on Your Browser by Exploiting GPU Vulnerabilities

Graphics processing units (GPUs) are important components of modern computing devices for not only graphics rendering, but also efficient parallel computations. However, their security problems are ignored despite their importance and popularity. In this paper, we first perform an in-depth security analysis on GPUs to detect security vulnerabilities. We observe that contemporary, widely-used GPUs, both NVIDIA’s and AMD’s, do not initialize newly allocated GPU memory pages which may contain sensitive user data. By exploiting such vulnerabilities, we propose attack methods for revealing a victim program’s data kept in GPU memory both during its execution and right after its termination. We further show the high applicability of the proposed attacks by applying them to the Chromium and Firefox web browsers which use GPUs for accelerating webpage rendering. We detect that both browsers leave rendered webpage textures in GPU memory, so that we can infer which webpages a victim user has visited by analyzing the remaining textures. The accuracy of our advanced inference attack that uses both pixel sequence matching and RGB histogram matching is up to 95.4%.

Click to access StealingWebpagesRenderedonYourBrowserbyExploitingGPUVulnerabilities.pdf


I just noticed this March-era update to the UEFI list of ACPI specs. It is a large, well-written spec, compared to some of the recent ACPI specs I’ve looked at.

I/O Virtualization Reporting Structure (IVRS)

This document describes AMD I/O Virtualization Technology. AMD I/O Virtualization Technology is embodied in the system-level function called the I/O Memory Management Unit (IOMMU). This document provides the IOMMU behavioral definition and associated design notes. It is intended for the use of system designers, chipset designers, and programmers involved in the development of low-level BIOS (basic input/output system) functions, drivers, operating system kernel modules, and virtual machine monitor (VMM) software. The intended user should have prior experience in personal computer design, microprocessor programming, and legacy x86 and AMD64 microprocessor architecture.

Click to access 48882_IOMMU.pdf

Rowhammer for AMD

A Tale of Two Hammers: A Brief Rowhammer Analysis of AMD vs. Intel
May 2016
Mark Lanteigne, CTO and Founder, Third I/O Inc.
This is the first addendum to Third I/O’s March 2016 Rowhammer report.


Click to access rowhammera1.pdf

Click to access rowhammer.pdf

List of UEFI vendors who care about security

Which UEFI vendors care — or at least may care — about security? The list (alphabetically) is shorter than you might expect:

Hewlett Packard Enterprises
HP Inc.
Insyde Software
Intel Corp.
Phoenix Technologies

Nobody else. If your vendor is not listed above, ask them why you should purchase a UEFI-based system from them.

The above list is from the list of vendors who have feedback mechanisms listed on the UEFI Forum’s security contact page.

AMD’s Secure Memory Encryption (SME) and Secure Encrypted Virtualization (SEV)

Linux is about to get more secure on some AMD systems, it seems… Tom Lendacky of AMD submitted an 18-part patch to many of the Linux dev lists, to add support for AMD’s new Secure Memory Encryption (SME) feature, and to prepare for an upcoming Secure Encrypted Virtualization (SEV) patch.

SME can be used to mark individual pages of memory as encrypted through the page tables. A page of memory that is marked encrypted will be automatically decrypted when read from DRAM and will be automatically encrypted when written to DRAM. Details on SME can found in the links below. The SME feature is identified through a CPUID function and enabled through the SYSCFG MSR. Once enabled, page table entries will determine how the memory is accessed. If a page table entry has the memory encryption mask set, then that memory will be accessed as encrypted memory. The memory encryption mask (as well as other related information) is determined from settings returned through the same CPUID function that identifies the presence of the feature. The approach that this patch series takes is to encrypt everything possible starting early in the boot where the kernel is encrypted. Using the page table macros the encryption mask can be incorporated into all page table entries and page allocations. By updating the protection map, userspace allocations are also marked encrypted. Certain data must be accounted for as having been placed in memory before SME was enabled (EFI, initrd, etc.) and accessed accordingly.

This patch series is a pre-cursor to another AMD processor feature called Secure Encrypted Virtualization (SEV). The support for SEV will build upon the SME support and will be submitted later.

AMD Memory Encryption whitepaper:

Click to access AMD_Memory_Encryption_Whitepaper_v7-Public.pdf

AMD64 Architecture Programmer’s Manual:

Click to access 24593.pdf

SME is section 7.10
SEV is section 15.34

For the patch, see the Linux-kernel or Linux-EFI (or other) lists:

Xen patches for AMD FIP/FCS/FDP/FDS/FOP instruction leak

The Xen security team posted an updated security advisory with a workaround to an AMD CPU issue. Heavily-edited announcement follows, see the OSS-security list post for the full announcement and patches:

Xen Security Advisory CVE-2016-3158,CVE-2016-3159 / XSA-172
version 3
broken AMD FPU FIP/FDP/FOP leak workaround

There is a workaround in Xen to deal with the fact that AMD CPUs don’t load the x86 registers FIP (and possibly FCS), FDP (and possibly FDS), and FOP from memory (via XRSTOR or FXRSTOR) when there is no pending unmasked exception.  (See XSA-52.) However, this workaround does not cover all possible input cases. This is because writes to the hardware FSW.ES bit, which the current workaround is based on, are ignored; instead, the CPU calculates FSW.ES from the pending exception and exception mask bits.  Xen therefore needs to do the same. Note that part of said workaround was the subject of XSA-52. This can leak register contents from one guest to another.  The registers in question are the FPU instruction and data pointers and opcode.

A malicious domain is able to obtain address space usage and timing information, about another domain, at a fairly low rate. The leaked address information might be used to help defeat address space randomisation in order to enable another attack.  The leaked address and timing information forms a low-bandwidth covert channel which might be used to gain information about the operation of a target guest. The affected FPU facility would not normally be used by cryptographic operations, as it does not provide cryptographically-relevant SIMD functions. It appears to us very unlikely that the leak might directly compromise sensitive information such as cryptographic keys, although (without knowledge of the guest software) this cannot be ruled out.  (This is notwithstanding the contrary statement in `Impact’ in XSA-52.)

Xen versions 4.0 and onwards are vulnerable.  Any kind of guest can exploit the vulnerability. The vulnerability is exposed only on AMD x86 systems.  Intel and ARM systems do not expose this vulnerability. Both PV and HVM guests are affected. The vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. On Xen versions 4.3 and earlier, turning off XSAVE support via the “no-xsave” hypervisor command line option will avoid the vulnerability. On Xen versions 4.4 and onwards there is no other known mitigation.

This issue was discovered by Jan Beulich from SUSE.


AMD microcode issue impacts Linux

[…] It happens only with 0x6000832 ucode, and Piledriver-based CPUs: i.e. newer AMD FX, and Opteron 300 series (4300, 6300 etc.). The visible effects are in ~80% of cases incorrect RSP leading to bad ‘rets’ into kernel data/bss or stack-protector faults. But there are also more elusive ones, like registers being cleared before use in indirect memory fetches or so. I can trigger it from within qemu guest (non-root), causing bad RIP in the host kernel. When testing, a couple of times (maybe 2) out of maybe 30 seen oopses, I was able to set it to user-space addresses mapped in the guest. It greatly depends on timing, but I think with some more effort and populating kernel stack with guest addresses it’d be possible to create a more reliable qemu-guest to host ring0 escape. I CC’d some AMD engineers from this list, and on of them replied with “We are working on the final testing of a new microcode patch to replace 0x06000832.” but without specifying any errata no, or ETA for the new ucode. […]

AMD announces HSAIL GDB and GPU Debug SDK

Budi Purnomo of AMD posted a message on the site, about AMD’s GPUOpen initiative, including HSAIL GDB and a related AMD GPU Debug SDK for it. These both sound very interesting, thanks AMD!

Today as part of AMD’s GPUOpen initiative, we are happy to announce the release of HSAIL GDB version 1.0 (prebuilt binary and source code).  This is AMD’s first debugger product that is built based on the new GCN debugger core technology. HSAIL GDB marks our first step toward building a rich debugging ecosystem for HSA and HCC.  Using HSAIL GDB, you can debug the execution of host CPU code and GPU agent kernel code (at the HSAIL language level) in a single debug session. HSA applications, including HCC and HIP, are supported on AMD APU platforms.  To learn more about the capability of HSAIL GDB, I encourage you to read through the HSAIL GDB tutorial. In addition, we also released a new AMD GPU Debug SDK (pre-built binary and source code).  This AMD GPU Debug SDK enables tool vendors to build their own rich GPU debugging ecosystem for AMD platforms based on the same GCN debugger core technology introduced within HSAIL GDB. The hardware based implementation provided in the GCN debugger core technology is a vast improvement over the previous debugger implementation provided in the AMD CodeXL OpenCL™ debugger which relies on repeated kernel recompilation and replay.  Using the GCN debugger technology, we are able to stop all the massively parallel threads in the GPU at a breakpoint, inspect the machine state by reading registers and memory, and then resume and execute all the GPU threads.  The instruction pointer at the ISA level can be correlated with the HSAIL line.  This project is the result of much hard work from the hardware and software teams within AMD over the past several years requiring much innovation in the hardware, firmware, kernel mode driver, user mode driver, runtime, compiler and the tools domain. […]

Full announcement:


I know nothing about firmware for GPUs, a lot to learn on this topic… 😦


ARM-based AMD device launched

AMD has used to be x64-based company. But now they’ve also got ARM technology in some of their new products, so things are about to get interesting, how this will turn out.,. Joel Hruska reports in ExtremeTech on the Opteron-A1100:

AMD’s first ARM-based processor, the Opteron A1100, is finally here

Today AMD is formally launching its first ARM processor core, the Opteron A1100. AMD first announced its plans to enter the ARM market in 2013, with the chip expected to ship by mid-2014. The company apparently began early sampling around that time frame, but is only now launching the processor. The new Opteron A1100 is pretty much what AMD promised in its early previews of the device. It packs eight Cortex-A57 CPU cores, with each pair of cores sharing a 1MB L2 (512K effectively allocated to each chip). An 8MB L3 cache backs the entire CPU cluster, and the CPU supports both DDR3 and DDR4. ECC support is also provided.

Who created the ACPI ASPT spec?


Earlier, the FWTS team thought this ACPI ASPT (ACPI System Performance Tuning) spec was from AMD.  AMD looked into it, and thinks it is probably from Intel, as does Insyde Software. Intel/anyone: Do you know who wrote the spec? If so, please leave a comment or send email. Thanks.

AMD comment:
Well, as far as I can tell, nobody at AMD knows about the ASPT table. First I asked the relevant specialists, then I asked everybody associated with BIOS. Nobody recognizes it as an AMD thing.
Then we found an IBV .txt file that listed a bunch of Intel-sounding platforms associated with ASPT. So, could you double check whether this is really being seen on AMD platforms, please?
Even if you do find it on some AMD platforms, I’m now pretty sure it’s not an AMD thing. It might be a proprietary ACPI table added by an OEM or and IBV. I believe proprietary tables are allowed by the ACPI spec.

and a later comment:
It’s actually a definition from another silicon vendor for their overclocking information. Since the table only shows up on systems that support overclocking, it only shows up on systems with fast graphics controllers. That’s might be why “AMD” is referenced.

Another comment from a firmware vendor (IFV):
I believe you would be better served by contacting any of your contacts at Intel Client.  I’m not saying they will document this table, but it’s clear to me by looking at our code, this is Intel’s table. Maybe the AMD false pointer is probably because most overclocking systems have non-integrated graphics?

AMD, Zen, and coreboot

There is speculation about AMD support of coreboot on Zen systems:

“However, one thing we’re still confused about is whether the next-gen platform will support Coreboot as an optional open-source firmware to replace the proprietary UEFI/BIOS.”

“More worrying about the prospects for Coreboot on future hardware is that since the end of 2014, AMD stopped providing open-source AGESA code. AGESA releases by AMD are now binary-only, with this being the bootstrap protocol needed to initialize AMD processor cores, memory, and HyperTransport. Binary AGESA is similar to Intel not opening up their firmware support packages.”

From an email-based interview I did with AMD’s firmware engineer, I get the impression that AMD has chosen UEFI as it’s main firmware, and coreboot is part of the AMD embedded team’s options:

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.


Qubes OS 3.1 rc1 released, with UEFI support

New features since 3.0:
 * Management Stack based of Salt Stack in dom0
 * Out of the box Whonix setup
 * UEFI support
 * LIVE edition (still alpha, not part of R3.1-rc1)
 * Updated GPU drivers in dom0
 * Colorful window application icons (instead of just colorful lock icon)
 * PV Grub support (documentation)
 * Out of the box USB VM setup, including handling USB mouse
 * Xen upgraded to 4.6, for better hardware support (especially Skylake platform)
 * Improve updates proxy flexibility – especially repositories served over HTTPS


Nikolaj on UEFI Security, part 7!

Nikolaj has written a 7th part to his 6-part series on UEFI security!

It covers AMD security processors, Intel STM, Intel SGX, TPM 2.0, and other current technologies.

There is mention at the end of an upcoming article on taming Secure Boot, generating your own keys, looking forward to that!

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:

coreboot changes

The coreboot blog has a long post, which covers the last five weeks of changes, and there were a lot: 314 commits. Some highlights:

Over one third of the commits covers Intel Skylake development, where boards and chipset code saw misc improvements and tons of clean ups.

There also was a notable effort of unifying common code across the more recent Intel SoCs, removing lots of duplicated code all over the place.

On x86, the romstage is now relocated for its final location in CBFS by cbfstool, obsoleting the old approach that had us link it twice, once to determine its final size and then to the actual location it’s supposed to run from. In the future this same approach may be extended to other files that need to be executed in place such as the FSP binary.

The romstage change eliminated the need for cbfstool’s “locate” command, and so it was removed. cbfstool also saw other extensions, the biggest one a compatible change to the format to allow for per-file attributes in CBFS. These attributes can contain additional information about a file, currently the compression method and uncompressed size of a file. cbfstool and the build system were extended to allow compressing files, libpayload is able to uncompress these files.

On the AMD side, there were various bugfixes both for new (merlin falcon) and old (Fam10) chipsets.

ARM64 and Tegra210 saw various bugfixes and improvements to power use. For the latter, coreboot also learned how to reserve memory for other functions than the main processor.
Rockchip’s RK3288 ARMv7 SoC also saw a number of bug fixes and the code was restructured to use a single mainboard directory for a large number of very similar Google Veyron mainboards based on that SoC.

Our RISCV support now boots on the Spike simulator which (besides supporting a wider variety of emulators) is notable because unlike the QEmu RISCV support, Spike supports RISCV’s revised ABI.
Speaking of emulators, recent versions of qemu-x86 expect the firmware to initialize the LAPIC, which we now do.

The ongoing effort to move CPU microcode into CBFS (and to store these as binaries in 3rdparty/blobs instead of header files in the main sources) saw some progress.

Lots of interesting things were omitted above. Full post:

AMD Secure Processor

AMD recently posted on Twitter about giving answers to IT security pros:

It points to a video on the AMD Secure Processor:

More Information on AMD’s security plans:

(I hope part of AMD’s security plans also include provide us a tool like — or a port of — CHIPSEC, to help their partners ship secure systems, and for owners to verify the systems’ firmware vulnerabilities, initially, and over time. Personally, I’ve found that once you have a tool like that to help you with HW/FW verification, you get nervous running a system with a CPU that doesn’t have without similar tools to verify that system. Dealing with security at design-time is nice, but having a run-time tool to test things is also very nice.)

AMI MegaRAC gets DMTF Redfish support

This week at Intel Developer Forum (IDF), AMI showcased their MegaRAC manageability solutions. MegaRAC is AMI’s Remote Management Firmware family of products for both in-band and out-of-band management, including supporting IPMI, Intel AMT, AMD systems with DMTF DASH. Amongst the new features of MegaRAC SP-X are DMTF Redfish support, and Intel(R) Innovation Engine support.

I don’t know much about Intel’s new “Innovation Engine” is yet, so I’ll excerpt one paragraph from the AMI press release:

“The Innovation Engine is a small, embedded, Intel-architecture processor and I/O subsystem built into future Intel data center platforms,” said Lisa Spelman, General Manager of Data Center Marketing at Intel. “Firmware such as MegaRAC PM-X running on the IE can improve or differentiate the system-builders’ platforms in a wide range of ways, including manageability, cost reduction or security.”

Maybe this means that AMI is the second vendor to support Redfish, after HP?

Read AMI’s full press release here:

AMD adds Absolute ComputeTrace support

Today AMD joins Intel in adding Absolute’s CompuTrace technology into their systems:

Absolute collaborates with AMD to extend benefits of persistence technology
Vancouver, Canada: August 18, 2015– Absolute® Software Corporation (TSX:ABT), the industry standard for persistent endpoint security and data risk management solutions for computers, laptops, tablets and smartphones, today announced an agreement with Advanced Micro Devices, Inc. (AMD) to incorporate Persistence® technology by Absolute into AMD chip designs.
Under the terms of this agreement, Absolute and AMD will provide an enhanced security offering by embedding patented Persistence technology directly into AMD x86 APU technologies.
“In the interest of improving the privacy and security of our customers, we have been steadfast in our commitment to evolve security offerings through our technology,” said Roy Taylor, corporate vice president, Alliances, AMD. “We are excited to work with Absolute to leverage its unique Persistence technology by integrating this security functionality into AMD processors.”
“AMD is a long-tenured leader in the semiconductor industry with a keen focus on advancing security offerings on the devices they power,” said Geoff Haydon, chief executive officer, Absolute. “By working together, we can explore new ways to advance Persistence technology and deliver a higher level of data and device security to AMD and Absolute customers.”
Persistence technology by Absolute is embedded into the core of devices at the factory. Once activated, Persistence technology provides a reliable two-way connection so IT can confidently manage mobility, investigate potential threats, and take action if a security incident occurs.