YARD Stick One, from Great Scott Gadgets

Michael Ossmann just announced the YARD STICK One, from Great Scott Gadgets:

This week we started shipping YARD Stick One, our latest test tool for radio systems operating below 1 GHz. The first thing you should know about it is that, unlike our popular HackRF One, YARD Stick One is not a Software Defined Radio (SDR) platform. Although we think that SDR is the overall best tool for the greatest number of wireless applications, sometimes it is beneficial to have a simpler tool for certain jobs. YARD Stick One (Yet Another Radio Dongle) can transmit or receive digital wireless signals at frequencies below 1 GHz. It uses the same radio circuit as the popular IM-Me. The radio functions that are possible by customizing IM-Me firmware are now at your fingertips when you attach YARD Stick One to a computer via USB. Capabilities:
* half-duplex transmit and receive
 * official operating frequencies: 300-348 MHz, 391-464 MHz, and 782-928 MHz
 * unofficial operating frequencies: 281-361 MHz, 378-481 MHz, and 749-962 MHz
 * modulations: ASK, OOK, GFSK, 2-FSK, 4-FSK, MSK
 * data rates up to 500 kbps
 * Full-Speed USB 2.0

More information:

http://greatscottgadgets.com/yardstickone/
http://greatscottgadgets.com/2015/09-30-introducing-yard-stick-one/

Akiba on hardware manufacturing

Akiba at FreakLabs has a new article on manufacturing in China:

Excerpt:

Manufacturer’s Corner – Sourcing And Logistics
Taking a look at the import/export e-commerce model

Hi everyone. This is Akiba and I’ll be writing a guest section in Hubhao focusing on manufacturing. I’m a designer and electrical engineer from the US, based out of Japan, and a frequent visitor to Dongguan and Shenzhen. I teach a course on manufacturing for MIT Media Lab in Shenzhen and frequently get my own designs, as well as other peoples’ designs, manufactured in Dongguan, as well as troubleshooting manufacturing “hiccups” that might occur.
     Akiba Wang is a designer and electrical engineer from the US, based out of Japan, and is a frequent visitor to Guangdong. He teaches a course on manufacturing for the MIT Media Lab in Shenzhen and he will be passing on some of the same lessons to our readers with his Manufacturing Corner column.

Full article:

http://www.hubhao.com/manufacturers-corner-sourcing-and-logistics/

TrustZone in AMD Pro APUs

Bruno Ferreira has a story in TechReport on TrustZone support in new AMD Pro APUs:

AMD goes Pro with TrustZone-enabled APUs

AMD has released a Pro family of APUs and management tools targeted at business environments. These APUs hail from the Godavari and Carrizo families, and come in both mobile and desktop flavors. According to AMD, its new Pro A12 mobile APU is “the first [HSA-compliant] commercial processor in the industry.” It’s also the first APU with support for ARM’s TrustZone, for system-wide separation of software execution environments. The mobile Pro A12 packs in four CPU cores with a 3.4 GHz Turbo clock, alongside an R7-series GPU with 512 compute units clocked at 800 MHz. The inclusion of an HEVC decoder is also a nice bonus. A similar part exists in the Pro-series desktop APU lineup, with four cores and Turbo speeds of 4.1 GHz. Along with the hardware, AMD has released its companion Pro Control Center software, which offers centralized system management features like system health monitoring, traffic shaping, and USB port blocking. If this whole thing sounds similar to Intel’s vPro, you’re probably right. Still, AMD’s take has a few unique features. AMD already has a few partners on board. HP is using Pro APUs in  its “AMD Elite” family of products, and Lenovo is building around these chips with its M79 Tower. More AMD Pro products should be coming soon.

Full story:

http://techreport.com/news/29121/amd-goes-pro-with-trustzone-enabled-apus

Nexus status update

Tom’s Hardware has an article with an interview of a few Nexus engineers, talking about upcoming releases:

Nexus Engineers Reveal More Nexus 5X, Nexus 6P Details
by Lucian Armasu

Four members of the Google Nexus team, including Hiroshi Lockheimer, David Burke, Krishna Kumar and Sandeep Waraich, took the time to answer questions from Nexus 5X and Nexus 6P fans about the two new phones. Here’s a summary of the most important details. […]

http://www.tomshardware.com/news/nexus-5x-nexus-6p-ama,30208.html#xtor=RSS-999

Minnowboard status

The Minnowboard community has given an update on the status of current and upcoming models:

“There have been a lot of reports / misconceptions of the MAX being discontinued (or being End of Lifed), these are not entirely accurate.  Some distributors are reporting the board is going EOL because we are coming up on a product SKU change due to user facing changes (things like pin 26 in the LSE are changing to provide a MCLK reference for example).  So while the A2 PCB based MinnowBoard MAXes are being EoLed, the A4s should be available shortly, and the MinnowBoard Turbot’s should be publicly available, in quantity, in early November (assuming production holds to the current schedule). We aren’t going anywhere folks, we have a lot of exciting things coming down the line, lures and software and we are hard at work on things for the future, so stay tuned!”

Below is URL of Google+ post:

https://plus.google.com/+MinnowboardOrg/posts/cwhJsfgcFkt

VMware security update

VMware issued a security advisory for 3 CVEs today:

Excerpt of announcement:

VMSA-2015-0007
VMware vCenter and ESXi updates address critical security issues.
Advisory ID:  VMSA-2015-0007
Updated on:     2015-10-01 (Initial Advisory)
CVE numbers:     CVE-2015-5177 CVE-2015-2342 CVE-2015-1047

1) VMware ESXi contains a double free flaw in OpenSLP’s SLPDProcessMessage() function. Exploitation of this issue may allow an unauthenticated attacker to execute code remotely on the ESXi host. VMware would like to thank Qinghao Tang of QIHU 360 for reporting this issue to us.

2) VMware vCenter Server contains a remotely accessible JMX RMI service that is not securely configured. An unauthenticated remote attacker that is able to connect to the service may be able use it to execute arbitrary code on the vCenter server. VMware would like to thank Doug McLeod of 7 Elements Ltd and an anonymous researcher working through HP’s Zero Day Initiative for reporting this issue to us.

3) VMware vCenter Server does not properly sanitize long heartbeat messages. Exploitation of this issue may allow an unauthenticated attacker to create a denial-of-service condition in the vpxd service. VMware would like to thank the Google Security Team for reporting this issue to us.

More Information:

https://www.vmware.com/go/download-vsphere
https://www.vmware.com/patchmgr/findPatch.portal
http://kb.vmware.com/kb/2110247
http://kb.vmware.com/kb/2114875
http://kb.vmware.com/kb/2120209
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5177
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2342
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1047
http://www.vmware.com/security/advisories
http://kb.vmware.com/kb/2078735
https://www.vmware.com/security/advisories/VMSA-2015-0007

UDK 2015 available

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.

Intel Sharks Cove

I keep waiting to hear about Intel’s new Innovation Engine, announced the other month at IDF. So far, I’ve not found much.

But I did just find another new Intel UEFI project:  Shark’s Cove.

Introducing Sharks Cove: Sharks Cove is a development board that you can use to develop hardware and drivers for Windows and Android. The Sharks Cove board designed by Intel® supports development of devices and drivers that use a variety of interfaces, including GPIO, I2C, I2S, UART, SDIO, USB, and MIPI for Display and Camera. The primary target usage of the Sharks Cove board is for development of subsystems for Intel® Atom™ processors based Tablets and Mobile devices, but this development board can be used for any Windows or Android based system which uses the Intel® Atom™ processor.

Wow, this board was launched in 2014 and I just noticed it. 😦 I’d swear that it just appeared on the Intel firmware site the other day, though. Anyway, exciting to see another UEFI dev board. But sad to see Windows/Android-only focus, I’d hope to see Linux among the list of supported OSes, like Yocto.

More Info:

http://www.sharkscove.org/
https://firmware.intel.com/projects/sharks-cove-uefi-firmware

Click to access Sharks-Cove-Technical-Specifications.pdf

https://channel9.msdn.com/Events/Windows-Compatible-Hardware-Development-Boards/Live-Event-2014/Morning

UDK2015 expected mid-October

The UDK github wiki has been updated to give information about upcoming UDK 2015 release next month. It appears to include most UEFI 2.5 features, plus a few new ones. Excerpt of changes:

 

