Tag: Intel

microcode update tool for Intel Broadwell systems

~ hucktech ~ Leave a comment

There’s a new firmware-related github-hosted project out there, as of the last hour: bdw-ucode-update-tool by Benjamin Woodruff:

Broadwell μcode Update Installer: Intel i5-5675C, i7-5775C, and i7-5700HQ microcode updates extracted from MSI’s UEFI updates, along with a tiny zero-dependency install script for Linux users. Intel’s late Broadwell chips shipped with a whole slew of stability issues, causing Machine Check Exception kernel panics on Linux and BSODs on Windows. While Intel hasn’t directly distributed any new microcode updates since January, they’ve apparently distributed updates to some motherboard vendors. Until Intel updates the downloads on their site, I’ve extracted the updates from MSI’s firmware, using a custom python script. I don’t use Windows however, so I’ve only personally verified the first case. I also don’t have installation instructions for Windows, as I don’t know how to install custom microcode updates on Windows. […]

Interesting solution… IMO, it sounds like Intel should be solving this directly, not forcing end-users obtain it from other IBV’s blobs. 🙂 I wish there was a tool that could tell me if a system had the latest microcode from the vendor, and how I could check if the vendor had updates available.

More information:

https://github.com/bgw/bdw-ucode-update-tool

 

UDK 2015 available

~ hucktech ~ Leave a comment

UDK2015 has been released.

Intel(R) UEFI Development Kit (UDK) 2015

UDK2015.Complete.MyWorkSpace.zip
https://svn.code.sf.net/p/edk2/code/branches/UDK2015: r18552
https://svn.code.sf.net/p/edk2-fatdriver2/code/trunk/FatPkg: r96

NEW FEATURES AND CHANGES :
1.  Support UEFI specification 2.5, except for EXCEPTION_LIST are not implemented.
2.  Support Platform Initialization(PI) specification 1.4.
3.  Add ACPI 6.0 definitions.
4.  Add SMBIOS 3.0 definitions.
5.  Support OpenSSL version 1.0.2d.

EXCEPTION_LIST*:
1)  1220 UEFI.Next feature – Bluetooth
2)  1212 UEFI.Next feature – HTTP API (HTTP 1.1 IPv6)
3)  1214 UEFI.Next feature – Boot from HTTP (IPv6)
4)  1217 UEFI.Next feature – WIFI support
5)  1218 UEFI.Next feature – EAP2 Protocol
6)  1219 UEFI.Next Feature – UEFI TLS API
7)  1221 UEFI.Next feature – REST Protocol
8)  1222 UEFI.Next feature – BMC/Service Processor Device Path
9)  1263 UEFI.Next feature – Customized Deployment of Secure Boot
10) 1268 RAM Disk UEFI Device Path Node
11) 1251 EFI_REGULAR_EXPRESSION_PROTOCOL
12) 1227 UEFI.Next feature – Platform recovery
13) 1347 Boot Manager Policy Errata
14) 1352 Errata for 1263 and 1227
15) 1353 SATA Device Path Node Errata

http://sourceforge.net/projects/edk2/files/UDK2015_Releases/UDK2015/
http://www.tianocore.org/news/2015/09/29/UDK2015_Preview.html

There’s a lot of UEFI 2.5 NOT in this UDK release, I guess we have to wait for future UDK releases for full UEFI 2.5 support.

Libiquity Taurinus X200

~ hucktech ~ Leave a comment

As noted by LinuxDevices:

The Ministry of Freedom is getting some competition refurbishing Thinkpads with Free Software!  Purism is getting some competition disabling Intel security features! 🙂

https://shop.libiquity.com/product/taurinus-x200

http://www.linux.com/news/hardware/laptops/856777-taurinus-x200-now-the-most-free-software-laptop-on-the-planet/
http://www.zdnet.com/article/a-new-free-software-laptop-arrives/

 

coreboot changes

~ hucktech ~ Leave a comment

The coreboot blog has a long post, which covers the last five weeks of changes, and there were a lot: 314 commits. Some highlights:

Over one third of the commits covers Intel Skylake development, where boards and chipset code saw misc improvements and tons of clean ups.

There also was a notable effort of unifying common code across the more recent Intel SoCs, removing lots of duplicated code all over the place.

