Category: Uncategorized

Apple Mac Mini EFI firmware update 1.8

~ hucktech ~ Leave a comment

As reported by Apple Support, and mentioned by Apple Insider and 9to5Mac news sites, Apple just released a firmware update for Mac Mini hardware for some models.

“This update is recommended for Mac mini (late 2012) models. This update addresses an issue that may prevent a USB keyboard from being recognized after the system wakes from sleep.”

I don’t know specifics of this release, and what security implications this has.

More Information:

https://support.apple.com/en-us/HT201518
https://support.apple.com/kb/DL1828?locale=en_US
http://appleinsider.com/articles/15/07/15/apple-releases-mac-mini-emi-firmware-update-to-fix-usb-keyboard-issue

Apple issues Mac mini EFI firmware update 1.8 to address USB keyboard problem

CHIPSEC 1.2.1 released

~ hucktech ~ Leave a comment

Intel has released a new minor release of CHIPSEC, version 1.2.1. Some of the CHIPSEC team had just been giving pre-conference training at Recon the other week, and apparently this release fixes some bugs found during that training. There’s no additional information in the readme, the text from this Twitter post is the main information we have:

More information:

https://github.com/chipsec/chipsec

CHIPSEC v1.2.0 Released

ARM’s EDK-II maintainer leaves ARM Ltd for Labapart.com

~ hucktech ~ 1 Comment

Today, Oliver Martin, the TianoCore EDK2 maintainer for the ARM packages for the last 4 years, is leaving ARM, this is his last week. Oliver didn’t give many details on his new project:

Unfortunately, it is still too early to share more details about my future product, so I created a quick website (and found a neutral name) last week-end to allow people to follow the adventure: http://labapart.com/ (can either be pronounced as “Lab apart” or “Lab à Part”).

Given his background with ARM and UEFI, I’ll be curious to see if this new product is at all related…

As I understand it, Leif Lindholm of ARM will take over as new EDK2 ARM role; he has been co-maintainer for the last few months, is experienced with open source, Linux, and has been working on UEFI for Linaro for the last few years.

More Information:
edk2-devel mailing list archives (Subject: Farewell – last days at ARM Ltd)
http://labapart.com/

Reminder: firmware talk/lab at July DC206 Meeting

~ hucktech ~ Leave a comment

This Sunday we’re having a class on using CHIPSEC and related firmware security tools:
http://www.blacklodgeresearch.org/archive/defending-uefi-tools-lab-july-19th-2015/

UEFI tools at Black Lodge Research’s July DC206 Meeting

One change of plans for the lab: I’ve been having problems getting LUV-live to boot on various machines, so don’t want to tie the lab to booting thumbdrives to use CHIPSEC.

So let’s use CHIPSEC installed natively on your laptop. So please bring a Intel UEFI-based laptop running Windows or Linux, where you can install CHIPSEC on it. (The CHIPSEC kernel driver is not a safe thing to keep loaded, see their warning.txt. Only load it when you are using CHIPSEC.) I’ll bring some scripts to make it easier to use CHIPSEC on Linux systems. Watch the Youtube video of DEFCON22 talk on CHIPSEC to see when/why to use some of it’s commands.

CHIPSEC v1.2.0 Released


https://github.com/chipsec/chipsec

Or, instead of running CHIPSEC from w/i your installed OS, make your own LUV-live thumbdrive and see if it works on your system: if so, use CHIPSEC there.

LUV 2.0-RC1 released


https://01.org/linux-uefi-validation/downloads/luv-live-image
http://firmware.intel.com/blog/luv-your-firmware-part-iii
https://01.org/linux-uefi-validation/documentation/flashing-your-usb-stick

Regardless, please don’t use your primary laptop, backup anything important, in case you brick the box.

The lab will be fairly free-form, people trying to use CHIPSEC on their system, hopefully to save a ROM and share with others, and to some analysis of the ROM using CHIPSEC, UEFITool, UEFI Firmware Parser. If you are willing to share some ROMs with the rest of the lab attendees, please try to bring a system with a CD-R/DVD-R burner. I’ll bring some blank discs. CHIPSEC and most of the below tools are Python-based, so install CPython 2.7x on your system. Install any of the below tools if you want to use these to examine ROMs:

UEFITool:

tool mini-review: UEFITool


https://github.com/LongSoft/UEFITool

UEFI Firmware Parser:

tool mini-review: UEFI Firmware Parser


https://github.com/theopolis/uefi-firmware-parser

Copernicus’ BIOS Diff:

Tool mini-review: bios_diff.py


https://www.blackhat.com/docs/us-13/US-13-Butterworth-BIOS-Security-Code.zip

Most of these tools are Python-based, but UEFITool is a C++-based Qt GUI app. You need to get Qt Creator installed, open Qt Creator, open the UEFI Tools’s .pro file, then Build it. UEFITool builds on most platforms pretty painlessly. If you don’t want to install Qt on your system, you can download pre-built binaries of UEFITool for Windows and Mac OSX. For Linux, no binaries provided, you must build from source.
http://www.qt.io/download-open-source/
https://github.com/LongSoft/UEFITool/releases

One potential direction for the lab is to look at Intel’s analysis of the Hacking Team’s UEFI malware, and how to use CHIPSEC and UEFITool, using the GUIDs and strings from the below analysis to see if you have Hacking Team bootkit.
http://www.intelsecurity.com/advanced-threat-research/blog.html

Unfortunately, it looks like the PNWFHW (Pacific NorthWest FirmWare Hackers) stickers likely won’t arrive in time, probably next week, so no stickers this time, sorry.

Intel analysis of Hacking Team UEFI malware

~ hucktech ~ Leave a comment

[[
UPDATE: IntelSecurity.com web site has changed, the ATR blog URL is broken. Updated URL:
http://www.intelsecurity.com/advanced-threat-research/ht_uefi_rootkit.html_7142015.html
]]

A quick follow-up to the Hacking Team UEFI malware story. There’s been a lot of mainstream coverage on this news. I just found out about this blog entry by the Intel Advanced Threat Research (ATR) team:

http://www.intelsecurity.com/advanced-threat-research/blog.html

It’s analysis of the malware is excellent, and worth reading. Unlike other news stories on Hacking Team, this blog shows you how to check if your system is infected. They used CHIPSEC[1] and UEFItool[2] to analyse this malware, two excellent tools for UEFI forensic analysis. Study this Intel blog post for a very topical example of how to use CHIPSEC to protect your system from bootkits.

[1] https://firmwaresecurity.com/2015/06/10/chipsec-v1-2-0-released/
https://github.com/chipsec/chipsec
[2] https://firmwaresecurity.com/2015/05/25/tool-mini-review-uefitool/
https://github.com/LongSoft/UEFITool

Hacking Tool should remind people that they don’t have a clue what modules are burned into their firmware. Many firmware solutions target enterprise sales, so they’re happy to have phone-home style technology in their systems, to track their assets. Malware authors can take advantage of these remote control features, like Hacking Team is doing. Windows OEMs generally screw up Windows with various bloatware; unlike with OS software, you cannot undo firmware bloatware, the OEM won’t permit you to rebuilt the firmware image (unless you have a Tunnel Mountain or MinnowBoard), and the OEM doesn’t provide standalone UEFI drivers/services so that you could rebuilt your firmware from coreboot.org and/or tianocore.org plus the delta of blobs (OEM/IHV drivers). Then, we could focus on reliability of the open source codebase and the handful of closed-source firmware drivers, instead of relying on the IBV/OEM to give us black-box fimware updates when they feel like it. OEMs: give us better firmware options!

tool review: uefi-spider (and firmware_vault)

~ hucktech ~ 3 Comments

UEFI Spider is a tool that crawls/downloads UEFI/BIOS updates from multiple ISV/OEM distributors. It contains a set of highly specific scripts containing spidering logic for ISV/OEMs providing downloadable UEFI firmware updates. Each spider will attempt to document (in JSON) and download every identified UEFI firmware update. The tool is written in Python, and needs the Python scrapy library to work. It has support for these vendors: ASRock, Dell, Gigabyte, Intel, Lenovo, HP, MSI, and VMware.

