Colin Ian King of Canonical has been packaging up the Intel Thunderbolt user-space software for Ubuntu. His Tweets are private, but he just tweeted that the tool is now in Ubuntu!
Thunderbolt user-space components:
[…]The user-space components implement device approval support:
* Easier interaction with the kernel module for approving connected devices.
* ACL for auto-approving devices white-listed by the user.
So far, I’ve not found a public security page for Thunderbolt. Only a “Fun Facts” page… 😦 I was hoping to find a page listing Thunderstrike, Thunderstrike2, the Legbacore t2e tool, CIA Sonic Screwdriver, PCILeech, etc.
Colin has a new blog post about static source analysis of the Linux kernel:
Static analysis on the Linux kernel
There are a wealth of powerful static analysis tools available nowadays for analyzing C source code. These tools help to find bugs in code by just analyzing the source code without actually having to execute the code. Over that past year or so I have been running the following static analysis tools on linux-next every weekday to find kernel bugs: cppcheck, smatch, sparse, clang scan-build, CoverityScan, and The latest gcc. Typically each tool can take 10-25+ hours of compute time to analyze the kernel source; fortunately I have a large server at hand to do this. The automated analysis creates an Ubuntu server VM, installs the required static analysis tools, clones linux-next and then runs the analysis. The VMs are configured to minimize write activity to the host and run with 48 threads and plenty of memory to try to speed up the analysis process.[…]
Colin Ian King just tweeted about eventstat. But his tweets are protected, so you have to login to Twitter and Follow him in order to see them.
Eventstat periodically dumps out the current kernel event state. It keeps track of current events and outputs the change in events on each output update. The tool requires sudo to run since it needs to write to /proc/timer_stats to start and stop the event monitoring.
Maybe there’ll be a blog post on it shortly, as well.
Matt Fleming sent a message to Linux Kernel/EFI lists with a set of UEFI-centric patches for Linux 4.9. Excerpting his message:
[…]There’s more work on refactoring EFI code to be architecture independent and the largest number of patches is spent cleaning up the EFI memory map code and allowing drivers on x86 to reserve EFI boot services for all of runtime. The architecture independent quest is going pretty well and it was only a couple of lines to get the esrt driver working on arm64. Other than that there’s some cleanups and fixes, and a merge of the out of tree EFI runtime driver from the FWTS project.
* Refactor the EFI memory map code into architecture neutral files and allow drivers to permanently reserve EFI boot services regions on x86, as well as ARM/arm64 – Matt Fleming
* Add ARM support for the EFI esrt driver – Ard Biesheuvel
* Make the EFI runtime services and efivar API interruptible by swapping spinlocks for semaphores – Sylvain Chouleur
* Provide the EFI identity mapping for kexec which allows kexec to work on SGI/UV platforms with requiring the “noefi” kernel command line parameter – Alex Thorlton
* Add debugfs node to dump EFI page tables on arm64 – Ard Biesheuvel
* Merge the EFI test driver being carried out of tree until now in the FWTS project – Ivan Hu
* Expand the list of flags for classifying EFI regions as “RAM” on arm64 so we align with the UEFI spec – Ard Biesheuvel
* Optimise out the EFI mixed mode if it’s unsupported (CONFIG_X86_32) or disabled (CONFIG_EFI_MIXED=n) and switch the early EFI boot services function table for direct calls, alleviating us from having to maintain the custom function table – Lukas Wunner
* Miscellaneous cleanups and fixes
Colin Ian King has written kernelscan, a tool to help parse Linux kernel messages.
[…] The Linux kernel contains lots of error/warning/information messages; over 130,000 in the current 4.7 kernel. One of the tests in the Firmware Test Suite (FWTS) is to find BIOS/ACPI/UEFI related kernel error messages in the kernel log and try to provide some helpful advice on each error message since some can be very cryptic to the untrained eye. The FWTS kernel error log database is currently approaching 800 entries and I have been slowly working through another 800 or so more relevant and recently added messages. Needless to say, this is taking a while to complete. The hardest part was finding relevant error messages in the kernel as they appear in different forms (e.g. printk(), dev_err(), ACPI_ERROR() etc). In order to scrape the Linux kernel source for relevant error messages I hacked up the kernelscan parser to find error messages and dump these to stdout. kernelscan can scan 43,000 source files (17,900,000 lines of source) in under 10 seconds on my Lenovo X230 laptop, so it is relatively fast. […]
Last Friday, Lv Zheng of Intel sent a 5-part patch to the linux-acpi and linux-kernel mailing lists. Below is documentation excerpt from initial patch:
ACPICA / debugger: Add in-kernel AML debugger support
This patchset enables ACPICA debugger for Linux kernel and implements a userspace utility to access it.
A. Build the AML debugger
In order to build the kernel support of AML debugger, the following kconfig items should be enabled:
The userspace tool can be found at tools/power/acpi/tools/acpidbg. To build this utility, staying in tools folder and type “make acpi”.
B. Load the AML debugger during runtime
In order to use the in-kernel AML debugger, the following command should be executed using root user:
# modprobe acpi_dbg
# mount -t debugfs none /sys/kernel/debug
C. Batch mode
In order to support scripts, the userspace utility also supports single command batch mode:
# acpidbg -b “help”
# acpidbg -b “tables”
# acpidbg -b “find _LID”
# acpidbg -b “execute \_SB.LID0._LID”
You can find the documentation about the ACPICA debugger commands in:
(The latest document can be found at https://acpica.org/documentation)
And refer to the chapter – ACPICA debugger reference to obtain the full description of the debugger commands. Note that not all commands are supported by an in-kernel AML debugger.
D. Unload the AML debugger during runtime
After terminating all acpidbg instances, the following command can be executed to remove the AML debugger from kernel:
# rmmod acpi_dbg
The following tasks are not completed:
1. .flush() support in the kernel debugger IO driver.
2. multi-commands batch mode.
3. upstream the userspace acpidbg to the ACPICA upstream.
For more information, see the threads on the linux-kernel and linux-acpi mailing lists, run at vger.kernel.org.