UEFI updated to IPMI v2.0

Daocheng Bu of Intel has added IPMI 2.0 definitions to the EDK2 project.

MdePkg/Include/IndustryStandard/Ipmi.h             |  26 +
…/IndustryStandard/IpmiNetFnAppDefinitions.h     | 614 +++++++++++++++++++++
…/IndustryStandard/IpmiNetFnBridgeDefinitions.h  | 238 ++++++++
…/IndustryStandard/IpmiNetFnChassisDefinitions.h | 294 ++++++++++
…/IpmiNetFnFirmwareDefinitions.h                 |  26 +
…/IpmiNetFnGroupExtDefinitions.h                 |  26 +
…/IpmiNetFnSensorEventDefinitions.h              |  44 ++
…/IndustryStandard/IpmiNetFnStorageDefinitions.h | 514 +++++++++++++++++
…/IpmiNetFnTransportDefinitions.h                | 531 ++++++++++++++++++
9 files changed, 2313 insertions(+)

For more information see the edk2-devel posts (or look at the current EDK2 trunk in the above files):
https://lists.01.org/mailman/listinfo/edk2-devel

Netconsole added to LUV

Gayatri Kammela of Intel posted a new feature patch to LUV: the netconsole. From the patch’s comments:

This is about adding a Linux feature called Netconsole in Linux* UEFI Validation. In LUV netconsole feature is enabled only for the test suites that run once  the Linux takes control over and BITS test suite will be excluded from  having this kind of support.

Why this feature: Netconsole in LUV help us debug the kernel panics or system hangs by  sending not only kernel messages but also information regarding the running tests simultaneously on to the remote machine via ethernet. Now the remote machine can  be on same subnet or different subnet with respective to the local machine  ( machine you are trying to boot LUV). To enable netconsole feature in LUV, changes are made in various files to include kernel modules like netconsole  and different network utilites that can send messages  via ethernet.Besides these changes are made to luv-test-manger to make all the  running tests information sent to dmesg to make the debugging more easy.

How this feature works: Liberty is given to user to choose the ip address and port number where he/she wants all messages to sent to. once decided , user can replace the dummy ip address given  in grub.cfg as @,64001@10.11.12.13/ with the destined address and port number.  The same information is mentioned in README file , so that user can get  to know the usage of netconsole.

Requirements for this feature: Not many changes are required for this feature , except enabling some of the kernel config options. Luv kernel has config optons enabled that are  obsolutely necessary for the image and to keep the kernel size as low as possible. Since netconsole require lot of options enabled related to TCP/IP , IPV4 , IPV6 and  filesystem related options. These information can be overwhelming and just for the sake of clarity some of the important options that needs to enabled are given below […]

See checkin post for full comment and sources:
https://lists.01.org/mailman/listinfo/luv

Updated UEFI training from Intel SSG

It appears there are a few new files on Tianocore.org, beyond latest EDK-II trunk source changes.

Intel has a multi-day training course for (presumably) Intel employees and partners. Intel releases the presentations and lab workshop materials for the course for public access, as part of the Tianocore project, and updates it periodically. And they recently updated it again, grab the 2 files at the top of the list, with recent dates. I just downloaded it, unsure what is new in the labs yet…
http://sourceforge.net/projects/edk2/files/Training/TrainingMaterial/

Also see updated versions of the online presentations here:
http://sourceforge.net/projects/edk2/files/Training/
https://github.com/tianocore/tianocore.github.io/wiki/UEFI%20EDKII%20Learning%20Dev

I think this page may be slightly out-of-date for the moment:
http://firmware.intel.com/learn/uefi/uefi-training-materials

As for other updates to tianocore/EDK2, the EDK-II C Coding Conventions have been revised:
http://sourceforge.net/projects/edk2/files/Specifications/

I usually find it is best to find fresh Tianocore files by looking at these two locations first:
https://github.com/tianocore
http://sourceforge.net/projects/edk2/files/

LUV updated to include CHIPSEC 1.2.2

Ricardo Neri of Intel has updated LUV to include the latest CHIPSEC, version 1.2.2!  Excerpt from checkin patch message:

A new version of CHIPSEC has been released. Bump LUV to use such version.

Updating CHIPSEC requires to also update the patches that we apply on top of it. Changes to these patches are not functional; only rebased to 1.2.2.

Finally, take this opportunity to add a PV variable to the recipe.

