Tag: Intel

Insyde updates InsydeH2O and Supervyse

~ hucktech ~ Leave a comment

This week at Intel Developer Forum (IDF), Insyde Software announced support of Intel’s new “Innovation Engine”. Insyde has a Supervyse Systems Management product, as well as their InsydeH2O UEFI BIOS. Insyde announced that both of these products will fully-leverage Intel’s Innovation Engine, a newly-announced new processor and IO subsystem targeting data center platforms. Excerpting their press release:

“The Innovation Engine gives us tremendous opportunity to extend our BIOS and BMC product offerings,” said Stephen Gentile, Sr. Vice President, Strategy at Insyde Software. “More importantly, this powerful and open resource gives us a new framework for products targeted at next-generation data center servers,” added Gentile.

“The Innovation Engine is a new way that developers can tap Intel technology to improve the capabilities of data center solutions,” said Lisa Spelman, General Manager of Data Center Marketing at Intel. “Through working with our ecosystem partners like Insyde, our data center customers will have comprehensive hardware and software solutions that will drive new innovations and platform differentiation,” added Spelman.

More information:

http://www.insydesw.com/press_news/press-releases/insyde%C2%AE-software-helps-drive-innovation-future-intel%C2%AE-data-center-platform

AMI MegaRAC gets DMTF Redfish support

~ hucktech ~ Leave a comment

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:

http://www.ami.com/news/press-releases/?PressReleaseID=325&/American%20Megatrends%20to%20Showcase%20MegaRAC%20Manageability%20Solutions%20for%20Rack%20Scale%20Architecture%20and%20Innovation%20Engine%20at%20IDF%20San%20Francisco%202015/
https://www.megarac.com/live/document-library/
http://www.ami.com/products/remote-management/
https://firmwaresecurity.com/tag/redfish/

Intel SMI Transfer Monitor (STM) for SMM

~ hucktech ~ Leave a comment

Recently, Intel announced STM, a way to help secure SMM.

Intel announces STM at IDF

So far, it appears the some of the expert firmware security researchers do not dissapprove of STM, though they wanted it earlier:

https://twitter.com/rootkovska/status/633909806483566592

GlobalPlatform’s TEE Developers Workshop

~ hucktech ~ Leave a comment

Next month is the GlobalPlatform TEE conference in California; they’re also hosting a 1-day developer workshop on October 12th. GlobalPlatform, Trustonic, Intel, and Linaro are presenting; the agenda looks interesting:

1) GlobalPlatform
Kevin Gillick, GlobalPlatform Exec. Director
Gil Bernabeu, GlobalPlatform Technical Director
Christophe Colas, VP of Product Marketing at Trustonic and GlobalPlatform Device Committee Chair

2) Trustonic: Scaling Fast and Simply Across Trustonic TEE-based Devices
Rob Dyke, Senior Field Application Engineer, Trustonic

3) Intel: Open-TEE – A Virtual TEE and SDK
Brian McGillion, Security Engineer, Intel
Tanel Dettenborn, Security Engineer, Intel
Thomas Nyman, Doctoral Candidate, Aalto University, Finland
Valentin Manea, Security Engineer, Huawei

4) Linaro: TEE and TA Development the Easy Way
Joakim Bech, Technical Lead, Security Working Group, Linaro

http://www.teeseminar.org/about_the_workshop.asp
https://github.com/Open-TEE

Home


https://wiki.linaro.org/WorkingGroups/Security/OP-TEE

http://www.globalplatform.org/TEEevent/about_the_workshop.asp

Early bird pricing is $199 USD before 30 August 2015. $299 USD after. There is no price distinction between GlobalPlatform members and non-members for this workshop. Organizations sending two or more people will receive $50 discount per student.

Intel ITS

~ hucktech ~ Leave a comment

Intel has a device to help with UEFI testing, the Intelligent Test System (ITS). ITS may have been around for a while, but I just noticed it on the Intel firmware web site. I’m presuming for now that it’s new from IDF, but I may be wrong about that. If you do UEFI testing, you might want to look at this device.

https://firmware.intel.com/learn/its/intel-its

https://designintools.intel.com/product_p/q6ujitshub001.htm

I wonder how it compares to Linaro’s LAVA. LAVA does mostly target ARM devices, but does also target Intel via QEMU, perhaps there are direct Intel targets these days.

https://validation.linaro.org/

