Toshiba to exit semiconductor manufacturing, except for NAND flash

[…] Toshiba has firmed up plans to unload a large portion of its semiconductor-manufacturing operations as part of sweeping reforms to improve profitability in the wake of an accounting scandal. The Japanese company plans to keep NAND flash memory operations, its biggest profit source and a field where its market share is second only to Samsung Electronics. Product lines up for sale include analog chips, LSI chips, microcontrollers and power-saving semiconductors. Applications include cars, industrial machinery, home electronics and housing construction equipment. […]

http://www.eetimes.com/document.asp?doc_id=1328763&_mc=RSS_EET_EDT

http://asia.nikkei.com/Business/Deals/Toshiba-to-whittle-down-chipmaking-ops

I wonder if there are any Toshiba chips for sale that might be useful to acquire for an Open Hardware venture?

reversing ARM1 conditionals

Conditional instructions in the ARM1 processor, reverse engineered
By carefully examining the layout of the ARM1 processor, it can be reverse engineered. This article describes the interesting circuit used for conditional instructions: this circuit is marked in red on the die photo below. Unlike most processors, the ARM executes every instruction conditionally. Each instruction specifies a condition and is only executed if the condition is satisfied. For every instruction, the condition circuit reads the condition from the instruction register (blue), evaluates the condition flags (purple), and informs the control logic (yellow) if the instruction should be executed or skipped. […]

Full post:
http://www.righto.com/2016/01/conditional-instructions-in-arm1.html

Zero perms to TrustZone: Android mediaserver CVEs discussion

https://pbs.twimg.com/media/CZgC2lkUEAA16RP.png:large

Android privilege escalation to mediaserver from zero permissions (CVE-2014-7920 + CVE-2014-7921)

In this blog post we’ll go over two vulnerabilities I discovered which, when combined, enable arbitrary code execution within the “mediaserver” process from any context, requiring no permissions whatsoever. How bad is it? The first vulnerability (CVE-2014-7921) was present in all Android version from 4.0.3 onwards. The second vulnerability (CVE-2014-7920) was present in all Android versions from 2.2 (!). Also, these vulnerabilities are not vendor specific and were present in all Android devices. Since the first vulnerability is only needed to bypass ASLR, and ASLR is only present (in a meaningful form) from Android 4.1 onwards, this means that these vulnerabilities allow code execution within “mediaserver” on any Android device starting from version 2.2. Although I reported both vulnerabilities in mid October 2014, they were unfortunately only fixed much later (see “Timeline” for full description, below) – in Android version 5.1!  This means that there are many devices out there which are still vulnerable to these issues, so please take care. You can find the actual patches here. The patches were pushed to AOSP five months after the vulnerabilities were reported. That said, the Android security team was very pleasant to work with, and with other vulnerabilities I reported later on, were much more responsive and managed to solve the issues within a shorter time-frame.
[…]

Full post:
http://bits-please.blogspot.com/2016/01/android-privilege-escalation-to.html

Sigh, it seem harder to track ARM firmware bugs, since they’re often hidden in the description of an app bug. And SCAP has no firmware OVAL definitions for CVEs to mention things like TrustZone. 😦

Intel Haswell GPU reversing

Joshua Barczak has a new blog post on reversing an Intel Haswell GPU, and has sample code on Github.