Full message:
https://lists.01.org/pipermail/luv/2015-November/000687.html

Intel Platform QoS tool for Linux

Colin King of Canonical has a new blog post on Intel’s Cache Monitoring Tool, and Intel’s Ubuntu implementation:

The Intel Platform Shared Resource Monitoring features were introduced in the Intel Xeon E5v3 processor family. These new features provide a mechanism to measure platform shared resources, such as L3 cache occupancy via Cache Monitoring Technology (CMT) and memory bandwidth utilisation via Memory Bandwidth Monitoring (MBM). Intel have written a Platform Quality of Service Tool (pqos) to use these monitoring features and I’ve packaged this up for Ubuntu 16.04 Xenial Xerus.” […]

http://smackerelofopinion.blogspot.com/2015/11/intel-platform-shared-resource.html

https://software.intel.com/en-us/blogs/2014/12/11/intels-cache-monitoring-technology-use-models-and-data

https://github.com/01org/intel-cmt-cat

SeaBIOS 1.9.0 released

Kevin O’Connor announced the release of SeaBIOS version 1.9.0 today, on the SeaBIOS, QEMU-devel, and coreboot mailing lists. New in this release:

* The default boot menu key is now the ESC key (instead of F12)
* Initial support for Trusted Platform Module (TPM) hardware and BIOS calls
* Initial support for chain loading SeaBIOS from Grub (via multiboot support)
* Initial support for booting from SD cards on real hardware
* virtio 1.0 device support
* The build will no longer include the build hostname or build time on “clean” builds.  This makes the build binaries more “reproducible”.
* Basic support for running SeaBIOS on Baytrail Chromebooks
* SeaVGABIOS: improved support for old versions of x86emu (the “leal” instruction is now emulated)
* Several bug fixes and code cleanups

TPM support sounds interesting! And remember, if F12 no longer works, try ESC…

More information:
http://seabios.org/Releases
http://seabios.org/Download
http://www.seabios.org/mailman/listinfo/seabios

GRUB with Trusted Boot for TPM v1 or v2

This from September, I only just noticed it. 😦

Matthew Garrett has updated GRUB bootloader with support for Trusted Boot, on TPM v1 or v2 systems!

In a follow-up to the above tweet, Matthew also states:

“I need to add equivalent code to Shim now lucky me”

 

https://github.com/mjg59/grub

 

So I need to check if that happened, and if Debian and other distros are using this version of GRUB and Shim…

I wish somebody — Wikipedia, the Linux Foundation, the Linux kernel security wiki, the UEFI Forum, etc. —  were tracking the various hardware/firmware security features of various vendors, and what system components (grub and shim in this case) had support for the various technologies, with a table of red/green boxes. Then we could more easily see things like tboot only supporting BIOS and not UEFI, etc..

Linaro FW-Summit list migrates to UEFI Forum’s FWOS Forum

Al Stone of Red Hat announced on the Linaro Firmware Summit mailing list that the list would transition over to the new UEFI Forum’s FW/OS list. Excerpt of announcement:

Since the fw-summit mailing list was only meant as a holding place until we could set up a forum like this, we will soon be disabling the mailing list. Any and all of the discussions we would have had on fw-summit should now be held on the FW/OS Forum mailing list instead. […]  I would like to thank Dong Wei of UEFI especially, but also Michael Krau and the rest of the board of the UEFI Forum for all of their hard work and effort to make this public forum possible.  It was a bit of a stretch for everyone, but it got done.  Thanks!

Full announcement:
https://lists.linaro.org/pipermail/fw-summit/2015-November/000184.html

http://www.uefi.org/FWOSForum
https://lists.linaro.org/pipermail/fw-summit/
https://lists.linaro.org/mailman/listinfo/fw-summit

Teddy Reed on bypassing Linux Secure Boot

Teddy Reed has a second article on UEFI, MinnowboardMax and Linux! This one is called “Minnowboard Max: Booting Linux Securely”, and talks about how the Linux shim is used, and enumerates the various ways this boot security can be bypassed.

[…] I say ‘more-or-less’ because there are tons of places where the verification can be subverted. Unfortunately, if you start examining the implementation and configuration details of the streamlined Secure Boot support, you’ll find plenty of bypasses. Let’s talk briefly about each bypass and conclude with a simple way to use Secure Boot and enforce a signed kernel execution on Ubuntu. To be clear, there are no vulnerabilities here as there is no documented intention to boot Linux securely (e.g., BUG/1401532), only to support a Secure Boot and boot Linux. […]