Intel announces STM at IDF

~ hucktech ~ Leave a comment

Intel just announced STM at IDF, read Vincent’s blog for more details:

http://vzimmer.blogspot.com/2015/08/smi-transfer-monitor-stm-unleashed.html

https://firmware.intel.com/content/smi-transfer-monitor-stm

https://firmware.intel.com/sites/default/files/STM_Release_1.0.zip

Click to access A_Tour_Beyond_BIOS_Launching_STM_to_Monitor_SMM_in_EFI_Developer_Kit_II.pdf

Click to access STM_User_Guide-001.pdf

AArch64 support for ACPI BERT in Linux

~ hucktech ~ Leave a comment

ACPI is not only in the firmware of Intel-based systems, but it’s also now inside ARM-based systems. Today on the Linaro-ACPI mailing list, there was a patch for ACPI BERT support for AArch64. I think support had already been in for Intel already, unclear how long.

APEI Boot Error Record Table (BERT) support

Under normal circumstances, when a hardware error occurs, kernel will be notified via NMI, MCE or some other method, then kernel will process the error condition, report it, and recover it if possible. But sometime, the situation is so bad, so that firmware may choose to reset directly without notifying Linux kernel. Linux kernel can use the Boot Error Record Table (BERT) to get the un-notified hardware errors that occurred in a previous boot. In this patch, the error information is reported via printk. Once error log is printed out clear error status so it would not be print during next boot again.

ACPI/APEI is designed to verifiy/report H/W errors, like Corrected Error(CE) and Uncorrected Error(UC). It contains four tables: HEST, ERST, EINJ and BERT. The first three tables have been merged for a long time, but because of lacking BIOS support for BERT, the support for BERT is pending until now. Recently on ARM 64 platform it is has been supported. So here we come. The following log is a BERT record after system reboot because of hitting a fatal error.

BERT: Obtained BERT iomem region <00000000fe801000-00000000fe802000> for BERT.
[Hardware Error]: Error record from previous boot:
[Hardware Error]: event severity: fatal
[Hardware Error]:  Error 0, type: fatal
[Hardware Error]:   section_type: memory error
[Hardware Error]:   physical_address: 0x00000000fe800000
[Hardware Error]:   physical_address_mask: 0x0000000000000fff
[Hardware Error]:   card: 0 module: 1 bank: 0 device: 1 row: 1 column: 1 bit_pos

For more information about BERT, please refer to ACPI Specification version 6.0, section 18.3.1.

For more information about this patch, see this thread:
https://lists.linaro.org/pipermail/linaro-acpi/2015-August/005611.html

For more on BERT, also see /src/acpi/bert/bert.c in the FirmWareTestSuite (FWTS).

Click to access ACPI_6.0.pdf

http://www.spinics.net/lists/linux-acpi/msg57384.html
https://lists.linaro.org/mailman/listinfo/linaro-acpi

WPBT attacks from the past: Alex at SyScan12

~ hucktech ~ 1 Comment

The recent Lenovo LSE blunder made most of the world aware of Windows WBPT ACPI table and how the firmware injects an executable into the OS, a feature of Windows that all OEMs are likely using. While the media is wondering about WBPT and why it’s not prominently displayed on many web sites, Xeno of LegbaCore pointed out that Alex Ionescu gave a talk at SyScan 2012 on this specific topic:

ACPI 5.0 Rootkit Attacks Againts Windows 8
Alex Ionescu
This talk will disclose certain new features of the ACPI 5.0 Specification which is now public and was primarily designed to support ACPI on ARM Embedded SoCs for the upcoming release of Windows 8. Some of these new features have important security considerations which have not been traditionally monitored by security products and/or users, specifically in the areas of covert code execution at Ring 0 privileges.

https://www.syscan.org/index.php/download/get/a722b1acb9396d82323da3a78235fdc0/SyScan12Slides.zip
https://www.syscan.org/index.php/archive/view/year/2012/city/sg/pg/program
https://www.syscan.org/index.php/archive/view/year/2012/city/sg/pg/speakers#004
https://www.syscan.org/index.php/download/previous
http://www.alex-ionescu.com/

Thanks for reminding us, Xeno!

RISC-V Raven processor talk at HotChips

~ hucktech ~ Leave a comment

HotChips 2015 is happening in Cupertino, California later this month, 23-25th. Today Krste Asanovic posted a message on the RISC-V blog:

RISC-V at HotChips: Analyst Kevin Krewell has posted a HotChips preview at EE Times, which mentions the RISC-V Raven-3 presentation to be made in the last session at HotChips by Yunsup Lee.  UC Berkeley will again be sponsoring a table at HotChips to promote RISC-V, so please drop by if you’ll be there and want to chat about RISC-V uptake.

Hot Chips is a symposium on High Performance Chips, sponsored by the IEEE Technical Committee on Microprocessors and Microcomputers, in cooperation with ACM SIGARCH. The RISC-V presentation is on the “Raven” processor:

Raven: A 28nm RISC-V Vector Processor with Integrated Switched-Capacitor DC-DC Converters and Adaptive Clocking
by: Yunsup Lee, Brian Zimmer, Andrew Waterman, Alberto Puggelli, Jaehwa Kwak, Ruzica Jevtic, Ben Keller, Stevo Bailey, Milovan Blagojevic, Pi-Feng Chiu, Henry Cook, Rimas Avizienis, Brian Richards, Elad Alon, Borivoje Nikolic and Krste Asanovic, University of Berkeley

The EE Times blog article, by Kevin Krewell of Tirias Research, gives a good overview of all the vendors presenting at HotChips, focusing on the traditional ones (Intel, ARM, AMD, etc.), and calls RISC-V an “odd duck”. 🙂

The last session on Tuesday is traditionally the main “big” processor session. […] The odd duck in the session is an implementation of UC Berkeley RISC-V Vector Processor. Last year the Berkeley contingent showed off RISC-V instruction set in the break area, but now with a real chip, they made it to inside the auditorium. It’s not too often you see a chip design of this integration and complexity coming from academia. What started as a project to give universities a royalty-free and extendable CPU architecture to build on, has gained traction, especially in India and Asia for development purposes.”

RISC-V and Open Hardware aside, there are many other interesting presentations at Hot Chips 2015, including talks from Intel, ARM, AMD, and others. There are a handful of other Open Hardware/Maker-related talks, eg: Adapteva is talking about their Kickstarted chip, and Univerisity of Wisconson’s MIAOW project, an OpenGL API-compatible GPGPU.

http://www.hotchips.org/
https://blog.riscv.org/
http://www.eetimes.com/author.asp?section_id=36&doc_id=1327424

Low-cost UEFI debugging options for Intel

~ hucktech ~ 2 Comments

The other day I asked on the UEFI development list about hardware options for debugging UEFI, for security researchers (many UEFI debugging solutions only target OEMs/IBVs/IHVs). I was mainly thinking about Intel Tunnel Mountain, and related widgets like the Intel ITP-XDP, and other options in addition to AMI’s AMIdebug and Arium’s ITP products. It looks interesting; previously, all I knew of was Arium’s ITP and AMI’s AMIdebug products. Some of the commercial tools (eg, Arium) have new, expensive, closed-source debuggers, and don’t enable use of existing GDB/Windbg skills.

Zachary Gray of of the Intel System Studio debugger team replied with some answers:

Tunnel Mountain is OK but it is a bit old (by Intel standards) If you are looking for a small target for UEFI research purposes I *strongly* recommend the MinnowBoard Max.  This target has a freely available firmware that is mostly public, you can compile the firmware with GCC or MSVC, it is debuggable using JTAG (Arium,  or our Intel System Studio debugger with the ITP-XDP3 probe) and it is also debuggable using the Agent-based solution that is built into the image (cheap and easy!).

With regards to Intel System Studio vs Arium, I would say that the Arium JTAG debugger has a broader feature set that is proportional to their price, but the System Studio JTAG debugger also provides a useful feature set at a lower cost.  We can debug all the UEFI code from reset to boot loader, and also into the OS if you have an interest there as well.  With any of these debug tools you do not need a special compiler, you just use a standard debuggable build of the firmware.

Another even cheaper alternative would be to debug an Intel Galileo board using a low-cost FTDI probe such as an Olimex with the OpenOCD open-source JTAG debug server.  The board + probe would be <$200 and the firmware is publicly available.  For a front-end to the OpenOCD debug server you can use either the Intel System Studio debugger, or simply use GDB.  Some google searches will lead you to some documentation on all this.  The catch is that Galileo is not a “normal” Intel CPU so depending on your research interest the firmware may not present the concepts you are interested in.