[…] Why Did I Go To All This Trouble? There are a couple of reasons why this is more than just a pointless exercise in reverse engineering. This hardware contains a lot of goodies that the graphics APIs simply do not expose, and I’m wondering if I can exploit any of them to demonstrate cool stuff. I obviously can’t do anything in a shipping product, but perhaps we’ll find ways of using the hardware that aren’t anticipated by current APIs and programming models. There is a lot of unexposed functionality in this architecture. You can send messages back and forth between threads. Threads can spawn child threads and read/write their register files using message passing. I dont know whether all the right bits are set by the GL driver to enable this, but if it works, it might be fun to experiment with. You can mix SIMD modes. Use SIMD4 instructions in one cycle and SIMD8/SIMD16 in another. You can use swizzles or register movs to do all sorts of cross-lane communication at very little cost. You can do warp-level programming, where each thread is 1 16-wide instruction stream instead of 16 1-wide streams. You can switch modes multiple times within the same thread if you like. As some of my Intel friends like to point out, on this hardware, every thread has 4KB of register space. The register file in total is roughly the size of the cache. There’s no “use fewer registers to boost occupancy”, the occupancy is just there. There is also GPR indexing, and unlike on other architectures it is actually potentially useful. Hardware threads can implement small fixed-size data structures entirely in their register files without it totally sucking. […]

Full post:
http://www.joshbarczak.com/blog/?p=1028
https://github.com/jbarczak/HAXWell
https://onedrive.live.com/view.aspx?resid=EBE7DEDA70D06DA0!107&app=PowerPoint&authkey=!AD-O3oq3Ung7pzk
https://01.org/linuxgraphics/documentation

Fast Boot, instead of UEFI Secure Boot

There may be some situations where Secure Boot is not useful, and Fast Boot is an alternative, which is fast but NOT SECURE. Here’s a quick summary by Nikolaj Schleg (aka CodeRush) of what is needed to disable Secure Boot and enable Fast Boot with use on Windows systems:

The best way to decrease boot time is to switch to UEFI boot, disable CSM, enable FastBoot and disable SecureBoot, because it takes some time to check a signature of your bootloader, and it will be checked on every boot.
If you remove all SecureBoot keys, the SecureBoot will switch into so called “Setup Mode”, where you can add your own keys without having a private parts of older ones (that are only available to Microsoft and ASUS, in your case). AMI-based UEFIs have a “standard” keys in default map, so don’t worry about losing the keys – you can easily restore them from Security->SecureBoot Settings setup page.
What you need to do:
1. Disable CSM.
2. Enable FastBoot.
3. Enable (better protection from bootkits, a bit slower boot time) or disable (a bit faster boot time, the same security level you have now with CSM) SecureBoot.
4. Don’t touch the keys, they are fine by default.
5. Reinstall Windows in UEFI mode.

 

Full post:
http://www.win-raid.com/t1495f13-UEFI-clearing-secure-boot-keys.html

There’s another guide for Windows 8.x here:
http://answers.microsoft.com/en-us/windows/forum/windows_8-performance/windows-8-can-not-stop-fast-boot/239e56e7-649d-4110-af4c-6fe9c3340530?auth=1

More on disabling Secure Boot keys:

Nikolaj’s UEFI SecureBoot tutorial

More on disabling Secure Boot:
https://technet.microsoft.com/en-us/library/dn481258.aspx

And for a bit of contrasting — yet still informative — advice, here’s how to disable Fast Boot:
http://support.fixmestick.com/hc/en-us/articles/200578596-Disabling-Fast-Boot-on-Windows-8-8-1-and-10

Some more on Fast Boot and Windows:
https://blogs.msdn.microsoft.com/b8/2011/09/08/delivering-fast-boot-times-in-windows-8/
https://msdn.microsoft.com/en-us/library/ms858380.aspx
https://blogs.msdn.microsoft.com/b8/2012/05/22/designing-for-pcs-that-boot-faster-than-ever-before/
https://msdn.microsoft.com/en-us/library/windows/hardware/jj835779%28v=vs.85%29.aspx

Car hackers take note at the use of Fast Boot (instead of Secure Boot) in Windows Automotive stack, in above MSDN docs. Yikes.

 

AArch64 Xen gets Dom0 ACPI support

Shannon Zhao of Huawei submitted a 17-part patch to the Linux-ARM-kernel, Linux-EFI, Linux-Kernel, and Xen-devel lists, which adds ACPI support for Xen Dom0 on AArch64 systems.