On x86, the romstage is now relocated for its final location in CBFS by cbfstool, obsoleting the old approach that had us link it twice, once to determine its final size and then to the actual location it’s supposed to run from. In the future this same approach may be extended to other files that need to be executed in place such as the FSP binary.

The romstage change eliminated the need for cbfstool’s “locate” command, and so it was removed. cbfstool also saw other extensions, the biggest one a compatible change to the format to allow for per-file attributes in CBFS. These attributes can contain additional information about a file, currently the compression method and uncompressed size of a file. cbfstool and the build system were extended to allow compressing files, libpayload is able to uncompress these files.

On the AMD side, there were various bugfixes both for new (merlin falcon) and old (Fam10) chipsets.

ARM64 and Tegra210 saw various bugfixes and improvements to power use. For the latter, coreboot also learned how to reserve memory for other functions than the main processor.
Rockchip’s RK3288 ARMv7 SoC also saw a number of bug fixes and the code was restructured to use a single mainboard directory for a large number of very similar Google Veyron mainboards based on that SoC.

Our RISCV support now boots on the Spike simulator which (besides supporting a wider variety of emulators) is notable because unlike the QEmu RISCV support, Spike supports RISCV’s revised ABI.
Speaking of emulators, recent versions of qemu-x86 expect the firmware to initialize the LAPIC, which we now do.

The ongoing effort to move CPU microcode into CBFS (and to store these as binaries in 3rdparty/blobs instead of header files in the main sources) saw some progress.

Lots of interesting things were omitted above. Full post:

coreboot changelog, most-of-september edition

Intel EFI Disk Utilities

~ hucktech ~ Leave a comment

Intel has a set of disk utilities, for creating/checking GPT partitions and FAT file systems. They aren’t included in TianoCore’s EDK2 with the other BSD-licensed UEFI Shell commands. These tools ship separately, with a separate license, presumably due to the tool’s knowledge of FAT file system format. Here’s a brief description of the tools, as excerpted from the download license:

Microsoft EFI Utilities: The term “Microsoft EFI Utilities” shall mean the Guided Partition Table utilities Diskpart (Disk partitioning utility), Efifmt (EFI Format utility) and Efichk (EFI Check Disk utility) stored in a file named GPT_UTIL.zip.

To get the tools, you have to agree to the license on this page, if so you get to download a zip. Then you have to read the readme in that zip, to get the password for the other included zip, which contain the actual tools. Lawyer-designed.

http://www.intel.com/technology/efi/agree_diskutil.htm

The tools come with source, not just binary. They didn’t compile for me, this morning: I think they require a much older EDK2 environment to build. But at least they ship with source, though it is not BSD-licensed Open Source. The tools are old enough that they still use “EFI”, not the newer “UEFI” term.

I wish Intel could donate these tools to the UEFI Forum, so that Intel- *AND* ARM-based users could benefit. TianoCore already has a FAT license, for it’s file system driver. Adding these tools to that package would eliminate one FAT-centric license, and bundle FAT-centric tools along with the FAT-centric file system driver. It would be nice for TianoCore to be able to fix/create ESPs, not just run from ESPs created elsewhere. Perhaps use the Disk Util common code for some other UEFI-based file system diagnostic tools for file systems that UEFI ships, eg UFS, maybe UDF.

LUV 2.0 RC3 released

~ hucktech ~ Leave a comment

Ricardo Neri of Intel announced version 2.0-RC3 of the LUV (Linux UEFI Validation) distribution today. It includes fresh versions of CHIPSEC, FWTS, BITS, as well as changes to LUV. Excerpts of announcement:

This release includes improvements to allow to use the same LUV USB stick several times and save the results of all the executions. This comes handy when, for instance, you want tests several systems or you need to run LUV several times if you are debugging. From now on, the luv-results directory name will be appended with a timestamp; it will look like: luv-results-yyyy-mm-dd–hh-mm-ss. A new directory will be created each time you run LUV. If, for any reason (e.g., your system resets the real time clock each time you reboot) a directory with the same timestamps exists already in the luv-results partition, a number will be appended to the newly created directory.

We have bumped the following test suite versions: FTWS is now V15.09.00, CHIPSEC is now v1.2.1, BITS is now 2005.

