Tag: UEFI

Intel patch for UEFI pre-memory DMA protection in PEI

~ hucktech ~ Leave a comment

Intel has submitted a V3 patch to the tianocore EDK2 project, with additional DMA protection for UEFI on Intel systems.

[PATCH V3 0/2] IntelSiliconPkg: Add Pre-Memory DMA protection in PEI

V3:
1) update the function comments of InitDmar()
2) update the function comments of SiliconInitializedPpiNotifyCallback()
3) remove duplicated BAR debug message.
4) fix the size field in the mPlatformVTdNoIgdSample structure.

V2:
Minor enhancement: Replace IsDmaProtectionEnabled() by GetDmaProtectionEnabledEngineMask(), for better code management.

V1:
This series patch adds Pre-Memory DMA protection in PEI. The purpose is to make sure when the system memory is initialized, the DMA protection takes effect immediately. The IntelVTdPmrPei driver is updated to remove the global variable and add VTD_INFO_PPI notification. The VTdInfoSample driver is updated to install the initial VTD_INFO_PPI before memory init, and add more content after memory init by reinstalling VTD_INFO_PPI. This patch is validated on one Intel Client kabylake platform.

For more info, see full patch:
https://lists.01.org/mailman/listinfo/edk2-devel

Google wants servers without Intel ME and UEFI

~ hucktech ~ 2 Comments

Golem has a story about the recent Google presentation at OSSEU2017:

From Google Translation of German text:

Google wants servers without Intel ME and UEFI
by Sebastian Grüner
According to the motto “Are you afraid?” a team of Google’s coreboot developers is working with colleagues to make Intel’s ME and the proprietary UEFI harmless in servers. And probably with success.[…]

Click to access Replace%20UEFI%20with%20Linux.pdf

https://www.golem.de/news/freie-linux-firmware-google-will-server-ohne-intel-me-und-uefi-1710-130840.html

https://osseu17.sched.com/event/ByYt/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google

Ronald Minnich auf dem Open Source Summit in Prag

Maybe I missed it, but I didn’t see the video of this presentation archived.

 

ESET adds UEFI Scanner

~ hucktech ~ Leave a comment

ESET’s internet security just keeps getting better thanks to new IoT protection and UEFI Scanner
October 24, 2017

ESET, a global leader in cybersecurity celebrating 30 years of continuous IT innovation, today launched its latest consumer security product portfolio for Windows. The enhanced solutions are designed to protect people from an expanding array of cyberthreats, data theft, malware and viruses. The features released today enhance the security capabilities of ESET NOD32 Antivirus, ESET Internet Security and ESET Smart Security Premium. The Unified Extensible Firmware Interface (UEFI) Scanner, included in all three products, adds elevated levels of malware protection by detecting and removing threats that potentially launch before the operating system boots up. Threats, including rootkits and ransomware, target vulnerabilities in the UEFI and are highly persistent, even surviving after an operating system is reinstalled. ESET’s UEFI Scanner prevents these types of attacks.[…]

https://www.eset.com/us/about/newsroom/press-releases/esets-internet-security-just-keeps-getting-better-thanks-to-new-iot-protection-and-uefi-scanner/

http://www.businesswire.com/news/home/20171024005379/en/ESET%E2%80%99s-Internet-Security-New-IoT-Protection-UEFI

 

MSI-GT7x-VGA-Switch: toggle Intel/Nvidia VGA from UEFI Shell

~ hucktech ~ Leave a comment

MSI-GT7x-VGA-SWITCH: Selects VGA from LINUX or EFI!

These programs or batch scripts will let you swtch the VGA from INTEL to NVIDIA (or the opposite). This is possible at the moment only from Windows (bad choice MSI!). Now it will also be possible from Linux or directly from an EFI SHELL! Intel.nsh and nvidia.nsh are two EFI Shell scripts that can be run directly from EFI shell. Just “make intel” and “make nvidia” to compile the 2 C sources. A reboot is needed afterwards because the VGA is switched by BIOS at boot time.[…]

