Opensource.com: analyzing the Linux boot process

Nice introductory article.

Analyzing the Linux boot process
16 Jan 2018
Alison Chaiken
The oldest joke in open source software is the statement that “the code is self-documenting.” Experience shows that reading the source is akin to listening to the weather forecast: sensible people still go outside and check the sky. What follows are some tips on how to inspect and observe Linux systems at boot by leveraging knowledge of familiar debugging tools. Analyzing the boot processes of systems that are functioning well prepares users and developers to deal with the inevitable failures.[…]

https://opensource.com/article/18/1/analyzing-linux-boot-process

Summary of early kernel boot process.

io386: tool wrapping around ioperm(2), iopl(2), outb(b), etc.

Introduction: A command line tool wrapping around ioperm(2) iopl(2) outb(2), etc.
Where it is needed: Designed for Linux-as-bootloader-payload schemes like Heads, in order to perform low-level IO operations, e.g. triggering SMIs.

https://github.com/hardenedlinux/io386

 

microcode

[Someone just asked me a microcode question, I was digging up some pointers to a microcode tool for someone, ended up cleaning out my browser’s microcode-related bookmarks, and thought I mine as well post a blog entry of the links…]

https://github.com/platomav/MCExtractor
https://www.win-raid.com/t3355f47-Intel-AMD-amp-VIA-CPU-Microcode-Repositories.html#msg45883

https://github.com/RUB-SysSec/Microcode
http://syssec.rub.de/research/publications/microcode-reversing/
see below video:

https://github.com/torvalds/linux/blob/master/Documentation/x86/microcode.txt
https://github.com/torvalds/linux/tree/master/arch/x86/kernel/cpu/microcode

https://community.amd.com/thread/216246
https://en.wikipedia.org/wiki/Microcode
https://linux.die.net/man/8/microcode_ctl
http://manpages.ubuntu.com/manpages/zesty/man8/iucode_tool.8.html
http://manpages.ubuntu.com/manpages/precise/en/man8/microcode_ctl.8.html
http://manpages.ubuntu.com/manpages/precise/en/man8/update-intel-microcode.8.html
https://askubuntu.com/questions/545925/how-to-update-intel-microcode-properly

How to update CPU microcode in Linux


http://www.linuxfromscratch.org/blfs/view/svn/postlfs/firmware.html

Updating microcodes


https://support.mozilla.org/en-US/kb/microcode-update
https://lists.debian.org/debian-security/2016/03/msg00084.html

https://wiki.debian.org/Microcode
https://wiki.gentoo.org/wiki/Intel_microcode
https://wiki.archlinux.org/index.php/microcode

http://blog.fpmurphy.com/2016/12/python-3-utilities-for-parsing-intel-microcode.html

 

DPTFExtract – Linux DPTF Extract Utility

This is a companion tool to Linux Thermal Daemon (thermald). This tool tries to reuse some of the tables used by “Intel ® Dynamic Platform and Thermal Framework (Intel® DPTF)” by converting to the thermal_conf.xml format used by thermald.

https://github.com/intel/dptfxtract

 

 

Embedded Linux Japan Technical Jamboree 63 slides/videos uploaded

