Uncategorized

AMD updated AGESA?

There are news reports that AMD AGESA has been updated. AMD has a developer section on their web site, but I wish they included a section with news on AGESA, like Intel FSP site does.

https://www.dvhardware.net/article66244.html
https://www.bit-tech.net/news/hardware/2017/03/21/amd-ryzen-fma3-fix-promise/1
https://www.overclock3d.net/news/cpu_mainboard/amd_has_reportedly_released_new_agesa_microcode_for_ryzen/1
https://www.hardocp.com/news/2017/03/20/new_amd_agesa_microcode_in_wild_uefi

https://en.wikipedia.org/wiki/AGESA

Standard
Uncategorized

UEFI gets AMD Secure Encrypted Virtualization (SEV) support

AMD has submitted a similar patch to the Linux kernel, now there is support for AMD SEV in UEFI.

[RFC PATCH v1 0/5] x86: Secure Encrypted Virtualization (AMD)

This RFC series provides support for AMD’s new Secure Encrypted Virtualization (SEV) feature. SEV is an extension to the AMD-V architecture which supports running multiple VMs under the control of a hypervisor. The SEV feature allows the memory contents of a virtual machine (VM) to be transparently encrypted with a key unique to the guest VM. The memory controller contains a high performance encryption engine which can be programmed with multiple keys for use by a different VMs in the system. The programming and management of these keys is handled by the AMD Secure Processor firmware which exposes a commands for these tasks. SEV guest VMs have the concept of private and shared memory.  Private memory is encrypted with the guest-specific key, while shared memory may be encrypted with hypervisor key.  Certain types of memory (namely instruction pages and guest page tables) are always treated as private memory by the hardware. For data memory, SEV guest VMs can choose which pages they would like to be private. The choice is done using the standard CPU page tables using the C-bit, and is fully controlled by the guest. Due to security reasons all the DMA operations inside the  guest must be performed on shared pages (C-bit clear). Note that since C-bit is only controllable by the guest OS when it is operating in 64-bit or 32-bit PAE mode, in all other modes the SEV hardware forces the C-bit to a 1. KVM SEV RFC [1] extends the KVM_FEATURE cpuid instruction to indicate whether SEV is enabled. When SEV is enabled then OVMF can use cpuid Fn8000_001F[BX] to get the C-bit position in PTE.

AMD Memory Encryption whitepaper:
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf

AMD64 Architecture Programmer’s Manual (SME is section 7.10, SEV is section 15.34):
http://support.amd.com/TechDocs/24593.pdf

Secure Encrypted Virutualization Key Management:
http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf

KVM Forum Presentation:
http://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf

[1] http://marc.info/?l=linux-mm&m=148846752931115&w=2

More info:
https://lists.01.org/mailman/listinfo/edk2-devel

Standard
Uncategorized

Nikolaj on AMD AGESA/PSP

Nikolaj Schlej made a comment on the recent Snowden/AMD thread. The comment is on Twitter, so it is in multiple messages. I hope that AMD proves him wrong, AMD can change course, so can Intel, if they choose.

Standard
Uncategorized

Users ask firmware vendors for open source option

Vendors, your compiled code is an firmware attack vector, and makes it harder to trust your product. Secure Boot and signed images are not silver bullets. If you made golden images available, as per NIST 147, we could at least tell if your blobs have changed. But trusting blobs is not enough, there’s enough HW/FW vulnerabilities, and opportunities for attackers to subvert the supply chain. Only open source firmware will solve the firmware blob security problem. Intel has FSP, AMD has AGESA. All IBVs ship closed-source products, no open source vendors, and OEMs/IHVs ship closed-source drivers. Giving us an open source option would solve this problem. IBM claims the OpenPOWER is blob-free, but I’ve yet to verify this. RISC-V is also an ISA that also may be blob-free at the firmware level, depending on the manufacturer. Both OpenPOWER and RISC-V may offer some alternatives to current processors, if they wish to keep with status quo. I hope to see more security standards require the option to build firmware from source, and user ability to reinstall from their own locally-compiled version. And at least requiring that vendors ship hashes for all the blobs they ship.

 