https://github.com/Zibri/MSI-GT7x-VGA-SWITCH

Microsoft renames VBS

~ hucktech ~ Leave a comment

https://twitter.com/aionescu/status/922539069292400640

https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs

It is funny and also sad to see the new MSFT docs include data about how long it’ll take to read the page, for those potential readers who’re worried it’ll be too long to read. “4 minutes to read”. I wonder what the current attention span is, that forces writers to dumb down documents for reduced attention spans of modern readers? 😦

https://blogs.technet.microsoft.com/mmpc/2017/10/23/hardening-the-system-and-maintaining-integrity-with-windows-defender-system-guard/

 

gnu-efi-applets

~ hucktech ~ Leave a comment

The GNU-EFI-Applets project appears to be about a month old. There are a LOT of UEFI applications ported in this project, including a LISP interpreter. It also includes “efilibc”, another LibC implementation from musl or the EADK libraries. These build with GNU-EFI, not Tianocore/EDK2 build environment.

Name: gnu-efi-applets
Version: 3.0.3
Release: 3
Summary: Building Applets using GNU-EFI

Some missing applets for the EFI system.

Building Environment for building GNU-EFI applets.

Tue Sep 19 2017
Wei-Lun Chao <bluebat@member.fsf.org> – 3.0.3
First release

https://github.com/bluebat/gnu-efi-applets
https://github.com/bluebat/gnu-efi-applets/tree/master/efilibc.applets
https://github.com/bluebat/gnu-efi-applets/tree/master/efilibc

 

UK gov guidance on automating UEFI Firmware Updates

~ hucktech ~ Leave a comment

https://twitter.com/CysekSentinel/status/920640632271409152

 

Automating UEFI Firmware updates

In our previous blog post we talked about the state of UEFI firmware running on Windows laptops attached to one of our research networks. In case you don’t recall the conclusion: We were surprised that many of the devices were running out-of-date firmware and decided to investigate ways in which automated UEFI firmware updates could be scaled to meet the needs of an Enterprise. This blog tells the story of what happened next.[…]

https://www.ncsc.gov.uk/blog-post/automating-uefi-firmware-updates

 

UEFI security presentation at Seattle DC206 Meeting

~ hucktech ~ Leave a comment

If you missed the Intel presentation from BlackHat Briefings this summer, and if you are in the Seattle area this Sunday, Vincent Zimmer of Intel will be reprising this presentation at the DC206 Meeting at the Black Lodge Research hackerspace.

https://www.dc206.org/?p=216

What: Oct DC206 Meeting: Firmware is the New Black
When: October 15th, 1-3pm
Who: Vincent Zimmer
Where: Black Lodge Research

Firmware is the New Black – Analyzing Past Three Years of BIOS/UEFI Security Vulnerabilities

In recent years, we witnessed the rise of firmware-related vulnerabilities, likely a direct result of increasing adoption of exploit mitigations in major/widespread operating systems – including for mobile phones. Pairing that with the recent (and not so recent) leaks of government offensive capabilities abusing supply chains and using physical possession to persist on compromised systems, it is clear that firmware is the new black in security. This research looks into BIOS/UEFI platform firmware, trying to help making sense of the threat. We present a threat model, discuss new mitigations that could have prevented the issues and offer a categorization of bug classes that hopefully will help focusing investments in protecting systems (and finding new vulnerabilities). Our data set comprises of 90+ security vulnerabilities handled by Intel Product Security Incident Response Team (PSIRT) in the past 3 years and the analysis was manually performed, using white-box and counting with feedback from various BIOS developers within the company (and security researchers externally that reported some of the issues – most of the issues were found by internal teams, but PSIRT is involved since they were found to also affect released products).