“WARNING: Using this tool is dangerous, upon running each spider you will have downloaded well over 50G of firmware updates. This is highly taxing on both your bandwidth and the services hosting the updates. Please read the EULA for each site before spidering. This code is provided for reference only; this project and its authors do not encourage using the spiders.”

The tool is written by Teddy Reed (“theopolis”), who also created the UEFI Firmware Parser.

More Information:
https://github.com/theopolis/uefi-spider

There isn’t Apple support in these scripts. However, someone else recently started collecting Apple ROMs:
https://github.com/gdbinit/firmware_vault

I’m lazy, I wish one person would keep an online respository of ALL known BIOS/UEFI ROMs, so each security researcher wouldn’t have to crawl each vendors’ site on an ongoing basis.

UEFI 2.5 change list

~ hucktech ~ Leave a comment

I’ve been meaning to look more closely into version 2.5 changes in UEFI. So far, I’ve only looked at UEFI HTTP Boot, at a little at the NVMe passthru protocol.

Looking at the UEFI 2.5 spec from uefi.org, the initial pages of the document include it’s revision history.  It appears the UEFI 2.5 changes were done in two batches, February 2015 and April 2015. I’m listing the revisions below, with the “2.5” prefix and the “<Month> 2015” suffix removed, for clarity.

The number is the Mantis issue-tracking number, something only useful for UEFI Forum members. If you are a UEFI Forum member, you can presumably access their Mantis system and get more information about the changes. The public only has the title, and a useless Mantis number.  Perhaps the submitter for UEFI 2.5 mantis entry 1147 is the NSA or the Hacking Team? 🙂 We’ve no idea, the title for that change is “REDACT”. 😦

I wish the UEFI Forum would spend a few minutes in their release phase to give a paragraph or two of information about these changes. At minimum, they should mention where in the spec(s) this change impacts, if the new software feature will be in open source TianoCore implementation or only in commercial products. If the code is in TianoCore, it would be nice to mention the SVN build number, like the TiaonCore Security Advisories do — so you can compare the before/after in the code more easily. SVN build numbers would be more a lot useful to the public than the “<Month> <YEAR>” string added to the title of each revision entry.

Here are the UEFI 2.5 updates:

1071 New EFI_HASH2_PROTOCOL
1090 ESRT: EFI System Resource Table and component firmware updates
1091 Clarification of handle to host FMP
1103 Longer term New CPER Memory Section
1109 Smart Card Reader
1121 IPV6 support from UNDI
1147–REDACT
1163 Inline Cryptographic Interface Protocol proposal
1166 hash 2 protocol errata
1158 errata – boot manager clarification
1159 Proposal for System Prep Applications
1167 Persistent Memory Type support
1174 errata – Error in EFI_IFR_PASSWORD logic flowchart
1183 New Protocol with 2 Function for PKCS7 Signature Verification Services
1186 AArch64 binding clarifications and errata
1191 Add new SMBIOS3_TABLE_GUID in EFI_CONFIGURATION_TABLE
1199 Add NVM Express Pass Thru Protocol
1201 Exposing Memory Redundancy to OSPM
1204 new UEFI USB Function I/O Protocol addition to the UEFI spec
1212 UEFI.Next feature – HTTP API
1213 UEFI.Next feature – HTTP helper API
1214 UEFI.Next feature – HTTP Boot
1215 UEFI.Next feature – DNS version 4
1216 UEFI.next feature – DNS version 6
1217 UEFI.Next feature – WIFI support
1218 UEFI.Next feature – EAP2 Protocol
1219 UEFI.Next Feature – UEFI TLS API
1220 UEFI.Next feature – Bluetooth
1221 UEFI.Next feature – REST Protocol
1222 UEFI.Next feature – BMC/Service Processor Device Path
1223 UEFI.Next networking features – chapter 2.6 requirements
1224 UEFI.Next – Adding support for No executable data areas
1227 UEFI.Next feature – Platform recovery
1234 UEFI.Next feature – Smart card edge protocol
1244 sections of the spec mis-arranged
1251 EFI_REGULAR_EXPRESSION_PROTOCOL and EFI_IFR_MATCH2 HII op-code
1254 SD Device Path
1255 UFS Device Path Node Length
1257 Correct the typedef definitions for EFI_BOOT_SERVICES/EFI_RUNTIME_SERVICES–Reiterate
1263 Customized Deployment of Secure Boot
1266 UEFI.Next Feature – IP_CONFIG2 Protocol
1268 RAM Disk UEFI Device Path Node
1269 Configuration Routing Protocol and Configuration String Updates
1287 Errata: EFI Driver Supported EFI Version not matching the spec revision
1288 The Macro definition conflict in EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.SetAttribute() in UEFI 2.4 B
1303 Update the UEFI version to reflect new revision
1304 Add IMAGE_UPDATABLE_VALID_WITH_VENDOR_CODE to FMP Check image
1308 Fix typo’s found in the final/published UEFI 2.4 Errata B spec
1309 Disallow EFI_VARIABLE_AUTHENTICATION from Secure Boot Policy Variables
1339 Errata in section 7.2.3.2 Hardware Error Record Variables
1341 DNS4 – friendly amendment to be reviewed by USWG
1342 DNS6 – friendly amendment for review by USWG
1345 EFI_USB2_HC_PROTOCOL Errata
1346 Mantis 1288 Errata
1347 Boot Manager Policy Errata
1348 ERRATA – Section 10.12 EFI_ADAPTER_INFORMATION_PROTOCOL Custom Types
1350 Keyword Strings Errata
1352 Errata for 1263 and 1227
1353 SATA Device Path Node Errata
1358 v2.5 amendment and v2.4 errata (missed implementation of Mantis 1089)
1360 Vendor Range for UEFI memory Types
1362 HTTP boot typos/bugs
1364 Extend supplicant data type for EAP

I’ll start to dig into a subset of this list in upcoming blog entries, starting with ones that have TianoCore implementation-related checkins.

Twitter, and Hacking Team

~ hucktech ~ Leave a comment

This blog isn’t attempting to cover ALL firmware news issues. I presume you’re reading about elsewhere, and don’t need this blog to tell you about. Especially stories that make it ‘mainstream’, like the recent Apple EFI vulnerability, or the recent Hacking Team’s use of UEFI in their malware.

In general, I go online and try to see what is new with firmware news only once a day, and miss some days. I don’t use Twitter as much as many, so I’m naturally behind-the-times of fresh news. To track UEFI issues with Twitter, here are a few URLs to start with:

https://twitter.com/legbacore/
https://twitter.com/intel_uefi

For example the Hacking Team’s use of UEFI. Twitter is a good place for this kind of news:

And a few security researchers are starting to dig deeper with research about the malware, such as:
http://blog.trendmicro.com/trendlabs-security-intelligence/hacking-team-uses-uefi-bios-rootkit-to-keep-rcs-9-agent-in-target-systems/

coreboot 4.1 released

~ hucktech ~ Leave a comment

It has been 5 years since coreboot 4.0, so coreboot 4.1 is a big deal! Excerpting the coreboot blog:

“There have been as many significant original developments, such as support for many new architectures (ARM, ARM64, MIPS, RISC-V), and related architectural changes like access to non-memory mapped SPI flash, or better insight about the internals of coreboot at runtime through the cbmem console, timestamp collection, or code coverage support.”

In addition to new features, it appears coreboot will get on a more regular release cycle:

“Future releases will happen more frequently, and with more guarantees about the state of the release, like having a cool down phase where boards can be tested and so on. I plan to create a release every three months, so the changes between any two release don’t become too overwhelming. Starting with coreboot 4.1, we will maintain a high level changelog and ‘flag days’ document. The latter will provide a concise list of changes which went into coreboot that require chipset or mainboard code to change to keep it working with the latest upstream coreboot.”