Bruce Cran also replied with a lower-cost options:

Another even cheaper alternative, if you don’t need real hardware, is qemu+OVMF. It’s what I use to debug UEFI problems with the PCI driver I  work on (using gdb).

Alternatively, if you don’t need an x86-based system, I believe the BeagleBone/BeagleBoard (with ARM CPU) can be reflashed to edk2 firmware and debugged with a Flyswatter2 – with the main problem likely being being surface-mounting the JTAG header!

I also received some more advice via private email, from a firmware security researcher. Paraphrasing, they felt that the MinnowboardMAX is not much better than the Galileo for UEFI debugging, because it has many more blobs in it’s “open source” BIOS, and the Minnow is harder to debug than Galileo, since modern Atom CPUs are complex. Their advice was low-cost debugging was Galileo over Minnow, $20 for JTAG probe, and free GDB.

Thanks for all the advice!!

Obviously, this post doesn’t cover ARM [much], just Intel and virtual solutions. I’m still learning the best options for ARM-based hardware and UEFI, and will post another article on ARM in the future.

More Information:
https://software.intel.com/en-us/articles/using-intel-system-debugger-with-openocd
https://communities.intel.com/docs/DOC-22203
https://communities.intel.com/message/220257
https://communities.intel.com/message/220383
https://communities.intel.com/thread/48127
https://software.intel.com/en-us/forums/topic/391211
https://software.intel.com/en-us/forums/topic/531765
https://designintools.intel.com/product_p/itpxdp3brext.htm
https://communities.intel.com/community/makers
http://openocd.org/
http://www.minnowboard.org/
https://www.olimex.com/Products/ARM/JTAG/_resources/OpenOCD/
https://www.olimex.com/Products/ARM/JTAG/ARM-USB-OCD-H/
https://www.olimex.com/Products/ARM/JTAG/ARM-JTAG-20-10/
http://www.tincantools.com/wiki/Compiling_OpenOCD

Intel toolsuite supports Linux device software developers

Anatomy of the UEFI Boot Sequence on the Intel Galileo


https://designintools.intel.com/product_p/itpxdp3brext.htm
http://firmware.intel.com/develop/intel-uefi-tools-and-utilities/intel-uefi-development-kit-debugger-tool#overlay-context=develop
https://software.intel.com/en-us/intel-system-studio
https://software.intel.com/en-us/intel-system-debugger
http://tunnelmountain.net/
http://www.dediprog.com/

new tool: Visual UEFI for Windows

~ hucktech ~ 1 Comment

Alex Ionescu just created a new project to help with Visual Studio / EDK-II integration.

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

https://github.com/ionescu007/VisualUefi

Excerpting from it’s readme, VisualUEFI is 3 things:

1) a Solution and set of Visual Studio 2015 Project Files to allow building the official EDK-II without the use of inf files, Python and 50 other build tools, a custom dependency tracker and build system, and twenty other custom pieces of code. The EDK-II is present as a submodule, directly from the official TianoCore Tree, and no changes are done to it.
2) a Solution and couple of Visual Studio 2015 Project Files to show two UEFI sample components: A UEFI Application, and a UEFI Boot Driver. The code is 100% EDK-II compatible, but built with VisualUEFI instead.
3) a working copy of QEMU64 2.3 for Windows, with a fairly recent UEFI 2.5 OVMF Secure Boot ROM. These will updated on an ongoing basis as needed. This is integrated with the Visual Studio 2015 Sample Solution so that pressing F5 will spin up the instance for testing.

You should be able to open the EDK-II.SLN file and build without any issues in Visual Studio 2015. WDK or other 3rd party installations are not needed. Once the EDK-II libraries are built, you should be able to open the SAMPLES.SLN file and build the two samples, which will create UefiApplication.efi and UefiDriver.efi.

You can press F5 (Run/Debug) from within the Sample Solution, which should spin up the QEMU instance with 512MB of ram, and your release directory as a virtual file system accessible through “fs0:”. You can then try loading the driver with “Load fs0:\UefiDriver.efi”. You can verify its presence by using the Drivers or DevTree commands.

Visual UEFI looks like a nice improvement to Microsoft’s Visual Studio IDE. Thanks, Alex!

(This is the kind of thing I kept expecting the UEFI Forum to release, as an Eclipse plugin, like Yocto and some related projects have done.)

What’s the next built-in ACPI attack?

