Tag: Linux

ZFS-on-Root-Installer: Install ZFS on Root with Ubuntu

~ hucktech ~ Leave a comment

A Bare Metal Installer for ZFS on Root

This repository is intended to produce a bootable UEFI image that allows installing a full bare system with ZFS disks. Be aware that it is not intended for building dual-boot systems. While you are given the ability to choose which disks are used, the EFI boot system will wipe other OS entries. It uses an Ubuntu kernel and a minimal ramdisk builder to host the scripts used to perform the actual install.[…]

https://github.com/symmetryinvestments/zfs-on-root-installer

 

Inside Microsoft’s Azure Sphere hardware for secure IoT

~ hucktech ~ Leave a comment

Simon BIsson of InfoWorld has an article on Microsoft Azure Sphere, about various security components, and a bit on Sphere OS, their Linux distro.

https://www.infoworld.com/article/3276607/internet-of-things/inside-microsofts-azure-sphere-hardware-for-secure-iot.html#tk.twt_ifw

Pyra (Debian-based gaming console) needs kernel ARM/OMAP experts

~ hucktech ~ Leave a comment

Pyra needs help by kernel and low-level ARM/OMAP experts

W. Martin Borgert posted a message to the Debian kernel/ARM lists, about soliciting kernel dev help for a Debian-based gaming console, successor to OpenPandora.

Borgert quote:

I just read this post by Pyra project leader Michael Mrozek a.k.a. “Evil Dragon”. (Pyra is planned to be a Debian based gaming console, successor of OpenPandora.) They need help by kernel devs and folks who know OMAP etc. Maybe somebody here can help them? There even might be some money in it. No doubt about fame and fun, though!

Evil Dragon quote:

[…]This brings up another important point: Kernel developers! There’s still quite a few things which should be done before the release. We don’t have proper powersaving, the TILER implementation needs to be tidied up, 3D is not yet implemented, Audio needs a better setup, etc. It seems there are less and less kernel developers having the time to work on such things in their spare time. That’s why I decided to hire freelancers to help out as well![…]I know we’ve got quite a lot of OpenSource fans around here. Maybe some know some good kernel developers, who are able to include and improve hardware support and fix various issues. We can provide a test unit as well as the needed datasheets – but it needs someone who is capable of debugging and fixing low-level things.[…]

https://pyra-handheld.com/boards/threads/moving-along.82982/
https://pyra-handheld.com/

 

Linux Kernel Runtime Guard (LKRG) v0.2 released

~ hucktech ~ Leave a comment

The following changes have been made between LKRG 0.1 and 0.2:

*) Add support for being loaded at early boot stage (e.g. from initramfs)
*) [CI] Add a new sysctl to control whether LKRG performs code integrity checks on random events (or only at regular intervals)
*) Reduce performance impact, e.g. in our specific test case:
-> Average cost of running a fully enabled LKRG => 2.5%
-> Average cost of running LKRG without the code integrity checks on random events (disabled with the new sysctl) => 0.7%
*) [CI] Fix a potential deadlock bug caused by get_online_cpus() function, which might sleep if CONFIG_PREEMPT_VOLUNTARY=y
*) [CI] Fix dynamic NOPs injected by *_JUMP_LABEL for MWESTMERE
*) [CI] Remove false positives caused by *_JUMP_LABEL in corner case scenarios
*) [ED] Remove false positives when kernel executes usermode helper binaries

Legend:
[CI] – Code Integrity
[ED] – Exploit Detection

https://www.patreon.com/p_lkrg

http://www.openwall.com/lists/announce/2018/03/27/1

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

 

Polymorphic Linux: stops zero-day attacks like Spectre and Meltdown

~ hucktech ~ Leave a comment

https://twitter.com/Polyverse_io/status/983709488124379145

https://blog.polyverse.io/immunize-against-spectre-78c53985fb01

https://polyverse.io/

fwupd / LVFS and user privacy

~ hucktech ~ Leave a comment

There’s been a few blog posts from the LVFS project and the System76 team regarding firmware updates.

Don’t buy System76 hardware and expect to get firmware updates from the LVFS

System76: System76 and LVFS – what really happened

The latest article is from FOSSpost.org by M.Hanny Sabbagh, which focuses on privacy issues of LVFS, from the last System76 article. While privacy issues are important, don’t forget that firmware update privacy issues exist with ALL other OSes, and LVFS team mentions transition to Linux Foundation for hosting. Most firmware updates come from OEM, so each will have their own CDN/privacy/security issues. I’m hoping the LVFS project gets picked up by the Qubes/TAILS/Subgraph/GNUHardenedLinux or some other privacy/security-centric distro, and can integrate with latest security and privacy techniques, making it Tor-friendly, etc.

See threads here and comments in fosspost.org blog post, and in Twitter feed:

https://lists.debian.org/debian-efi/2018/05/threads.html

https://fosspost.org/analytics/privacy-security-concern-regarding-gnome-software

System76: System76 and LVFS – what really happened

~ hucktech ~ 1 Comment

