Tag: Intel

Intel FSP 2.0

~ hucktech ~ 1 Comment

Jiewen Yao of Intel submitted a 19-part patch to the UEFI Forum’s EDK2 project today, adding Intel FSP 2.0 support.

(The comments for the patch are also the first time I’ve seen a pointer to the 2.0 FSP spec. Strangely, at the moment Intel.com is down for me, though the rest of the intarwebs appears to be up, so I cannot verify the FSP PDF URL…)

This series of patch is to support FSP2.0 specification at
https://firmware.intel.com/sites/default/files/FSP_EAS_v2.0_Draft%20External.pdf

Some major updates include:
1) One FSP binary is separated to multiple components:
FSP-T, FSP-M, FSP-S, and optional FSP-O.
Each component has its own configuration data region.
2) All FSP-APIs use same UPD format – FSP_UPD_HEADER.
3) Add EnumInitPhaseEndOfFirmware notifyphase.
4) FSP1.1/FSP1.0 compatibility is NOT maintained.

The new Intel platform will follow FSP2.0.
The old platform can either use an old EDK branch, or move FSP1.1 support to platform directory.

We also add rename Fsp* to FspWrapper* in IntelFspWrapperPkg, to indicate that it is for FspWrapper only.

  IntelFspPkg: Update FSP header file to follow FSP2.0 spec.
  IntelFspPkg: Update FSP private header file used by FSP2.0 implementation.
  IntelFspPkg-FspCommonLib: Update FSP common lib for FSP2.0.
  IntelFspPkg/FspPlatformLib: Update FSP platform lib for FSP2.0.
  IntelFspPkg/FspSecPlatformLib: Update FSP SecPlatform lib for FSP2.0.
  IntelFspPkg/FspSecCore: Update FSP SecCore for FSP2.0.
  IntelFspPkg/FspNotifyPhase: Separate FSP NotifyPhase from DxeIpl to new module.
  IntelFspPkg: Update DEC/DSC for FSP2.0.
  IntelFspPkg/Tool: Update FSP tool for FSP2.0.
  IntelFspWrapperPkg/Ppi: Update FspInitDone to FspSiliconInitDone.
  IntelFspWrapperPkg/FspWrapperApiLib: Update FspApiLib to FspWrapperApiLib.
  IntelFspWrapperPkg/FspWrapperApiTestLib: Add ApiTestLib as hook.
  IntelFspWrapperPkg/FspWrapperHobProcessLib: Update FspHobProcessLib to FspWrapperHobProcessLib.
  IntelFspWrapperPkg/FspWrapperPlatformLib: Update FspPlatformInfoLib to FspWrapperPlatformLib.
  IntelFspWrapperPkg/FspWrapperPlatformSecLib: Align PlatformSecLib defined in UefiCpuPkg.
  IntelFspWrapperPkg/FspWrapperSecCore: Remove FspWrapperSecCore.
  IntelFspWrapperPkg/FspInit: Split FspInitPei to FspmWrapperPeim and FspsWrapperPeim.
  IntelFspWrapperPkg/FspWrapperNotifyDxe: Update FspNotifyDxe to FspWrapperNotifyDxe.
  IntelFspWrapperPkg: Update DEC/DSC for FSP2.0.

For more info, see the full patch sent to the EDK2-devel list:
https://lists.01.org/mailman/listinfo/edk2-devel

Intel to kill off Atom line (?)

~ hucktech ~ Leave a comment

Intel Atom line is apparently in danger, after recent corporate reorg.

http://www.intel.com/content/www/us/en/processors/atom/atom-processor.html
http://www.xda-developers.com/intel-cutting-significant-part-possibly-entire-atom-lineup/
http://www.pcworld.com/article/3063672/windows/the-death-of-intels-atom-casts-a-dark-shadow-over-the-rumored-surface-phone.html
http://www.pcworld.com/article/3063508/components/intel-is-on-the-verge-of-exiting-the-smartphone-and-tablet-markets-after-cutting-atom-chips.html

Workaround: if you put a liliputing.com-based URL in a WordPress post, any subsequent text after that URL will be omitted, the Liliputing URL must be the last text in the WordPress post. 😦
http://liliputing.com/2016/04/reports-intel-is-killing-off-low-power-atom-chips.html

 

Intel ATR site updates it’s research on web site

~ hucktech ~ Leave a comment

Intel Advanced Threat Research (ATR) is home of the CHIPSEC team. They just updated their web site with more presentation archives.

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

new CHIPSEC changes

~ hucktech ~ Leave a comment