~ hucktech ~ Leave a comment

[UPDATE: just confirmed that ACPI.info’s links page had the WPBT link since 2011. After posting below article, I wondered if the ACPI.info webmaster updated their links page in the last few days…)
https://web.archive.org/web/20111208014141/http://www.acpi.info/links.htm

While the media is currently blaming Lenovo for sloppy Windows QA, they’re also waking up to the reality that Windows has been using for the last few years. Initial Ars Technica and YCombinator posts on the topic quoted the abstract to the spec on a web page that was no longer available, so it sounds conspiratorial.  But the doc has been online since 2011. Besides microsoft.com-based links, the ACPI.info web site maintains a good set of links, including a pointer to the WPBT spec, and other ACPI-related table specs.

http://www.acpi.info/links.htm

The ACPI specs — at least some of them? — are maintained by the UEFI Forum. The UEFI Forum’s web site does NOT have a link to the WPBT spec.

http://www.uefi.org/acpi

I’ll bet there’re a few other existing ‘unknown’ ACPI features hidden on the ACPI.info links page that’ll be ‘discovered’ in the next few months, due to another sloppy OEM or sharp security researcher… From above links URL, here’ s a partial list (I omitted multiple entries which’re specs for other hardware, and some of those might also include ACPI tables) of ACPI tables to attack:

Core System Resources Table, CSRT
Debug Port Table, DBGP
Debug Port Table 2, DBG2
DMA Remapping Table, DMAR
IA-PC High Precision Event Timer Table, HPET
I/O Virtualization Reporting Structure, IVRS
iSCSI Boot Firmware Table, IBFT
Management Controller Host Interface Table, MCHI
Microsoft Software Licensing Tables, MSDM, SLIC
Multiprocessor Startup for ARM Platforms
PCI SIG’s MCFG
Serial Port Console Redirection Table, SPCR
Server Platform Management Interface Table, SPMI
Simple Boot Flag Table, BOOT
Smart Battery System Components and SMBus Spec
Trusted Platform Module 2 Table, TPM2
Trusted Computing Platform Alliance Capabilities Table, TCPA
Watchdog Action Table, WDAT
Watchdog Timer Resource Table, WDRT
Windows ACPI Emulated Devices Table, WAET
Windows Platform Binary Table, WPBT

Quoting Wikipedia on ACPI security risks:

“Ubuntu Linux founder Mark Shuttleworth has likened ACPI to Trojan horses. He has described proprietary firmware (ACPI-related or any other firmware) as a security risk, saying that “firmware on your device is the NSA’s best friend” and calling firmware (ACPI or non-ACPI) “a Trojan horse of monumental proportions”. He has pointed out that low quality, closed source firmware is a major threat to system security: “Your biggest mistake is to assume that the NSA is the only institution abusing this position of trust — in fact, it’s reasonable to assume that all firmware is a cesspool of insecurity, courtesy of incompetence of the highest degree from manufacturers, and competence of the highest degree from a very wide range of such agencies”. As a solution to this problem, he has called for declarative firmware (ACPI or non-ACPI). Firmware should be open-source so that the code can be checked and verified. Firmware should be declarative, meaning that it should describe “hardware linkage and dependencies” and should not include executable code.”

Vendors need to be disclosing a LOT MORE information about what they’ve included in their firmware, now that people are aware of this, thanks to Lenovo. It is easy to fix OEM’s mistakes at OS level, by reinstalling an open source OS, or installing vanilla Windows and then getting the drivers from the OEM/IHVs. But you can’t update your system’s firmware, and ACPI is the new dumping ground for OEM bloat. Well, not new, just newly-realized by some of us. I want a system with absolute minimail ACPI table bloat, and I want to KNOW what tables are shipped on the firmware. Linux OEMs: don’t ship COTS firmware that has Windows-centric ACPI blobs in them. If you look on #UEFI on G+ and Twitter, you’ll find more and more people demanding Open Hardware and fully-open source firmware, which is refreshing. 🙂

tool mini-review: RWEverything

~ hucktech ~ Leave a comment

RW, aka RWEverything (Read and Write Everything) is a GUI Windows-based firmware utility, written by Jeff.