This patch set adds ACPI support for Xen Dom0 on ARM64. The relevant Xen ACPI on ARM64 design document could be found from [1]. The corresponding Xen patches can be fetched from [2].

  Xen: ACPI: Hide UART used by Xen
  xen/grant-table: Move xlated_setup_gnttab_pages to common place
  Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
  arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table
  xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio
  Xen: ARM: Add support for mapping platform device mmio
  Xen: ARM: Add support for mapping AMBA device mmio
  Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen
  xen/hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ
  arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
  ARM: XEN: Move xen_early_init() before efi_init()
  ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
  ARM: Xen: Document UEFI support on Xen ARM virtual platforms
  XEN: EFI: Move x86 specific codes to architecture directory
  ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services
  FDT: Add a helper to get specified name subnode
  Xen: EFI: Parse DT parameters for Xen specific UEFI

[1] http://lists.xen.org/archives/html/xen-devel/2015-11/msg00488.html
[2] http://git.linaro.org/people/shannon.zhao/xen.git  ACPI_XEN_ARM_V3
http://vger.kernel.org/majordomo-info.html

AArch64 gets ACPI NUMA support

Hanjun Guo of Huawei submitted a 12-part patch to the Linux-ACPI, Linux-ARM-Kernel, and Linux-Kernel lists, which adds ACPU NUMA (Non-Uniform Memory Access) support for AArch64 systems.

Based on Ganapat’s v9 dt based NUMA patch set [1] for ARM64, this patch set introduce the ACPI based configuration to provide NUMA information. ACPI 5.1 already introduced NUMA support for ARM64, which can get the NUMA domain information from SRAT and SLIT table, so parse those two tables to get mappings from cpu/mem to numa node configration and system locality.

  acpi, numa: Use pr_fmt() instead of printk
  acpi, numa: Replace ACPI_DEBUG_PRINT() with pr_debug()
  acpi, numa: remove duplicate NULL check
  acpi, numa: introduce ACPI_HAS_NUMA_ARCH_FIXUP
  arm64, acpi, numa: NUMA support based on SRAT and SLIT
  acpi, numa: Enable ACPI based NUMA on ARM64
  acpi, numa: move acpi_numa_slit_init() to common place
  arm64, numa: rework numa_add_memblk()
  x86, acpi, numa: cleanup acpi_numa_processor_affinity_init()
  acpi, numa: move bad_srat() and srat_disabled() to common place
  acpi, numa: remove unneeded acpi_numa=1
  acpi, numa: reuse acpi_numa_memory_affinity_init()

[1] http://lwn.net/Articles/672329/

http://vger.kernel.org/majordomo-info.html
http://wiki.xen.org/wiki/Xen_on_NUMA_Machines
https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA

DAQRI Smart Helmet powered by AMI firmware

Firmware vendor AMI announced that it is building the firmware for the DAQRI smart helmet.

Excerpt of AMI press release:

[…] DAQRI, a company known for its innovative work in augmented reality, recently announced the next generation of its flagship product, DAQRI SMART HELMET. Powered by a 6th generation Intel® CORE™ m7 processor and Intel® RealSense™ camera technology, DAQRI SMART HELMET is a wearable human-machine interface (HMI) giving workers in industrial sectors a whole new way of seeing data while on the job. The Smart Helmet is designed to work in enterprise settings and displays real-time information based on the user’s surroundings, increasing safety and worker productivity. It comes equipped with many features to enhance user awareness including: 4D/augmented reality, thermal vision, and industry leading Intellitrack™ computer vision technology. With increasing interest in augmented reality technology, AMI has collaborated with DAQRI in the development of the next generation DAQRI SMART HELMET. […]

http://ami.com/news/press-releases/?PressReleaseID=350&/American%20Megatrends%20Collaborates%20with%20DAQRI%20on%20the%20Next%20Generation%20of%20DAQRI%20SMART%20HELMET%E2%84%A2%20Augmented%20Reality%20HMI/