http://prosauce.org/blog/2015/10/31/booting-linux-securely

Teddy Reed research on Minnow firmware

Secure Boot strength varies by Linux implementation

ACPI debugger for Linux kernel

Last Friday, Lv Zheng of Intel sent a 5-part patch to the linux-acpi and linux-kernel mailing lists. Below is documentation excerpt from initial patch:

ACPICA / debugger: Add in-kernel AML debugger support

This patchset enables ACPICA debugger for Linux kernel and implements a userspace utility to access it.

A. Build the AML debugger
In order to build the kernel support of AML debugger, the following kconfig items should be enabled:
 CONFIG_ACPI_DEBUG=y
 CONFIG_ACPI_DEBUGGER=y
 CONFIG_DEBUG_FS=y
 CONFIG_ACPI_DEBUGGER_USER=m
The userspace tool can be found at tools/power/acpi/tools/acpidbg. To build this utility, staying in tools folder and type “make acpi”.

B. Load the AML debugger during runtime
In order to use the in-kernel AML debugger, the following command should be executed using root user:
 # modprobe acpi_dbg
 # mount -t debugfs none /sys/kernel/debug
 # acpidbg

C. Batch mode
In order to support scripts, the userspace utility also supports single command batch mode:
 # acpidbg -b “help”
 # acpidbg -b “tables”
 # acpidbg -b “find _LID”
 # acpidbg -b “execute \_SB.LID0._LID”
You can find the documentation about the ACPICA debugger commands in:
 https://acpica.org/sites/acpica/files/acpica-reference_17.pdf
 (The latest document can be found at https://acpica.org/documentation)
And refer to the chapter – ACPICA debugger reference to obtain the full description of the debugger commands. Note that not all commands are supported by an in-kernel AML debugger.

D. Unload the AML debugger during runtime
After terminating all acpidbg instances, the following command can be executed to remove the AML debugger from kernel:
 # rmmod acpi_dbg

The following tasks are not completed:
1. .flush() support in the kernel debugger IO driver.
2. multi-commands batch mode.
3. upstream the userspace acpidbg to the ACPICA upstream.

For more information, see the threads on the linux-kernel and linux-acpi mailing lists, run at vger.kernel.org.

Steve Grobman on HW/FW vulnerability tools

Steve Grobman of Intel has written a blog post “Hardware.Next: Hardware and firmware vulnerabilities provide tools to attackers and defenders.” Steve Grobman is the CTO for Intel Security Group at Intel Corporation.

The post mentions Intel SGX — which may’ve been updated with DXL support, not sure what DXL is yet — and other Intel and related security technologies, including CHIPSEC.

https://blogs.mcafee.com/executive-perspectives/hardware-next-hardware-firmware-vulnerabilities-provide-tools-attackers-defenders/

http://newsroom.intel.com/community/intel_newsroom/bios?n=Steven%20L.%20Grobman&f=searchAll

TCG workshop in Tokyo next month

Today the TCG sent out a news announcement about their presence at JRF in Tokyo next month. Email header/footers removed, but body not excerpted, since no URL and only from TCG newsletter.

You’re Invited to Attend the Annual Japan Regional Forum (JRF) Workshop in Tokyo on December 2, 2015.

Date/Time:  Wednesday, December 2, 2015  13:30 – 19:30

Venue: Akihabara UDX Next 1 – Tokyo, Japan

The Japan Regional Forum (JRF) will be hosting its annual Open Workshop on Wednesday, December 2, 2015 at Akihabara UDX in Tokyo.

This 7th annual JRF Workshop is open to both members of the Trusted Computing Group (TCG) and non-members who are interested in TCG activities and issues around security.

This event provides an excellent opportunity to learn global trends and challenges in IoT, Automotive, and Embedded System, and get deep understanding through the discussions through the event.

The program includes a keynote address from David Grawrock, Senior Principal Engineer of Intel on TPM core features for Trustworthy in IoT Era. In addition, Koji Ono, Technical Sales, Consumer & Partner Group OEM at Microsoft Japan will lead a session on security feature of Windows 10 for IoT and Mark Schiller, Executive Director of the Trusted Computing Group will introduce TCG efforts for embedded system and IoT as well as benefit of joining TCG.

Other speakers include Shinji Sato, IPA (Information-technology Promotion Agency, Japan), Shinichi Horata, IPCERT/CC (Japan Computer Emergency Response Team Coordination Center), and Ryo Kurachi, TCG Invited Expert from Nagoya University.

The session is followed by reception with food & drink and will provide a great opportunity to network with speakers and members of the TCG.  TCG technology demo showcase will also be available for attendees.

If you are interested in attending this event please visit the TCG JRF website (Japanese) at http://www.trustedcomputinggroup.org/jp/jrfworkshop .

Registration will close on Wednesday, November 25, 2015.

More info:
http://www.trustedcomputinggroup.org/jp/jrfworkshop

Open Compute Project’s new Firmware focus group

The Open Compute Project’s Hardware group is starting a new Firmware focus group, focusing on UEFI Forum and DMTF technologies. The group is led by Mallik Bulusu of Microsoft and Vincent Zimmer of Intel.

During our last meeting, we had a very good discussion about standardizing UEFI interfaces and what make sense and does not make sense. There is also a need to standardize and streamline FW updates, define bare metal provisioning scenarios and interfaces, extend security framework to include auditing and monitoring, UEFI configuration management, etc. Also, our alliance groups (UEFI, DMTF) are working on similar or closely related technologies. We want to make sure we work closely with them to make sure we are aligned.  Towards that end, Mallik Bulusu and Vincent Zimmer are willing to bootstrap this effort and lead a subgroup that is focused on this. Anyone interested in this topic and willing to contribute please send an email to Mallik and Vincent expressing your interest. The goal here is to a) come up with a specification that capture OCP member specification and b) working with our members and alliance partners to get buy-in and implementations for those specs. We will discuss this further in our upcoming monthly meeting.