On top of FWTS, we have a applied a patch to downgrade the the severity of failure in systems that are prepared for Secure Boot (i.e., have a database of keys and certificates) but do not have the Microsoft UEFI CA certificate. This is especially relevant for users that want to build their own chain of trust. This is a patch that is in process of being merged in to FWTS (https://lists.ubuntu.com/archives/fwts-devel/2015-September/006884.html).

We also have included a change in the LEG (Linaro) kernel to fix a build break due to a problem in the kernel configuration. Work is in progress to use the mainline kernel instead of the LEG kernel tree.

There are patches to improve builds of sbsigntool in native and cross-compilation mode.

More info:
https://lists.01.org/pipermail/luv/2015-September/000610.html

https://download.01.org/linux-uefi-validation/v2.0/luv-live-v2.0-rc3.tar.bz2
https://download.01.org/linux-uefi-validation/v2.0/sha256_sums.asc

Intel Kernel Guard Tech: multiple projects

~ hucktech ~ Leave a comment

Earlier I briefly mentioned Intel Kernel Guard Technologies (iKGT).

https://firmwaresecurity.com/tag/ikgt/

I don’t see any checkins yet to the UEFI project, still empty.

But I just noticed that this project contains multiple other projects, which I didn’t notice earlier, and a few of them aren’t empty:

https://github.com/01org?utf8=%E2%9C%93&query=iKGT

https://github.com/01org/ikgt-uefi-loader
https://github.com/01org/ikgt-loader
https://github.com/01org/ikgt-manifest
https://github.com/01org/ikgt-api
https://github.com/01org/ikgt-core
https://github.com/01org/ikgt-plugin
https://github.com/01org/ikgt-usage

Teddy Reed research on Minnow firmware

~ hucktech ~ Leave a comment

As found by ‘retweeted’ by the CHIPSEC team:

Teddy Reed has an EXCELLENT blog post — the first in a series! — going into detail about the firmware of Intel’s MinnowBoard.

Again, this is an EXCELLENT article, worth reading!

http://prosauce.org/blog/2015/9/13/minnowboard-max-quickstart-uefi-secure-boot

Intel Clear Linux announces Clear Containers for Docker

~ hucktech ~ Leave a comment

Today Dimitri John Ledkov of Intel’s Linux team announced the availability of Clear Containers for Docker Engine for multiple OSes. This enables executing existing Docker applications in the secure and fast Clear Containers environment. The experimental source code is based on the Docker 1.8.1 upstream release. The primary host platform is Clear Linux Project for Intel Architecture, version 4000 or better, and binaries for multiple OSes, including: CentOS, Scientific Linux, Fedora, openSUSE, Debian, and Ubuntu.

The Clear Linux Project for Intel Architecture is a distribution built for various cloud use cases in order to showcase the best of Intel Architecture technology, from low-level kernel features to complex applications that span across the entire OS stack. We’re putting emphasis on power and performance optimizations throughout the operating system as a whole. Clear Containers leverage the isolation of virtual-machine technology along with the deployment benefits of containers. The security of containers is improved by using Intel Virtualization Technology (Intel VT). The optimization of key components results in slimmer, simpler, safer and substantially speedier virtualization.

For more information, see the full announcement on the archives of the dev list.

https://lists.clearlinux.org/mailman/listinfo/dev
http://clearlinux.org/
https://software.opensuse.org/download.html?project=home%3Aclearlinux%3Apreview&package=clear-containers-docker
https://clearlinux.org/features/clear-containers
https://lwn.net/Articles/644675/
https://github.com/clearlinux/docker

Home

AMI updates firmware of Intel Compute Stick

~ hucktech ~ Leave a comment

BIOS manufacturer AMI has updated their Aptio V UEFI-based firmware solution for the Intel Compute Stick. The update adds “UEFI Bluetooth Keyboard Support”.

Excerpt:
AMI is pleased to announce the addition of UEFI Bluetooth® keyboard support for the Intel® Compute Stick in its flagship Aptio® V UEFI Firmware. The Intel® Compute Stick is a small form factor computer with a quad-core Intel® Atom™ processor and Intel® HD Graphics. It features integrated WiFi® and Bluetooth capability and offers 32 GB of storage and 2 GB of RAM memory along with a USB 2.0 port and microSD™ card reader that can be plugged into any HDMI capable monitor. Users can add their own Bluetooth peripherals, such as keyboard and mouse, to create a full-fledged computer from this tiny yet powerful device. By adding Bluetooth keyboard support to Aptio V, the flagship UEFI firmware from American Megatrends, users of small form factor devices like the Intel® Compute Stick can now access the UEFI BIOS settings with their Bluetooth keyboard to make BIOS customizations that get the most out of these pocket powerhouse computers.
“Intel is pleased to have partnered with AMI on this achievement,” said Joel Christensen, General Manager, Intel® Compute Stick. “Adding the ability to utilize Bluetooth keyboards while in BIOS is a great step in improving the end user experience.”

(I’m not sure if this is a new UEFI protocol for BT keyboards, or just a normal BT stack with a normal keyboard, nor if this is new AMI code or part of what is in Tianocore.org.)

More Information:

http://www.ami.com/news/press-releases/?PressReleaseID=330&/American%20Megatrends%20Adds%20UEFI%20Bluetooth%C2%AE%20Keyboard%20Support%20for%20Intel%C2%AE%20Compute%20Stick%20to%20Aptio%C2%AE%20V%20UEFI%20Firmware/

Purism Librem-13 gets 100% funded

~ hucktech ~ Leave a comment

According to this tweet, Purism got their Librem13 laptop funded. Congratulations!

Looking at the above ‘thread’, it mentions two other items of Purism news.

It sounds like that after Notebooks, they’re going to target Tablets, then Smartphones.

“First privacy respecting Librem notebooks. Next: Tablets. And then: Smartphone.”

Also, it looks like they’ll have some more news on their firmware efforts, specifically related to their efforts fighting the Intel Management Engine (ME):

“we have big news soon on freeing the ME. All firmware updates will be provided”

The already have semi-regular posts on their blog by their firmware developer, with some more news that I’ve not covered. I’m not sure what the second sentence above means. Other OEMs currently provide firmware updates to ME already. Providing full source updates would be impressive, but I doubt they meant that.

https://www.crowdsupply.com/purism/librem-13

Purism gets a bit of criticism from some people because their marketing department claims that their BIOS is “almost free”, but they’re using a modern Intel system, which has many blobs and out-of-band activities. Other documentation from Purism clarifies that the “BIOS is not yet free”. Use of FSP is not a 100% requirement for modern Intel systems, it isn’t clear what the mainstream BIOS vendors are using it or alternate code. One recent BIOS vendor, I forget their name, they’re based in Sweden, released a BIOS solution for the Intel Minnowboard, which was not based on FSP. I presume, but am not sure, that anyone who does a FSP alternative codebase would still need some NDA for some specifications from Intel.

The Purism web site says:

While the BIOS is not yet free, the Librem will be the first laptop ever manufactured to ship a modern Intel CPU fused to run unsigned BIOS code, allowing for a future where free software can replace the proprietary, digitally signed BIOS binaries. This marks one of the largest hurdles to a BIOS that runs 100% free software and firmware. Recognizing the importance of this critical step toward consumer freedom, Dr. Richard M. Stallman, president of the Free Software Foundation (FSF), states:

    “Getting rid of the signature checking is an important step. While it doesn’t give us free code for the firmware, it means that users will really have control of the firmware once we get free code for it.” – Dr. Richard M. Stallman

There are also hardware components, like the HD or SSD, that are flashable, and therefore upgradeable, but that currently run firmware that is not yet freed. We are working to get freed versions of this firmware! Being the first manufacturer to care about privacy, security, and freedom, we are pushing this message upstream.

Bluntly, I’m not I understand or agree with RMS’s above statements, unclear of the context. Offhand, it seems to me that RMS isn’t considering security at all, only personal freedoms. I want both, and I don’t see why I need to chose just one. I want code to be checked, but I want to be able to control what is run. I get a little worried about some privacy enthusiasts, they sometimes only focus on technology choices that give them personal freedom, and completely ignore the use case of an attacker, who doesn’t care if the binaries were backed by open source or not.

[I want a box with a kill switch, like Purism has. And two-factor authentication required to boot firmware, locally or remotely. And a Developer Mode, like Google ChromeBook Pixel has, to override BIOS and let me do what I want. I want a metal enclosure that covers all ports (Thunderbolt, etc.) when closed, and I want a quality lock integrated into system, to deter Evil Maid from accessing ports or developer mode firmware override. I expect a good key won’t be viable, TSA checkpoints will want the ability to Evil Maid people and a good lock may slow them down.]

This quote from Joanna of Invisible Things Lab summarizes my trust of Purism exactly:

“I agree there are redflags in the @Puri_sm marketing lang. There are also positives, such as @ioerror being on board.”

Purism has a tough job trying to remove blobs from firmware, make system flexible enough for users to install new boot-time software, yet prevent attackers from attacking system, while removing protections that Intel has been adding to deter attackers. With some AMD systems, they may have less firmware to worry about blobs, but will have entirely new silicon attacks, and unlike Intel, ARM doesn’t provide any firmware vulnerability assessment tools. I’m unclear about AMD64 firmware and their AGESA, which is somewhat similar to Intel’s FSP; unclear about blob-removable potential by Purism. Also, AMD, like ARM systems, doesn’t have CHIPSEC or similar tools. Overly slick marketing aside, they’re the only OEM that’s trying to solve this problem — arguably the 2nd, after Bunnie, perhaps — which is nice to see.

It’ll be interesting to see what ISA they choose for their tablet and smartphone devices!

Intel announces Automotive Security Review Board and Security Best Practices

~ hucktech ~ Leave a comment

Intel just created “Automotive Security Review Board (ASRB)“. You can apply to get on the board on the below URL. Their initial best practices paper is also published at below URL. Free car to best security research!

To help mitigate cyber-security risks associated with connected cars while also encouraging technological progression and innovation, Intel today announced the creation of the Automotive Security Review Board (ASRB) made of automotive security experts. ASRB researchers will conduct cyber-security research for Intel’s automotive platform. The member with the most impactful contribution will be awarded a new car. The Automotive Security Review Board will bring together top security industry talent from around the world who have expertise in particular areas of cyber-physical systems. ASRB researchers will perform ongoing security tests and audits intended to codify best practices and design recommendations for advanced cyber-security solutions and products to benefit the automobile industry and drivers. To motivate the ASRB researchers, Intel will award a new car to the member who provides the most significant and impactful cybersecurity contribution that can be implemented on Intel’s automotive platform. All details related to the Intel development platform and areas of security audit focus will be provided at the inaugural ASRB meet-up next month.

The new Intel white paper “Automotive Security Best Practices: Recommendations for Security and Privacy in the Era of the Next-Generation Car,” analyzes risks associated with the next generation of connected automobiles and provides specific security recommendations for the automotive industry. Intel is inviting industry experts to comment on the white paper and will publish revisions based upon feedback and ASRB findings.

https://www-ssl.intel.com/content/www/us/en/automotive/automotive-security-review-board.html
http://newsroom.intel.com/community/intel_newsroom/blog/2015/09/14/chip-shot-intel-looks-to-secure-connected-cars
http://newsroom.intel.com/community/intel_newsroom/blog/2015/09/13/intel-commits-to-mitigating-automotive-cybersecurity-risks
http://www.mcafee.com/autosecuritywp
http://www.intel.com/automotive/asrb

RehabMan’s ACPI tools for OSX

~ hucktech ~ Leave a comment

I just noticed the project Laptop-DSDT-Patch, by RehabMan. It contains “Common DSDT patches for Ivy/Sandy/Haswell laptops for running OS X“, so it’s for ‘hackintosh’ hackers using non-Apple hardware to run Apple’s OS, OS X, and have to deal with non-Apple hardware/firmware, particularly ACPI’s DSDT table, a nice example of how the modding community generates some interesting firmware tools, if nothing else.

Quoting from from the beginning of RehabMan’s HP-ProBook-4x30s wiki on How to patch your DSDT (useful background even if you don’t this HP model):

Although there are pre-patched DSDTs available as downloads from the tonymacx86.com forums and in installer packages such as the HP ProBook Installer, there can be differences in individual DSDTs that can cause delays in booting and perhaps other problems. Perhaps there are slight differences in BIOS settings, memory installed, etc, that is causing these differences. It is best, therefore, to patch your own DSDT and install it into /Extra/dsdt.aml (Chameleon) or EFI/Clover/ACPI/patched (Clover). I have included five different methods for extracting your native DSDT. Just pick the method that seems easiest for you. The easiest one will depend on whether you still have Windows installed, whether you already have a Linux USB stick prepared, and just how familiar you are with both systems.

Quoting from the OSx86 wiki, for the Mac OSX-perspective on it, ACPI’s DSDT is:

The Differentiated System Description Table is the main table in the ACPI part of a computer’s BIOS. The Advanced Configuration and Power Interface (ACPI) defines a large number of tables that provide the interface between an ACPI-compliant operating system and system firmware. These allow description of system hardware in a platform-independent manner in ACPI Machine Language (AML). The problem is that OS X has an incomplete ACPI implementation which supports only a subset of DSDT. Modifying the DSDT allows the user to better support their hardware. For example, fixing Time Machine and the UUID 35 error is possible after modifying the DSDT. To patch your DSDT, you must either use a new table file that someone else has provided, or extract and modify your own. Then tell your bootloader to use the new DSDT file instead of the BIOS. On a few motherboards it is also possible to replace the BIOS with an updated BIOS with a patched DSDT. One of the simplest ways to extract your DSDT from your BIOS is by using DSDT Editor. Once you have downloaded DSDT Editor, open it and press File –> Extract DSDT. After 2-15 seconds, your DSDT should appear on the screen.

Look at the various ACPI-centric projects RepoMan has, there’re many! Also, the Ubuntu wiki and SmackerelOfOpinion blog are both excellent for ACPI diagnostic tips.

These ‘modding community’-based ACPI changes for OS X are educational, to see how people can extend their purchases for use cases beyond those that the vendor could imagine. As systems get more tamper-proof, it seems likely that users will have less and less ability to change things. [There also exists a HUGE modding community by photographers and their smartcameras (embedded devices). They add amazing new features. The other day I saw one talk about how they update the system to be able to take pictures of lighting better. Nice example of how owners can add features to their purchases, if able to update their firmware. 🙂 And of course there is custom ‘firmware’ for smartphones, entire distros.]

Personal modding hobbies aside, how much time, if any, do enterprise sysadmins currently spend fixing OEM ACPI tables and other firmware features, to make their systems work properly?

More Info:
https://github.com/RehabMan/Laptop-DSDT-Patch
https://github.com/RehabMan/HP-ProBook-4x30s-DSDT-Patch/wiki/How-to-patch-your-DSDT
https://bitbucket.org/RehabMan/os-x-maciasl-patchmatic
http://www.insanelymac.com/forum/topic/223205-dsdt-editor-and-patcher/
https://github.com/RehabMan?tab=repositories
http://uefi.org/acpi
http://smackerelofopinion.blogspot.com/2009/10/dumping-acpi-tables-using-acpidump-and.html
http://acpi.sourceforge.net/dsdt/
https://01.org/linux-acpi/documentation/overriding-dsdt
http://www.tldp.org/HOWTO/ACPI-HOWTO/dsdt.html
http://wiki.osdev.org/DSDT
http://wiki.osx86project.org/wiki/index.php/DSDT
https://msdn.microsoft.com/en-us/library/windows/hardware/dn495660%28v=vs.85%29.aspx#dsdt
https://wiki.debian.org/OverridingDSDT
http://www.insanelymac.com/forum/topic/278170-dsdt-%E2%80%94-what-is-it-and-how-do-i-get-it/
https://wiki.ubuntu.com/Kernel/Reference/ACPITricksAndTips
https://www.kernel.org/doc/Documentation/acpi/dsdt-override.txt
http://smackerelofopinion.blogspot.com/search/label/ACPI
http://clover-wiki.zetam.org/Configuration/ACPI#DSDT

Intel 01.org Thunderbolt project

~ hucktech ~ Leave a comment

I just noticed a Thunderbolt software project on 01.org, the Intel Open Source project site:

https://01.org/thunderbolt-sw/blogs/mjamet/2015/thunberbolt-software-15.32

The last release was a few months ago. However, this is not a normal open source project. It is “restricted open source”, only only for Thunderbolt vendors, not the public.

The code can be accessed from the restricted Git Hub at: https://github.com/01org/thunderbolt-software
An access can requested at thunderbolt-linux@intel.com only for manufacturers having a valid Thunderbolt technology license.

https://01.org/thunderbolt-sw/
https://github.com/01org/thunderbolt-software
https://lists.01.org/mailman/listinfo/thunderbolt-software
https://thunderbolttechnology.net/
https://thunderbolttechnology.net/news/press

 

VZ on Intel STM

~ hucktech ~ Leave a comment

Vincent Zimmer of Intel wrote a blog on recent Intel UEFI activities relating to open source. He talks about a few things, including “SMI Transfer Monitor (STM)”, recently announced at Intel Developer Forum. I briefly posted on STM, but barely mentioned any details, better points to information are in Vincent’s current post. I hope to see vendors using this powerful technology in the future.

https://firmware.intel.com/blog/developing-best-class-security-principles-open-source-firmware

 

Intel XED

~ hucktech ~ Leave a comment

Intel has a library to help encode/decode instructions, called the Intel(R) XED (X86 Encoder Decoder). I’ve yet to determine if it its PE image support also includes supports UEFI’s TE image format.

Intel XED is a software library (and associated headers) for encoding and decoding X86 (IA32 and Intel64) instructions. It is widely used inside and outside of Intel. The decoder takes sequences of 1-15 bytes along with machine mode information and produces a data structure describing the opcode and operands, and flags. The encoder takes a similar data structure and produces a sequence of 1 to 15 bytes. Disassembly is essentially printing pass on the data structure produced by the decoder. The examples also include binary image readers for Windows PECOFF, ELF, and Mac OSX MACHO binary file formats (32b and 64b). These allow Intel XED to be used as a simple disassembler. The Intel XED disassembler supports 3 output formats: Intel (dest on left), ATT SYSV (dest on right), and a more detailed internal format describing all resources read and written. Intel XED compiles with all major compilers and O/Ses and was designed for portability. If required, Intel XED can be built without the encoder or without the decoder to reduce the code/data footprint.  The code in the Intel XED library is written in C and is partially generated from tables using python scripts at build time. Intel XED is designed for embedding and has a minimal set of simple external dependencies. It makes no system calls and allocates no memory. It is multithread-safe after one-time initialization of the tables. Both the 32b and 64b versions of the library can decode or encode 32b and 64b instructions.  The machine mode for decoding the instructions is specified in a data structure that is input to the encoding and decoding APIs.

https://software.intel.com/en-us/articles/xed-x86-encoder-decoder-software-library
https://software.intel.com/en-us/articles/pin-a-dynamic-binary-instrumentation-tool
https://software.intel.com/sites/landingpage/xed/ref-manual/html/index.html

Purism BIOS efforts

~ hucktech ~ Leave a comment

Purism mentioned in a Tweet that they have 3 developers working on Intel Management Engine:

They have one document, from the summer, talking about how they’re trying to free the BIOS:

https://puri.sm/posts/freeing-the-bios-the-memory-init-stage/

And another more recently-updated status page:

https://puri.sm/road-to-fsf-ryf-endorsement-and-beyond/

Purism offers the first high-end privacy and freedom-respecting laptops by manufacturing the motherboard and sourcing daughter cards, where all chips are designed to run free software. Purism laptops are completely free from the bootloader through the kernel (with no mystery code, binary blobs, or firmware blobs), including the operating system and all software. We have yet to free the Intel FSP binary and ME binary from within the coreboot BIOS to move us toward FSF RYF endorsement. We are working diligently to free the BIOS, but our goal is to go further than that: Purism also intends to free the firmware within HDDs and SSDs.

I’m still unclear how this will result. I’m of two minds on this: I love the idea of having a system I can trust, so am happy to see projects like Novena and Purism. On the other hand, Purism is fighting Intel’s security mechanisms, and I’m a little concerned the result will remove some Intel defensive technology that makes the system more easily attackable.

Their current model has a kill switch, which is a nice feature. [I’d also like a case that closes access to the ports when closed, and has a LOCK, with a good quality lock, that can’t be easily picked. That’d be an issue for TSA checkpoints, though.] I might also consider getting ride of Suspend/Resume, a lot of attacks happen there, and systems are fast enough these days to live without this feature.

I wish other OEMs would compete with Purism, it would be nice to have more options than a handful of ancient refurbished Thinkpads and a handful of remaining Novenas. The current Purism model is nearly done with funding, only a few days left:

 

UEFITool 0.21.0 released

~ hucktech ~ Leave a comment

Nikolaj Schlej has released  UEFITool v0.21.0.

Features improved Skylake support, among other things:
– added support for new Intel descriptor type, based on [this](http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=1f7fd720c81755144423f2d4062c39cc651adc0a) coreboot commit, thanks to lordkag for issue #32
– solved a bug with incorrect volume free space item placement during volume replace, now works as expected
– solved an issue with incorrect Aptio capsule parsing introduced in 0.20.8

https://github.com/LongSoft/UEFITool
https://firmwaresecurity.com/tag/uefitool/