http://daqri.com/home/product/daqri-smart-helmet/

ARM-based AMD device launched

AMD has used to be x64-based company. But now they’ve also got ARM technology in some of their new products, so things are about to get interesting, how this will turn out.,. Joel Hruska reports in ExtremeTech on the Opteron-A1100:

http://www.extremetech.com/extreme/221282-amds-first-arm-based-processor-the-opteron-a1100-is-finally-here?sf19369490=1

AMD’s first ARM-based processor, the Opteron A1100, is finally here

Today AMD is formally launching its first ARM processor core, the Opteron A1100. AMD first announced its plans to enter the ARM market in 2013, with the chip expected to ship by mid-2014. The company apparently began early sampling around that time frame, but is only now launching the processor. The new Opteron A1100 is pretty much what AMD promised in its early previews of the device. It packs eight Cortex-A57 CPU cores, with each pair of cores sharing a 1MB L2 (512K effectively allocated to each chip). An 8MB L3 cache backs the entire CPU cluster, and the CPU supports both DDR3 and DDR4. ECC support is also provided.

Windows 10 health check features

https://twitter.com/dfullerto/status/690555872917987328

Microsoft has an article that describes the new health check security features of Windows 10, which include use of UEFI Secure Boot and TPM technology, among others:

This article details an end-to-end solution that helps you protect high-value assets by enforcing, controlling, and reporting the health of Windows 10-based devices, including hardware requirements.

https://technet.microsoft.com/en-us/library/mt592023%28v=vs.85%29.aspx

Google Android Nexus debug cable is open source

Google has specs for the Nexus debug cable:

USB debug cable design documents:  Eagle schematics and PCB, gerber files, and BOM for a debug cable
for the headset serial port found on most Nexus devices.

https://android.googlesource.com/device/google/debugcable/+/master

Bill of Materials for Things

As Dyngnosis says:

“Bill of Materials for embedded devices could/should include a list of included 3rd party libraries. (Think heartbleed on an infusion pump)”

Consumers should know a lot more about the details of what is included in firmware. U-Boot has SPDX metadata.

 

Kali 2016.1 UEFI user experience notes

Debian Derivative-based Kali just released a new release, with UEFI support, based on upstream Debian. J.A. Watson wrote an article for ZDNet about trying to install the latest release, focusing on UEFI issues. I’ve included a few UEFI-centric excerpts below. Additionally it sounds like the Kali Mini version is based on Debian netinstall, “but it doesn’t boot on a UEFI system”.

[…]  To top it all off, the new distribution is UEFI compatible, and installed without any problem on the systems I have tried so far. This is really the best news of all for me, because I have spent huge amounts of time fighting to get the previous Kali distributions properly loaded and configured on UEFI systems (NOT in Legacy boot mode). […]  It looks to me like what they have finally done is what I thought they should have been doing all along – they simply use the Debian installer, which has been able to deal with UEFI for ages. […] The new ISO images can be obtained from the Kali Downloads page, and these are also a pretty impressive creation. They can be booted in (normal) Live mode, in (forensic) Live mode, or they can be directly installed. As far as I can tell there is no way to install from a Live boot, and I consider that to be a good thing because the previous Live installers didn’t work worth beans on UEFI firmware systems. […] The bottom line is, the new Kali release is here, it’s beautiful, it works, even on UEFI firmware. […]

Full article:
http://www.zdnet.com/article/hand-on-with-kali-linux-rolling/
https://www.kali.org/news/kali-linux-rolling-edition-2016-1/

Hackaday on Intel ME

Hackaday has a new blog on the Intel ME, covering recent news, as well as some background history I’d not seen.