For more information, see the posting on the OCP Hardware Management list, and their next upcoming monthly meeting.

http://lists.opencompute.org/pipermail/opencompute-hardwaremngt/2015-November/000668.html

Intel IoT technology update

Rick Merritt has an article in EE Times, covering multiple stories on new Intel’s IoT-related offerings, including new Quarks, and IoT OS releases (Rocket and Pulsar) from Intel’s Wind River:

http://www.eetimes.com/document.asp?doc_id=1328176

OpenPOWER port comments, and EFI creation story

A few weeks ago, I noticed a new Github project where someone at IBM had ported UEFI to OpenPOWER. Later that day, someone *ELSE* at IBM had *ALSO* ported UEFI to OpenPOWER — two ports! And they found out about each other because of my blog, too funny! Anyway, they’re actively conversing on the Comments thread on the blog:

Tianocore for OpenPOWER

In addition to OpenPOWER issues, the Comments section has MULTIPLE people posting comments, which is a first for this blog! There’s some good background on history of EFI, including a pointer to 2005-era message that includes the ‘creation saga’ of EFI! In the past, Apple used OpenFirmware on PowerPC-based Macs, and PC vendors used BIOS on x86-based PCs. When Windows NT started support for non-x86 systems, ARC was used for the RISC vendors. Then Intel Itanium needed a solution. They nearly used ARC or OpenFirmware, before going down the route for EFI for Itanium, which later grew into UEFI and is now on Apple and PC systems as well. Here’s an excerpt with Andrew Fish talking about how EFI was created:

“At that time, two firmware solutions were put on the table as
replacements for BIOS architectures for the Itanium: Alpha Reference
Console (ARC) and Open Firmware. It turned out that nobody really
owned the inellectual property to ARC, and in any case, it did not
have enough extensible properties to make it practical for a
horizontal industry. At this point, Open Firmware became the
frontrunner as Apple and Sun both used it. However, Open Firmware was
not without its own technical challenges. The PC had started down a
path of using the Advanced Configuration and Power Interface (ACPI) as
its runtime namespace to describe the platform to the operating
system. As I liked to say at the time, the only thing worse than one
namespace is keeping two namespaces in sync. The other problem was the
lack of third party support for Open Firmware. We invited the
FirmWorks guys to come visit us at Dupont (WA), and we had a great
talk. Given we had just gone through an exercise of inventing a
firmware base from scratch, I think we were uniquely qualified to
appreciate what Open Firmware had been able to achieve. Unfortunately,
it became clear that the infrastructure to support a transition to
Open Firmware did not exist. Given the namespace issue with Open
Firmware and the lack of industry enabling infrastructure, we decided
to go on and make EFI a reality.”

