Tag: Intel

Intel Skylake bug

~ hucktech ~ Leave a comment

Don’t do any “complex workloads” on your Skylake boxes until you get a BIOS update…

https://communities.intel.com/mobile/mobile-access.jspa#jive-content?content=%2Fapi%2Fcore%2Fv3%2Fcontents%2F524553

BIOS updates on the way to fix problem says Intel

Four days ago Intel reported that its engineering department had identified the issue which “only occurs under certain complex workload conditions… [when] the processor may hang or cause unpredictable system behaviour”. It has released a fix for the issue to hardware partners which will be distributed via BIOS updates for Skylake compatible motherboards. Now users will just have to wait for their motherboard vendors to publish BIOS updates with the Intel fix incorporated.

Full story:

http://hexus.net/tech/news/cpu/89636-intel-skylake-bug-seizes-pcs-running-complex-workloads/

You might want to check here for updates from Intel-based devices:

https://security-center.intel.com/SearchResults.aspx

Code available for new rowhammer research

~ hucktech ~ Leave a comment

More on this recent research:

Skylake and Rowhammer

https://github.com/IAIK/rowhammerjs/tree/master/native

The source is a single C++ file (not Javascript, like the Github project name hints at), built targets for Sandy/Ivy/Haswell/Skylake, works on 64-bit Linux. Usage:

# ./rowhammer[-architecture] [-t nsecs] [-p percent] [-c cores] [-d dimms] [-r row] [-f first_offset] [-s second_offset]
    ”-c” the number of cores (only important with ”#define EVICTION_BASED”)
    ”-p” percent of memory to use
    ”-d” number of dimms (very important)
    ”-r” loop only over the specified row
    ”-f” only test addresses with the specified first aggressor offset
    ”-s” only test addresses with the specified second aggressor offset

 

 

Intel on Intel SGX enclaves

~ hucktech ~ Leave a comment

https://twitter.com/intelswfeed/status/685961977324265472

 

Intel SGX: Debug, Production, Pre-release what’s the difference?

Simon Johnson, Dan Zimmerman, and Derek B., all of Intel, presumably on the Intel SGX team, posted a new article on the Intel blog, on Intel SGX.

Since release the SDK we’ve had a few questions about debug vs pre-release vs release mode (production) enclaves. Part of the security model of Software Guard Extensions is to prevent software from peaking inside and getting at secrets inside the enclave… but no-one writes perfect code the first time round; so how do you debug an enclave?
[…]

Full post:

https://software.intel.com/en-us/blogs/2016/01/07/intel-sgx-debug-production-prelease-whats-the-difference

 

Intel Memory Encryption Engine (MEE)

~ hucktech ~ Leave a comment

https://drive.google.com/file/d/0Bzm_4XrWnl5zOXdTcUlEMmdZem8/edit?pref=2&pli=1

Real World Cryptography Conference 2016
6-8 January 2016, Stanford, CA, USA
Intel® Software Guard Extensions (Intel® SGX)
Memory Encryption Engine (MEE)
Shay Gueron
Intel Corp., Intel Development Center, Haifa, Israel
University of Haifa, Israel

Skylake and Rowhammer

~ hucktech ~ Leave a comment

 

Reverse Engineering Intel DRAM Addressing and Exploitation
Peter Pessl, Daniel Gruss, Clémentine Maurice, Michael Schwarz, Stefan Mangard

In this paper, we present a method to reverse engineer DRAM addressing functions based on a physical bus probing. Second, we present an automatic and generic method to reverse engineer DRAM addressing functions merely from performing a timing attack. This timing attack can be performed on any system without privileges and even in virtual machines to derive information about the mapping to physical DRAM channels, ranks and banks. We reversed the complex adressing functions on a diverse set of Intel processors and DRAM configurations. Our work enables side-channel attacks and covert channels based on inner-bank row conflicts and overlaps. Thus, our attack does not exploit the CPU as a shared resource, but only the DRAM that might even be shared across multiple CPUs. We demonstrate the power of such attacks by implementing a high speed covert channel that achieves transmission rates of up to 1.5Mb/s, which is three orders of magnitude faster than current covert channels on main memory. Finally, we show how our results can be used to increase the efficiency of the Rowhammer attack significantly by reducing the search space by a factor of up to 16384.

http://arxiv.org/abs/1511.08756

Intel Curie

~ hucktech ~ Leave a comment

Intel announced Curie back in the Summer:

Arduino 101, an Intel Curie-based device

And they’re doing it again at CES:

https://software.intel.com/en-us/articles/intels-newest-wearable-module-intel-curie
http://www.intel.com/content/www/us/en/wearables/wearable-soc.html

Click to access Intel_CURIE_Module_Factsheet.pdf

Click to access intel-curie-module-fact-sheet.pdf

I still can’t tell you that flavor of firmware it uses, UEFI, BIOS, or something else. If you know, please leave a Comment (see left).

EDK II specifications updated

~ hucktech ~ Leave a comment

Laurie Jarlstrom of Intel has announced a documentation update to the UEFI Forum’s EDK II Specifications:

“Announcing the V1.25 and V1.26 updates to the EDK II Specifications. Go to the EDK II Specifications page to download the latest documentation.”

These are the specs beyond the UEFI Forum’s PI and UEFI specs, focused on development implementation details of Tianocore’s EDK-II.

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Specifications
http://article.gmane.org/gmane.comp.bios.edk2.devel/6371

BITS: new network-enabled release (and new mailing list)

~ hucktech ~ Leave a comment

Burt Triplett of Intel has announced the version 2070 release of BITS (BIOS Implementation Test Suite). The main new feature is network support, but also includes new UEFI and ACPI and Python features, better command line features, and other new features. I’ve just excerpted the first paragraph of the networking-centric portion of the announcement below, there are a lot of implementation caveats to read. See the full announcement for the list of features and bugfixes.

Note that there is also a new BITS mailing list, see below URL for ‘first post’ message in the archives:

BITS on EFI now supports TCP networking, using the Python socket module and various modules built atop it.  On EFI systems that provide `EFI_IP4_CONFIG_PROTOCOL` and `EFI_TCP4_SERVICE_BINDING_PROTOCOL`, we implement a `_socket` module in Python with support for TCP sockets over IPv4.  We then include Python’s higher-level socket module that runs on top of `_socket`.

https://lists.01.org/mailman/listinfo/bits
https://lists.01.org/pipermail/bits/2016-January/000000.html
http://biosbits.org/news/bits-2070/
http://biosbits.org/downloads/bits-2070.zip
https://github.com/biosbits/bits

Intel 01.org mailing lists

~ hucktech ~ Leave a comment

It is sometimes funny to watch a company do open source. Intel’s 01.org, for Open Source projects, has a mailing list server with multiple lists:
https://lists.01.org/

There are lists for LUV and CHIPSEC. These work fine!
https://lists.01.org/mailman/listinfo/chipsec
https://lists.01.org/mailman/listinfo/luv

There is a list for Thunderbolt Software. …but it is a closed list, with no public archives. 😦
https://lists.01.org/mailman/listinfo/thunderbolt-software

The text that it is a closed list:
“This is a hidden list, which means that the list of members is available only to the list administrator.”

There’s a list for Intel Kernel Guard Technology (KGT). It also is a closed list, with the same text as the Thunderbolt list. BUT, their archives are publicly-available.
https://lists.01.org/mailman/listinfo/intel-kgt
https://lists.01.org/pipermail/intel-kgt/

There’s a list for BIOS Implementation Test Suite (BITS)!
But there are no archives, perhaps a closed list, or just broken archives?
https://lists.01.org/mailman/listinfo/bits

I rather wish Intel used intel.com or 01.com for closed lists, and kept the Open Source-centric 01.0rg’s list all public, with working archives. 😦

ITL’s Stateless Laptop proposal

~ hucktech ~ Leave a comment

Joanna Rutkowska of Invisible Things Lab (ITL) has proposed the Stateless Laptop, and will be presenting at CCC in a few days (2015/12/27) on the topic.

http://blog.invisiblethings.org/2015/12/23/state_harmful.html
https://events.ccc.de/congress/2015/Fahrplan/events/7352.html

Click to access state_harmful.pdf

https://github.com/rootkovska/state_harmful/blob/master/state_harmful.md

I can’t begin to create a list of tags this article covers… This article is all about firmware security (and hardware security) for x86 systems, a MUST READ!!

Purism must consider this a holiday gift from ITL: the spec for their next Librem box. Looking forward to this box, built with fully Open Source Hardware designs/parts, hopefully from multiple OEMs next year! 🙂

LUV-live 2.0-RC4 released

~ hucktech ~ Leave a comment

Ricardo Neri of Intel announced Linux UEFI Validation (LUV) v2.0-rc4 release, with lots of changes, new versions of CHIPSEC, BITS, FWTS, and multiple UEFI improvements in LUV. IMO, one of the most important features it that LUV-live’s CHIPSEC should properly log results now! Excerpts from Ricardo’s announcement:

This release touches many areas. Here are some highlights:

Naresh Bhat implemented changes to build from Linus’ tree when building LUV for ARM. While doing this, he got rid of the leg-kernel recipe. Now the kernel is built from linux-yocto-efi-test for all architectures. Also, he took the opportunity to remove some of the LUV-specific changes we had in the meta layer (i.e., our genericarmv8 machine). It always good to restrict ourselves to the meta-luv layer, unless we plan to upstream to the Yocto Project. Now LUV for aarch64 is built using qemuarm64.

It was reported that CHIPSEC was not running correctly in LUV due to missing configuration files and Python modules. This release includes a major rework of CHIPSEC integration into LUV. It ran correctly on all the systems in which we tested. Also, we bumped to v1.2.2; the CHIPSEC latest release.

This release includes new functionality to build BITS from its source rather than just deploying its binaries. BITS is a challenging piece of software when it comes to integration into a bitbake recipe. The build process was broken into several steps. This work help for future work to customize BITS for other CPU architectures and netboot.

The UEFI specification v2.5 includes a Properties Table for the memory map. Under this feature, it is possible to split into separate memory sections the code and data regions of the PE/COFF image. Unfortunately, kernels previous to v4.3 crash if this features is enabled. We have backported a fix pushed to Linux v4.3. We will be bumping the kernel for x86 to 4.3 in our next release.

The EFI stub feature in the kernel allows to run the kernel as an EFI application. Also, it allows the kernel to parse the memory map directly from the firmware rather than taking the map from the bootloader. This is clearly advantageous in case of bugs in the bootloader.

Now that LUV support storing the results of multiple bots, it may happen that disk runs out of space. Gayatri Kammela made updates to increase the size of the results partition and issue a warning when available space runs below 2MB.

Finally, keeping up with the latest changes in the Yocto Project has paid off handsomely. This release is based on Jethro, the latest version of the Yocto Project. Rebasing to this new version as done with very little effort. In the LUV tree you can find the jethro and jethro-next branches; the bases of this release. The fido and fido-next branches are still maintained.

We have bumped the following test suite versions:

 *FTWS is now V15.12.00
 *CHIPSEC is now v1.2.2
 *BITS is 2005

Time to update your LUV-live images! It is a Release Candidate, so please help the LUV team by testing it out and pointing out any issues on the LUV mailing list. This version of CHIPSEC includes VMM tests, so time to test LUV-luv in your virtual machines, not just on bare-metal boxes.

Many people contributed to this release, including: Ricardo Neri, Naresh Bhat, Darren Bilby, Megha Dey, Gayatri Kammela, John Loucaides, Sai Praneeth Prakhya, and Thiebaud Weksteen. It was nice to see the LUV and CHIPSEC teams work together in this release!

More information:
https://lists.01.org/pipermail/luv/2015-December/000745.html
https://download.01.org/linux-uefi-validation/v2.0/luv-live-v2.0-rc4.tar.bz2
https://download.01.org/linux-uefi-validation/v2.0/sha256_sums.asc

https://01.org/linux-uefi-validation/

Console OS: be wary

~ hucktech ~ Leave a comment

Console OS is an Intel-based Android-based operating system that is funded via Kickstart. Before you fund/use it, please read this thread, starting with a message from Android-x86’s project leader:

https://lists.01.org/pipermail/android-ia/2015-December/001038.html

Hi all,
[CC this to Android-IA list since the guy continues lying on Android-IA list]

Honestly speaking, I really have no time to check what Christopher Price and his crappy Console OS did recently. But I’m getting more and more private requests to ask me to stop him from stealing the Android-x86 effort. So as the project leader of the Android-x86 project, I think I need to do something. As a background for new comers who haven’t heard the story of Console OS, here is a brief: […]

More info:
https://lists.01.org/pipermail/android-ia/2015-December/thread.html
http://www.android-x86.org/
https://01.org/android-IA
http://consoleos.com/

TPM-tools for TPM 2.0

~ hucktech ~ Leave a comment

I was just looking on Intel’s 01.org to see what’s new, or some older things I’ve not yet noticed.

I just noticed there are two projects with updated TPM 2.0 support:

TPM2-0-TSS:

TPM (Trusted Platform Module) 2.0 Software Stack (TSS). This stack consists of the following layers from top to bottom:
 * Feature API (FAPI), see specification 0.12, (published but still in progress and unimplemented)
 *  Enhanced System API (ESAPI), (specification in progress and unimplemented)
 *  System API (SAPI), see 1.0 specification, (public, 0.97 implementation complete)
 *  TPM Command Transmission Interface (TCTI), used by SAPI to communicate with next lower layer (either the TAB/RM or TPM 2.0 device driver), see SAPI specification
 *  Trusted Access Broker/Resource Manager (TAB/RM), see 0.91 specification, (public, implementation complete)

https://github.com/01org/TPM2.0-TSS

TPM2-0-tools:

This site contains the code for the TPM (Trusted Platform Module) 2.0 tools based on TPM2.0-TSS. Below is the name list of the implemented tools:
Subset 1: NV tools: tpm2_nvdefine tpm2_nvrelease tpm2_nvread tpm2_nvwrite tpm2_nvlist
Subset 2: Attestation tools: tpm2_takeownership tpm2_getpubek tpm2_getpubak tpm2_akparse tpm2_makecredential tpm2_activatecredential tpm2_listpcrs tpm2_quote
Subset 3: Key management tools: tpm2_createprimary tpm2_create tpm2_evictcontrol tpm2_load tpm2_loadexternal
Subset 4: Encryption tools: tpm2_encryptdecrypt tpm2_rsaencrypt tpm2_rsadecrypt tpm2_unseal
Subset 5: Signing tools:  tpm2_sign tpm2_verifysignature tpm2_certify
Subset 6: utilities:  tpm2_getrandom tpm2_hash tpm2_hmac tpm2_readpublic

https://github.com/01org/tpm2.0-tools

Qubes OS 3.1 rc1 released, with UEFI support

~ hucktech ~ Leave a comment

New features since 3.0:
 * Management Stack based of Salt Stack in dom0
 * Out of the box Whonix setup
 * UEFI support
 * LIVE edition (still alpha, not part of R3.1-rc1)
 * Updated GPU drivers in dom0
 * Colorful window application icons (instead of just colorful lock icon)
 * PV Grub support (documentation)
 * Out of the box USB VM setup, including handling USB mouse
 * Xen upgraded to 4.6, for better hardware support (especially Skylake platform)
 * Improve updates proxy flexibility – especially repositories served over HTTPS

https://www.qubes-os.org/news/2015/12/08/qubes-OS-3-1-rc1-has-been-released/

https://www.qubes-os.org/doc/releases/3.1/release-notes/

 

Brian on Secure Boot -vs- Nemesis

~ hucktech ~ Leave a comment

Brian Richardson of Intel wrote a new blog on the recent Nemesis malware:

(Nemesis targets BIOS-centric MBR not UEFI-centric GPT partititions.)

http://blogs.intel.com/evangelists/2015/12/08/nemesis-meet-uefi-secure-boot/

new Linux-IMA patchset closes multiple measurement/appraisal gaps

~ hucktech ~ Leave a comment

Mimi Zohar and Dmitry Kasatkin have created a new patchset for Linux IMA which:

“closes a number of measurement/appraisal gaps by defining a generic function named ima_read_and_process_file() for measuring and appraising files read by the kernel (eg. kexec image and initramfs, firmware, IMA policy). To differentiate between callers of ima_read_and_process_file() in the IMA policy, a new enumeration is defined named ima_read_hooks, which initially includes KEXEC_CHECK, INITRAMFS_CHECK, FIRMWARE_CHECK, and POLICY_CHECK.

separate ‘security.ima’ reading functionality from collect
load policy using path
update appraise flags after policy update completes
measure and appraise kexec image and initramfs
measure and appraise firmware (improvement)
measure and appraise the IMA policy itself
require signed IMA policy

 Documentation/ABI/testing/ima_policy      |  2 +-
 drivers/base/firmware_class.c             | 15 +++++–
 include/linux/ima.h                       | 12 +++++
 kernel/kexec_file.c                       | 28 +++++++—–
 security/integrity/digsig.c               |  2 +-
 security/integrity/iint.c                 | 24 +++++++—
 security/integrity/ima/ima.h              | 24 +++++—–
 security/integrity/ima/ima_api.c          | 51 +++++++++++++++——
 security/integrity/ima/ima_appraise.c     | 40 +++++++++++——
 security/integrity/ima/ima_crypto.c       | 56 ++++++++++++++++——–
 security/integrity/ima/ima_fs.c           | 45 ++++++++++++++++++-
 security/integrity/ima/ima_init.c         |  2 +-
 security/integrity/ima/ima_main.c         | 55 ++++++++++++++++++—–
 security/integrity/ima/ima_policy.c       | 73 ++++++++++++++++++++++++——-
 security/integrity/ima/ima_template.c     |  2 –
 security/integrity/ima/ima_template_lib.c |  3 +-
 security/integrity/integrity.h            | 14 +++—
 17 files changed, 329 insertions(+), 119 deletions(-)

More information:
https://lists.sourceforge.net/lists/listinfo/linux-ima-devel

Purism adopts Qubes OS

~ hucktech ~ 3 Comments

Purism has announced a partnership with Qubes OS, users will be able to order Qubes OS preinstalled on the Librem 13.

https://twitter.com/revskills/status/674209460492115968

Excerpted quotes from press release:

“We are pleased to partner with the Purism team both in offering a certified Qubes OS laptop today, and in the future improving the functionality and security of Purism laptops to ensure that users can have the best of freedom, security and privacy in one convenient package,” said Joanna Rutkowska, well-known security researcher and founder of the Qubes OS project.

“We are ecstatic about the partnership between Purism and Qubes so we can bring together our goals of privacy, security and freedom in hardware with the best approach in software security. This union represents the ideal approach to protecting users by default, without sacrificing convenience or usability,” said Todd Weaver, CEO of Purism. “Qubes OS is a natural fit with the Purism Librem laptops in both functionality and ideology.”

Full press release:
https://puri.sm/posts/purism-partners-with-qubes-security-focused-hardware-and-software-together/
https://puri.sm/
https://www.qubes-os.org/

 

I was originally wondering why not use Qubes instead of PureOS in the first place, so I’m happy with their use of Qubes for OS solution.

I’m unclear about status of PureOS, is it mothballed or is it another OS option for Librem? Given use of Qubes, what does this say about future hardware architecture choices by Purism? AFAICT, Qubes is an Intel/AMD-centric OS, will PureOS still be used on ARM-based tablets/smartphones? Will Qubes have any ARM port?

Intel’s Debug Extensions for WinDbg

~ hucktech ~ Leave a comment

Windbg is Microsoft’s Windows system debugger (both user-mode and kernel-mode), which has the ability to load third party extensions. I just noticed some Windbg extensions that Intel has created. One enables Windbg to work over JTAG, the other enables support for Intel PT:

 


The “Intel Debug Extensions for WinDbg” consists of two sets of debugger extensions:

1) Intel Debug Extensions for WinDbg for IA JTAG debugging (IA JTAG) enables the connection of WinDbg to a target over the JTAG. The server acts as a mediator and forwards the calls from WindDbg* to the IPC interface and back.