“This utility access almost all the computer hardware, including PCI (PCI Express), PCI Index/Data, Memory, Memory Index/Data, I/O Space, I/O Index/Data, Super I/O, Clock Generator, DIMM SPD, SMBus Device, CPU MSR Registers, ATA/ATAPI Identify Data, Disk Read Write, ACPI Tables Dump (include AML decode), Embedded Controller, USB Information, SMBIOS Structures, PCI Option ROMs, MP Configuration Table, E820, EDID and Remote Access. And also a Command Window is provided to access hardware manually. Powerful utility for hardware engineers, firmware (BIOS) engineers, driver developers, QA engineers, performance test engineers, diagnostic engineers, etc.”

“This utility comes with ABSOLUTELY NO WARRANTY, it allows you to modify hardware settings, this may damage your system if something goes wrong. Author will not take any responsibility about that, you are on your own risk. This utility should not be used in commercial products.”

RW supports multiple Super I/O devices (Winbond (18), ITE (12), SMSC (8), FinTek (4), Nuvoton (6)) and SMBus Controllers (Intel (9), SiS (6), VIA (4), ULi (4), ATI (3), nVidia (13)).

It is Windows-centric utility, shipping with Win32 or Win64 binaries. It has an extensive ChangeLog, spanning v1.6.8 from 8/6/2015 to v0.1 back around 2005, but does not ship with any documentation, just EXEs. If you use Windows, you might want to check this out. If you find the tool useful, the author has a Donate button on his home page, please consider donating to the program’s author. I wish the tool was open source, and supported multiple operating systems, …but I’ll take what I can get. Thanks Jeff!

Home

Supported Hardware

Download

more research on Domas’ x86 memory sinkhole

~ hucktech ~ Leave a comment

As reported earlier, Christopher Domas gave a talk at Black  Hat Briefings with an interesting Intel vulnerability:

Domas’ x86 vulnerability

Post-Domas Intel BIOS update

Beyond the earlier presentation, there’s now more research on this, a whitepaper:

Click to access us-15-Domas-TheMemorySinkhole-wp.pdf

as well as sample code:
https://github.com/xoreaxeaxeax/sinkhole/blob/master/sinkhole.asm

Intel update on Debian and UEFI

~ hucktech ~ Leave a comment

Yesterday Brian Richardson of Intel UEFI posted a new blog entry on 32-bit UEFI and Linux support, with specific information about Debian.  It was NICE to see the Debian swirl as the icon on an Intel.com-hosted blog post! 🙂 I am sometimes concerned that UEFI Forum and Intel only think about UEFI Forum-member Linux OSVs (Canonical, RedHat, SuSE) when it comes to UEFI and Linux. It’s NICE to see Intel working with non-UEFI Forum members on UEFI issues, especially Debian!

Blog excerpt:

“Thanks to Steve McIntyre from the Debian team for pointing out my error. Steve’s also helping organize a repository for information on UEFI implementations that don’t play nice with Linux. I think this is a great idea, so check it out if you have any relevant info. I’ll share my tips for testing UEFI & Linux in an upcoming post, in case you want to contribute to their project.”

Brian@Intel’s full blog post:
http://blogs.intel.com/evangelists/2015/08/11/update-on-ia32-uefi-and-linux-support/

Steve@Debian’s blog post:
http://blog.einval.com/2015/08/02#intel_justifies_mixed_efi

This repo of Linux UEFI information sounds GREAT!. Amongst the things it tracks, I hope it tracks the various Secure Boot strengths that Linux distributions have:

Secure Boot strength varies by Linux implementation

UEFI upstreaming OpenSSL patch

~ hucktech ~ Leave a comment

UEFI has an optional build directive to enable “Secure Boot”. Secure Boot’s crypto is backed by the Open Source library libOpenSSL. For a long time, Tianocore’s OpenSSL was based on 0.98x release of OpenSSL. It sucks for UEFI that every time OpenSSL issues a new release (which is often, these months), the UEFI patch sometimes has to get updates to reflect OpenSSL changes. Plus, it was scary to see UEFI using such an ancient 0.98x release of OpenSSL for so long. Recently, UEFI updated to 1.0x releases of OpenSSL, and have been doing a lot of patch churning, due to frequent OpenSSl releases. So, it’s nice to see that there’s a effort by David Woodhouse of Intel’s Open Source Technology Centre, to make an effort to upstream the UEFI patches to OpenSSL, for the first time filing an issue in the RT. (Previously, AFAICT, the only effort to upstream was brief email on the OpenSSL mailing list, no RT filed.) I don’ t think UEFI Forum is one of the members of the OpenSSL Foundation; it might be nice if they were, given their Secure Boot dependence on this library. (OEMs/IBVs can swap out OpenSSL with another crypto lib, unclear which do…)