Dear AMD, could you please release the Platform Security Processor (PSP) source code to the Coreboot / Libreboot project? (or publicly)
[…]
Thanks for the inquiry. Currently we do not have plans to release source code but you make a good argument for reasons to do so. We will evaluate and find a way to work with security vendors and the community to everyone’s benefit.
–AMD_jamesProduct Manager 487 points 4 hours ago 

https://www.coreboot.org/Binary_situation https://libreboot.org/faq/#amd

 

Standard
Uncategorized

Schneier: avoid Intel/AMD hardware, Intel ME, and UEFI

[[UPDATE: See comment from one reader, I mistakingly took below quote to be from Bruce, where it is apparently from someone else. Oops.]]

Bruce Schneier has a new blog post on citizen cybersecurity, including advice for non-US citizens to avoid blobs in firmware.

I hope Intel and AMD are reading this. Are the patents in the IP you’re protecting in your FSP and AGESA binaries really worth the security risks you’re enabling for attackers to all of your systems? Open-sourcing your blobs will reduce this attack vector and make your products more trustworthy, and reduce the potential market loss to RISC-V and OpenPOWER, which by contrast to Intel/AMD have blob-free firmware potential.  In addition to criminal use by cybercriminals, backdoors can be “legally” misused by tyrants, bigly. Hidden backdoor management processes like Intel ME should be owner-controllable, including the ability to remove/disable it. How can I use NIST 147 guidance to check the hashes of the hundreds of blobs within the FSP/AGESA packages? The are numerous supply-chain opportunities for firmware attackers to subvert these blobs, at the IHV, OEM, ODM, IBV, some of which also have source access to these packages and modify them (for example Purism modifies FSP for their laptops, but they can’t publish their code, due to Intel NDA).

New Rules on Data Privacy for Non-US Citizens”
[…]
“- build firewalls everywhere, if possible based on non-Intel, non-AMD too, hardware platforms or at least supporting old, non-Intel ME and non-UEFI, firmware;”

I

https://www.schneier.com/blog/archives/2017/01/new_rules_on_da.html

 

See-also:

https://firmwaresecurity.com/2015/12/23/itls-stateless-laptop-proposal/

Standard
Uncategorized

FSF: back the Raptor Talos Secure Workstation

A message from Donald Robertson of the Free Software Foundation, quoted verbatim:

Support the Talos Secure Workstation by January 14th Raptor Computing Systems is crowdfunding on Crowd Supply to produce, from the ground up, a high-powered computer with no proprietary software or firmware blobs called the Talos Secure Workstation. The project’s decision to raise funds via [Crowd Supply][0] means that you can support their work with anonymous payments, and without the use of [proprietary JavaScript][1]. We wrote about this project previously, and encouraged people to [voice their support][2]. While there are several companies that offer refurbished computers that have been freed to [Respect Your Freedom][3], the Talos Secure Workstation will be built from its inception with freedom in mind. But in order for that to happen, the project needs your help to meet their fund raising goal. The project has set a crowdfunding goal of $3.7 million and still has a ways to go to reach that mark. It may seem like they are asking for a lot of money, but relative to the scope of what the folks at Raptor Computing are trying to accomplish, it is a small amount. As Raptor Computing Systems Senior Electrical Engineer Timothy Pearson explained:

‘Large, complex systems such as Talos require minimum order quantities to be met for the component parts in use, in addition to R&D expenditure for prototyping, validation, and conformance testing. We have set the goal at the minimum level required to ensure that we can not only design the Talos systems, but also purchase the parts needed to manufacture these complex machines.’

They need every dollar they can get to make this system a reality. It is a difficult goal, but also one that is critical for the future of free computing. As they note in their explanation[4] of the problem:

‘As of this writing, all currently manufactured, low- to mid-range and higher x86 devices, with the exception of two obsolete AMD CPUs, incorporate a security processor that is cryptographically signed, updateable, unauditable, and for which no source code or documentation has been made public. Worse, these security processors must load and continually execute this signed firmware for the system to either be brought online (AMD) or for it to remain operational (Intel).’