Full post:

http://beowulf.org/pipermail/beowulf/2009-November/026956.html

I thought ARC stood for “Advanced RISC Consortium”, but I can’t argue with Andrew, maybe it originally stood for “Alpha Reference Console”.  (During these years, I was doing “ring0′ work, not firmware, and my favorite box at the time was a DEC Alpha AXP with ARC-based firmware.) ARC is very similar to early EFI: a single firmware image with a FAT partition where additional firmware images are stored, using ‘variables’ to specify the boot loader to invoke. ARC died off, like all the RISC-based Windows NT platforms, a shame, IMO. The ARC spec is still archived by the NetBSD project, who still supports ARC:

https://www.netbsd.org/docs/Hardware/Machines/ARC/

I wonder how life would be today if Intel would have chosen ARC or OpenFirmware?

UEFI 2.5 Platform Recovery feature appearing in Tianocore

Ruiyu Ni of Intel has posted an 12-part patch addding UEFI 2.5’s Platform Recovery feature to the public Tianocore EDK2 trunk.

Amongst the features of UEFI 2.5, the last public release of UEFI from the UEFI Forum, was #1227 “UEFI.Next feature – Platform recovery“. Load up the multi-thousand page UEFI 2.5 specification, with a PDF viewer with good search abilities, to find all the locations in the spec which Platform Recovery impacts. A good place to start would be around page 119, the OsRecovery#### and PlatformRecovery#### variables that’re new to UEFI 2.5.

Given that the patch includes a question from Intel asked HP:  “Could you please check my patch to see whether it can meet your real requirement?“, it appears that HP already has an existing implementation of this, perhaps already publicly available, probably separate from the Tianocore implementation, like they did with HTTP Boot. I’m not sure of other vendors with existing UEFI 2.5 Platform Recovery support.

Given UEFI capsule updates can add new features, your next firmware update may include this feature; is your organization ready to deal with UEFI 2.5 Platform Recovery support appearing in the near future? I’m not ready. I don’t understand what this feature really means, in terms of system impact. Earlier (not in this patch), there was a LOT of new code dealing with recovery in drivers. I don’t now know how to test this feature yet in Tianocore. Are there any new tools involved with this feature, for sysadmins to use? How do I test if this feature is working in a specific driver, or in the entire system? Where are some test scripts that exercise the feature? If someone has any more pointers to using this new feature, please add a Comment to this post (see left), thanks!

Subject: [Patch 00/11] Add Platform Recovery support

OS Recovery will be added later.

Ruiyu Ni (11):
  MdePkg: Add Platform Recovery definitions.
  MdeModulePkg: Add Bm prefix for internal functions
  MdeModulePkg: Use BmCharToUint in BmIsKeyOptionVariable
  MdeModulePkg: Use BM_OPTION_NAME_LEN instead of sizeof L”Boot####”
  MdeModulePkg: Use BmForEachVariable to collect all key options
  MdeModulePkg: Support to expand File device path
  MdeModulePkg: Add Platform recovery support
  MdeModulePkg: Add missing PrintLib to BdsDxe.inf
  MdeModulePkg: Use UefiSpec.h defined macro to replace L”xxx” string
  MdeModulePkg: Add PlatformRecovery#### pointing to default file path
  MdeModulePkg: Enable PlatformRecovery in BdsDxe driver

 MdeModulePkg/Include/Library/UefiBootManagerLib.h  |   1 +
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c   |  76 ++++
 MdeModulePkg/Library/UefiBootManagerLib/BmHotkey.c | 181 +++++—-
 …/Library/UefiBootManagerLib/BmLoadOption.c      | 155 +++++–
 MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c   |  26 ++
 …/Library/UefiBootManagerLib/InternalBm.h        |  30 +-
 …/UefiBootManagerLib/UefiBootManagerLib.inf      |   1 +
 MdeModulePkg/Universal/BdsDxe/Bds.h                |   3 –
 MdeModulePkg/Universal/BdsDxe/BdsDxe.inf           |   1 +
 MdeModulePkg/Universal/BdsDxe/BdsEntry.c           | 447 ++++++—————
 MdePkg/Include/Uefi/UefiSpec.h                     |   1 +
 11 files changed, 474 insertions(+), 448 deletions(-)

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