Genode 17.11 released, UEFI support

[…]At the platform level, the release unifies the boot concept across all supported x86 microkernels and offers the option to boot 64-bit kernels via UEFI. For both UEFI and legacy boot, Genode consistently uses GRUB2 now.[…]

https://genode.org/documentation/release-notes/17.11
http://genode.org/

Trammell on LinuxBoot (NERF) and Heads

Note that NERF is also called LinuxBoot now.

https://twitter.com/qrs/status/935661801064165377

The NERF project is a collaboration with Ron Minnich at Google (creator of LinuxBIOS and coreboot) that aims to build an open, customizable, and slightly more secure firmware for server machines based on using Linux and Heads in the ROM to replace UEFI as the bootloader. Unlike coreboot, NERF doesn’t attempt to replace the chipset initialization code with opensource. Instead it retains the vendor PEI (Pre-EFI environment) code as well as the signed ACM (authenticated code modules) that Intel provides for establishing the TXT (trusted execution environment). The NERF firmware replaces the DXE (Driver Execution Environment) portion of UEFI with a few open source wrappers, the Linux Kernel and the Heads measured runtime.

https://trmm.net/NERF

https://github.com/osresearch/heads/labels/nerf

https://github.com/osresearch/heads

 

Igor on DAL applets

https://github.com/intel/dynamic-application-loader-host-interface/commit/7b49da96ee2395909d867234c937c7726550c82f

https://github.com/intel/dynamic-application-loader-host-interface

Monotonic Counter in Intel SGX and ME

Some notes on the Monotonic Counter in Intel SGX and ME
Posted on November 10, 2017 by daveti

SGX sealing is vulnerable to rollback attacks as the enclave is not able to tell if the sealed data is the latest or a old copy. To mitigate this attack, monotonic counter (MC) has been introduced in Intel SGX SDK 1.8. This post looks into some implementation details inside Intel SGX SDK.[…]

Some notes on the Monotonic Counter in Intel SGX and ME

a bit more on INTEL-SA-00068 (Intel ME)

Intel has updated the advisory page, I think the doc is at v1.3 now:

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

https://www.intel.com/content/www/us/en/support/articles/000025619/software.html

The list of OEMs is larger now:

Acer
Compulab
Dell Client
Dell Server
Fujitsu
Getac
HP Inc.
HPE Servers
Intel® NUC, Intel® Compute Stick, and Intel® Compute Card: Support Information
Lenovo
MSI
Panasonic
Quanta/QCT

 

 

Western Digital embraces RISC-V

[…]Western Digital’s leadership role in the RISC-V initiative is significant in that it aims to accelerate the advancement of the technology and the surrounding ecosystem by transitioning its own consumption of processors – over one billion cores per year – to RISC-V.[…]

https://www.wdc.com/about-wd/newsroom/press-room/2017-11-28-western-digital-to-accelerate-the-future-of-next-generation-computing-architectures-for-big-data-and-fast-data-environments.html

Apple macOS High Sierra: can login as root with empty password!

https://twitter.com/MagerValp/status/935621178869407750

https://twitter.com/DennisCode/status/935616298683207681

https://twitter.com/a_hailes/status/935601901839806464

OEMs: support Linux firmware updates via fwupd

OEMs: users install Linux on some of the Windows boxes you sell. It is a PITA to update firmware from Linux if you only ship Windows EXEs. Rebooting into an ISO is slightly better. The proper solution for Linux is to support FWUpd.

(And the proper solution for Windows is to support Windows Update. But I heard that only a few OEMs support this, and still require OEM-centric tools to update their firmware. Sigh…)

https://fwupd.org/vendors

Be careful with special characters and BIOS passwords

“So for future reference: Do not set a special symbol as password in your bios. Although it acts like it is correct. It will brick your laptop and this will cost you a new motherboard if you dont find out what the symbol is replaced by.”