[…] To break the Management Engine, though, this code will have to be reverse engineered, and figuring out the custom compression scheme that’s used in the firmware remains an unsolved problem. But unsolved doesn’t mean that people aren’t working on it. There are efforts to break the ME’s Huffman algorithm. Of course, deciphering the code we have would lead to another road block: there is still the code on the inaccessible on-chip ROM. Nothing short of industrial espionage or decapping the chip and looking at the silicon will allow anyone to read the ROM code. While researchers do have some idea what this code does by inferring the functions, there is no way to read and audit it. So the ME remains a black box for now. […]

The Trouble With Intel’s Management Engine

FYI: This blog was Hackaday’s first UEFI-tagged post. A few others had BIOS tags.

Who created the ACPI ASPT spec?

Re: https://firmwaresecurity.com/2015/12/08/fwts-adds-test-for-undocumented-aspt-acpi/

Earlier, the FWTS team thought this ACPI ASPT (ACPI System Performance Tuning) spec was from AMD.  AMD looked into it, and thinks it is probably from Intel, as does Insyde Software. Intel/anyone: Do you know who wrote the spec? If so, please leave a comment or send email. Thanks.

AMD comment:
Well, as far as I can tell, nobody at AMD knows about the ASPT table. First I asked the relevant specialists, then I asked everybody associated with BIOS. Nobody recognizes it as an AMD thing.
Then we found an IBV .txt file that listed a bunch of Intel-sounding platforms associated with ASPT. So, could you double check whether this is really being seen on AMD platforms, please?
Even if you do find it on some AMD platforms, I’m now pretty sure it’s not an AMD thing. It might be a proprietary ACPI table added by an OEM or and IBV. I believe proprietary tables are allowed by the ACPI spec.

and a later comment:
It’s actually a definition from another silicon vendor for their overclocking information. Since the table only shows up on systems that support overclocking, it only shows up on systems with fast graphics controllers. That’s might be why “AMD” is referenced.

Another comment from a firmware vendor (IFV):
I believe you would be better served by contacting any of your contacts at Intel Client.  I’m not saying they will document this table, but it’s clear to me by looking at our code, this is Intel’s table. Maybe the AMD false pointer is probably because most overclocking systems have non-integrated graphics?

FOSDEM

FOSDEM is happening soon, and there are a *LOT* of interesting talks there this year:

https://fosdem.org/2016/schedule/events/

Here’s a mere teaser of the many hardware/firmware-related ones, from a very quick (incomplete) look at their schedule, there are MANY other interesting talks not listed below.:

Genode’s TrustZone demo on the USB Armory
Developing eco-conscious Libre Hardware
Libreboot – free your BIOS today!
MIPS, the other side of the embedded
open source FPGA toolchain and hardware
NemoTablet, a FOSS DIY tablet using Raspberry Pi 2
Make your own USB device without pain and money!
Security in IoT; more a cultural chock than a technical challenge
IoT meets Security
USBGuard: Take control over your USB devices

Intel Quark gets Measured Boot

The Intel Quark support in the UEFI Forum’s public EDK-II has been updated to support Trustworthy Computing Group’s TPM-based Measured Boot. For more information, see the patch thread on the edk2-devel mailing list.

QuarkPlatformPkg: Add MEASURED_BOOT_ENABLE feature

Add MEASURED_BOOT_ENABLE flag
Add TPM_12_HARDWARE flag
Add TrEEConfigPei to detect TPM 1.2 hardware device
Use Tpm12DeviceLib instance for Atmel I2C TPM
Use Tpm12DeviceLib instance for Infineon I2C TPM
Add TcgPei and TcgDxe modules for TPM 1.2 support
Clean up TpmMeasurementLib mappings

ACPI 5.1a/6.0 GIC structure inconsistency

Mark Doron of Intel posted a message to the Linux-ACPI and Linux-Kernel lists, clarifying some spec deltas between ACPI 5.1a and 6.0, specificaly for the GIC structure. Most of Mark’s message is quoted verbatim below, see the Linux-ACPI list archives for the full post.