https://www.blackhat.com/us-17/briefings.html#firmware-is-the-new-black-analyzing-past-three-years-of-bios-uefi-security-vulnerabilities
http://vzimmer.blogspot.com/2017/08/black-hat-usa-2017-firmware-is-new-black.html

Click to access BlackHat2017-BlackBIOS-v0.13-Published.pdf

https://blacklodgeresearch.org/

https://www.facebook.com/events/1611758852222280/

UEFI slides from SOURCE Seattle uploaded

~ hucktech ~ Leave a comment

Last week I gave a presentation at SOURCE Seattle Conference, on defensive UEFI tools/guidance, mostly talking about NIST 147’s lifecycle, and how to use tools like (CHIPSEC, acpidump, FWTS) to look for signs of firmware attacks.

As I understand it, SOURCE Conference will have video of this presentation online sometime in the near future.

https://www.sourceconference.com/copy-of-seattle-2016-agenda-details

Slides have been uploaded to this blog, and are available here:.srcsea17. (PreOS Security will have an archive of all of our post-conference materials on Github shortly.)

At the conference, Bryan of the Brakeing Security podcast interviewed PreOS Security co-founder Paul English and myself, along with some other SOURCE Seattle speakers. I am not sure when that podcast is queued up for. I hate public speaking in general, but I cringe at completely unprepared interviews like this podcast. Sorry I didn’t have better concise answers to the questions put to me. I think the normal podcast drinking game is to drink whenever you hear ‘um’ or ‘I mean’. Be careful if you’re playing that game during my brief audio clips. 😦

http://www.brakeingsecurity.com/

http://brakeingsecurity.com/rss

@bryanbrake

 

A slide in the presentation pre-announces an upcoming tool we’re working on. That tool should be ready in a few weeks, more details soon.

v3x4 – UEFI driver giving turbo boost to Intel Xeons

~ hucktech ~ Leave a comment

Intel(R) Xeon(R) Processor Max Effort Turbo Boost UEFI DXE driver

Programs Haswell-E/EP Xeon(R) processors (cpuid = 306F2h) on X99 (single) and C612 (dual) platforms to allow for maximum all-core turbo boost for all cores regardless of whether there are motherboard options present for overclocking/voltage control or not. For example, the 18-core Xeon(R) E5-2696 v3 processor has set from the factory an all-core turbo of 2.8GHz. This driver programs the highest un-fused ratio (i.e. the 1C Turbo bin) as the new Turbo bin for all boost configurations including all-core turbo. In other words, the 1C turbo bin becomes the all-core turbo bin and the E5-2696 v3 processor now demonstrates an all-core turbo of 3.8GHz!

Allows for per-package, dynamic undervolting (retains PCU control while applying a fixed negative Vcore offset) IA (i.e. Core), CLR (CBo/LLC/Ring) a.k.a Uncore, and System Agent (SA) voltage domains independently which provides for higher all-core sustained clocks during heavy workloads, including AVX2 workloads

Allows for setting static Uncore ratio for maximum performance (lowest typical access latency and accompanying maximum throughput) or setting to limit less than maximum (typical 30x). It is possible to trade cache speed for Core speed and studies show that 100MHz of Core speed-up is roughly equivalent to 1000MHz of cache speed-up. That being said, lowering your Uncore power budget to make it to that next-higher Core speed bin is often a worthwhile trade-off

Allows to disable CPU SVID telemetry (a.k.a. “PowerCut”) which may reduce or remove altogether TDP power limitations for some system combinations. Allows to set a fixed VCCIN voltage (not recommended if available to be set in BIOS)

Driver is designed to work on up to 8S systems. Verified functional on multiple 1S and 2S systems with accompanying modified BIOS (remove any microcode revision update patches)

May work for other Intel(R) Xeon(R) processor types/steppings including Broadwell-E/EP (untested as of yet), and possibly even SKY-E/EP (also, untested as of yet)
[…]

https://github.com/freecableguy/v3x4