2) Intel Debug Extensions for WinDbg for Intel Processor Trace (Intel PT) is designed to help WinDbg users by extending their debugging tool set with execution tracing. The extension allows for easy setup of Intel PT by abstracting hardware configuration and then reconstructing and displaying execution flow from the collected trace data. It will integrate with other WinDbg* features like symbolization and high-level source display.  Intel PT is a new technology for low-overhead execution tracing. It facilitates debugging a program by exposing an accurate and detailed trace of the program’s activity, and its triggering and filtering capabilities help identifying and isolating the relevant program executions. Intel PT records information about software execution on each hardware thread using dedicated hardware facilities. After execution completes, a software can process the recorded trace data and reconstruct the exact program flow.
[…]
BIOS / UEFI firmware: With firmware that is Intel PT-aware, you can set up an Intel PT-specific memory allocation. In this case, the firmware allocates a dedicated memory area and reserves it in a memory map for further use. Operating systems will recognize this reserved memory range and will not use it. When firmware reserves a memory region for Intel PT, it also configures the Intel PT output MSRs accordingly and indicates that Intel PT output configuration is ready to be used. The extension will recognize this setup. No further configuration (from user’s side) is required.

I presume these extensions are only available as part of the commercial-only Intel System Studio product. If you use Windbg, you may want to try to get these extensions, they sound useful.

