Category: Uncategorized

U-Boot ported to Intel64

~ hucktech ~ Leave a comment

Simon Glass of Chromium posted a *82-part* patch to the U-Boot list, with a port of U-Boot from 32-bit x86 to 64-bit x64 support. Quoting Simon’s initial message:

[PATCH 00/82] x86: Add initial support for 64-bit U-Boot

At present U-Boot runs entirely in 32-bit mode on x86, except for the initial switch from 16-bit mode. On 64-bit machines it is possible to run in 64-bit mode. This series starts the process of adding this support. The main benefit of 64-bit mode for a boot loader is direct access to all available memory. There are also more registers, but this makes very little difference. This feature is implemented by putting all of the 32-bit code in an SPL build. SPL then runs through all the init that has to be done in 32-bit mode, changes to 64-bit mode and then jumps to U-Boot proper. Typically the total code size increases slightly. For example, on link in 32-bit mode, U-Boot has around 480KB of code (admittedly with a large number of features enabled). In 64-bit mode, U-Boot falls to around 460KB, but SPL adds another 60KB, for a net increase of 40KB. Partly this is due to code duplication and partly it is due to the worse code density of 64-bit code on x86. Many major features are not implemented yet, for example:
  – SDRAM sizing
  – Booting linux
  – FSP support
  – EFI support
  – SCSI device init
  – Running video ROMs
Still, this is a big step forward towards full 64-bit support. To enable it, select CONFIG_X86_RUN_64BIT. This series is available at u-boot-x86/64-working.

91 files changed, 1796 insertions(+), 705 deletions(-)
See full description in the post:
http://lists.denx.de/pipermail/u-boot/2016-September/267925.html

UEFI EDK2 Platform Proposal V2

~ hucktech ~ Leave a comment

Michael Kinney of Intel posted the V2 RFC for the EDK2 Platform Proposal, dealing with how to deal with repos and branches. Outline of changes and problem statement excerpted below, see the full proposal for much more details.

Changes from V1:
* edk2-platform is not a fork of edk2.
* edk2-platforms branches contain CPU, Chipset, SoC, and platform specific packages
* edk2-plaforms/master contains all open platforms that are synced with edk2/master.
* Each edk2-platforms branch may support many platforms (not just one)
* Use PACKAGES_PATH to do builds using packages from multiple repositories
* Update edk2-platforms branch naming to clearly identify platforms that are considered stable and platforms that are under active development.
* edk2 developers may be required to verify platforms in edk2-platforms builds as part of test criteria.  Especially platforms that are intended to be used with edk2/master in edk2-platforms/stable-* branches.

Problem statement: Need place on tianocore.org where platforms can be maintained by the EDK II community.  This serves several purposes:
* Encourage more platforms sources to be shared earlier in the development process
* Allow platform sources to be shared that may not yet meet all edk2 required quality criteria
* Allow platform source to be shared so the EDK II community may choose to help finish and validate
* Allow more platforms to be used as part of the edk2 validation and release cycle.
* Not intended to be used for bug fixes.

For more information, see the archives of the edk2-devel@lists.01.org list.

https://lists.01.org/mailman/listinfo/edk2-devel

OpenBSD adds sysctl kern.allowkmem to reduce ‘decades of kernel snooping’

~ hucktech ~ Leave a comment

“Make a move towards ending 4 decades of kernel snooping. Add sysctl kern.allowkmem (default 0) which controls the ability to open /dev/mem or /dev/kmem at securelevel > 0.  Over 15 years we converted 99% of utilities in the tree to operate on sysctl-nodes (either by themselves or via code hiding in the guts of -lkvm). pstat -d and -v & procmap are affected and continued use of them will require kern.allowkmem=1 in /etc/sysctl.conf.  acpidump (and it’s buddy sendbug) are affected, but we’ll work out a solution soon. There will be some impact in ports.”

http://marc.info/?l=openbsd-cvs&m=147481705211536&w=2

 

KernelFuzzer

~ hucktech ~ Leave a comment

“KernelFuzzer: This is the core Kernel Fuzzer, with example library calls and Syscalls to start fuzzing Windows. The fuzzer has been tested on Windows 7 / 10, OS X and QNX. […] See our Def Con 24 slides over at MWR Labs which give an explanation of the fuzzer and examples of writing library calls and syscalls for the fuzzer. One of each is provided as an example and more examples are provided in the slides. […]”

https://github.com/mwrlabs/KernelFuzzer
https://labs.mwrinfosecurity.com/publications/platform-agnostic-kernel-fuzzing/

Open Trust Protocol (OTrP) gets revised

~ hucktech ~ Leave a comment

As Marc Canel of EETimes points out the 1st revision of the Open Trust Protocol is out. Open Trust Procotol is an IETF submission by multiple vendors, the companies Symantec, Intercede, Solacia, and ARM Ltd are the employers of the editors of the I-D.

Abstract: This document specifies the Open Trust Protocol (OTrP), a protocol to install, update, and delete applications and to manage security configuration in a Trusted Execution Environment (TEE). TEEs are used in environments where security services should be isolated from a regular operating system (often called rich OS). This form of compartmentlization grants a smaller codebase access to security sensitive services and restricts communication from the rich OS to those security services via mediated access.

http://www.eetimes.com/author.asp?section_id=36&doc_id=1330455&
https://www.ietf.org/id/draft-pei-opentrustprotocol-01.txt
https://tools.ietf.org/html/draft-pei-opentrustprotocol-01
https://datatracker.ietf.org/doc/draft-pei-opentrustprotocol/
https://www.ietf.org/mail-archive/web/saag/current/msg07206.html

 

Alex leaves Intel ATR!

~ hucktech ~ Leave a comment