I am looking forward to seeing how this release works with the UEFI CoreBootPkg…

More Information:

Announcing coreboot 4.1


http://www.coreboot.org/releases/

UEFI Mini-Summit at LinuxCon Europe in October

~ hucktech ~ Leave a comment

The UEFI Forum has recently announced they’ll do a UEFI Mini-Summit at the next LinuxCon Europe, in Dublin on October 7th.

Sessions:
* UEFI Forum Update and Open Source Community Benefits – Mark Doran, Intel
* What Linux Developers Need to Know About Recent UEFI Spec Advances – Jeff Bobzin, Insyde Software
* LUV Shack: An automated Linux kernel and UEFI firmware testing infrastructure – Matt Flemming, Intel
* The Move from iPXE to Boot from HTTP – Dong Wei, HP
* UEFI Development in an Open Source Ecosystem – Vincent Zimmer and Michael Krau, Intel

More Information:
http://uefi.org/node/947
http://events.linuxfoundation.org/events/linuxcon-europe/extend-the-experience/co-located-events

 

Tool review: UBU-helpers

~ hucktech ~ 1 Comment

Tool Review: UBU-helpers

[UPDATED, with feedback from reader. Thanks!]

UBU-helpers is a collection of tools used to examine UEFI binaries. The UBU-helpers code is portable C, built with CMake, so it should work on most UNIX systems as well as other common platforms with decent C compilers. The project is maintained: the tools were updated a few days ago. Currently there three tools: Hex Find (hexfind), Find Version (findver), and Driver Version (drvver).

1) Hex Find (hexfind) is a simple tool that searches for a pattern in a file.

hexfind v0.1.2
Usage: hexfind PATTERN FILENAME

2) Find Version (finder) is simple tool that also searches for version-based patterns in a file.

findver v0.3.2
Prints version string found in input file
Usage: findver prefix pattern offset end_marker max_length FILE
Options:
prefix      – Prefix string, ASCII symbols
pattern     – Pattern to find, hex digits
offset      – Offset of version string, integer
end_marker  – Pattern that marks end of version string, 2 hex digits
max_length  – Maximum length of printed version string, integer
num_location- Number of location, integer

3) Driver Version (driver) searches for multiple UEFI drivers/applications via hardcoded string/offset searches.  It — as do the other two tools — uses a Boyer-Moore-Horspool algorithm for it’s find algorithm.

drvver v0.19.2
Reads versions from input EFI-file
Usage: drvver DRIVERFILE
Support:
GOP driver Intel, AMD, ASPEED.
SATA driver Intel, AMD, Marvell
LAN driver Intel, Realtek, Broadcom

Here’s the printf statements of what drvver recognizes:

EFI GOP Driver SandyBridge – 2.0.%s
EFI GOP Driver IvyBridge   – 3.0.%s
EFI GOP Driver Haswell     – 5.0.%s
EFI GOP Driver Broadwell   – 5.5.%s
EFI GOP Driver CloverView  – 6.0.%s%S
EFI GOP Driver ValleyView  – 7.%c.%s%S
EFI GOP Driver CherryView  – 8.0.%s
EFI GOP Driver SkyLake     – 9.0.%s
EFI GOP AMD                – %s_signed
EFI GOP AMD                – %s
EFI GOP-in-OROM ASPEED     – %x.%02x.%02x
EFI GOP ASPEED             – %x.%02x.%02x
EFI IRST RAID for SATA     – %s
EFI AMD RAID               – %s
EFI AMD Utility            – %s
EFI AMD Utility            – %c.0.0.%c%c
EFI IRSTe RAID for SCU     – %s
EFI IRSTe RAID for sSATA   – %s
EFI IRSTe RAID for SATA    – %s
EFI Marvell SATA RAID      – %x.%x.%x.%04x
EFI Marvell SATA AHCI      – %x.%x.%x.%04x
EFI Intel 40GbE UNDI       – %x.%x.%02x
EFI Intel 10GbE UNDI       – %x.%x.%02x
EFI Intel PRO/Server UNDI  – %x.%x.%02x
EFI Intel Gigabit UNDI     – %x.%x.%02x
EFI Intel PRO/1000 UNDI    – %x.%x.%02x
EFI Intel FCoE Boot        – %s
EFI Broadcom UNDI          – %d.%d.%d
EFI Realtek UNDI           – %x.%03x %X%s
EFI Realtek UNDI           – %x.%03X%s
CPU Microcode 040671 BDW   – %02X
CPU Microcode 0306C3 HSW   – %02X
CPU Microcode 0206A9 IVB   – %02X
CPU Microcode 0306A7 SNB   – %02X
CPU Microcode 0306F2 HSW-E – %02X
CPU Microcode 0506E3 SKL-S – %02X
Unknown version GOP Driver
Unknown Intel LAN version.
Unknown Broadcom LAN version.
Unknown Realtek LAN version.
Unknown Realtek LAN version.