As I understand things, Intel has a private source tree for CHIPSEC, and makes snapshots of [a subset of] this private tree to their public github.com-hosted source tree. As a result, CHIPSEC usually doesn’t release incrementally, updates usually come in big batches. So it is a surprise to see some recent incremental changes to the CHIPSEC public code tree. Here are some commits between mid-March and today:

Merge pull request #26 from tweksteen/cmos_test_reviewed
Merge pull request #25 from tweksteen/spi_test_reviewed
Merge pull request #27 from tweksteen/x1_carbon_test_reviewed
Merge pull request #23 from tweksteen/fix_i386_linux_driver
Remove unused setUp and tearDown
Add hardware test for X1 Carbon
Add test for CMOS dump
Add test for SPI info
Merge pull request #24 from tweksteen/raise_oshelper
Merge pull request #22 from tweksteen/sort_acpi_tables
Change sys.exit to re-raise
Sort ACPI tables by name
Fix Linux driver build on i386
Merged changes from #17 pull request
removed win specific cleanup script
Merge pull request #21 from chipsec/dev
Merge pull request #11 from tweksteen/setup
Merge pull request #14 from tweksteen/uefi_clean_up
Fix ACPI RSDP resolution based on EBDA
Add tests for ACPI RSDP, RSDT and XSDT.
Add basic tests
Fix Linux helper close
Do not force kernel module loading on Linux
Use metaclass to autoload helpers

https://github.com/chipsec/chipsec
https://github.com/chipsec/chipsec/commits/master

LibIPT – Intel Processor Trace Decoder Library

~ hucktech ~ Leave a comment

libipt – an Intel(R) Processor Trace decoder library

The Intel Processor Trace (Intel PT) Decoder Library is Intel’s reference implementation for decoding Intel PT.  It can be used as a standalone library or it can be partially or fully integrated into your tool. The library comes with a set of sample tools built on top of it and a test system built on top of the sample tools.  The samples demonstrate how to use the library and may serve as a starting point for integrating the library into your tool.

Processor Trace を使ってデバッグ時に詳細なトレースを取得する


https://github.com/01org/processor-trace
https://software.intel.com/en-us/intel-platform-analysis-library

Intel releases firmware source code to Arduino 101

~ hucktech ~ Leave a comment

Zoe Romano posted a new blog entry on Arduino.cc site, about Intel releasing the source code to the Arduino 101 firmware.

[…] We’re very happy to announce that the source code of the real-time operating system (RTOS) powering the Arduino 101 and Genuino 101 is now available for hacking and study purposes. The package contains the complete BSP (Board Support Package) for the Curie processor on the 101. It allows you to compile and modify the core OS and the firmware to manage updates and the bootloader. (Be careful with this one since flashing the wrong bootloader could brick your board and require a JTAG programmer to unbrick it). The firmware runs on the x86 chip inside the Curie module and communicates with the ARC core (which runs your Arduino sketches) using these callbacks. Right now, the x86 core takes care of handling Bluetooth Low Energy (BLE) and USB communication, offloading the ARC core. You can use the code which implements these functionalities as a starting point for your custom extra features. […]

Intel releases the Arduino 101 firmware source code


https://downloadcenter.intel.com/download/25832
https://github.com/01org/corelibs-arduino101
http://forum.arduino.cc/index.php?board=103.0

Intel to release SGX for Linux

~ hucktech ~ Leave a comment

Dan Zimmerman of Intel posted a status update regarding Linux availability of an SDK for Intel SGX:

Excerpting the blog:

The Intel intends to:
* Open-Source the Intel® SGX SDK for Linux* and associated Platform Software in June 2016.
* There will be a few user-space components where binaries will be provided instead of source

It sounds like this will be a freeware release that includes partial source, not a proper open source project. At least, I am not sure how it can be called “Open Source” if it includes a few binaries instead of source…

Going a bit off SGX-topic, in his blog post, Dan mentions:

“Whenever I talk with developers about Intel® SGX, one of the first questions asked is ‘When will Linux support be available’?”

I am glax Intel SGX team is paying attention to Linux. There are many other Intel teams that only pay attention to Windows. 😦

Full blog:

https://software.intel.com/en-us/blogs/2016/04/11/intel-software-guard-extensions-sdk-for-linux-availability-update

UEFI Customized Secure Boot: EDK2 branch

~ hucktech ~ Leave a comment

Chao B Zhang of Intel has created a branch of the Tianocore EDK-II for Customized Secure Boot, presumably a new flavor mentioned in the UEFI Forum’s private issue tracking system (or it is public, not sure yet what branch will contain). It sounds like some new post-2.6, pre-2.7 feature that Microsoft is requesting. I wonder how this will impact non-Windows OSes…