More information:

https://software.intel.com/en-us/iss-2016-windbg-pt-user-guide-windows
https://software.intel.com/en-us/articles/intel-system-studio-release-notes
https://software.intel.com/en-us/iss-2016-get-started-debug-extensions-windbg-windows
https://software.intel.com/en-us/intel-system-studio

Exploiting Intel DRAM

~ hucktech ~ Leave a comment

Reverse Engineering Intel DRAM Addressing and Exploitation
Peter Pessl, Daniel Gruss, Clémentine Maurice, Stefan Mangard

In this paper, we present a method to reverse engineer DRAM addressing functions based on a physical bus probing. Second, we present an automatic and generic method to reverse engineer DRAM addressing functions merely from performing a timing attack. This timing attack can be performed on any system without privileges and even in virtual machines to derive information about the mapping to physical DRAM channels, ranks and banks. We reversed the complex adressing functions on a diverse set of Intel processors and DRAM configurations. Our work enables side-channel attacks and covert channels based on inner-bank row conflicts and overlaps. Thus, our attack does not exploit the CPU as a shared resource, but only the DRAM that might even be shared across multiple CPUs. We demonstrate the power of such attacks by implementing a high speed covert channel that achieves transmission rates of up to 1.5Mb/s, which is three orders of magnitude faster than current covert channels on main memory. Finally, we show how our results can be used to increase the efficiency of the Rowhammer attack significantly by reducing the search space by a factor of up to 16384.

http://arxiv.org/abs/1511.08756