BIOS maker: WinZent Technologies AB

WinZent Technologies AB is headquartered in Stockholm, Sweden. They make a BIOS and an operating system for 32-bit Intel systems. According to their LinkedIn page, they were founded in 2013 and have 11-50 employees. Their OS is called “wIOS” (WinZent Instant OS). Their BIOS is called “wION” (WinZent Instant ON BIOS) — the B for BIOS is silent :-). Their code is written in assembler, not C, and is focused on performance and size. The binary image of their BIOS is apparently less than 64KB. Their OS is 116KB, targets 32-bit systems, and has FAT32 support.

Some fun quotes from a 2014 embedded presentation WinZent gave:
“UEFI very complex and bloated.”
“coreboot is basically Linux.”
“Linux is complex and bloated.”

They have a video of their BIOS loading in 1second, with an AMI BIOS taking about 8 seconds.
http://winzenttech.com/AdlinkwIONvsAMI.html

“WinZent’s software has a footprint small enough to execute in the cache memory which is 1500 times faster than the DRAM memory extensively used by other BIOS and general purpose OS, such as Linux, OSX and Windows.”

If you have a MinnowBoard MAX — or a Terasic DE2i-150 — you can get a BIOS from them to try out.

The BIOS uses ACPI version 2. ACPI version 6.1 was released last week.

Their BIOS does NOT use Intel FSP. I don’t have the URL or quote handy, but on the Minnowboard or eLinux list in the past, someone from WinZent mentioned this.

The BIOS targets Intel x86 systems, specifically “ATOM, Silverthorn, Diamondville, Cedarview, Pineview, Lincroft, and CloverTrail.”. Unclear about the newer Intel 32-bit boards systems.

They claim their BIOS works with “all operating systems”, which is too vague to be useful. They mention Microsoft Windows 7-10, Linux, and Android.

I see no references to any security features. If speed and size are your only concerns, WinZent sounds excellent. If you have security concerns, then you might consider something else.

There are multiple PDFs to read more about their technology:
http://winzenttech.com/Tech.html
http://winzenttech.com/wION.html
http://winzenttech.com/wIOS.html

Click to access wION%20Tech%20Spec.pdf

http://winzenttech.com/Media.html
https://www.linkedin.com/company/winzent-technologies-ab

WinZent releases wION BIOS for Minnow

Facebook on defending against firmware threats (and osquery)

Ted Reed of Facebook — aka the Teddy Reed who creates UEFI Firmware Parser and related tools — posted a VERY GOOD article on how Facebook defends systems against hardware and firmware attacks, including coverage of Facebook’s osquery tool, and his recent Usenix Enigma presentation. Excerpt of introduction (with whitespace editing by me, sorry):

Hardware and Firmware Attacks: Defending, Detecting, and Responding

The attack landscape for firmware is maturing and needs more attention from defense and detection communities. Recent examples of firmware attacks include the Equation Group’s attacks on drive firmware, Hacking Team’s commercialized EFI RAT, Flame, and Duqu. Simple tools like osquery give defenders important insights about what’s happening on their network so they can quickly detect a potential compromise. Facebook released osquery as an open source project in 2014. Facebook recently added hardware monitoring to osquery, which already aids security teams in vulnerability management, incident response, OS X attacks, and IT compliance. Firmware on commodity laptops and servers is interesting to me as a security engineer for several reasons. This code often bootstraps trust protocols and protective architecture primitives. At the same time, it is a target for vulnerabilities aimed at bypassing those exact controls to unlock, jailbreak, and homebrew β€” for either good or malicious purposes. Firmware is also a vector for virtualization escapes, hypervisor attacks, and extreme persistence. That risk is magnified by the same fragmentation problem plaguing Android devices, but with an even more complex ecosystem of developers and supported devices. Recent examples of firmware attacks include the Equation Group’s attacks on drive firmware, Hacking Team’s commercialized EFI RAT, Flame, and Duqu. Trammell Hudson’s Thunderstrike-style local system takeover is fast and effective. Drew Suarez’s demonstrations of firmware flashing of Android devices take four seconds of a distracted local user’s attention. Additionally, Computrace has used a UEFI DXE driver capable of injecting a RAT onto unencrypted NTFS partitions for several years. All of this makes firmware security critical for protecting your enterprise. This week, I shared recent work on firmware security at the Enigma 2016 Conference, hosted by USENIX. Since releasing osquery to open source in 2014, I’ve been using it to explore new ways to recognize vulnerable systems and potential compromise. Defensive security professionals should begin scoping firmware components and use simple tools like osquery to gather insight and signal from their corporate network. […]

