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
Uncategorized

more info for AMD Secure Memory Encryption (SME) for Linux

A follow-up to:

https://firmwaresecurity.com/2016/04/26/amds-secure-memory-encryption-sme-and-secure-encrypted-virtualization-sev/

Tom Lendacky of AMD posted v2 of a 20-part patch to most of the linux-kernel (and other) lists, adding support for AMD Secure Memory Encryption (SME), adding more documentation about AMD SME.

Secure Memory Encryption (SME) is a feature found on AMD processors.
SME provides the ability to mark individual pages of memory as encrypted using the standard x86 page tables.  A page that is marked encrpyted will be automatically decrypted when read from DRAM and encrypted when written to DRAM.  SME can therefore be used to protect the contents of DRAM from physical attacks on the system.
[…]
BOOT data (such as EFI related data) is not encyrpted when the system is booted and needs to be accessed as non-encrypted.  Add support to the early_memremap API to identify the type of data being accessed so that the proper encryption attribute can be applied.  Currently, two types of data are defined, KERNEL_DATA and BOOT_DATA.
[…]
Documentation/x86/amd-memory-encryption.txt

http://vger.kernel.org/majordomo-info.html

Also check out the older v1 patch posting on the lists, there was some interesting technical discussion. The above previous blog post has a pointer to that discussion, as well as some other AMD specs.

Standard
Uncategorized

AMD Zen

Click on tweet for video of event:

http://www.amd.com/en-us/innovations/software-technologies/zen-cpu
http://www.amd.com/en-us/press-releases/Pages/zen-processor-core-2016aug18.aspx
https://community.amd.com/thread/204259

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. […]

 

Standard
Uncategorized

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.

Tools for DMTF DASH

Tools for DMTF DASH

Standard
Uncategorized

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%.

http://www.ieee-security.org/TC/SP2014/papers/StealingWebpagesRenderedonYourBrowserbyExploitingGPUVulnerabilities.pdf

Standard