Excerpted readme:

[Staging/Customized-Secure-Boot]: Create branch for Customized Secure Boot

Create a remote branch Staging/Customized-Secure-Boot for EC1263 feature. This staging branch is requested by Jeremiah Cox of Microsoft for ECR 1263 Customized Secure Boot feature. This ECR has some conflicting language/figures that may result in in consistent implementations. Customized Secure Boto feature provides capabilities for automated platform deployment by enterprises, OEMs, system integrators, and enthusiasts into custom, higher security Secure Boot configurations.  This can mitigate chain of custody concerns in the supply chain of a given hardware platform. It further provides the ability to manage multiple UEFI certificate signers and image revocations from multiple signers.  It also provides a viable solution to enterprise, enthusiast, and OS vendor signing of images while maintaining overall security of the pre-boot environment.  Finally, it provides for a consistent programmatic and secure re-deployment of already-deployed systems.

More info:
https://github.com/tianocore/edk2-staging/tree/Customized-Secure-Boot
https://mantis.uefi.org/mantis/view.php?id=1263 (UEFI Forum members only, not for public)
https://lists.01.org/mailman/listinfo/edk2-devel

new Intel patch adding TCG OPAL unlock to Linux NVMe

~ hucktech ~ Leave a comment

Rafael Antognolli of Intel posted a patch to the Linux-(NVMe,Block,Kernel) mailing lists, adding TCG OPAL unlock support to NVMe:

Add Opal unlock support to NVMe. This patch series implement a small set of the Opal protocol for self encrypting devices. It’s implemented only what is needed for saving a password and unlocking a given “locking range”. The password is saved on the driver and replayed back to the device on resume from suspend to RAM. It is specifically supporting the single user mode. It is not planned to implement the full Opal protocol (at least not for now).

Add optane OPAL unlocking code. This code is used to unlock a device during resume from “suspend to RAM”. It allows the userspace to set a key for a locking range. This key is stored in the module memory, and will be replayed later (using the OPAL protocol, through the NVMe driver) to unlock the locking range. The nvme_opal_unlock() will search through the list of saved devices + locking_range + namespaces + keys and check if it is a match for this namespace. For every match, it adds an “unlocking job” to a list, and after this, these jobs are “consumed” by running the respective OPAL “unlock range” commands (from the OPAL spec):
  * STARTSESSION
  * SET(locking range, readwrite)
  * ENDSESSION

NVMe: Add ioctls to save and unlock an Opal locking range. Two ioctls are added to the NVMe namespace: NVME_IOCTL_SAVE_OPAL_KEY and NVME_IOCTL_UNLOCK_OPAL. These ioctls map directly to the respective nvme_opal_register() and nvme_opal_unlock() functions. Additionally, nvme_opal_unlock() is called upon nvme_revalidate_disk, so it will try to unlock a locking range (if a password for it is saved) during PM resume.

For more information, see the post on the list archives:
http://lists.infradead.org/mailman/listinfo/linux-nvme

CHIPSEC training at REcon

~ hucktech ~ Leave a comment

The Intel CHIPSEC team doesn’t give training often, so when they do, it is worth mentioning.

Like last year, CHIPSEC will be offering training at REcon!

A variety of attacks targeting system firmware have been discussed publicly, drawing attention to the pre-boot and firmware components of the platform such as BIOS and SMM, OS loaders and secure booting. This training will detail and organize objectives, attack vectors, vulnerabilities and exploits against various types of system firmware such as legacy BIOS, SMI handlers and UEFI based firmware, mitigations as well as tools and methods available to analyze security of such firmware components. It will also detail protections available in hardware and in firmware such as Secure Boot implemented by modern operating systems against bootkits. The training includes theoretical material describing a structured approach to system firmware security analysis and mitigations as well as many hands-on exercises to test system firmware for vulnerabilities. After the training you should have basic understanding of platform hardware components and various types of system firmware, security objectives and attacks against system firmware, mitigations available in hardware and firmware. You should be able to apply this knowledge in practice to identify vulnerabilities in BIOS and perform forensic analysis of the firmware.

https://recon.cx/2016/training/trainingfirmware.html

Motherboard interview on Intel UEFI and IoT security

~ hucktech ~ Leave a comment

Motherboard has an interview with Brian Richardson of the Intel UEFI team, on the topic of IoT security. Wide range of topics covered!

http://motherboard.vice.com/en_uk/blog/protecting-firmware-is-crucial-for-iot-technology

 

Intel Tamper Protection Toolkit

~ hucktech ~ Leave a comment

Intel has posted a blog post on their Intel Tamper Protection toolkit:

Intel® Tamper Protection Toolkit Helps Protect the Scrypt Encryption Utility against Reverse Engineering

Roman Kazantsev, Denis K., Thaddeus Letnes

This article describes how the Intel® Tamper Protection Toolkit can help protect critical code and valuable data in a password-based encryption utility (Scrypt Encryption Utility) [3] against static and dynamic reverse-engineering and tampering. Scrypt [4] is a modern secure password-based key derivation function that is widely used in security-conscious software. There is a potential threat to scrypt described in [2] when an attacker can force generation of weak keys by forcing use of specific parameters. Intel® Tamper Protection Toolkit can be used to help mitigate this threat. We explain how to refactor relevant code and apply tamper protection to the utility.

https://software.intel.com/en-us/articles/intel-tamper-protection-toolkit-helps-protect-the-scrypt-encryption-utility-against-reverse
https://software.intel.com/en-us/tamper-protection

Intel Ethernet diagnostics driver for Windows vulnerable

~ hucktech ~ Leave a comment

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00051&languageid=en-fr

Potential vulnerability in the Intel® Ethernet diagnostics driver for Windows®
Intel ID:      INTEL-SA-00051
Product family:      Intel® Ethernet diagnostics driver for Windows®
Impact of vulnerability:      Denial of Service
Severity rating:      Important
Original release:      Apr 11, 2016
CVE Name:  CVE-2015-2291

A vulnerability was identified in the Intel diagnostics driver IQVW32.sys and IQVW64.sys, also identified as CVE-2015-2291. Intel released an update to mitigate this issue in June 2015. Intel highly recommends that customers of the affected products obtain and apply the updated versions of the driver.

https://downloadcenter.intel.com/download/22283/Intel-Ethernet-Adapters-Connections-CD
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00051&languageid=en-fr

ByoSoft supports Intel Firmware Engine

~ hucktech ~ Leave a comment

https://twitter.com/FirmwareEngine/status/720168913229590528

Intel Developer Forum (IDF) takes place in San Francisco and also in China, and the one in ShenZhen is in the news now. Nanjing Byosoft Co., Ltd — aka Byosoft, a UEFI firmware vendor, announced that their ByoCore(TM) BIOS will fully support Intel Firmware Engine:

“Byosoft is the first vendor announce to fully support Intel® Firmware Engine among the independent firmware vendors in the industry, and the Intel® Firmware Engine technology will offer a low-cost, high-flexibility, easy-to-use service solution to Byosoft’s customers in Internet of Thing (IoT) and embedded market.”
 
“Byosoft believe Intel® Firmware Engine can greatly help customer to use ByoCoreTM BIOS and finish the customization, especially for those who don’t purchase source code of the ByoCoreTM. Intel® Firmware Engine offers flexible method of firmware customization based on binary, and without involving Byosoft engineer direct support, the customer can finish the firmware modification by themselves to create the required image.”

“Byosoft has co-worked with Intel and upgraded the ByoCoreTM BIOS codebase to support Intel® Firmware Engine. ByoCoreTM customer can fast customize ByoCoreTM firmware through Intel® Firmware Engine, configuring, adding or removing the existed firmware packages, and integrate user-defined payload. With Intel® Firmware Engine, ByoCoreTM customer can build customized firmware faster and easier.”

Full announcement:
http://www.byosoft.com.cn/xwzxx/98.htm

This is great news for the Windows UEFI ecosystem. Again, I wish Intel would release a Linux version of the Windows-only Firmware Engine. 😦

Brian Richardson on UEFI community changes

~ hucktech ~ Leave a comment

Brian Richardson of Intel’s UEFI team posted a new blog with information about recent changes in the Tianocore development ecosystem. Brian summarizes recent activity, including Tony Mangefeste’s new community roadmap, the recent UEFI plugfest in Taipei, and other changes:

http://blogs.intel.com/evangelists/2016/04/11/tianocore-community-uefi/

LUV 2.0 released!

~ hucktech ~ Leave a comment

The Intel LUV team, at least including: Gayatri Kammela (12), Megha Dey (12), Naresh Bhat (1), and Ricardo Neri (46) have released 2.0 of LUV, the Linux UEFI Validation Project.

These are the highlights of the release:

*Different types of image available (i386 and x86_x64)
*Logging and debugging via network (or serial)
*Tests for persistent memory (NVDIMM)
*Support for i386
*Booting LUV via network (PXE, HTTP boot later)
*Miscellaneous updates (BITS perf improvements, Linux 4.4 kernel, …)
*Dropped support for fido (focus is on Jethro)
*Known issues and limitations (Debugging works only over Ethernet, not WiFi, …)