Wow, Alex Matrosov is leaving Intel Advanced Threat Research (ATR).

As I understand it, he is one of the CHIPSEC team. I hope the project can handle his loss.

It is unclear what he’ll be doing next. Maybe he’ll be joining Apple?  They are hiring all the great researchers…)

https://keybase.io/matrosov

Matthew Garrett on Linux boot security

~ hucktech ~ Leave a comment

Amber Ankerholz wrote an article for Linux.com on the Linux boot-time security presentation that Matthew Garrett recently gave at the Linux Security Summit. In addition to the article, the video of the presentation is also available.

https://www.linux.com/news/matthew-garrett-explains-how-increase-security-boot-time

 

Sequitur Labs’ IoT security checklist

~ hucktech ~ Leave a comment

Philip Attfield of Sequitur Labs Inc. wrote an article for IoT Agenda on IoT Security; excerpting a checklist from the article:

* Devices must implement a “root of trust” as a trustworthy measure of integrity and authenticity. A root of trust, once established, is unchangeable and is therefore always reliable and trustworthy.
* Secure interaction between devices on a network is necessary. Implement mechanisms enabling mutual device authentication.
* Isolation and separation are well-accepted principles of security. Isolating sensitive information such as encryption keys, proprietary algorithms or other information raises the difficulty level for an attacker and minimizes the impact of a breach.
* Separate application functions critical to security. Execute such functions in isolated and secured memory regions to prevent compromise.
* Choose hardware platforms that include tamper resistance features. Such features protect against physical device tampering by destroying critical information such as encryption keys before hackers are able to access them.

http://internetofthingsagenda.techtarget.com/blog/IoT-Agenda/IoT-security-is-not-a-check-box

CHIPSEC adds capsule parsing and blacklists ThinkPwn

~ hucktech ~ Leave a comment

CHIPSEC has had a few significant updates recently:

https://github.com/chipsec/chipsec/pull/73

https://github.com/chipsec/chipsec/pull/89

[…] It detects EFI binaries which have the following attributes:
1. GUID A56897A1-A77F-4600-84DB-22B0A801FA9A string of vulnerable UEFI SmmRuntime protocol within the contents of EFI binaries
2. Two names (UI strings) ‘SystemSmmRuntimeRt.efi’ and ‘SmmRuntime’ and two GUIDs 7C79AC8C-5E6C-4E3D-BA6F-C260EE7C172E and A56897A1-A77F-4600-84DB-22B0A801FA9A of vulnerable EFI binaries found in different systems[…]

 

Peter Jones on Secure Boot failures and mitigations

~ hucktech ~ Leave a comment

I just now came across a blog post written by Peter Jones from LAST MONTH on that “Microsoft Secure Boot Golden Key” news reports that is worth reading. Peter owns the Linux shim, so he knows a bit about UEFI’s boot process.

https://blog.uncooperative.org/blog/2016/08/18/secure-boot-failures-and-mitigation/

Especially because I’ve had nearly nothing useful in this blog on this post:

more on Microsoft UEFI Secure Boot golden key news

 

Microsoft UEFI Secure Boot key problem

Also note other articles in Peter’s blog: he makes regular canary posts about the state of his Shim code. I wish all of the boot/firmware code required all contributes to have canaries!

New UEFI Capsule Update and Recovery sample

~ hucktech ~ Leave a comment

Jiewen Yao of Intel checked in a *45-part* patch to the Tianocore project, adding a new UEFi Capsule sample and documentation!

This series patch provides sample on how to do signed capsule update and recovery in EDKII. The feature includes:
1) Define EDKII signed system BIOS capsule format.
2) Provide EDKII signed system BIOS update sample.
3) Provide EDKII signed recovery sample.
4) Provide Microcode update sample for X86 system.
5) Update Quark to use new capsule/recovery solution.
6) Update Vlv2(MinnowMax) to use new capsule/recovery solution.

The signed capsule/recovery solution is in MdeModulePkg. The capsule in IntelFrameworkModulePkg is deprecated. The Microcode update solution is in UefiCpuPkg.

124 files changed, 17848 insertions(+), 384 deletions(-)

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

Reversing Sage’s SmartProbe

~ hucktech ~ Leave a comment

[[UPDATE: see-also: http://bioshacking.blogspot.com/2016/09/down-to-silicon-level-debugging.html ]]

I received the below URL as a Comment on this blog. I know very little about it, but it sounds potentially interesting some of this blog’s readers, maybe. The post is about Sage’s SmartProbe.. I haven’t had a chance to read the code the article points to, please use care.

A Complete Pill for the Sage SmartProbe.
The Sage SmartProbe was a very spiffy “Hard ICE” debugger, one of the few ever manufactured for use with modern (2010s) AMD x86-64 processors, and – as far as I’m aware – the only one ever sold on the mass market, rather than as part of “favourite son” deals (as, e.g., Intel’s, and Arium’s similar products were, and perhaps still are.) Probe (right hand side) and “GizmoBoard” AMD G-series motherboard (left hand side.) Quite a few of these things ended up bundled with various dev boards, saddled with time-limited demo expiration (yes, a time-limited hardware peripheral! don’t ask me…) The vendor perma-re-enabled an expired probe for a small fee. Sage Eng. LLC, it appears, is long dead. Leaving no trace! How and why it died is unknown to me. So now, instead of being unique tools in the development of, e.g., Coreboot, or whatever other attempts at sane utilization of x86-64 iron, the demo probes are stuck in limbo, working as so many peculiar paperweights. This is a crying shame. Now you cannot unbrick the expired probes for any price. (At least not by buying the magic code from the original maker…) So, without further delay, let us get one of these patients onto the operating table:[…]

Dodgy Coder on modern fuzzers