Status of Embedded Linux, Tim Bird
Review of ELC Europe 2017, Tim Bird
mplementing state-of-the-art U-Boot port, 2017 edition, by Marek Vasut
Linux カーネルのメモリ管理の闇をめぐる戦い(協力者募集中, Tetsuo Handa (NTT Data)
Request for your suggestions: How to Protect Data in eMMC on Embedded Devices, Gou Nakatsuka (Daikin)
Fuego Status and Roadmap, Tim Bird
Multicast Video-Streaming on Embedded Linux environment, Daichi Fukui (TOSHIBA)
From 1 to many Implementing SMP on OpenRISC, Stafford Horne
Core Partitioning Technique on Multicore Linux systems, Kouta Okamoto (TOSHIBA)
Debian + YoctoProject Based Projects: Collaboration Status, Kazuhiro Hayashi (TOSHIBA)

https://elinux.org/Japan_Technical_Jamboree_63#Agenda

See-also: Septemer 2017 Jamboree 62:

Status of Embedded Linux, Tim Bird
EdgeX Foundry: Introduction and demonstration of end to end IoT system, Victor Duan, Linaro
Lighting Talk: Integration between GitLab and Fuego, Tomohito Esaki, IGEL Co., Ltd.
DebConf17 Report, Kazuhiro Hayashi, TOSHIBA
Lightning Talk : About the LTS now, Shinsuke kato, Panasonic Corporation
Kernel Recipes 2015 – Linux Stable Release process, Greg KH
Lightning Talk: IPv6 Ready Logo Test for LTSI 4.9 and introduction about CVE-2016-5863 and CVE-2017-11164, Fan Xin, Fujitsu Computer Technologies Limited

https://elinux.org/Japan_Technical_Jamboree_62#Agenda

Intel adds ROP-detection Branch Monitoring support to Linux

https://twitter.com/aionescu/status/947990492062420992

https://lwn.net/Articles/738166/

Date: Fri, 3 Nov 2017 11:00:03 -0700

This patchset adds support for Intel’s branch monitoring feature. This feature uses heuristics to detect the occurrence of an ROP(Return Oriented Programming) or ROP like(JOP: Jump oriented programming) attack. These heuristics are based off certain performance monitoring statistics, measured dynamically over a short configurable window period. ROP is a malware trend in which the attacker can compromise a return pointer held on the stack to redirect execution to a different desired instruction. Currently, only the Cannonlake family of Intel processors support this feature. This feature is enabled by CONFIG_PERF_EVENTS_INTEL_BM. Once the kernel is compiled with CONFIG_PERF_EVENTS_INTEL_BM=y on a Cannonlake system, the following perf events are added which can be viewed with perf list:
intel_bm/branch-misp/ [Kernel PMU event]
intel_bm/call-ret/ [Kernel PMU event]
intel_bm/far-branch/ [Kernel PMU event]
intel_bm/indirect-branch-misp/ [Kernel PMU event]
intel_bm/ret-misp/ [Kernel PMU event]
intel_bm/rets/ [Kernel PMU event]

A perf-based kernel driver has been used to monitor the occurrence of one of the 6 branch monitoring events. There are 2 counters that each can select between one of these events for evaluation over a specified instruction window size (0 to 1023). For each counter, a threshold value (0 to 127) can be configured to set a point at which an interrupt is generated. The entire system can monitor a maximum of 2 events(either from the same or different tasks) at any given time. Apart from the kernel driver, this patchset adds CPUID of Cannonlake processors to Intel family list and the Documentation/x86/intel_bm.txt file with some information about Intel Branch monitoring.

The mysterious case of the Linux Page Table Isolation patches

WordPress chokes on this Tumbler.com-based document; please click on the URLs in the below tweets to reach article.

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

The mysterious case of the Linux Page Table Isolation patches

tl;dr: there is presently an embargoed security bug impacting apparently all contemporary CPU architectures that implement virtual memory, requiring hardware changes to fully resolve. Urgent development of a software mitigation is being done in the open and recently landed in the Linux kernel, and a similar mitigation began appearing in NT kernels in November. In the worst case the software fix causes huge slowdowns in typical workloads. There are hints the attack impacts common virtualization environments including Amazon EC2 and Google Compute Engine, and additional hints the exact attack may involve a new variant of Rowhammer.

See-also: https://firmwaresecurity.com/2017/12/07/tu-graz-story-on-rowhammer/

VbiosFinder and rom-parser

VBiosFinder: extract a VBIOS from a BIOS update.

This tool attempts to extract a VBIOS from a bios update.

Dependencies include: UEFIDump and rom-parser.

https://github.com/coderobe/VBiosFinder

—–

UEFIDump, of course, is included with UEFITool. But rom-parser is new to me.

To view ROM contents:
usage: rom-parser [ROM file]

This program does not have support for reading the ROM from pci-sysfs, please do this manually in advance, ex:
cd /sys/bus/pci/devices/0000:01:00.0/
echo 1 > rom
cat rom > /tmp/image.rom
echo 0 > rom

Pass the resulting image file as the argument to this program.
To modify ROM conents:
usage: rom-fixer [ROM file]
Obtain ROM as above, program prompts for modifying ROM vendor and device IDs and invalid checksums.
IMPORTANT: rom-fixer will update the ROM file in place. Make a backup!

https://github.com/awilliam/rom-parser

swsusp2bin: Utility to decompress Linux swsusp hibernation file

Comaeio Technologies has created a new tool to help with Linux forensics:

https://twitter.com/msuiche/status/942985467217268737

swsusp (Software Suspend) is a kernel feature/program which is part of power management framework in the Linux kernel. It’s the default suspend framework as of kernel 3.8. To hibernate the system, type the following at a shell prompt as root: “systemctl hibernate”. This command saves the system state on the hard disk drive and powers off the machine. When you turn the machine back on, the system then restores its state from the saved data without having to boot again. Because the system state is saved on the hard disk and not in RAM, the machine does not have to maintain electrical power to the RAM module, but as a consequence, restoring the system from hibernation is significantly slower than restoring it from suspend mode.[…]

https://github.com/comaeio/swsusp2bin

https://www.comae.io/

Environment variable whitelisting patch for U-Boot

Quentin Schulz of Free Electrons submitted a patch to U-Boot, adding whitelisting of variables, based on a patch by Maxim Ripard of Free Electrons.

[PATCH 00/11] Introduce variables whitelisting in environment

This patch series is based on a patch series from Maxime. This is an RFC. It’s been only tested in a specific use case on a custom i.MX6 board. It’s known to break compilation on a few boards. I have a use case where we want some variables from a first environment to be overriden by variables from a second environment. For example, we want to load variables from the default env (ENV_IS_NOWHERE) and then load only a handful of other variables from, e.g., NAND. In our use case, we basically can be sure that the default env in the U-Boot binary is secure but we want only a few variables to be modified, thus keeping control over the overall behaviour of U-Boot in secure mode. It works in that way:
– from highest to lowest priority, the first environment that can be loaded (that has successfully init and whose load function has returned no errors) will be the main environment,
– then, all the following environment that could be successfully loaded (same conditions as the main environment) are secondary environment. The env variables that are defined both in CONFIG_ENV_VAR_WHITELIST_LIST and in the secondary environments override the ones in the main environment,
– for saving, we save the whole environment to all environments available, be they main or secondary (it does not matter to save the whole environment on secondary environments as only the whitelisted variables will be overriden in the loading process
[…]

[1] https://patchwork.ozlabs.org/cover/842057/

For more info, see full email/patch on:
https://lists.denx.de/listinfo/u-boot

Ubuntu 17.10 corrupting BIOS – many Lenovo laptops models (and Acer and Toshiba)

“Canonical has pulled downloads for its Ubuntu 17.10 Linux distribution following reports that it can trigger a bug in the UEFI firmware of selected Lenovo, Acer, and Toshiba laptops, corrupting the BIOS and disabling the ability to boot from USB Drives.”

https://www.bit-tech.net/news/tech/software/canonical-pulls-ubuntu-1710-over-uefi-corruption-issue/1/

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147

LUV 2.2-rc2 released

Megha Dey of Intel announced the v2.2-rc2 release of LUV, Linux UEFI Validation. Excerpts of announcement below, for full announcement, see LUV mailing list post.

Two main new features:

Dump list of Device-Specific Methods:
DSM (Device Specific Method) as defined in ACPI spec is a control method that enables devices to provide device specific control functions that are consumed by the device driver. DSM’s are optional on a platform and they are optional to be consumed by OS. Both these points mean that a kernel developer might be unaware of these DSM’s and hence might never use them in their device driver. By adding this feature, LUV could be used as a vehicle to educate kernel developers about these DSM’s. A device driver developer, from the list of DSM’s provided by LUV, could then evaluate the usefulness of a DSM and then decide if it needs to be used or left as an option.

Add tests in bits to detect Machine Check Errors:
Machine Check Error (MCE) test is a way to find the errors generated by the hardware or any specific subsystem(s). The value of these tests is that it detects any MCEs that might have occurred before Linux starts to boot. Hence, if detected, they were caused by hardware or possibly BIOS.

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

https://lists.01.org/mailman/listinfo/luv

Debsources: browse/search sources of all Debian releases

Matthieu Caneill of Debian announced Debsources. Excerpt of announcement below, for full announcement, see the debian-devel-announce mailing list archives.

https://twitter.com/zacchiro/status/938327579135807488

Announcing sources.debian.org

We’re happy to announce that Debsources, the Web application that allows to browse and search the entire source code of all Debian releases, is now hosted on the official Debian infrastructure and available at https://sources.debian.org . You may already know this service as previously hosted at sources.debian.net . We took the move to Debian hardware as the opportunity to officially announce it here.[…]

https://sources.debian.org
https://codesearch.debian.net/search?q=firmware
https://codesearch.debian.net/search?q=UEFI
https://codesearch.debian.net/search?q=coreboot

Hmm, “EFI” does not work as a search string, and there are Linux-centric UEFI commands that only use “EFI”, not “UEFI”…

proposal: add Security Version to Linux Shim

Gary Ching-Pang Lin of SuSE has submitted a proposal for Linux kernel and Shim to include a Security Version. In addition to below shim wiki page, there is active discussion on this on the Linux-EFI list.

Security Version

When a vulnerability is found, every distro will release the patch as soon as possible and push it into the update channel. However, since the signature of the old kernel is still valid, the attacker may trick the user to boot the old and insecure kernel to exploit the system. For the system with UEFI Secure Boot, although the admin can add the hashes of the insecure kernels into MokX, it could be burdensome to do this in large scale. Besides, it’s almost impossible to obsolete the kernels before a certain version. Not to mention that the old kernel sometimes might be useful for debugging. To keep the system secure and also flexible, we propose “Security Version”. The basic concept of Security Version is to use a whitelist to record the “version” of the latest known secure linux kernel. If the “version” of the kernel is lower than that in the whitelist, then the kernel is considered as “not secure”. The “version” in the whitelist can only be incremented monotonically unless the user decides to lower it.[…]

https://github.com/lcp/shim/wiki/Security-Version

https://marc.info/?l=linux-efi&m=151246813626512&w=2

PS:  Hmm, Gmane’s linux-efi links aren’t working for me.
http://dir.gmane.org/gmane.linux.kernel.efi

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

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/

Linux Power Management summit

Juri Lelli of Red Hat announced the OSPM-Summit 2018, on the Linux-(pm,acpi,pci,rt-user,kernel) lists. Edited version of that announcement below.

Power Management and Scheduling in the Linux Kernel II edition (OSPM-summit 2018)
April 16-18, 2018
Scuola Superiore Sant’Anna
Pisa, Italy

Deadline for submitting topics/presentations is 9th of December 2017.

Focus: Power management and scheduling techniques to reduce energy consumption while meeting performance and latency requirements are still receiving considerable attention from the Linux Kernel development community. After the success of the first edition, II edition of the Power Management and Scheduling in the Linux Kernel (OSPM) summit aims at replicating such focused discussions, understanding what has been achieved and what instead still remains to be addressed. The summit is organised to cover three days of discussions and talks. Topics:

* Power management techniques
* Real-time and non real-time scheduling techniques
* Energy awareness
* Mobile/Server power management real-world use cases (successes and failures)
* Power management and scheduling tooling (configuration, integration, testing, etc.)
* Tracing
* Recap lightning talks (what has been achieved w.r.t. I edition?)

http://retis.sssup.it/ospm-summit/
https://goo.gl/forms/QHebUBdSWgFeSrKv2
http://retis.sssup.it/ospm-summit/#site
https://goo.gl/maps/2pPXG2v7Lfp
https://docs.google.com/spreadsheets/d/1ZPfASW6zVOM3xQvOrcaDEf1c-Pxi1XnFukVYHHwGUq4/edit?usp=sharing
https://lwn.net/Articles/721573/

Full announcement:
http://vger.kernel.org/majordomo-info.html