Linux ACPI Time and Alarm Device (TAD) driver

Rafael J. Wysocki of Intel submitted a patch to Linux ACPI for a ACPI Time and Alarm Device (TAD) driver:

Introduce a driver for the ACPI Time and Alarm Device (TAD) based on Section 9.18 of ACPI 6.2. This driver only supports the system wakeup capabilities of the TAD which are mandatory. Support for the RTC capabilities of the TAD will be added to it in the future. This driver is entirely sysfs-based. It provides attributes (under the TAD platform device) to allow user space to manage the AC and DC wakeup timers of the TAD: set and read their values, set and check their expire timer wake policies, check and clear their status and check the capabilities of the TAD reported by AML. The DC timer attributes are only present if the TAD supports a separate DC alarm timer. The wakeup events handling and power management of the TAD is expected to be taken care of by the ACPI PM domain attached to its platform device.

The ACPI Time and Alarm (TAD) device is an alternative to the Real Time Clock (RTC). Its wake timers allow the system to transition from the S3 (or optionally S4/S5) state to S0 state after a time period elapses. In comparison with the RTC Alarm, the TAD provides a larger scale of flexibility in the wake timers. The time capabilities of the TAD maintain the time of day information across platform power transitions, and keep track of time even when the platform is turned off.

More info: linux-acpi list archives, http://vger.kernel.org/majordomo-info.html

https://patchwork.kernel.org/patch/10287043/

Documentation/ABI/testing/sysfs-devices-platform-ACPI-TAD

SOF Project and Project ACRN

https://www.phoronix.com/scan.php?page=news_item&px=Sound-Open-Firmware

https://01.org/blogs/2018/introducing-acrn-and-sound-open-firmware

https://www.sofproject.org/

SOFProject: Sound Open Firmware is an open source audio DSP firmware and SDK that provides audio firmware infrastructure and development tools for developers who are interested in audio or signal processing on modern DSPs

ACRN:  a flexible, lightweight reference hypervisor, built with real-time and safety-criticality in mind, optimized to streamline embedded development through an open source platform

https://projectacrn.org/

add-to-efi.sh – script to add boot entries to native EFI loader

This script allows users and administrators to automatically add their EFISTUB-enabled Linux system to the system’s native EFI bootloader without the need of any additional bootloader. It’s required that all files needed to perform the boot process (e.g. vmlinuz-xxx, initramfs-xxx.img) reside on the EFI system partition, which has to be mounted somewhere. The tool searches for the EFI partition by its partition type, then for installed kernels and finally for suitable initrds (including Intel Microcode). Furthermore, the tool is able to detect if the root filesystem is encrypted and adds appropriate kernel parameters. If you want to use (PART)UUID for booting, this tool will also do.[…]

 

https://github.com/stertingen/add-to-efi.sh

ASUS doesn’t care about Linux [Firmware]

See image in below tweet. A tweet with a bug report about ACPI and TPM2 on ASUS systems.

Linux users: remember that you’re not using a Linux box, you’re using a Windows box, or a Chrome box, and reinstalling an OS, which the OEM doesn’t support, so they won’t be offering you any way to update your firmware with that OS. Unless you’re buying your machine from an OEM that installs Linux. If you are a Linux user, stop buying Windows/Chrome PCs and buy Linux PCs.

https://twitter.com/orionwl/status/968517661704556545

Oracle Solaris 11.4: UEFI Secure Boot on Intel HW

UEFI Secure Boot on Oracle Solaris x86 enables you to install and boot Oracle Solaris on platforms where UEFI Secure Boot is enabled. This feature provides more security by maintaining a chain of trust during boot: digital signatures of the firmware and software are verified before executing the next stage. No break occurs in the chain because of unsigned, corrupt, or rogue firmware or software during the boot process. This feature helps assure that the firmware and software used to boot Oracle Solaris on a hardware platform is correct, and has not been modified or corrupted.

https://docs.oracle.com/cd/E72435_01/html/E72445/grijo.html
https://docs.oracle.com/cd/E37838_01/html/E60974/index.html
https://blogs.oracle.com/solaris/oracle-solaris-114-beta-released
https://github.com/oracle/solaris-userland/tree/master/components/shim
https://www.phoronix.com/scan.php?page=news_item&px=Oracle-Linux-7-Update-4

 

 

Nintendo’s new KDE Linux tablet :-)

Re: https://firmwaresecurity.com/2018/01/16/dumping-the-playstation4-kernel/

https://twitter.com/fail0verflow/status/964954316892119040

https://liliputing.com/2018/02/fail0verflow-turns-a-nintendo-switch-into-a-full-fledged-linux-pc.html

https://www.theverge.com/circuitbreaker/2018/2/19/17029916/nintendo-switch-hack-linux-fail0verflow

https://www.forbes.com/sites/jasonevangelho/2018/02/09/hackers-are-running-linux-on-the-switch-and-claim-nintendo-cant-patch-it/#73bc32eb512c

https://www.nintendo.com/switch/

I have never once considered purchasing a Nintendo Switch …until now. 🙂

 

dtrace for linux; Oracle does the right thing

dtrace for linux; Oracle does the right thing
Posted on February 14, 2018, 11:13.

[…]This changeset integrates DTrace module sources into the main kernel source tree under the GPLv2 license. Sources have been moved to appropriate locations in the kernel tree. That is right, dtrace dropped the CDDL and switched to the GPL![…]

dtrace for linux; Oracle does the right thing

ARM adds Shared Virtual Addressing (SVA) for IOMMU to Linux kernel

Jean-Philippe Brucker of ARM sent a 37-part patch, adding SVA support to Linux kernel, excerpts of announcement below:

Shared Virtual Addressing (SVA) is the ability to share process address spaces with devices. It is called “SVM” (Shared Virtual Memory) by OpenCL and some IOMMU architectures, but since that abbreviation is already used for AMD virtualisation in Linux (Secure Virtual Machine), we prefer the less ambiguous “SVA”. Sharing process address spaces with devices allows to rely on core kernel memory management for DMA, removing some complexity from application and device drivers. After binding to a device, applications can instruct it to perform DMA on buffers obtained with malloc.

The device, buses and the IOMMU must support the following features:
* Multiple address spaces per device, for example using the PCI PASID (Process Address Space ID) extension. The IOMMU driver allocates a PASID and the device uses it in DMA transactions.
* I/O Page Faults (IOPF), for example PCI PRI (Page Request Interface) or Arm SMMU stall. The core mm handles translation faults from the IOMMU.
* MMU and IOMMU implement compatible page table formats.

This series requires to support all three features. I tried to facilitate using only a subset of them but enabling it requires more work. Upcoming patches will enable private PASID management, which allows device driver to use an API similar to classical DMA, map()/unmap() on PASIDs. In the future device drivers should also be able to use SVA without IOPF by pinning all pages, or without PASID by sharing the single device address space with a process. Although we don’t have any performance measurement at the moment, SVA will likely be slower than classical DMA since it relies on page faults, whereas classical DMA pins all pages in memory. SVA mostly aims at simplifying DMA management, but also improves security by isolating address spaces in devices. Intel and AMD IOMMU drivers already offer slightly differing public functions that bind process address spaces to devices. Because they don’t go through an architecture-agnostic API, only integrated devices could use them so far. […]

Full patch:
https://lists.linuxfoundation.org/pipermail/iommu/2018-February/025992.html
More info on IOMMUs:
http://pages.cs.wisc.edu/~basu/isca_iommu_tutorial/index.htm
https://github.com/chipsec/chipsec/blob/master/chipsec/hal/iommu.py
https://www.spinics.net/lists/arm-kernel/msg609771.html
https://www.spinics.net/lists/kernel/msg2651481.html
https://www.spinics.net/lists/kvm/msg148819.html
https://developer.arm.com/products/architecture/a-profile/docs/100940/latest/separation-of-kernel-and-application-virtual-address-spaces
https://software.intel.com/en-us/articles/opencl-20-shared-virtual-memory-overview
https://www.khronos.org/registry/OpenCL/sdk/2.1/docs/man/xhtml/sharedVirtualMemory.html
https://lwn.net/Articles/726606/

Click to access 48882_IOMMU.pdf

https://en.wikipedia.org/wiki/List_of_IOMMU-supporting_hardware
https://software.intel.com/en-us/blogs/2009/03/02/intels-virtualization-for-directed-io-aka-iommu-part-1

 

Linux man pages updated

I’ve released man-pages-4.15. This release resulted from patches, bug reports, reviews, and comments from 26 contributors. Just over 200 commits changed around 75 pages. In addition, 3 new manual pages were added.

http://linux-man-pages.blogspot.com/2018/02/man-pages-415-is-released.html

https://www.kernel.org/pub/linux/docs/man-pages/

LKRG – Linux Kernel Runtime Guard

Linux Kernel Runtime Guard (LKRG) is a loadable kernel module that performs runtime integrity checking of the Linux kernel and detection of security vulnerability exploits against the kernel. As controversial as this concept is, LKRG attempts to post-detect and hopefully promptly respond to unauthorized modifications to the running Linux kernel (integrity checking) or to credentials (such as user IDs) of the running processes (exploit detection). For process credentials, LKRG attempts to detect the exploit and take action before the kernel would grant the process access (such as open a file) based on the unauthorized credentials. There’s a mailing list where you can share your experience with LKRG and ask questions.[…]

http://www.openwall.com/lkrg/

Linux OEMs: support fwupd.org

FWupd.org is a Linux firmware update service, roughly like Windows Update, but for Linux.

https://fwupd.org/
https://github.com/hughsie/fwupd

Building local firmware in fwupd

fwupd hits 1.0.0

It is nice to have a central place for firmware updates, so you don’t have to rely on the tools from a single OEM. Right now, most OEMs force you to use their firmware upedate tools. Windows OEMs mostly don’t bother to use Windows Update. And it looks like that problem is not OS-centric: Linux OEMs mostly don’t bother to use fwupd. However, many Linux vendors are not helping customers with firmware updates, look at second half of this page for all the vendors that suck:

https://fwupd.org/lvfs/vendorlist

It looks like Purism is heading toward supporting fwupd:

https://puri.sm/posts/coreboot-on-the-skylake-librems-part-2/

I am suprised that System76 is going their own route and not supporting fwupd, they claimed they were going to support it, but they’ve gone their own direction, sad.

https://twitter.com/hughsient/status/953375956412108806

https://twitter.com/CassidyJames/status/890610653882269696

https://github.com/system76/firmware-update

Before you buy a system from a Linux OEM, ask them if they support fwupd for firmware updates. If they do not, ask them when they are going to support it.

Thunderbolt talk from LCA2018

From: Joel Wirāmu Pauling <joel@aenertia.net>
Subject: [Thunderbolt-Software] Lca2018 talk
Date: Thu, 25 Jan 2018 15:51:10 +1300
To: thunderbolt-software@lists.01.org

Hi all; I delivered my talk on tb3 (and some other things this morning) at Linuxconf Australasia. I’ve made all my benchmarking tests using flent available (and some dmesg
dumps of crash situations etc) public. Hopefully this of help to someone, and Wellcome feedback.

https://github.com/aenertia/lca2018-talk/tree/talk