Watch this site for any 2016-dated specs, for an update: http://uefi.org/acpi

GIC version inconsistency in ACPI 5.1a versus 6.0 documents

Hi Everyone:

I have been asked to post here on behalf of the UEFI Forum’s ACPI Spec Work Group (ASWG) to provide some clarification regarding the ACPI Specification versions 5.1a and 6.0.  For those who may not know me, I am the Chair of this work group.

In particular it turns out that there are different definitions contained in the these two versions of the document for the GIC version field contained in the GIC Distributor Structure.  This structure is located in Table 5-63 in both versions of the document.  I am told this inconsistency is causing some problems for implementation work.

The inconsistency arises purely from an administrative error on our part as keepers of the ACPI Specification.  I want to apologize to anyone who has been inconvenienced by this issue.

The sharp-eyed may notice that the dates on the covers of the two versions are the same.  The Forum’s normal practice when making a new revision is to re-publish the prior version with all known errata included so that the content that is common between the existing and new documents matches.  This accounts for the two documents having the same date; in fact they were published on the exact same day at the same time.

In the case of this one particular structure definition, as shown in Table 5-63, the content was corrected to match what it should say in the 6.0 version of the document.  Unfortunately we messed up and the same fix was not properly retrofitted to the ACPI 5.1 spec to be included with the 5.1a (latest errata included version of 5.1 that was released at the same time as 6.0).

Now this inconsistency has been pointed out, the UEFI Forum will publish a revised version 5.1b that will incorporate a fix for this problem.  This will however take a little time to organize so it may be some days before that updated document appears on the Forum’s public web site.

Since it was felt that this issue is causing friction for implementation work going on right now, the Work Group asked that I post the above explanation and mitigation as well as the following recommendation to help move implementation work ahead without delay.

The recommendation from the UEFI Forum in this case then is:

– For implementation purposes, the definition in the ACPI 5.1a for the GIC version field that is part of the GIC Distributor Structure (Table 5-63) is incorrect and instead implementers should refer to the corresponding sections of the ACPI 6.0 Specification (the Table to refer to is numbered the same in both documents).  The inconsistency will be corrected shortly with the release of a revised ACPI Spec 5.1b update.

For the avoidance of doubt, this means that implementers seeking to conform to the ACPI 5.1 specification should implement to the ACPI 5.1a in every particular except for the above referenced GIC version field which should follow the definition contained in the ACPI 6.0 version of the specification.  This advice holds true until a revised ACPI 5.1b is published at which time there will be no inconsistency.

 

NVIDIA Nouveau Secure Boot

Quoting Michael of Phoronix:

NVIDIA Publishes Nouveau Patches For Secure Boot, Unified Firmware Loading

NVIDIA has released new patches today for helping the open-source Nouveau driver step towards properly supporting the GeForce GTX 900 “Maxwell” graphics cards as well as better supporting Tegra. The first patch series sent out today was authored by NVIDIA’s Alexandre Courbot and provides unified firmware loading functions. He explained, “This patchset centralizes the firmware-loading procedure to one set of functions instead of having each engine load its firmware as it pleases. This helps ensure that all firmware comes from the same place, namely nvidia/chip/. This changes where the firmware is fetched from for falcon/xtensa/bios, but these locations never seemed to have been official anyway. Also for most (all?) chips supported by Nouveau there is corresponding internal firmware, so disruption should be minimal/non-existent. If this assumption is wrong, feel free to drop patches 3-5. At the very least, firmware officially provided by NVIDIA should be looked up using the new functions for consistency.”[…]

http://www.phoronix.com/scan.php?page=news_item&px=Nouveau-Secure-Boot-FW

http://www.phoronix.com/scan.php?page=news_item&px=MTc5ODA

http://lists.freedesktop.org/archives/nouveau/2016-January/023814.html

http://lists.freedesktop.org/archives/nouveau/2016-January/023820.html