Re: https://firmwaresecurity.com/2018/05/10/dont-buy-system76-hardware-and-expect-to-get-firmware-updates-from-the-lvfs/ this is the Sytem76 side of the story:

The Future of Firmware

LVFS and UpdateCapsule might be okay for companies mostly focused on a proprietary future (Logitech, Dell, etc.). UpdateCapsule is not the technique companies will use in a future of open source firmware—the future we’re working toward. Liberating firmware is going to be a long and challenging process. Much like Free Software has replaced proprietary software over time, we must chip away at the proprietary firmware pieces within the hardware supply chain. Manufacturing is the first step. This year we’ll manufacture open source desktop designs in our Denver plant. The CAD will be free to download, change, and produce. There will be a separate, open source electrical design and open source firmware daughter board to control functions within the desktop. On a mainboard there is the BIOS chip and one or more embedded controllers that manage fans, keyboard, LEDs, hotkeys and other critical functions. It’s all proprietary. Our strategy is to move this functionality from the proprietary mainboard to the open source daughter board. Then anyone can create a PCB with basic computer functionality, understand how it works, and improve upon the work. One could have this PCB made at Osh Park, install it in their desktop, tune it, and replace a bunch of proprietary firmware instantly. We’ll grow from there. Slowly we’ll chip away at more and more of the mainboard functions until what’s left is Intel and AMD bits. Then there’s the challenge of convincing them to go open. There’s room for cautious optimism.[…]

http://blog.system76.com/post/173801677358/system76-and-lvfs-what-really-happened

Who is working to fix (unify) Linux firmware solutions? UEFI Forum? Linux Foundation? I don’t see a single OEM (eg, System76) driving any such standardization. … 😦

Don’t buy System76 hardware and expect to get firmware updates from the LVFS

~ hucktech ~ 2 Comments

Re: https://firmwaresecurity.com/2018/01/29/linux-oems-support-fwupd-org/

This is a good example of how vendors have vendor-centric tools. Windows Update supports updating firmware, but most Windows OEMs don’t use it. LVFS supports updating firmware on Linux, but most Linux OEMs don’t use it. Sad for users. It seems a bit worse now that UEFI supposedly has a common interface to update firmware, there’s still a problem with UEFI firmware updates. 😦

tl;dr: Don’t buy System76 hardware and expect to get firmware updates from the LVFS

System76 and the LVFS

 

 

Linaro Connect Vancouver BC: CfP open

~ hucktech ~ Leave a comment

 

Call for Proposals: opened 8 May 2018
Deadline to submit proposals: ends 23 July 2018

 

http://connect.linaro.org/cfp/
http://connect.linaro.org/

PS: Resources from last Linaro Connect:

http://connect.linaro.org/hkg18/resources/

EFI-RPM-macros: helps packaging of EFI code into Red Hat RPMs

~ hucktech ~ Leave a comment

efi-rpm-macros provides a set of RPM macros for use in EFI-related packages.

The following variables are meaningful on the make command line:

EFI_ESP_ROOT the directory where the EFI System Partition is mounted
EFI_ARCHES the rpm arches %efi will match on
EFI_VENDOR the vendor name for your EFI System Partition directory

The following rpm macros are set:

%efi the arches that EFI packages should be built on, suitable for use with %ifarch
%efi_vendor the vendor name for your EFI System Partition directory
%efi_esp_root the directory where the EFI system Partition is mounted
%efi_esp_efi the full path to \EFI on the EFI System Partition
%efi_esp_boot the full path to \EFI\BOOT on the EFI System Partition
%efi_esp_dir the full path to your vendor directory on the EFI System Partition
%efi_arch the EFI architecture name, e.g. x64
%efi_arch_upper the EFI architecture name in upper case, e.g. X64

https://github.com/rhboot/efi-rpm-macros

 

postmarketOS: liberating bootloaders and cellular modem firmware of MediaTek phones

~ hucktech ~ Leave a comment

Liberating Bootloaders and Cellular Modem Firmware of MediaTek Phones

As a community project, and one that encourages contributors to work on what they like, we have attracted people with a broad range of interests and skill levels. Recently a small hacking group #postmarketOS-lowlevel has emerged, and its masterminds @McBitter and @unrznbl are eager to introduce you to the madness that awaits when digging deeper and deeper in the embedded hardware and software stack. But before we get started, please keep in mind that these are moon shots. So while there is some little progress, it’s mostly about letting fellow hackers know what we’ve tried and what we’re up to, in the hopes of attracting more interested talent to our cause. After all, our philosophy is to keep the community informed and engaged during the development phase! For those new to postmarketOS, we are a group of developers, hackers, and hobbyists who have come together with a common goal of giving a ten year life cycle to mobile phones. This is accomplished by using a simple and sustainable architecture borrowed from typical Linux distributions, instead of using Android’s build system. The project is at an early stage and isn’t useful for most people at this point. Check out the newly-updated front page for more information, the previous blog post for recent achievements, and the closed pull requests to be informed about what’s going on up to the current minute. Let’s dive in!