Full post:
https://code.facebook.com/posts/182707188759117

I’ve not used Facebook’s osquery before, so I have a lot of catching up to do. ;-(
https://github.com/facebook/osquery
https://osquery.io/
https://code.facebook.com/projects/658950180885092/osquery/
https://code.facebook.com/posts/844436395567983/introducing-osquery/
https://osquery-slack.herokuapp.com/

Intel SGX key concerns

Matthew Green has a thread on Twitter about concerns of Intel SGX attestation keys, including some text of how the SGX uesr docs differ from the SGX patent docs.

“Intel appears to have dropped the idea of securely provisioning SGX attestation keys. Now you have to contact Intel.”

I can’t claim to understand SGX well enough to give any useful comments on this post. ;-( I still need to spend time to learn SGX… I’m going to read that new SGX Explained document… πŸ™‚

Intel SGX Explained

Victor Costan and Srinivas Devadas have a new document on SGX:

https://twitter.com/FredericJacobs/status/693731134602018816

Intel’s Software Guard Extensions (SGX) is a set of extensions to the Intel architecture that aims to provide integrity and privacy guarantees to security-sensitive computation performed on a computer where all the privileged software (kernel, hypervisor, etc) is potentially malicious. This paper analyzes Intel SGX, based on the 3 papers that introduced it, on the Intel Software Developer’s Manual (which supersedes the SGX manuals), on an ISCA 2015 tutorial, and on two patents. We use the papers, reference manuals, and tutorial as primary data sources, and only draw on the patents to fill in missing information. This paper’s contributions are a summary of the Intel-specific architectural and micro-architectural details needed to understand SGX, a detailed and structured presentation of the publicly available information on SGX, a series of intelligent guesses about some important but undocumented aspects of SGX, and an analysis of SGX’s security properties.

http://eprint.iacr.org/2016/086

sigrok update

Thanks to JoeFitz at SecuringHardware.com for showing me about the libsigrok project!

New supported devices in libsigrok:

* Logic analyzers: AKIP-9101, BeagleLogic, LeCroy LogicStudio, mcupro Logic16 clone, Pipistrello OLS, SysClk LWLA1016
* Oscilloscopes: Rigol/Agilent DS1000Z series, Yokogawa DLM2000 series, Yokogawa DL9000 series, Hung-Chang DSO-2100, GW Instek GDS-800
* Multimeters: Agilent U1241A/B, Agilent U1242A/B, Brymen BM25x series, MASTECH MS8250B, Metrahit 16T/16U/KMM2002, PeakTech 3415, Tenma 72-7730/72-7732/72-9380A, Testo 435-4, UNI-T UT372, UNI-T UT71A/B/C/D/E, * * Velleman DVM4100, Voltcraft VC-870/VC-920/VC-940/VC-960
* Programmable power supplies: Fluke/Philips PM2800 series, HP 663xx series, Manson HCS-3xxx series, Motech LPS-30x series, Rigol DP800 series, Korad KAxxxxP series (a.k.a Velleman LABPS3005D and others)
* AC/DC sources: Agilent N5700A series (DC sources), Chroma 61600 series (AC sources), Chroma 62000 series (DC sources)
* Electronic loads: Maynuo M97 (and compatibles)
* LCR meters: DER EE DE-5000
* Scales: KERN EW 6200-2NM
* BeagleBone Black capes: BayLibre ACME (revA and revB)

http://sigrok.org/

https://www.sigrok.org/blog/major-sigrok-releases-libsigrok-libsigrokdecode-sigrok-cli-pulseview

PXE-config: PXE config files for BIOS and UEFI

There’s a new github project for BIOS/UEFI-centric PXE use, called PXE-config:

PXE config files for Legacy BIOS and UEFI netboot installs; also contains kickstart files for automated CentOS, Fedora, etc. installs. This repo contains various config files including PXE boot menu config files & kickstart files for unattended installs over PXE boot. It does not contain /etc/dnsmasq.conf, however, which contains PXE server settings for dhcp, tftp boot, and detecting client architectures (Legacy BIOS vs UEFI). dnsmasq.conf can be found in my jun-dotfiles repo on github.

https://github.com/gojun077/pxe-config

X-Ray Inspector for PCBs

If you have not read about the “Stateless Laptop” proposal, please read it, it covers modern Intel firmware/hardware security issues:

ITL’s Stateless Laptop proposal

http://blog.invisiblethings.org/2015/12/23/state_harmful.html

One part in the article talks about how to trust silicon:

The physical protections mentioned above do not, however, resolve the problem of the attackers subverting the laptop hardware at manufacturing or shipment stages. This includes, naturally, a potentially conspiring laptop vendor. In order to address this latter problem we — the industry — need to come up with reliable and simple methods for comparing PCBs with each other. A tool analogical to ‘diff’, only working for PCBs rather than on files. Such a tool, implemented as a software, could e.g. take two (sets of) photos taken by the user of the two boards to compare. The photos might be taken with an ordinary camera, or, in a more sophisticated setup, using X-ray imaging to reveal also the internal layer wiring. This inititive has already been proposed by other researchers recently (e.g. [@appelbaum_technical_action_plan]), so it is not unreasonable to expect some progress in this area in the near future.

So when Make Magazine retweated a recent PCB Xray project, I thought of the above:

Homemade X-Ray Inspector Reveals PCB Secrets

Anyone who has ever tried to reverse engineer a printed circuit board is familiar with the frustration of tracing out the connections by eye and by multimeter. It’s a long process, and if there are multiple layers to the board, you may not even get the full picture. It would be a lot easier if you could just see through the board. On an industrial scale, X-ray inspection machines are used for this, but as you might suspect, they’re not cheap. So, hardware hacker John McMaster built his own.

Homemade X-Ray Inspector Reveals PCB Secrets

Linux ACPI to IBM and Lenovo: help!

If you know someone at IBM or Lenovo, the Linux-ACPI community needs more involvement from you, please help.

 

——– Forwarded Message ——–
Subject: Β Β Β  ibm-acpi developers not responding despite serious bugs and debuggers
Date: Β Β Β  Sat, 30 Jan 2016 13:22:27 +0000
From: Β Β Β  jono <lejono@gmail.com>
To: Β Β Β  Rafael J. Wysocki <rafael@kernel.org>
CC: Β Β Β  ACPI Devel Maling List <linux-acpi@vger.kernel.org>, ibm-acpi-devel@lists.sourceforge.net

Dear Rafael,
Sorry to trouble you, but a number of us are having lots of grief
getting a response from ibm/lenovo regarding acpi bugs in newer models
like the Helix 2. The bugs make these machines difficult to use, and
there are various reports of this on the internet, along with people
willing to debug patches. But it’s impossible to contact anyone on the
ibm-acpi team to help with this. Do you know who we can contact to
help sort these bugs out? Myself and others are polite, fairly tech
savy, and willing to help, so I’m a bit puzzled by the silence from
this team.

The example is the Helix 2, see:
https://bugzilla.kernel.org/show_bug.cgi?id=100171

and various repetitions of this…
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1424088
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1520965?comments=all

For more information, see the Linux-ACPI mailing list archives on kernel.org

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

Intel MPX support for AddressSanitizer

Sanitizers is a collection of analysis tools tools:

AddressSanitizer (detects addressability issues)
LeakSanitizer (detects memory leaks)

ThreadSanitizer (detects data races and deadlocks) for C++ and Go
MemorySanitizer (detects use of uninitialized memory)

https://github.com/google/sanitizers

The AddressSanitizer has recently obtained Intel MPX support:

On July 2013 Intel released documentation on the upcoming instruction set extensions, including the Memory Protection Extensions (MPX). Here we will discuss the applicability of MPX for memory error detection. Links: MPX-enabled GCC wiki; Using the MPX-enabled GCC and SDE (emulator); Fresh documentation on Intel ISA which includes MPX; Intel Pointer Checker. Some external feedback: 1, 2, 3. NEW As of January 2016, Intel MPX is available in hardware and one can actually try how it works!

https://github.com/google/sanitizers/wiki/AddressSanitizerIntelMemoryProtectionExtensions

 

Systemd, UEFI, and efivarfs bricking concerns

https://github.com/systemd/systemd/issues/2402

coreboot 4.3 released

Patrick Georgi of the coreboot project has announced version 4.3 of coreboot! There are too many changes for me to excerpt the release, so I’m including most of the announcement below, with some minor whitespace editing:

Since the last release, 1030 commits by 114 authors added a net total of 17500 lines to the source code. Thank you to all who contributed! Besides the usual addition of new mainboards (14) and chipsets (various), a big theme of the development since 4.2 was cleaning up the code: 20 mainboards were removed that aren’t on the market for years (and even hard to get on Ebay). For several parts of the tree, we established tighter controls, making errors out of what were warnings (and cleaning up the code to match) and provided better tests for various aspects of the tree, and in general tried to establish a more consistent structure across the code base. Besides that, we had various improvements across the tree, each important when using the hardware, but to numerous for individual shout outs. Martin compiled a list that’s best posted verbatim. Thanks Martin!

Added 14 mainboards:
– asus/kfsn4-dre_k8: Native init Dual AMD K8 CPUs & Nvidia CK804 southbridge
– esd/atom15: Bay Trail SOC mainboard using Intel’s FSP
– gigabyte/ga-g41m-es2l: Intel Core 2 / Native init x4x NB / I82801GX SB
– google/guado: Intel Broadwell chromebox (Asus Chromebox CN62)
– google/oak: Mediatek MT8173 SoC chromebook
– google/tidus: Intel Broadwell chromebox (Lenovo ThinkCentre Chromebox)
– google/veyron_emile: Rockchip RK3288 SoC board
– intel/d510mo: Native init Intel Pineview with Intel I82801GX southbridge
– intel/littleplains: Intel Atom c2000 (Rangeley) SoC board
– intel/stargo2: Intel Ivy Bridge / Cave Creek usint Intel’s FSP
– lenovo/r400: Intel Core 2 / Native init GM45 NB / Intel I82801IX SB
– lenovo/t500: Intel Core 2 / Native init GM45 NB / Intel I82801IX SB
– purism/librem13: Intel Broadwell Laptop using Intel MRC
– sunw/ultra40m2: Native init Dual AMD K8 Processors & Nvidia MCP55 SB

Removed 20 mainboards:
– arima/hdama
– digitallogic/adl855pc
– ibm/e325, e326
– intel/sklrvp
– iwill/dk8s2, dk8x
– newisys/khepri
– tyan/s2735, s2850, s2875, s2880, s2881 & s2882
– tyan/s2885, s2891, s2892, s2895, s4880 & s4882

Improvements to mainboards:
– amd/bettong: fixes to Interrupts, Memory config, S4, EMMC, UARTS
– asus/kgpe-d16: IOMMU and memory fixes, Add CMOS options, Enable GART
– intel/strago: GPIO, DDR, & SD config, FSP updates, Clock fixes
– ACPI fixes across various platforms
– Many individual fixes to other mainboards
Continued updates for the Intel Skylake platform
– google/chell, glados, & lars: FSP & Memory updates, Add Fan & NHLT support
– intel/kunimitsu: FSP & GPIO updates, Add Fan & NHLT (audio) support

Build system:
– Update build to use FMAP based firmware layout with multiple cbfs sections
– Enable Kconfig strict mode – Kconfig warnings are no longer allowed.
– Enable ACPI warnings are errors in IASL – warnings are no longer allowed.
– Tighten checking on toolchains and give feedback to users if there are issues
– Updates to get the ADA compiler to work correctly for coreboot
– Various improvements to Makefiles and build scripts
– Cleanup of CBFS file handling

Utilities:
– cleanups and improvements to many of the utilities
– cbfstool: Many fixes and extensions to integrate with FMAP
– Add amdfwtool to combine AMD firmware blobs instead of using shell scripts.
– Toolchain updates: new versions of GMP & MPFR. Add ADA.
– Updates for building on NetBSD & OS X

Payloads:
– SeaBIOS: Update stable release to 1.9.0
– coreinfo: fix date, hide cursor, use crosscompiler to build
– libpayload: updates for cbfs, XHCI and DesignWare HCD controllers

ARM:
– Added 1 soc: mediatek/mt8173
– Various fixes for ARM64 platforms

X86:
– Added 2 northbridges: intel/pineview & x4x
– Removed 1 northbridge: intel/i440lx
– Added 1 southbridge: intel/fsp_i89xx
– Removed 2 southbridge(s): intel/esb6300 & i82801cx
– Rename amd/model_10xxx to family_10h-family_15h.
– ACPI: fix warnings, Add functions for IVRS, DMAR I/O-APIC and HPET entries
– Work in many areas fixing issues compiling in 64-bit
– Numerous other fixes across the tree
Areas with significant work on updates and fixes
– cpu/amd/model_fxx
– intel/fsp1_x: Fix timestanps & postcodes, add native CAR & microcode
– nb/amd/amdfam10: Add S3, voltage & ACPI, speed fixes & MANY other changes
– nb/amd/amdmct: Add S3, mem voltage, Fix performance & MANY other changes
– nb/intel/sandybridge: Add IOMMU & ACPI DMAR support, Memory cleanup
– soc/intel/braswell: FSP & ACPI updates, GPIO & clock Fixes
– soc/intel/fsp_baytrail: GPIO, microcode and Interrupt updates.
– soc/intel/skylake: FSP, Power/Thermal & GPIO Updates, Add NHLT support
– sb/amd/sb700: Add ACPI & CMOS Setting support, SATA & clock Fixes

MIPS:
– Imgtec Pistachio: Memory, PLL & I2C fixes, add reset

SuperIO:
– Expand functionality for ite/it8718f & nuvoton/nct5572d superio devices
Added 3 SIOs
– intel/i8900
– winbond/w83667hg-a & wpcd376i
Removed 6 SIOs
– fintek/f71889
– ite/it8661f
– nsc/pc8374 & pc97307
– nuvoton/nct6776
– smsc/fdc37m60x

Lib:
– Several updates for reading EDID tables

MISC:
– Commonlib: continued updates for cbfs changes
– Work on getting license headers on all coreboot files
– Drop the third paragraph of GPL copyright header across all of coreboot

Submodules:
3rdparty/blobs: Update to CarrizoPI 1.1.0.1 (Binary PI 1.5)

Full announcement:

Announcing coreboot 4.3

 

UEFI 2.6 spec changes

Here’s a bit more information about UEFI 2.6, from the changelog in the spec. There are 25 2.5 errata changes, and 39 new 2.6 features, ranging from October 2015 to January 2016.

UEFI 2.5 errata:
1209 UEFI networking API chapter 2.6 requirements errors
1363 Short form URI device path
1365 7.4 Virtual Memory Services lists Section 2.3.2 through Section 2.3.4. incorrectly
1381 Remove informative content in 12.6.1
1388 Missed memory type
1398 Errata update to the runtime GetVariable operation documentation
1399 Clarification for EFI_BROWSER_ACTION_REQUEST_RECONNECT
1405 Errata in table 271 in Appendix O
1407 Networking errata – EFI_HTTP_STATUS typos
1410 Clarifications in appendix O
1417 Add HttpMethodMax to EFI_HTTP_METHOD enum
1418 Inconsistent issues in DNS
1419 Supplicant protocol using same GUID as TLS protocol
1420 GetNextHighMonotonicCount clarification
1421 Misc HTTP API typos
1424 Incorrect link in Section 22.1 FMP GetImageInfo()
1426 UEFI 2.5 typo
1441 UEFI2.5 errata – UNDI Protocol Clarification
1451 Memory Map Consistency
1468 Errata on UEFI Supplicant protocol
1469 UNDI Errata – add more statistics
1472 ATA Pass Thru Errata
1476 Update to Indicate that CloseEvent Unregisters Corresponding Protocol Notification Registrations
1477 Allow CloseEvent to be called within the Notification Function
1481 new network config2 protocol data structure has a magic number

UEFI 2.6 new features:
1357 ARM CPER extensions
1402 Add EFI_BROWSER_ACTION_SUBMITTED
1471 SD/eMMC PassThru Protocol update (follow up to mantis 1376)
1376 SD/eMMC PassThru Protocol
1408 EFI HII Font EX protocol and EFI HII Font Glyph Generator protocols
1414 Generalisation of communication method in Appendix O
1467 New API – EFI_WIRELESS_MAC_CONNECTION_II_PROTOCOL
1480 Refine Progress description in EFI_KEYWORD_HANDLER_PROTOCOL
1452 Minor edits to 0001409
1409 EFI HII ImageEX protocol and EFI HII Image Decoder protocols
1466 UEFI Ram disk protocol
1383 Adding an EraseBlocks() function to a new protocol
1479 UEFI Properties Table Clarification
1491 supplicant errata
1492 wireless mac connection protocol II errata
1493 Updates to the SD_MMC_PASS_THRU interface
1494 Errata against UEFI 2.5 Properties Table
1496 Bad table reference in 13.2 EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Configuration()
1501 Define the usage of the “Address Space Granularity” field is defined in the PCI Root IO
1502 PCI IO Define how to use the Address Translation Offset for systems that are not mapped 1:1
1507 Insufficient qualification of page attributes for AArch64
1508 Lack of flexibility and realism in exception level choice when calling runtime services
1509 EFI_PLATFORM_TO_DRIVER_CONFIGURATION_PROTOCOL Response to unsupported ParameterTypeGuid
1516 Editorial comments against 2.6 Draft
1518 Comments against 2.6 Draft
1519 Version for the next UEFI spec is…
1521 comment against UEFI.next draft – M1479
1522 AArch64 bindings Alignment bit errata
1523 Comments against 2.6 Draft
1533 Bugs in the HTTP usage example
1534 Editorial comments against 2.6 Final Draft
1536 UEFI 2.6 Errata : IMAGE EX Protocol and EFI HII Image Decoder protocol Errata
1538 UEFI TLS errata
1539 New EFI_HTTP_ERROR Status Code
1542 UEFI 2.6 supplicant errata
1543 ip4/6 config policy errata/2.6 update
1544 DNS lookup API spelling
1547 Clarify requirements for setting the PK variable.
1548 Clarify boot procedure when file name is absent

The numbers mentioned are the Mantis issue tracking number that UEFI Forum uses to track changes in the spec. This mantis database is only available to UEFI Forum members, nonmmembers can ignore these, sometimes you can search for older references to mantis numbers for older UEFI spec features.

UEFI 2.6 released

UEFI 2.6 has been released! I’ll have another post shortly that lists the changes to the spec.

Jiewen Yao of Intel checked in a patch to UEFI’s EDK-II trunk today for UEFI 2.6 Memory Attributes Tale support, apparently one of the first 2.6-centric checkins.

Click to access UEFI%20Spec%202_6.pdf

http://uefi.org/specifications

Subject: Β Β Β  [edk2] [patch 0/7] Add UEFI2.6 MemoryAttributesTable support.

This series patches add UEFI2.6 MemoryAttributesTable support. This table is used to retire old PropertiesTable. This is standalone table published by DxeCore, so there is no compatibility issue. The patch is validated with or without properties table.

Β  MdePkg: Add UEFI2.6 MemoryAttributes Table definition.
Β  MdePkg: Add UEFI2.6 MemoryAttributesTable GUID
Β  MdeModulePkg: Add MemoryAttributesTable generation.
Β  MdeModulePkg: Update PropertiesTable for MemoryAttributesTable.
Β  MdeModulePkg: Add CoreInitializeMemoryAttributesTable() to header file.
Β  MdePkg: Call CoreInitializeMemoryAttributesTable() in DXE Entrypoint.
Β  MdePkg: Update DxeCore INF for MemoryAttributesTable.

 

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

ACPI 6.1 released

ACPI v6.1 spec has been released, apparently. I have yet to read it, so not sure what has changed yet.

http://uefi.org/acpi

The UEFI Forum has already started doing EDK-II trunk checkins for 6.1 support for UEFI.

[edk2] [patch] MdePkg: Add ACPI6.1 definition.
Add ACPI 6.1 definitions from the ACPI
Specification Revision 6.1 January, 2016.

MdePkg/Include/IndustryStandard/Acpi61.h | 2375 ++++++++++++++++++++++++++++++
1 file changed, 2375 insertions(+)
create mode 100644 MdePkg/Include/IndustryStandard/Acpi61.h

diff –git a/MdePkg/Include/IndustryStandard/Acpi61.h b/MdePkg/Include/IndustryStandard/Acpi61.h
new file mode 100644

More info:

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

coreboot update

coreboot is nearing it’s 4.3 release. Their last post shows stats of project activity for a single week this month, especially 36 contributors, 11 of them new. The week before there were 13 new contributors!

– Total commits: 111
– New authors: 11
– Total authors: 36
– Total lines added: 10885
– Total lines removed: -604
– Delta: 10281

Two new mainboards – the Google Tidus board (Lenovo ThinkCentre Chromebox), and the Purism Librem 13 laptop are added.

There’s even Ada compiler support added to the toolchain. There are many other changes, not mentioned here, see the full post:

coreboot changelog Jan 20 – Jan 26

NTCTL (NFIT Defined Control) tests added to LUV

Megha Dey of Intel just checked in a 5-part patch to the LUV project, adding a new NDCTL (NFIT Defined Control) test suite to LUV.

This patchset adds the NDCTL(NFIT Defined Control) test suite to LUV. Apart from the recipe, it updates the Linux kernel headers, adds the related binaries and a parser to the final LUV image.It addresses issue 58. We also compile and install the required kernel modules for running theΒ  NDCTL test suite and add the configurations needed by the NDCTL testsuite as config fragments to the default config values from v4.4 kernel. A Non-Volatile DIMM (NVDIMM), is a module that can be integrated into the main memory of a compute platform, perform workloads at DRAM speeds, yet be persistent & provide data retention in the event of a power failure or system crash. The LIBNVDIMM subsystem provides block device drivers for three types of NVDIMMs namely nd_pmem (NFIT enabled version of existing ‘pmem’ driver), nd_blk (mmio aperture method for accessing persistent storage) and nd_btt(give persistent memory disk semantics)that can simultaneously support both PMEM and BLK mode access. The NVDIMM Firmware Interface Table (NFIT) numerates persistent memory ranges, memory-mapped-I/O apertures, physical memory devices (DIMMs), and their associated properties. Prior to the arrival of the NFIT, non-volatile memory was described to a system only using a single system-physical-address range where writes are expected to be durable after a system power loss. Now, the NFIT specification standardizes not only the description of PMEM, but also BLK and platform message-passing entry points for control and configuration. The NDCTL test suite has 5 tests in total divided into 2 sets of tests: One uses the manufactured NFIT (NVDIMM Firmware Interface Table) to build the nfit_test module as an external module and arrange for the external module replacements of nfit, libnvdimm, nd_pmem, and nd_blk and the other which has the actual *destructive* tests that create namespaces and perform I/O tests on them.

Β  luv: NDCTL:Β  Update the linux kernel headers
Β  core-image-efi-initramfs: Add NDCTL binaries
Β  luv-test-manager: Add stderr output to LUV parser
Β  luv : NDCTL: Add NDCTL test suite
Β  linux-efi-yocto-test: build NDCTL test suite

More info:
https://github.com/01org/luv-yocto/issues/58
https://www.kernel.org/doc/Documentation/nvdimm/nvdimm.txt

Click to access ACPI_6.0.pdf

https://github.com/pmem/ndctl
http://permalink.gmane.org/gmane.linux.kernel.commits.head/535671
https://lists.01.org/mailman/listinfo/luv
https://lwn.net/Articles/640891/

LUV/BITS/CHIPSEC ported from x64 to x86!!

Get ready to test your Intel x86 systems!

Megha Dey of Intel submitted an 8-part patch to LUV that enables it to build on x86.

LUV has been useful for 64-bit x64 systems, and now is getting useful for 32-bit x86 systems!

Including 32-bit versions of BITS and CHIPSEC!

Is this the first time that pre-compiled binaries of CHIPSEC for x86 systems have been available? Not sure. Anyway, if you build from source you can start now, otherwise, look for the LUV-live binary download site to start having 32- and 64-bit versions, hopefully

Excerpt from part 0 of the patch:

[PATCH 0/8] Build and run LUV on 32 bit platforms

Currently LUV can be built only for 64 bit target platforms. This patchset contains patches which make sure that LUV can be compiled and run on both 32 as well as 64 bit target platforms. This required reworking of the PE header checks, adding call wrappers used by the shim bootloader to store and restore context, making sure chainloader.c compiled for 32 bit systems, adding support to ensure correct direct directory structure for 32 bit case and removing bugs in chipsec so that it could build without any erros on 32 bit systems. Also, the bits recipe is updated to build the grub EFI image only for target builds.This patchset addresses the following issue:
https://github.com/01org/luv-yocto/issues/57

grub: chainloader: shim: rework PE header checks
grub: shim: Add call wrappers for 32 bit systems
grub: shim: compile chainloader.c for 32bit system
luv : Correct directory structure for 32 bit case
luv: Add the ARCH parameter to chipsec Makefile
luv: chipsec : compile for 32 bit systems
bits: only build grub EFI image for target builds
bits: grub: specify location of images and modules for mkimage

More information:

https://lists.01.org/mailman/listinfo/luv