If you need to search for specific EFI strings in EFI binaries, these tools might be just what you needed. For more information, see the source code:

https://github.com/LongSoft/UBU-helpers

These tools were created to augment another tool which I’ve not used yet, “UEFI BIOS Updater (UBU)”. Here’s more information on that:

http://www.win-raid.com/t154f16-Tool-Guide-News-quot-UEFI-BIOS-Updater-quot-UBU.html

LinuxCon North America this August in Seattle

~ hucktech ~ Leave a comment

LinuxCon North America is happening this August, in Seattle for the first time (I think). A quick look at their schedule shows a variety of interesting presentations related to firmware security:

* Extending the Secure Boot Certificate and Signature Chain of Trust in the OS – Fionnuala Gunter, Hypori
* Resurrecting Internet Booting – Boot Boot, Booting Over the Internet – John Hawley, Intel
* Demystifying ACPI and EFI via Python and BITS – Josh Triplett
* ACPI for Network Switches – Dustin Byford, Cumulus Networks
* Tying TPMs Throughout The Stack – Matthew Garrett, CoreOS
* Turtles All The Way: Running Linux on Open Hardware – Rob Landley
* ACPI 6 and Linux – Rafael J. Wysocki, Intel
* The Bare-Metal Hypervisor as a Platform for Innovation – Russell Pavlicek, Citrix
* Suspend/Resume at the Speed of Light – Len Brown, Intel

Josh Triplett on BIOS BITS sounds especially interesting. It’ll be interesting to see if the boot boot reboot will get integrated with UEFI HTTP Boot support.

More information:
http://events.linuxfoundation.org/events/linuxcon-north-america
http://events.linuxfoundation.org/events/linuxcon-north-america/program/schedule

Replicant on mobile device security

~ hucktech ~ Leave a comment

The Replicant project is a Free Software-specific fork of Android, which focuses on users’ freedoms, and privacy/security. They try to get Android running without any firmware- or OS-level “blobs”, which gives them technical perspectives that most don’t have. They have a document which gives a decent introduction to mobile device security, including hardware, firmware, OS, and app issues, and about security issues of mobile baseband chips.. The advice is focused for someone using Replicant, but the app advice is applicable to most Android users.

More Information:

http://www.replicant.us/freedom-privacy-security-issues.php

FreeBSD 10.2 beta1 released

~ hucktech ~ Leave a comment

Today FreeBSD announced availability of release 10.2-BETA1.

Amongst the new features/changes in this release, for firmware these changes are interesting:

* The uefisign(8) utility has been added. [r282974] (Sponsored by The FreeBSD Foundation)
* The acpi(4) subsystem has been updated to version 20150515. [r284460]
* Throttling via ACPI and P4TCC via device.hints(5) have been turned off by default. [r276986]
* The boot loader has been updated to support entering the GELI passphrase before loading the kernel. To enable this behavior, add geom_eli_passphrase_prompt=”YES” to loader.conf(5). [r281843]
* The memory test run at boot time on FreeBSD/amd64 platforms has been disabled by default. [r283262] (Sponsored by The FreeBSD Foundation)