Support UEFI 2.5 Updates:
 + Smart Card Reader & Smart card edge protocol (H file only)
 + Inline Cryptographic Interface Protocol (H file only)
 + UEFI USB Function I/O Protocol (H file only)
 + Add NVM Express Pass Thru Protocol
 + Add UFS stack
 + Add SD Device Path (H file only)
 + Add reconnect Browser Action
 + Ability to refresh the entire form
 + The default/options for the Ordered List question
 + Keyword Strings support
 + New CPER Memory Section (H file only)
 + New EFI_HASH2_PROTOCOL
 + Adding support for No executable data areas
 + Persistent Memory Type support
 + Add the Support for new PKCS7 Verification Services
 + System Prep Applications
 + Add SMBIOS3_TABLE_GUID in configuration table.
 + Exposing Memory Redundancy to OSPM
 + ESRT: EFI System Resource Table and component firmware updates
 + IPV6 support from UNDI
 + UEFI “Next” Feature –
    * IP_CONFIG2 Protocol
    * Boot from HTTP (Excluding IPV6)
    * DNSv4 and DNSv6

Support PI 1.4 Updates:
 + PI SMM GPI
 + New MP Service PPI
 + Multiple CPU health info
 + PEI SetBootMode Service() clarification
 + GetMemoryMap Update for ReservedMemory
 + New Graphics PPI
 + New Capsule PPI
 + SIO PEI and UEFI-Driver Model Architecture
 + Extended File Size Errata
 + Add Reset2 PPI

Excluded from UEFI 2.5 Updates:
 + Match2 Opcode and EFI_REGULAR_EXPRESSION_PROTOCOL
 + Bluetooth Support (H file only)
 + Errata Boot Manager Policy & SATA Device Path Node
 + RamDisk Device Path
 + UEFI “Next” Feature –
    * Boot from HTTP (Excluding IPV6)
    * WIFI support (H file only)
    * EAP2 Protocol (H file only)
    * UEFI TLS API
    * REST Protocol
    * Platform recovery
    * Customized Deployment of Secure Boot
    * BMC/Service Processor Device Path

Other features:
 + Add ACPI 6.0 definitions.
 + Add SMBIOS 3.0 definitions.
 + Support OpenSSL version 1.0.2d.

Looking forward to the upcoming checkins to Tianocore’s EDK2 trunk!

Full roadmap article:
https://github.com/tianocore/tianocore.github.io/wiki/RoadMap2015

Nikolaj on UEFI security, part 5

Nikolaj’s part 5 of his series on UEFI security. Google Translation of first paragraph:

On safety UEFI, Part Five

After a short break, we continue to talk about the safety of UEFI. This time we will focus on technology SecureBoot, its pros and cons, about the attacks on her and protect them. For the first time we are talking about SecureBoot standard UEFI 2.2 in 2011, but finally all the aspects have been implemented in version 2.3.1C in early 2012. The main developer of the technology has been Microsoft, which once said that to obtain a certificate of Windows 8 Ready for his not yet released the new operating system requires the implementation and integration SecureBoot by default on all new PCs. This announcement sparked a wave of sharp criticism from the supporters of the free software, which is successfully sunk, and until Habra. If you’re wondering what exactly ended confrontation MS and the community as SecureBoot looks after almost 4 years of growing up, and the attacks on him are still possible – welcome under the cut.

http://habrahabr.ru/post/267953/

 

http://translate.google.com/translate?hl=en&sl=ru&tl=en&u=http%3A%2F%2Fhabrahabr.ru%2Fpost%2F267953%2F&sandbox=1

 

Microsoft updating it’s C Compiler?

Microsoft bought a C Compiler from Lattice C years ago, and started Microsoft C (MSC). But after Borland and other commercial C compilers died off, Microsoft stopped adding anything to the C compiler except new security features in reaction to attacks. The C++ team owns the C compiler, and lets it starve, while feeding C++, as below post shows the leash C is on by the C++ team. Once C# became the top langauge, the C/C+ team not only was starved from budget, but also headcount (the good compiler engineers don’t want to work on the old C compiler, but the sexy new C# compiler, etc.).

Microsoft has a fork of LLVM’s clang (fresh, last update only 10 hours ago), and I’ve been assuming that they’d replace MSC with clang, like ARM and other other vendors are apparently doing. I’m unclear if Microsoft has replaced their old codebase, but they are adopting clang as part of their toolchain.

This is great news. Open source hackers won’t have to add a bunch of lame workarounds for dumb MSC. BEST YET, UEFI Forum might be able to revise it’s C language requirements, no longer dealing with the dumbest compiler from Redmond anymore. However, I think that Intel’s C compiler (ICC) may become the new blocking point for any language improvements to UEFI, I think. Once UEFI Forum sponsors someone to write LLVM front- and back-ends for EBC, then ARM and Microsoft (and other) toolchains will also get EBC support! 🙂