https://postmarketos.org/blog/2018/04/14/lowlevel/

https://github.com/postmarketOS/
https://wiki.postmarketos.org/wiki/Devices

 

EFI-CI: Red Hat team’s build CI for EFI-related tools

~ hucktech ~ 1 Comment

This repo contains the tools to build images to run CI for the Red Hat bootloader team’s EFI tools. This build includes all of the dependencies of the build as well as the testing infrastructure, to minimize the time spent per Travis build. Each repo has a .travis.yml will install this docker image, fetch and build any prerequisites, and build that repo using whatever branch travis specifies.

https://github.com/rhboot/efi-ci

Linux UEFI Validation (LUV) v2.3-rc1 released

~ hucktech ~ Leave a comment

Megha Dey of Intel has announced the latest release of LUV, with multiple new features and bugfixes by multiple contributors:

Gayatri Kammela (12), Megha Dey (9), Naresh Bhat (3), Ricardo Neri (22),  Sai Praneeth (5)

It mostly includes updates to yocto, meta-oe, various test suites and kernel version and bug fixes. We have also added a feature to display the severity of failed test cases. Since we had the stable v2.2 release 2 months back, it made sense to have this release as rc1 of v2.3 to allow stabilization towards the next release cycle.

Main new feature: Display the severity of failed test cases In this release, Ricardo submitted 2 patchsets to display the severity of failed test cases. This is a valuable addition as LUV now ships with 7 different test suites. Some test suites include hundreds of test cases. Thus, we could possibly have tens of failed test cases, which can be overwhelming. In order to help users to decide on which failed test cases focus their attention, it is useful to indicate the severity of failed test cases.

See the full announcement for list of bugfixes.

https://download.01.org/linux-uefi-validation/v2.3/
https://lists.01.org/mailman/listinfo/luv

Intel seeks BIOS/UEFI Tools Developer

~ hucktech ~ Leave a comment

BIOS-UEFI Firmware Tools Engineer

As BIOS-UEFI Firmware Tools Engineer you will develop tools and scripts needed for build and test automation infrastructure that is the backbone of the the Continuous Integration process in Intel’s Data Center UEFI firmware BIOS team.[…]

https://jobs.intel.com/ShowJob/Id/1573600/BIOS%20UEFI%20Firmware%20Tools%20Engineer

PS: I need to figure out a way to get some swag/etc from jobs that’re filled via this blog. ;-(

PS: Intel HR: spaces in URLs is generally frowned upon.

 

Matthew Garret on the Linux Kernel Lockdown Patch, and UEFI

~ hucktech ~ Leave a comment

Re: Kernel Lockdown Patch:

Linus on UEFI and Kernel Lockdown patch

Linux kernel lockdown patch

Background for Kernel Lockdown patch

Linux Kernel lockdown

Linux Kernel lockdown

Matthew Garret of Google has a new blog post that gives some background on this patch, w/r/t UEFI:

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

UbootKit: A Worm Attack for the Bootloader of IoT Devices

~ hucktech ~ Leave a comment

https://www.blackhat.com/asia-18/briefings.html#ubootkit-a-worm-attack-for-the-bootloader-of-iot-devices

bootKit: A Worm Attack for the Bootloader of IoT Devices

The security of the IoT has never been so important, especially when millions of devices become parts of everyday life. Most of the IoT devices, however, are vulnerable to cyberattacks, as the hardware resources are limited or the security design is missing during the development. Tencent Anti-Virus Laboratory demonstrates a new worm prototype dubbed UbootKit, which targets the bootloader of IoT devices, to indicate how a worm can propagate between variable devices and why it is difficult to eliminate. UbootKit attack is a kind of manipulation attack against the bootloader, causing infected devices to be remotely controlled and spread malware to other devices. UbootKit is extremely difficult to remove, even by physically pressing the reset button, and is able to attack various kinds of IoT devices with Linux system. A demonstration will be introduced to explain how UbootKit is able to propagate between ARM and MIPS based devices. First, the worm rewrites the bootloader to parasite on the host. Second, the modified bootloader hijacks the start procedure of the Linux kernel in memory. The malicious code in the kernel will download a worm program and execute it with the root privilege. Finally, the downloaded worm program attacks other devices through password scanning or remote execution exploits. The experiment affirms that UbootKit is able to infect real IoT products, such as routers and webcams. Just to clarify, all experiments were restricted in the laboratory environment, and no harmful payload has ever been applied. The reason the UbootKit attack can be launched is that the integrity verification for bootloader is missing for most IoT devices. At the end of the paper, a mitigation solution – which is adding an integrity verification procedure at the on-chip code – is explained to address the vulnerability.

slides:

Click to access asia-18-Yang-UbootKit-A-Worm-Attack-for-the-Bootloader-of-IoT-Devices.pdf

paper:

Click to access asia-18-Yang-UbootKit-A-Worm-Attack-for-the-Bootloader-of-IoT-Devices-wp.pdf