Read the full announcement, there are pages of details not included here.

One new feature is i386 support. LUV 1.x was x64-centric, now we hopefully also use LUV 2.0 for testing x86 systems! But signed shim is still only available for 64-bit, so Secure Boot is not enabled for 32-bit support [yet?]. Quoting the release notes:  “At the last minute we faced a kernel issue when booting on a i386-based system. We are debugging. Once this is cleared, a bootable image will be uploaded (issue #76 on [3])”

Full announcement:
https://lists.01.org/pipermail/luv/2016-April/001035.html
https://download.01.org/linux-uefi-validation/v2.0
https://download.01.org/linux-uefi-validation/v2.0/sha256_sums.asc
[1]. https://github.com/01org/luv-yocto/tree/master/meta-luv
[2]. https://github.com/pmem/ndctl
[3]. https://github.com/01org/luv-yocto

Intel patch to Linux kernel for ACPI overlays

~ hucktech ~ Leave a comment

Octavian Purdila of Intel has posted a 10-part patch to the Linux-(ACPI,EFI,I2C,SPI,Kernel) lists, adding “ACPI Overlays” to the Linux kernel:

This patch set enables custom ACPI board configuration by adding mechanisms in the Linux kernel for loading user defined SSDTs. In order to support ACPI open-ended hardware configurations we need a way to augment the ACPI configuration provided by the firmware image. A common example is connecting sensors on I2C / SPI buses on development boards. Although this can be accomplished by creating a kernel platform driver or recompiling the firmware image with updated ACPI tables, neither is practical: the former proliferates board specific kernel code while the latter requires access to firmware tools which are often not publicly available. Because ACPI supports external references in AML code a more practical way to augment firmware ACPI configuration is by dynamically loading user defined SSDT tables that contain the board specific information.

This patch sets provides three methods for loading custom SSDTs:
1) From an EFI variable: This is the preferred method, when EFI is supported on the platform, because it allows a persistent, OS independent way of storing and updating the user defined SSDTs. There is also work underway to implement EFI support for loading user defined SSDTs and using this method will make it easier to convert to the EFI loading mechanism when that will arrive.
2) From the first uncompressed initrd (similar with the override functionality): This is useful when EFI is not supported on the platform and when it is not possible to defer the loading to userspace.
3) From userspace via configfs: This is useful when we want to defer the operation to userspace for platform detection, loading the SSDTs from a custom partition, etc.

Octavian Purdila (10):
  kernel: add TAINT_OVERLAY_ACPI_TABLE
  acpi: install SSDT tables from initrd
  acpi: add support for ACPI reconfiguration notifiers
  acpi: fix enumeration (visited) flags for bus rescans
  i2c: add support for ACPI reconfigure notifications
  spi: add support for ACPI reconfigure notifications
  efi: load SSTDs from EFI variables
  configfs: fix CONFIGFS_BIN_ATTR_[RW]O definitions
  acpi: add support for configfs
  acpi: add support for loading SSDTs via configfs

 Documentation/ABI/testing/configfs-acpi |  23 +++++
 Documentation/acpi/ssdt-overlays.txt    | 174 ++++++++++++++++++++++++++++++++
 Documentation/kernel-parameters.txt     |   7 ++
 Documentation/oops-tracing.txt          |   2 +
 Documentation/sysctl/kernel.txt         |   1 +
 MAINTAINERS                             |   1 +
 drivers/acpi/Kconfig                    |   9 ++
 drivers/acpi/Makefile                   |   1 +
 drivers/acpi/bus.c                      |  72 +++++++++++++
 drivers/acpi/configfs.c                 | 143 ++++++++++++++++++++++++++
 drivers/acpi/internal.h                 |   3 +
 drivers/acpi/scan.c                     |  73 +++++++++++++-
 drivers/acpi/sysfs.c                    |   6 +-
 drivers/firmware/efi/efi.c              | 107 ++++++++++++++++++++
 drivers/i2c/i2c-core.c                  |  38 ++++++-
 drivers/spi/spi.c                       |  36 ++++++-
 include/acpi/acpi_bus.h                 |   8 ++
 include/linux/configfs.h                |   4 +-
 include/linux/kernel.h                  |   1 +
 kernel/panic.c                          |   2 +
 20 files changed, 699 insertions(+), 12 deletions(-)
 create mode 100644 Documentation/ABI/testing/configfs-acpi
 create mode 100644 Documentation/acpi/ssdt-overlays.txt
 create mode 100644 drivers/acpi/configfs.c

For more information, see the full patch on the above-listed mailing lists.