http://blogs.msdn.com/b/vcblog/archive/2015/09/25/rejuvenating-the-microsoft-c-c-compiler.aspx
http://cppcon2015.sched.org/event/306cd32001a6e6b403a4495710cc3591#.VgwWSZeZeV4
https://github.com/Microsoft/clang
https://en.wikipedia.org/wiki/Lattice_C

Libiquity Taurinus X200

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/

 

Android Marshmallow shows security patch level

Android Police has an article on Android Marshmallow, and how the UI now can show you the security patch level.

http://www.androidpolice.com/2015/09/29/android-now-shows-your-devices-android-security-patch-level-in-marshmallow/

Unrelated to the above Marshmallow news, but there is also this security tool for Android:

Android Vulnerability Test Suite

And if you have an Intel-based Android device, you may also be able to boot a Linux live-boot distros, like LUV-live, and run CHIPSEC, for Intel-specific firmware security tests. (I don’t have an Intel Android-IA-based device to verify if this works, speak up if you can confirm it does or does not work.)

Bromium Labs on Microsoft Control Flow Guard

Rafal Wojtczuk has a new entry on the Bromium Labs blog, on Microsoft’s Control Flow Guard security feature, and evading it.

http://labs.bromium.com/2015/09/28/an-interesting-detail-about-control-flow-guard/

http://blogs.msdn.com/b/vcblog/archive/2014/12/08/visual-studio-2015-preview-work-in-progress-security-feature.aspx

Firmware.RE

Firmware.RE is a web service I’ve been wanting for a few months, and didn’t realize that it has existed for a few years! 🙂

There is the UEFI-Spyder and the Apple-centric Firmware Vault. But no good place to upload ROMs to. I even asked DigitalCorpora.org, but they had no interest. Anyway, Firmware.RE exists and solicits new ROM uploads!

This URL has some pointers to papers from the site’s authors:

http://firmware.re/bh13us.php

One of the authors just defended his PHD the other day:

Costin’s embedded firmware security thesis

If you’re looking for a place to upload your ROM to, here it is! There’s also a GoogleGroup, but appears to be unused as-of-yet.

http://firmware.re/

coreboot changes

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

PAE-enabled SeaBIOS

On the SeaBIOS mailing list, Kevin O’Connor recently provided a patch to SeaBIOS to enable it to run in PAE mode. SeaBIOS is the main open source implementation of 16-bit x86 BIOS, used in coreboot, tianocore, and elsewhere. Excerpting Kevin’s posting:

I was curious to see if SeaBIOS could run its 32bit code with PAE paging enabled.  So, I put together some test code, and so far it seems to work.

The reason why PAE is interesting (instead of standard i386 paging) is that it allows for 64bit mappings and because one can set it up with just a single level page directory of 2MB pages.  The single level page directory makes maintaining it much easier.

The SeaBIOS’ malloc code could also be updated to remap pages which would make it possible for it to relocate itself above 4GB and to store data above 4GB.  That’s likely not all that useful, but I think it would be a little amusing for a 16bit bios to fully support 64bit memory.

I haven’t done any performance tests.  It’s unclear what the performance impact of enabling paging on every 32bit entry point would be.

It appears that more work will be done before this patch is contributed to trunk. But it is interesting to see PAE-enabled BIOS!

More Information:
http://www.seabios.org/pipermail/seabios/2015-September/009788.html
http://www.seabios.org/

Linux Journal: Thinkpad X60 and Libreboot

Kyle Rankin has a new article in Linux Journal, entitled “Libreboot on an X60, Part I: the Setup”. Excerpt:

In my next couple articles, I’m going to walk through the journey that brought me to the X60 running Libreboot that I’m using to type this column. In this first part, I discuss the setup, including what Libreboot is, what hardware it currently supports and some of the risks around flashing your BIOS. If I haven’t scared you off by the end of this article, in future articles, I’ll cover how to download Libreboot and verify its integrity, how to flash the BIOS itself in detail with sample script output and how to modify the default GRUB bootloader. If you can’t wait until next month, a lot of my process is based on the excellent guide provided at https://github.com/bibanon/Coreboot-ThinkPads/wiki/ThinkPad-X60.

Full article:
http://www.linuxjournal.com/content/libreboot-x60-part-i-setup

https://github.com/bibanon/Coreboot-ThinkPads/wiki/ThinkPad-X60