Besides the above changes, there’ve also been a variety of iSCSI changes, unclear if this impacts UEFI’s iSCSI at all. And the Hyper-V drivers have been updated, sponsored by Microsoft’s Open Source Technology Center. [I am ignorant to Hyper-V technology, I guess I need to check how open source Hyper-V code in NanoBSD  impacts UEFI.]

More Information:
https://www.freebsd.org/relnotes/10-STABLE/relnotes/article.html
https://lists.freebsd.org/pipermail/freebsd-stable/2015-July/082704.html

PS: Unrelated to FreeBSD release, appears Intel CHIPSEC team is about to release 1.2.1, there is activity on their Github site:

https://github.com/chipsec/chipsec

VirtualBox 5.0 released

~ hucktech ~ Leave a comment

Oracle relased version 5.0 of VirtualBox yesterday. I don’t see any firmware features listed in the press, and I’ve not had a chance to do a code review of the new code yet. It has improved CPU and USB 3.0 support, at minimum.

QEMU is the main platform for running UEFI’s virtual firmware: OVMF. But Xen, KVM, and VirtualBox also support OVMF, to some degree. VirtualBox can also be recompiled with EFI-specific build directives to enable additional UEFI diagnostics.

https://www.oracle.com/corporate/pressrelease/oracle-vm-virtualbox-5-070915.html

https://blogs.oracle.com/virtualization/entry/oracle_vm_virtualbox_5_07

(In somewhat related news, back in March, Oracle’s Linux distro got Secure Boot support.)

https://blogs.oracle.com/wim/entry/secure_boot_support_with_oracle

 

OpenStack’s hardware introspection service 2.0 released

~ hucktech ~ Leave a comment

Dmigtry Tantsur of Red Hat announced version 2.0 of OpenStack’s hardware introspection service was released today on the openstack-announce list.

“This is an auxiliary service for discovering hardware properties for a node managed by OpenStack Ironic. Hardware introspection or hardware properties discovery is a process of getting hardware parameters required for scheduling from a bare metal node, given it’s power management credentials (e.g. IPMI address, user name and password). A special ramdisk is required to collect the information on a node. The default one can be built using diskimage-builder and ironic-discoverd-ramdisk element. Highlights of this release:

* Main Python module was renamed to ironic_inspector
* Client library was split away to a separate project
* edeploy plugin was removed in favor of more generic one called ‘extra_hardware’
* Processing hooks interface was changed
* The way we return API errors was changed to better match Ironic one
* Removed deprecated /v1/discover endpoint
* All options (except for ‘database’) were moved to sections instead of  using ‘discoverd’ for everything
* oslo.db configuration should be used instead of ‘discoverd.database’  option
* keystonemiddleware options should be used instead of reusing ‘ironic’  credentials for checking authentication
* Deprecated ‘authenticate’ opt in favor of ‘auth_strategy’
* Explicit green thread pool is used instead of just launching new threads
* NodeInfo class became more helpful for hooks
* Now it’s possible to hook into processing chain when node is not found
* Inspector no longer checks for Ironic presence on start up as it was  causing problems in real life
* SSL/TLS Support”

More Information:

https://github.com/openstack/ironic-inspector
https://pypi.python.org/pypi/ironic-inspector/2.0.0
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

EDK-II specs updated

~ hucktech ~ Leave a comment

[

UPDATE: Below I complain about lack of an announce mechanism to find these updates; TianoCore has an RSS feed that I’ve been neglecting to check, so they have been announcing it, but I’ve not been noticing…

http://www.tianocore.org/news/feed.xml

]

Today, the EDK-II specs were revised.

“Announcing the 1.25 Updates to the EDK II Specifications (BUILD, DSC and FDF). Also Update to Visual Forms Representation (VFR) V 1.9.”

(I stumbled upon announcement on web page by accident; I wish these were announced on edk2-devel or somewhere else more easily-discoverable.)

More Information:

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Specifications