https://forums.lenovo.com/t5/ThinkPad-L-R-and-SL-series/Important-TIP-Concerning-bug-with-passwords-set-in-bios/m-p/268696

OEM/IBV — not just Lenovo — better input validation. Try checking for emojiis too. 😦 Int’l characters are likely to also have issues. A bit more error checking will help users from having to buy new mobos to replace their bricks, big impact!

I recently helped an IPMI vendor with a problem where they would not accept punctuation in passwords, because this misread a security FAQ by David Wheeler, and were afraid punctuation would put them at risk of shell injection attacks.

https://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/validation-basics.html

 

Matthew on Intel ME security: worst case here is terrible, but unlikely to be relevant to the vast majority of users

Matthew has an excellent new blog post on recent Intel ME security news.

https://mjg59.dreamwidth.org/49611.html

[…]The big problem at the moment is that we have no idea what the actual process of compromise is. Intel state that it requires local access, but don’t describe what kind. Local access in this case could simply require the ability to send commands to the ME (possible on any system that has the ME drivers installed), could require direct hardware access to the exposed ME (which would require either kernel access or the ability to install a custom driver) or even the ability to modify system flash (possible only if the attacker has physical access and enough time and skill to take the system apart and modify the flash contents with an SPI programmer). The other thing we don’t know is whether it’s possible for an attacker to modify the system such that the ME is persistently compromised or whether it needs to be re-compromised every time the ME reboots. Note that even the latter is more serious than you might think – the ME may only be rebooted if the system loses power completely, so even a “temporary” compromise could affect a system for a long period of time. It’s also almost impossible to determine if a system is compromised. If the ME is compromised then it’s probably possible for it to roll back any firmware updates but still report that it’s been updated, giving admins a false sense of security. The only way to determine for sure would be to dump the system flash and compare it to a known good image. This is impractical to do at scale. So, overall, given what we know right now it’s hard to say how serious this is in terms of real world impact. It’s unlikely that this is the kind of vulnerability that would be used to attack individual end users – anyone able to compromise a system like this could just backdoor your browser instead with much less effort, and that already gives them your banking details. The people who have the most to worry about here are potential targets of skilled attackers, which means activists, dissidents and companies with interesting personal or business data. It’s hard to make strong recommendations about what to do here without more insight into what the vulnerability actually is, and we may not know that until this presentation next month.[…]

Apple SEP story from August, again

[AFAICT nothing new recently, this is just the August story being rehashed again in November, I think…]

Re: https://firmwaresecurity.com/2017/08/17/apple-secure-enclave-processor-sep-firmware-hacked/

https://twitter.com/kwestin/status/934677472293072896

https://www.theiphonewiki.com/wiki/Greensburg_14G60_%28iPhone6,1%29

https://github.com/xerub/img4lib

Arg, WordPress inserts the entire contents of Github Gists into posts. To view sepsplit.c, remove the 2 spaces from below URL, or click on 2nd t.co-based URL in above @xerub tweet.

https://gist. github.com /xerub/0161aacd7258d31c6a27584f90fa2e8c

Click to access us-16-Mandt-Demystifying-The-Secure-Enclave-Processor.pdf

Hackaday:

Apple’s Secure Enclave Processor (SEP) Firmware Decrypted

Halium for Android-IA/Clovertrail+

Ilya Bizyaev posts on the Intel Android-IA mailing list about working to get Halium port of the ASUS ZenFone5:

I am writing to announce that I am working on a Halium (halium.org) port for ASUS ZenFone 5, a Clovertrail+ based phone. Porting Halium base to this Intel platform enables numerous open-source projects, including Ubuntu Touch (ubports.com), Plasma Mobile (plasma-mobile.org), LuneOS (webos-ports.org) and Mer (merproject.org) to use all of the Clovertrail+ devices for development and testing. I am proud to report that as of now, the Halium build system supports using custom Intel boot tools, and the device boasts a stable 3.10 kernel and Android 7.1-based system build that has Wi-Fi, touch sensor, hardware keys, LEDs and vibrator working.