I  hope the OpenSSL Foundation and it’s developers accept this patch, or work with UEFI Forum’s developers to come up with acceptable patch to upstream.  I may be biased, but UEFI Secure Boot might be one of OpenSSL’s most important uses. Having UEFI target code in main OpenSSL trunk will save UEFI developers time, but also help with OpenSSL developers to understand the UEFI codepath differences, and may help reduce UEFI-centric code issues later. Imagine if Windows or Linux target support for OpenSSL was a separate patch, yuck.

Even if OpenSSL Foundation doesn’t accept the patch, it is still a significant new OpenSSL patch for UEFI, worth a review.

http://rt.openssl.org/Search/Simple.html?q=UEFI

Below is David’s posting to the edk2-devel list at 01.org:

——– Forwarded Message ——–
Subject: [edk2] [PATCH v3 0/16] CryptoPkg: OpenSSL update
From: David Woodhouse

Not sure which version this is; let’s call it v3 despite the fact that I think it’s actually the first time all this lot has been posted together in a single coherent series.

All the OpenSSL fixes are filed in upstream RT and in my git tree at http://git.infradead.org/users/dwmw2/openssl.git/ and backported to OpenSSL 1.0.2 in the OpenSSL_1_0_2-stable branch of the same repo.

This series cleans up a number of our outstanding OpenSSL patches to match what’s been submitted upstream, including the use of OPENSSL_SYS_UEFI instead of abusing OPENSSL_SYSNAME_UWIN.

It also cleans up places in our code where we access OpenSSL “internal” structures which are going to be made opaque in OpenSSL 1.1 and accessor functions should be used instead.

The build infrastructure is fixed to be more consistent with the way that OpenSSL is usually built all the OPENSSL_NO_xxx definitions are moved into opensslconf.h, and the file list is properly synchronised with the result of ‘make files’ in the suitably-configured OpenSSL source.

A script is provided which allows the opensslconf.h file and the list of files in OpensslLib.inf to be automatically updated. This script is not required during a normal build; it’s only for when we update the OpenSSL which is used by the EDK II repository.

Finally, we remove CryptoPkg/include/openssl and instead use the real OpenSSL include directory. This Just Works on POSIX-compliant platforms, and has symlinks to the original files. In OpenSSL 1.1 it’ll work even on Windows, as those files have been *moved* to the include/openssl/ directory of the OpenSSL source tree. For the time being, Install.sh can die and Install.cmd is updated to copy the files to $(OPENSSL_PATH)/include/openssl to work around Windows’ lack of symlinks.

