[…]Through ongoing collaboration with industry researchers AMD became aware that, if using the user-selectable AMD secure encryption feature on a virtual machine running the Linux operating system, an encryption key could be compromised by manipulating the encryption technology’s behavior.[…]
This vulnerability was discovered and reported to AMD by Cfir Cohen of the Google Cloud security team.
Last updated in 2017, it used to work on the old TunnelMountain desktop systems, I’ve been meaning to see if it works on MinnowBoard2 systems. And this is Intel-centric (and I presume it may also work on AMD), but, I’m not aware of ARM — nor UEFI Forum’s Tianocore — having a similar offering, which I’d like to be able to use on a UEFI-based Rasberry Pi. HOWEVER… I just noticed this, which came out LAST YEAR, somehow I missed it, an open source solution!!
This is a open code replacement for Intel’s binary only GDB server that comes as part of the ‘Intel UEFI Development Kit Debugger Tool’. Since that tool is Intel x86/64 Linux/Windows only this allows more flexibility. E.g. you can run this on any ARM based SoC with python3 and a USB OTG port connected directly to your target via a USB2.0 EHCI Debug port using the Linux USB OTG Debug Port gadget. You can then connect to that target remotely from your build box, etc. This also allows you to tweak the debugger itself. I’ve already added some additional functionality here to assist when using SourceLevelDebugPkg on non-EDK2 (i.e. no source available) firmwares such as AMI Aptio IV.
BOOT SECURITY MODES AND RECOMMENDATIONS Modern computing platforms provide a variety of boot options. The security implications, advantages, and disadvantages are rarely identified in documentation. Some configuration options, such as Secure Boot and Trusted Platform Module (TPM) 1 may appear redundant despite serving complementary roles. Six different configurations are compared below. Recommendations for different use cases are presented at the end of this document.
It appears the coreboot project has 2 Google Summer of Code projects going, one is this project, addressing security issues found by Coverity!
[…]My project is on making coreboot Coverity clean. Coverity is a free static-analysis tool for open source projects that searches for common coding mistakes and errors, such as buffer overruns, null pointer dereferences, and integer overflow. Coverity automatically analyzes the coreboot codebase and flags issues it finds, and my job is to classify them into bugs and false-positives and patch them if I can. You can check the Coverity overview for coreboot here, though seeing the issue tracker itself requires registration. At the beginning of the summer, coreboot had over 380 flagged issues, but it’s now down to 303, so we’re making progress! I plan to address 20-30 issues per week depending on the source component, which so far has gone surprisingly well (surprising, in the sense that coming into the summer I knew very little about coreboot or firmware development in general).[…]
The US DoD has a new grant offered for a side-channel attack tool:
The Defense Advanced Research Projects Agency (DARPA) Small Business Programs Office (SBPO) is issuing an SBIR/STTR Opportunity (SBO) inviting submissions of innovative research concepts in the technical domain of side channel security. In particular, DARPA is interested in the feasibility of effective pre-silicon side channel and fault injection estimation. These vulnerabilities are of interest to this program only in the context of emissions from the parts of the design that perform on-chip cryptographic functions. This would permit these vulnerabilities to be identified and reduced to acceptable constraints at design time rather than with a costly chip re-spin after fabrication and test.
[…]The DARPA Common Evaluation Platform (CEP) is a publicly available RISC-V based System-on-a-Chip (SoC). It will be used as a reference design and may have to be extended for the purposes of this program. The reference point for the current state of the art of side channel attack simulation technology will be based on transistor level simulation with SPICE. All the baseline metrics will be based on leakage sources found with SPICE simulation of a meaningful number of traces on the cryptographic block(s) within the CEP.[…]