Intel Whitepaper updated: Using IOMMU for DMA Protection in UEFI Firmware

~ hucktech ~ Leave a comment

We recommend firmware developers review this docment to understand threats from unauthorized internal DMA, as well as DMA from non-PCI devices that platform firmware may configure. Using an IOMMU such as Intel VT-d allows fine-grain control of memory protection without broadly disabling bus-mastering capabilities in the pre-boot space.

Note: this whitepaper was originally published under the title “A Tour beyond BIOS Using Intel® VT-d for DMA Protection in UEFI BIOS” in January 2015.

https://firmware.intel.com/blog/updated-whitepaper-using-iommu-dma-protection-uefi-firmware

Click to access Intel_WhitePaper_Using_IOMMU_for_DMA_Protection_in_UEFI.pdf

kernelstub

~ hucktech ~ 2 Comments

Ian Santopietro of System76 has a Python-based tool called kernelstub, which boots Linux using the Linux Stub bootloader instead of an external bootloader.

Kernelstub is a basic program enabling booting from the kernel’s built-in EFI Stub bootloader. It keeps the ESP and NVRAM up to date automatically when the kernel updates and allows for modifying and setting the boot parameters/kernel options stored in NVRAM. Kernelstub is a basic program enabling booting from the kernel’s built-in EFI Stub bootloader. It keeps the ESP and NVRAM up to date automatically when the kernel updates and allows for modifying and setting the boot parameters/kernel options stored in NVRAM. It works by detecting certain information about the running OS, kernel, storage devices, and options, then combines all of that together into a unified entity, then calls efibootmgr to register the kernel with the NVRAM. It also copies the latest kernel, initrd.img to the EFI System Partition so that UEFI can find it. It will also store a copy of the kernel’s command line (/proc/cmdline) on the ESP in case of necessary recovery from an EFI shell.

https://launchpad.net/kernelstub

He just gave a talk/demo of it at SeaGL:

https://osem.seagl.org/conferences/seagl2017/program/proposals/326

His presentation mentioned this blog in the ‘more info’ slide! 🙂

VisualUEFI udpated

~ hucktech ~ Leave a comment

https://github.com/ionescu007/VisualUefi

Windows UEFI & ACPI Development

more on Google NERF

~ hucktech ~ Leave a comment

Google NERF looks interesting, they keep UEFI’s PI but replace the UEFI layers with Linux kernel, and the code is written in Go. Looks like they’re focusing on removing dynamic code in UEFI and SMM. Unclear about their position towards dynamic code in ACPI, as well as PCIe (eg, PCIleech-style attacks).

The slides from the recent North American OSS presentation are online, but I can’t find the video online:

Click to access Linuxcon%202017%20NERF.pdf

There’s an upcoming European OSS event upcoming:

Replace Your Exploit-Ridden Firmware with Linux
Ronald Minnich, Google

With the WikiLeaks release of the vault7 material, the security of the UEFI (Unified Extensible Firmware Interface) firmware used in most PCs and laptops is once again a concern. UEFI is a proprietary and closed-source operating system, with a codebase almost as large as the Linux kernel, that runs when the system is powered on and continues to run after it boots the OS (hence its designation as a “Ring -2 hypervisor”). It is a great place to hide exploits since it never stops running, and these exploits are undetectable by kernels and programs. Our answer to this is NERF (Non-Extensible Reduced Firmware), an open source software system developed at Google to replace almost all of UEFI firmware with a tiny Linux kernel and initramfs. The initramfs file system contains an init and command line utilities from the u-root project (http://u-root.tk/), which are written in the Go language.

https://osseu17.sched.com/event/ByYt/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google
https://ossna2017.sched.com/event/BCsr/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google
https://osseu17.sched.com/event/ByYt/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google

http://u-root.tk/
https://github.com/u-root/u-root

Google NERF: Non-Extensible Reduced Firmware