Both the final commit (using OpenSSL HEAD) and the penultimate (still using a patched 1.0.2d) have been build-tested for IA32 and X86 both using GCC on Linux and VS2008 under Windows. And also using MinGW32/MingGW64 under Linux, although the final link there fails due to calls to __chkstk_ms (see GCC PR#67169).

Git tree at http://git.infradead.org/users/dwmw2/edk2.git

David Woodhouse (16):
CryptoPkg/BaseCryptLib: Add missing OpenSSL includes
CryptoPkg/BaseCryptLib: Use i2d_X509_NAME() instead of abusing X509_NAME
CryptoPkg/BaseCryptLib: Use accessor functions for X509_ATTRIBUTE
CryptoPkg/BaseCryptLib: Use accessor functions for ASN1_OBJECT
CryptoPkg/BaseCryptLib: Clean up checking of PKCS#7 contents type
CryptoPkg/BaseCryptLib: Use X509_V_FLAG_PARTIAL_CHAIN
CryptoPkg/BaseCryptLib: Use X509_V_FLAG_NO_CHECK_TIME
CryptoPkg/OpensslLib: Undefine NO_BUILTIN_VA_FUNCS to fix varargs breakage
CryptoPkg: Fix OpenSSL BN wordsize and OPENSSL_SYS_UEFI handling
CryptoPkg/OpensslLib: Eliminate GETPID_IS_MEANINGLESS definition
CryptoPkg/OpensslLib: Move OPENSSL_NO_xxx defines into opensslconf.h
CryptoPkg: Use OpenSSL include directory directly
CryptoPkg/OpensslLib: Include complete copy of opensslconf.h
CryptoPkg/OpensslLib: Update OpenSSL patch
CryptoPkg/OpensslLib: Automatically configure OpenSSL and generate file list
CryptoPkg: Support building with OpenSSL HEAD (1.1.0-devel)

CryptoPkg/CryptoPkg.dec                                               |   2 +
CryptoPkg/Include/OpenSslSupport.h                                    |  26 ++
CryptoPkg/Include/openssl/README                                      |   1 –
CryptoPkg/Library/BaseCryptLib/InternalCryptLib.h                     |  10 +-
CryptoPkg/Library/BaseCryptLib/Pk/CryptAuthenticode.c                 |   7 +-
CryptoPkg/Library/BaseCryptLib/Pk/CryptDh.c                           |   1 +
CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Verify.c                  |  94 +—
CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaBasic.c                     |   1 +
CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaExt.c                       |   1 +
CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c                           | 102 +—
CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c                         |  18 +-
CryptoPkg/Library/BaseCryptLibRuntimeCryptProtocol/InternalCryptLib.h |   8 –
CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2d.patch               | 380 —————
CryptoPkg/Library/OpensslLib/Install.cmd                              |  77 —
CryptoPkg/Library/OpensslLib/Install.sh                               |  79 —-
CryptoPkg/Library/OpensslLib/OpenSSL-HOWTO.txt                        |  44 ++
CryptoPkg/Library/OpensslLib/OpensslLib.inf                           | 480 ++—————–
CryptoPkg/Library/OpensslLib/Patch-HOWTO.txt                          |  61 —
CryptoPkg/Library/OpensslLib/opensslconf.h                            | 488 ++++++++++++++++++++
CryptoPkg/Library/OpensslLib/process_files.sh                         |  38 ++
20 files changed, 691 insertions(+), 1227 deletions(-)

Intel Boot Guard

~ hucktech ~ 1 Comment

Intel Boot Guard

As defined by Wikipedia: “Intel Boot Guard is a processor feature that prevents the computer from running firmware images not released by the system manufacturer. When turned on, the processors verifies a signature contained in the firmware image before executing it, using the hash of the public half of the signing key, which is fused into the system’s Platform Controller Hub (PCH) by the system manufacturer (not by Intel). Intel Boot Guard is an optional processor feature, meaning that it does not need to be activated during the system manufacturing. As a result, Intel Boot Guard, when activated, makes it impossible for end users to install replacement firmware such as Coreboot.”

Boot Guard attempts to protect the system before Secure Boot starts. Boot Guard is a big new player in the security -vs- user-control equation. To conserve words, I’ll just point to a few other blog posts on this topic by others:

http://patrick.georgi-clan.de/2015/02/17/intel-boot-guard/
https://hacked.com/quick-hack-bios-passwords-computer/
https://mjg59.dreamwidth.org/33981.html
https://news.ycombinator.com/item?id=9135767
http://www.pcworld.com/article/2883903/how-intel-and-pc-makers-prevent-you-from-modiying-your-pcs-firmware.html

Security must be addressed, but the cost might be General Purpose Computing?

Lockdown: The coming war on general-purpose computing


http://readwrite.com/2012/01/13/the-four-horsemen-of-the-gener
https://github.com/jwise/28c3-doctorow/blob/master/transcript.md

I hope Intel — or other chip vendors — can help both audiences, not only enterprise vendors who want to use the OEM’s installation of Windows and never change their systems. The locally-present user should be able to override features like this, and install what they want, at firmware, pre-OS and OS-level software. Some systems may need to be tamper-resistant to local users, but that’s just for enterprise bank employees, not for citizens. Intel: please give us more control over the products we purchase.

UEFI HTTP Boot support announced

~ hucktech ~ Leave a comment

I’ve been wondering about UEFI 2.5’s HTTP Boot support since the Tianocore checkins started, a few months ago:

https://firmwaresecurity.com/tag/uefi-http-boot/

Intel announced more on this today, preparing for their upcoming IDF presentations on the topic:

https://twitter.com/Intel_UEFI/status/630806998951407616

https://twitter.com/Intel_UEFI/status/630807551664263168

UEFI 2.5 also added DNS support to complete the network stack needed for UEFI HTTP boot. I’ve yet to see any vendor except HP announce a product yet, perhaps IDF will unveil new products from other vendors.