If we want a future in which we can continue to have fully free systems that run only free software, we have to build that future ourselves. The Talos Secure Workstation is a proposed system to help secure that future. Their plans are to create a device that will meet the criteria for [Respects Your Freedom][3] certification, but in order for their plans to come to fruition, they need your help. You can support their work by backing the project via their [crowdfunding page][0], or even better, by purchasing a mainboard andaccessory package. Every little bit counts. Will you help support the future of free computing?

[0]: https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstation
[1]: https://www.gnu.org/philosophy/javascript-trap.en.html
[2]: https://www.fsf.org/blogs/licensing/interested-in-a-powerful-free-software-friendly-workstation
[3]: https://www.fsf.org/resources/hw/endorsement/respects-your-freedom
[4]: https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstation/updates/a-word-on-lockdown

 

Standard
Uncategorized

AMD Secure Encrypted Virtualization (SEV) patch for Linux kernel

Brijesh Singh of AMD submitted a 28-part patch to the Linux-(kernel,efi,kvm,…) mailing lists, with a patch for the the Linux kernel to support AMD’s Secure Encrypted Virtualization (SEV), which relies on the recent AMD Secure Memory Encryption (SME) patch by Tom Lendacky of AMD. I’m excerpting the intro text from part 1/28:

[RFC PATCH v1 00/28] x86: Secure Encrypted Virtualization (AMD)

This RFC series provides support for AMD’s new Secure Encrypted Virtualization (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFC.

SEV is an extension to the AMD-V architecture which supports running multiple VMs under the control of a hypervisor. When enabled, SEV hardware tags all code and data with its VM ASID which indicates which VM the data originated from or is intended for. This tag is kept with the data at all times when inside the SOC, and prevents that data from being used by anyone other than the owner. While the tag protects VM data inside the SOC, AES with 128 bit encryption protects data outside the SOC. When data leaves or enters the SOC, it is encrypted/decrypted respectively by hardware with a key based on the associated tag.

SEV guest VMs have the concept of private and shared memory.  Private memory is encrypted with the  guest-specific key, while shared memory may be encrypted with hypervisor key.  Certain types of memory (namely instruction pages and guest page tables) are always treated as private memory by the hardware. For data memory, SEV guest VMs can choose which pages they would like to be private. The choice is done using the standard CPU page tables using the C-bit, and is fully controlled by the guest. Due to security reasons all the DMA operations inside the  guest must be performed on shared pages (C-bit clear).  Note that since C-bit is only controllable by the guest OS when it is operating in 64-bit or 32-bit PAE mode, in all other modes the SEV hardware forces the C-bit to a 1.

SEV is designed to protect guest VMs from a benign but vulnerable (i.e. not fully malicious) hypervisor. In particular, it reduces the attack surface of guest VMs and can prevent certain types of VM-escape bugs (e.g. hypervisor read-anywhere) from being used to steal guest data.

The RFC series also includes a crypto driver (psp.ko) which communicates with SEV firmware that runs within the AMD secure processor provides a secure key management interfaces. The hypervisor uses this interface to enable SEV for secure guest and perform common hypervisor activities such as launching, running, snapshotting , migrating and debugging a  guest. A new ioctl (KVM_SEV_ISSUE_CMD) is introduced which will enable Qemu to send commands to the SEV firmware during guest life cycle.

The RFC series also includes patches required in guest OS to enable SEV feature. A guest OS can check SEV support by calling KVM_FEATURE cpuid  instruction.

The following links provide additional details:

AMD Memory Encryption whitepaper:

http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf

AMD64 Architecture Programmer’s Manual:
http://support.amd.com/TechDocs/24593.pdf
SME is section 7.10
SEV is section 15.34

Secure Encrypted Virutualization Key Management:
http://support.amd.com/TechDocs/55766_SEV-KM%20API_Spec.pdf

See the full patch for more information.
https://lkml.org/lkml/2016/8/22/960

Standard