Full post:  android-ia@lists.01.org archives.

https://github.com/Halium/android_kernel_asus_T00F
https://github.com/Halium/android_device_asus_T00F

Hmm, I didn’t know about Halium…

https://halium.org/

https://halium.org/announcements/2017/04/24/halium-is-in-the-air.html

From the Halium blog’s initial post:

Over the years, various efforts have been made to bring GNU/Linux to mobile devices (for example Maemo, Meego, Mer, SailfishOS, Ubuntu Touch, Plasma Mobile). They have either achieved their individual goals or are working in direction of achieving them. During the development of such projects it was suggested multiple times that these communities should work together as their ultimate goal is the same. However due to various reasons this never happened in the past. However we believe that it is time to change this situation. Currently distributions like AsteroidOS, LuneOS, Mer, Plasma Mobile, SailfishOS, and Ubuntu Touch have one thing in common that they use the libhybris to interact with the android binary blobs and they also run the various android daemons using different methods. And there is lot of fragementation on how this task is handled even though these parts don’t need to be different as their essential goal is to make use of android binary blobs. Project Halium is the effort by the community which aims to bring the common grounds for different distributions and have a common base which includes the Linux kernel, Android Hardware Abstraction Layer, and libhybris. Project Halium also aims to standardize the middlewares used to interact with the hardware of the device. By having these parts shared, we believe that it will reduce the fragmentation we have currently.[…]

architecture

 

OEMs: publish your platform firmware hashes [using codehash.db]

Reminder to OEMs: publish the hashes of your platform firmware. Hopefully using codehash.db.

In below twitter thread, Joanna asked Dell support for hashes for their firmware. Eventually, Rick Martinez of Dell got involved, so this is a good example of a conversation on this topic by two who understand the issues.

http://en.community.dell.com/techcenter/extras/m/white_papers/20287278

It looks like Dell needs to use HTTPS:

https://github.com/rootkovska/codehash.db

Linux Plumbers Conference 2017: audio archives uploaded

Quoting the Phoronix post:
talks range from Linux power management and energy awareness to developments around kernel live patching, NUMA, the state of UEFI support, NVMe, DRM/KMS, and other areas of the Linux kernel. “

https://www.linuxplumbersconf.org/2017/ocw/events/LPC2017/schedule

https://www.linuxplumbersconf.org/2017/audio-recordings-posted/

HP Labs: Co-processor-based Behavior Monitoring: Application to the Detection of Attacks Against the SMM

Co-processor-based Behavior Monitoring: Application to the Detection of Attacks Against the System Management Mode
Ronny Chevalier, Maugan Villatel, David Plaquin, Guillaume Hiet
HP Labs
Highly privileged software, such as firmware, is an attractive target for attackers. Thus, BIOS vendors use cryptographic signatures to ensure firmware integrity at boot time. Nevertheless, such protection does not prevent an attacker from exploiting vulnerabilities at runtime. To detect such attacks, we propose an event-based behavior monitoring approach that links to an isolated co-processor. We instrument the code executed on the main CPU to send information about its behavior to the monitor. This information helps to solve the semantic gap issue. Our approach does not depend on a specific model of the behavior nor a specific target. We apply this approach to detect system management mode (SMM), a highly privileged x86 executable mode executing firmware code at runtime. We model the behavior of SMM using CPU registers (CR3 and SMBASE). We have two open-source firmware implementations: EDK II and coreboot. We evaluate the ability to detect and detect the effects of ARM Cortex A5 co-processor. The results show that our solution detects intrusions from the state of the art, without any false positives, while remaining acceptable in terms of performance overhead in the context of the SMM (ie, less than the 150 μs threshold defined by Intel).

https://hal.inria.fr/hal-01634566/