fidzu : Linux

A roundup of stories/articles for weekend reading.

20 May 2018 9:52am GMT

While containers and Kubernetes are among the hottest areas in application deployment, enterprises are still deploying virtual machines and hypervisors. To help support the continued demand for virtualization, Red Hat announced its Red Hat Virtualization 4.2 update on May 15.

20 May 2018 7:57am GMT

Touch-panel systems based on Linux, and to a lesser extent, Android, are gaining share from those that use the still widely used Windows Embedded, and over the past year, several Raspberry Pi based systems have reached market. Here we look at six RPi-based contenders.

20 May 2018 6:03am GMT

KDE Student Programs is happy to present our 2018 Google Summer of Code students to the KDE Community. Students will work on improving KStars for Android. Traditionally, Google Summer of Code starts with an introduction period where students get to know their mentors, after which they start coding. The coding period for 2018 has began on May 14, and will last until August 6. We wish all our students a productive, successful, and fun summer!

20 May 2018 4:08am GMT

In this tutorial, we will show you, how to use the Ubuntu crontab. In a few simple steps, we will explain, how to automate your system tasks on your Ubuntu server, using the crontab in Ubuntu. The cron software utility is a time-based job scheduler in Unix-like operating systems. Cron is driven by a crontab (cron table) file, a configuration file that specifies shell commands to run periodically on a given schedule.

20 May 2018 2:14am GMT

News briefs for May 18, 2018.

20 May 2018 12:20am GMT

In this tutorial, I will show you step-by-step how to install and configure Kubernetes and Docker on CentOS 7. Kubernetes is an open source platform for managing containerized applications developed by Google. It allows you to manage, scale, and automatically deploy your containerized applications in the clustered environment.

19 May 2018 10:25pm GMT

An issue often faced by Ubuntu users after upgrading to a new version is the "no-sound" problem. Luckily, it's a pretty easy problem to resolve.

19 May 2018 8:31pm GMT

Today KDE unveils a beta release of Plasma 5.13.0. Members of the Plasma team have been working hard to continue making Plasma a lightweight and responsive desktop which loads and runs quickly, but remains full-featured with a polished look and feel.

19 May 2018 6:37pm GMT

In 2018 media such as CD's and DVD's have almost died out, with USB drives holding more capacity and being produced relatively cheaply. This means it makes more sense and is better value to use USB drives in place of CD's or DVD's.This article looks at how to create a bootable USB drives for various uses.

19 May 2018 4:42pm GMT

The Lubuntu development team promised to finally switch from LXDE (Lightweight X11 Desktop Environment) to the more modern and actively maintained LXQt (Lightweight Qt Desktop Environment), and the switch is now official.

19 May 2018 2:48pm GMT

Running Android is not just for tech nerds, it also saves battery life and gives you access to applications only available to Android. Note that many applications check if you have a full phone and refuses to run on anything else than real device. This tutorial will show you how to dual boot Android and Linux.

19 May 2018 12:53pm GMT

The Raspberry Pi 3 and RPi 3 Compute Module are quickly expanding into the industrial touch-panel market. Here's a guide to six RPi-based contenders. In the smart home, voice agents are increasingly replacing the smartphone touchscreen interface as the primary human-machine interface (HMI). Yet, in noisier industrial and retail IoT environments, touchscreens are usually the […]

19 May 2018 10:59am GMT

Like ARM processors, the U540 sips power, and they already seem capable of doing the type of heavy lifting required of servers. Sherwani told us it would be years before that's possible, but this year two Linux distributions, Debian and Red Hat's Fedora, have been ported to run on the architecture.

19 May 2018 9:05am GMT

Regular expressions can be one of the most powerful tools in your toolbox as a Linux user, system administrator, or even as a programmer. It can also be one of the most daunting things to learn, but it doesn't have to be! While there are an infinite number of ways to write an expression, you don't have to learn every single switch and flag. In this short how-to, I'll show you a few simple ways to use regex that will have you running in no time and share some follow-up resources that will make you a regex master if you want to be.read more

19 May 2018 7:10am GMT

News briefs for May 17, 2018.

19 May 2018 5:16am GMT

HowToForge: Learn how to install and configure Kubernetes and Docker on CentOS 7

18 May 2018 10:00pm GMT

ostechnix: GNU Ncurses is a programming library that allows the users to write text-based user interfaces(TUI).

18 May 2018 9:00pm GMT

GamingOnLinux: This is great, not long after the rather good release of Horizon Chase Turbo, we have another retro-inspired racer with Slipstream.

18 May 2018 8:00pm GMT

ScribblesAndSnaps: For someone who doesn't write code for a living, creating even the simplest Android app can be a daunting proposition.

18 May 2018 7:00pm GMT

These shortcuts allow you to easily and in a fast manner, perform certain activities such as accessing and running previously executed commands

18 May 2018 6:00pm GMT

LinuxConfig: Learn how to reset the lost root or user password on Ubuntu 18.04 Bionic Beaver Linux.

18 May 2018 5:00pm GMT

opensource.com: Every website has a unique, public IP address that can be reached by anyone and from anywhere.

18 May 2018 4:00pm GMT

LinuxUprising: The Gnome Shell Dash to Panel extension combines the Dash with the top Gnome panel.

18 May 2018 3:00pm GMT

Tecmint: When you compile a custom kernel module such as device driver on a CentOS system, you need to have kernel header files installed on the system

18 May 2018 2:00pm GMT

Not being a native speaker, I get amusing results sometimes when searching on Amazon. For example, "floor scoop" brings up mostly fancy dresses. Apparently, a scoop is a type of dress, which can be floor-length, and so. The correct request is actually "dust pan". Today though, searching for "Peliton termite" ended with a bunch of bicycle saddles. Apparently, Amazon force-replaced it with "peloton", and I know of no syntax to force my spelling. I suspect that Peliton may have trouble selling their products at Amazon. This sort of thing is making me wary of Alexa. I don't see myself ever winning an argument with a robot who knows better, and is implemented in proprietary software that I cannot adjust.

17 May 2018 5:48pm GMT

Today, I want to build a satellite that receives ADS-B signals from airplanes over the open ocean, far away from land. With a decent receiver and a simple antenna, it should be possible on a gravity-stabilized cubesat. I know about terrestrial receivers picking signals 200..300 km out, surely with care one can do better. But I highly doubt that it's possible to finance such a toy - unless someone has already done that. I know that people somehow manage to finance AIS receivers, which are basically the same thing, only for ships. How do they do that?

09 May 2018 3:27am GMT

07 May 2018 5:53pm GMT

I've released man-pages-4.16. The release tarball is available on kernel.org. The browsable online pages can be found on man7.org. The Git repository for man-pages is available on kernel.org.

This release resulted from patches, bug reports, reviews, and comments from 29 contributors. Somewhat more than 160 commits changed around 60 pages. A summary of the changes can be found here.

30 Apr 2018 7:28pm GMT

29 Apr 2018 8:52pm GMT

My father got himself in a nice trap: he let his Lenovo notebook to update to Windows 10. Hard to blame him, as user interface was confusing on purpose.Now 2 out of 3 USB ports are non-functional (USB 2 port works USB 3 ports don't), and there's no way to fix that. And apparently, Microsoft knew about the problem. Congratulations, Microsoft...

29 Apr 2018 8:50pm GMT

Just because you are paying for internet service does not mean O2 will not try to replace web-pages with advertising. Ouch. Seems like everyone needs to use https, we need better network-neutrality laws, and probably also class-action lawsuits.

29 Apr 2018 8:45pm GMT

Got Jolla installed. Ok, it looks cool. But already some unnice things can be seen. You _need_ jolla account to install apps. You need to agree to nasty legaleese. You are asked for name and password, it looks like that's all, and then it wants to know real name, email address, birthday... Appstore looks cool... but does not list licenses for software being installed. Still better than Android. Miles away from Debian.

29 Apr 2018 8:43pm GMT

23.4.2018, around 12:34... I realized how unix ttys are sabotaging my attempts to send SMS.. and solved it. So now I have Motorola Droid 4, running 4.17-rc1 kernel, with voice calls working, SMSes, data connection, GPS working and have some basic GUIs to control the stuff. WIFI works. Screen locks, and keyboard map still could be improved. Battery life will probably will not be great. But hey, its a start -- I have GNU/Linux working on a cellphone. More precisely Maemo Leste, based on Devuan, based on Debian. Sure, some kernel patches are still needed, and there's a lot more work to do in userland... Today, Microsoft sold out last Windows Mobile phones. I guess that's just a coincidence.

29 Apr 2018 8:40pm GMT

Oh Microsoft, you card:

[Azure Sphere OS] combines security innovations pioneered in Windows, a security monitor, and a custom Linux kernel [...]</p>

Kinda like Oracle shipping "Unbreakable Linux". Still in the "embrace" phase.

23 Apr 2018 6:37pm GMT

As part of preparing my last two talks at LCA on the kernel community, "Burning Down the Castle" and "Maintainers Don't Scale", I have looked into how the Kernel's maintainer structure can be measured. One very interesting approach is looking at the pull request flows, for example done in the LWN article "How 4.4's patches got to the mainline". Note that in the linux kernel process, pull requests are only used to submit development from entire subsystems, not individual contributions. What I'm trying to work out here isn't so much the overall patch flow, but focusing on how maintainers work, and how that's different in different subsystems.

Methodology

In my presentations I claimed that the kernel community is suffering from too steep hierarchies. And worse, the people in power don't bother to apply the same rules to themselves as anyone else, especially around purported quality enforcement tools like code reviews.

For our purposes a contributor is someone who submits a patch to a mailing list, but needs a maintainer to apply it for them, to get the patch merged. A maintainer on the other hand can directly apply a patch to a subsystem tree, and will then send pull requests up the maintainer hierarchy until the patch lands in Linus' tree. This is relatively easy to measure accurately in git: If the recorded patch author and committer match, it's a maintainer self-commit, if they don't match it's a contributor commit.

There's a few annoying special cases to handle:

• Some people use different email addresses or spellings, and sometimes MTAs, patchwork and other tools used in the patch flow chain mangle things further. This could be fixed up with the mail mapping database that LWN for example uses to generate its contributor statistics. Since most maintainers have reasonable setups it doesn't seem to matter much, hence I decided not to bother.

• There are subsystems not maintained in git, but in the quilt patch management system. Andrew Morton's tree is the only one I'm aware of, and I hacked up my scripts to handle this case. After that I realized it doesn't matter, since Andrew merged exceedingly few of his own patches himself, most have been fixups that landed through other trees.

Also note that this is a property of each commit - the same person can be both a maintainer and a contributor, depending upon how each of their patches gets merged.

The ratio of maintainer self-commits compared to overall commits then gives us a crude, but fairly useful metric to measure how steep the kernel community overall is organized.

Measuring review is much harder. For contributor commits review is not recorded consistently. Many maintainers forgo adding an explicit Reviewed-by tag since they're adding their own Signed-off-by tag anyway. And since that's required for all contributor commits, it's impossible to tell whether a patch has seen formal review before merging. A reasonable assumption though is that maintainers actually look at stuff before applying. For a minimal definition of review, "a second person looked at the patch before merging and deemed the patch a good idea" we can assume that merged contributor patches have a review ratio of 100%. Whether that's a full formal review or not can unfortunately not be measured with the available data.

A different story is maintainer self-commits - if there is no tag indicating review by someone else, then either it didn't happen, or the maintainer felt it's not important enough work to justify the minimal effort to record it. Either way, a patch where the git author and committer match, and which sports no review tags in the commit message, strongly suggests it has indeed seen none.

An objection would be that these patches get reviewed by the next maintainer up, when the pull request gets merged. But there's well over a thousand such patches each kernel release, and most of the pull requests containing them go directly to Linus in the 2 week long merge window, when the over 10k feature patches of each kernel release land in the mainline branch. It is unrealistic to assume that Linus carefully reviews hundreds of patches himself in just those 2 weeks, while getting hammered by pull requests all around. Similar considerations apply at a subsystem level.

For counting reviews I looked at anything that indicates some kind of patch review, even very informal ones, to stay consistent with the implied oversight the maintainer's Signed-off-by line provides for merged contributor patches. I therefore included both Reviewed-by and Acked-by tags, including a plethora of misspelled and combined versions of the same.

The scripts also keep track of how pull requests percolate up the hierarchy, which allows filtering on a per-subsystem level. Commits in topic branches are accounted to the subsystem that first lands in Linus' tree. That's fairly arbitrary, but simplest to implement.

Last few years of GPU subsystem history

Since I've pitched the GPU subsystem against the kernel at large in my recent talks, let's first look at what things look like in graphics:

Fig. 1 GPU total commits, maintainer self-commits and reviewed maintainer self-commits Fig. 2 GPU percentage maintainer self-commits and reviewed maintainer self-commits

In absolute numbers it's clear that graphics has grown tremendously over the past few years. Much faster than the kernel at large. Depending upon the metric you pick, the GPU subsystem has grown from being 3% of the kernel to about 10% and now trading spots for 2nd largest subsystem with arm-soc and staging (depending who's got a big pull for that release).

Maintainer commits keep up with GPU subsystem growth

The relative numbers have a different story. First, commit rights and the fairly big roll out of group maintainership we've done in the past 2 years aren't extreme by historical graphics subsystem standards. We've always had around 30-40% maintainer self-commits. There's a bit of a downward trend in the years leading towards v4.4, due to the massive growth of the i915 driver, and our failure to add more maintainers and committers for a few releases. Adding lots more committers and creating bigger maintainer groups from v4.5 on forward, first for the i915 driver, then to cope with the influx of new small drivers, brought us back to the historical trend line.

There's another dip happening in the last few kernels, due to AMD bringing in a big new team of contributors to upstream. v4.15 was even more pronounced, in that release the entirely rewritten DC display driver for AMD GPUs landed. The AMD team is already using a committer model for their staging and internal trees, but not (yet) committing directly to their upstream branch. There's a few process holdups, mostly around the CI flow, that need to be fixed first. As soon as that's done I expect this recent dip will again be over.

In short, even when facing big growth like the GPU subsystem has, it's very much doable to keep training new maintainers to keep up with the increased demand.

Review of maintainer self-commits established in the GPU subsystem

Looking at relative changes in how consistently maintainer self-commits are reviewed, there's a clear growth from mostly no review to 80+% of all maintainer self-commits having seen some formal oversight. We didn't just keep up with the growth, but scaled faster and managed to make review a standard practice. Most of the drivers, and all the core code, are now consistently reviewed. Even for tiny drivers with small to single person teams we've managed to pull this off, through combining them into larger teams run with a group maintainership model.

Last few years of kernel w/o GPU history

Fig. 3 kernel w/o GPU maintainer self-commits and reviewed maintainer self-commits Fig. 4 kernel w/o GPU percentage maintainer self-commits and reviewed maintainer self-commits

Kernel w/o graphics is an entirely different story. Overall, review is much less a thing that happens, with only about 30% of all maintainer self-commits having any indication of oversight. The low ratio of maintainer self-commits is why I removed the total commit number from the absolute graph - it would have dwarfed the much more interesting data on self-commits and reviewed self-commits. The positive thing is that there's at least a consistent, if very small upward trend in maintainer self-commit reviews, both in absolute and relative numbers. But it's very slow, and will likely take decades until there's no longer a double standard on review between contributors and maintainers.

Maintainers are not keeping up with the kernel growth overall

Much more worrying is the trend on maintainer self-commits. Both in absolute, and much more in relative numbers, there's a clear downward trend, going from around 25% to below 15%. This indicates that the kernel community fails to mentor and train new maintainers at a pace sufficient to keep up with growth. Current maintainers are ever more overloaded, leaving ever less time for them to write patches of their own and get them merged.

Naively extrapolating the relative trend predicts that around the year 2025 large numbers of kernel maintainers will do nothing else than be the bottleneck, preventing everyone else from getting their work merged and not contributing anything of their own. The kernel community imploding under its own bureaucratic weight being the likely outcome of that.

This is a huge contrast to the "everything is getting better, bigger, and the kernel community is very healthy" fanfare touted at keynotes and the yearly kernel report. In my opinion, the kernel community is very much not looking like it is coping with its growth well and an overall healthy community. Even when ignoring all the issues around conduct that I've raised.

It is also a huge contrast to what we've experienced in the GPU subsystem since aggressively rolling out group maintainership starting with the v4.5 release; by spreading the bureaucratic side of applying patches over many more people, maintainers have much more time to create their own patches and get them merged. More crucially, experienced maintainers can focus their limited review bandwidth on the big architectural design questions since they won't get bogged down in the minutiae of every single simple patch.

4.16 by subsystem

Let's zoom into how this all looks at a subsystem level, looking at just the recently released 4.16 kernel.

Most subsystems have unsustainable maintainer ratios

Trying to come up with a reasonable list of subsystems that have high maintainer commit ratios is tricky; some rather substantial pull requests are essentially just maintainers submitting their own work, giving them an easy 100% score. But of course that's just an outlier in the larger scope of the kernel overall having a maintainer self-commit ratio of just 15%. To get a more interesting list of subsystems we need to look at only those with a group of regular contributors and more than just 1 maintainer. A fairly arbitrary cut-off of 200 commits or more in total seems to get us there, yielding the following top ten list:

In short there's very few places where it's easier to become a maintainer than in the already rather low, roughly 15%, the kernel scores overall. Outside of these few subsystems, the only realistic way is to create a new subsystem, somehow get it merged, and become its maintainer. In most subsystems being a maintainer is an elite status, and the historical trends suggest it will only become more so. If this trend isn't reversed, then maintainer overload will get a lot worse in the coming years.

Of course subsystem maintainers are expected to spend more time reviewing and managing other people's contribution. When looking at individual maintainers it would be natural to expect a slow decline in their own contributions in patch form, and hence a decline in self-commits. But below them a new set of maintainers should grow and receive mentoring, and those more junior maintainers would focus more on their own work. That sustainable maintainer pipeline seems to not be present in many kernel subsystems, drawing a bleak future for them.

Much more interesting is the review statistics, split up by subsystem. Again we need a cut-off for noise and outliers. The big outliers here are all the pull requests and trees that have seen zero review, not even any Acked-by tags. As long as we only look at positive examples we don't need to worry about those. A rather low cut-off of at least 10 maintainer self-commits takes care of other random noise:

Yes, XFS and f2fs have their shit together. More interesting is how wide the spread in the filesystem code is; there's a bunch of substantial fs pulls with a review ratio of flat out zero. Not even a single Acked-by. XFS on the other hand insists on full formal review of everything - I spot checked the history a bit. f2fs is a bit of an outlier with 4.16, barely getting above the cut-off. Usually it has fewer patches and would have been excluded.

Everyone not in the top ten taken together has a review ratio of 27%.

Review double standards in many big subsystems

Looking at the big subsystems with multiple maintainers and huge groups of contributors - I picked 500 patches as the cut-off - there's some really low review ratios: Staging has 7%, networking 9% and tip scores 10%. Only arm-soc is close to the top ten, with 50%, at the 14th position.

Staging having no standard is kinda the point, but the other core subsystems eschewing review is rather worrisome. More than 9 out of 10 maintainer self-commits merged into these core subsystem do not carry any indication that anyone else ever looked at the patch and deemed it a good idea. The only other subsystem with more than 500 commits is the GPU subsystem, at 4th position with a 83% review ratio.

Compared to maintainers overall the review situation is looking a lot less bleak. There's a sizeable group of subsystems who at least try to make this work, by having similar review criteria for maintainer self-commits than normal contributors. This is also supported by the rather slow, but steady overall increase of reviews when looking at historical trend.

But there's clearly other subsystems where review only seems to be a gauntlet inflicted on normal contributors, entirely optional for maintainers themselves. Contributors cannot avoid review, because they can't commit their own patches. When maintainers outright ignore review for most of their patches this creates a clear double standard between maintainers and mere contributors.

One year ago I wrote "Review, not Rocket Science" on how to roll out review in your subsystem. Looking at this data here I can close with an even shorter version:

What would Dave Chinner do?

Thanks a lot to Daniel Stone, Dave Chinner, Eric Anholt, Geoffrey Huntley, Luce Carter and Sean Paul for reading and commenting on drafts of this article.

23 Apr 2018 12:00am GMT

I spent some time yesterday building out a UEFI server that didn't have on-board hardware RAID for its system drives. In these situations, I always use Linux's md RAID1 for the root filesystem (and/or /boot). This worked well for BIOS booting since BIOS just transfers control blindly to the MBR of whatever disk it sees (modulo finding a "bootable partition" flag, etc, etc). This means that BIOS doesn't really care what's on the drive, it'll hand over control to the GRUB code in the MBR.

With UEFI, the boot firmware is actually examining the GPT partition table, looking for the partition marked with the "EFI System Partition" (ESP) UUID. Then it looks for a FAT32 filesystem there, and does more things like looking at NVRAM boot entries, or just running BOOT/EFI/BOOTX64.EFI from the FAT32. Under Linux, this .EFI code is either GRUB itself, or Shim which loads GRUB.

So, if I want RAID1 for my root filesystem, that's fine (GRUB will read md, LVM, etc), but how do I handle /boot/efi (the UEFI ESP)? In everything I found answering this question, the answer was "oh, just manually make an ESP on each drive in your RAID and copy the files around, add a separate NVRAM entry (with efibootmgr) for each drive, and you're fine!" I did not like this one bit since it meant things could get out of sync between the copies, etc.

The current implementation of Linux's md RAID puts metadata at the front of a partition. This solves more problems than it creates, but it means the RAID isn't "invisible" to something that doesn't know about the metadata. In fact, mdadm warns about this pretty loudly:

# mdadm --create /dev/md0 --level 1 --raid-disks 2 /dev/sda1 /dev/sdb1 mdadm: Note: this array has metadata at the start and may not be suitable as a boot device. If you plan to store '/boot' on this device please ensure that your boot-loader understands md/v1.x metadata, or use --metadata=0.90

Reading from the mdadm man page:

-e, --metadata= ... 1, 1.0, 1.1, 1.2 default Use the new version-1 format superblock. This has fewer restrictions. It can easily be moved between hosts with different endian-ness, and a recovery operation can be checkpointed and restarted. The different sub-versions store the superblock at different locations on the device, either at the end (for 1.0), at the start (for 1.1) or 4K from the start (for 1.2). "1" is equivalent to "1.2" (the commonly preferred 1.x format). "default" is equivalent to "1.2".

First we toss a FAT32 on the RAID (mkfs.fat -F32 /dev/md0), and looking at the results, the first 4K is entirely zeros, and file doesn't see a filesystem:

# dd if=/dev/sda1 bs=1K count=5 status=none | hexdump -C 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00001000 fc 4e 2b a9 01 00 00 00 00 00 00 00 00 00 00 00 |.N+.............| ... # file -s /dev/sda1 /dev/sda1: Linux Software RAID version 1.2 ...

So, instead, we'll use --metadata 1.0 to put the RAID metadata at the end:

# mdadm --create /dev/md0 --level 1 --raid-disks 2 --metadata 1.0 /dev/sda1 /dev/sdb1 ... # mkfs.fat -F32 /dev/md0 # dd if=/dev/sda1 bs=1 skip=80 count=16 status=none | xxd 00000000: 2020 4641 5433 3220 2020 0e1f be77 7cac FAT32 ...w|. # file -s /dev/sda1 /dev/sda1: ... FAT (32 bit)

Now we have a visible FAT32 filesystem on the ESP. UEFI should be able to boot whatever disk hasn't failed, and grub-install will write to the RAID mounted at /boot/efi.

However, we're left with a new problem: on (at least) Debian and Ubuntu, grub-install attempts to run efibootmgr to record which disk UEFI should boot from. This fails, though, since it expects a single disk, not a RAID set. In fact, it returns nothing, and tries to run efibootmgr with an empty -d argument:

Installing for x86_64-efi platform. efibootmgr: option requires an argument -- 'd' ... grub-install: error: efibootmgr failed to register the boot entry: Operation not permitted. Failed: grub-install --target=x86_64-efi WARNING: Bootloader is not properly installed, system may not be bootable

Luckily my UEFI boots without NVRAM entries, and I can disable the NVRAM writing via the "Update NVRAM variables to automatically boot into Debian?" debconf prompt when running: dpkg-reconfigure -p low grub-efi-amd64

So, now my system will boot with both or either drive present, and updates from Linux to /boot/efi are visible on all RAID members at boot-time. HOWEVER there is one nasty risk with this setup: if UEFI writes anything to one of the drives (which this firmware did when it wrote out a "boot variable cache" file), it may lead to corrupted results once Linux mounts the RAID (since the member drives won't have identical block-level copies of the FAT32 any more).

To deal with this "external write" situation, I see some solutions:

• Make the partition read-only when not under Linux. (I don't think this is a thing.)
• Create higher-level knowledge of the root-filesystem RAID configuration is needed to keep a collection of filesystems manually synchronized instead of doing block-level RAID. (Seems like a lot of work and would need redesign of /boot/efi into something like /boot/efi/booted, /boot/efi/spare1, /boot/efi/spare2, etc)
• Prefer one RAID member's copy of /boot/efi and rebuild the RAID at every boot. If there were no external writes, there's no issue. (Though what's really the right way to pick the copy to prefer?)

Since mdadm has the "--update=resync" assembly option, I can actually do the latter option. This required updating /etc/mdadm/mdadm.conf to add <ignore> on the RAID's ARRAY line to keep it from auto-starting:

ARRAY <ignore> metadata=1.0 UUID=123...

(Since it's ignored, I've chosen /dev/md100 for the manual assembly below.) Then I added the noauto option to the /boot/efi entry in /etc/fstab:

/dev/md100 /boot/efi vfat noauto,defaults 0 0

And finally I added a systemd oneshot service that assembles the RAID with resync and mounts it:

[Unit] Description=Resync /boot/efi RAID DefaultDependencies=no After=local-fs.target [Service] Type=oneshot ExecStart=/sbin/mdadm -A /dev/md100 --uuid=123... --update=resync ExecStart=/bin/mount /boot/efi RemainAfterExit=yes [Install] WantedBy=sysinit.target

(And don't forget to run "update-initramfs -u" so the initramfs has an updated copy of /dev/mdadm/mdadm.conf.)

If mdadm.conf supported an "update=" option for ARRAY lines, this would have been trivial. Looking at the source, though, that kind of change doesn't look easy. I can dream!

And if I wanted to keep a "pristine" version of /boot/efi that UEFI couldn't update I could rearrange things more dramatically to keep the primary RAID member as a loopback device on a file in the root filesystem (e.g. /boot/efi.img). This would make all external changes in the real ESPs disappear after resync. Something like:

# truncate --size 512M /boot/efi.img # losetup -f --show /boot/efi.img /dev/loop0 # mdadm --create /dev/md100 --level 1 --raid-disks 3 --metadata 1.0 /dev/loop0 /dev/sda1 /dev/sdb1

And at boot just rebuild it from /dev/loop0, though I'm not sure how to "prefer" that partition…

© 2018, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

20 Apr 2018 12:34am GMT

Liferea irritated me for many years with a strange behavior when dragging a subscription. You mouse down on the feed, it becomes selected - so far so good. Then you drag it somewhere - possibly far off screen, making the view scroll - then drop it. Drops fine, updates the DB, model, and the view fine. But! The selection then jumps to a completely random feed somewhere.

Well, it's not actually random. What happens instead, the GtkTreeView implements DnD by removing a row, then re-inserting it. When a selected row is removed, obviously the selection has to disappear, but instead it's set to the next row after the removed one. I suppose I may be uniquely vulnerable to this because I have 300+ feeds and I drag them around all the time. If Liferea weren't kind enough to remember the preferred order, this would not matter so much.

I meant to fix this for a long time, but somehow a wrong information got stuck in my head: I thought that Liferea was written in C++, so it took years to gather the motivation. Imagine my surprise when I found plain old C. I spent a good chunk of Sunday figuring out GTK's tree view thingie, but in the end it was quite simple.

16 Apr 2018 3:09pm GMT

Previously: v4.15

Linux kernel v4.16 was released last week. I really should write these posts in advance, otherwise I get distracted by the merge window. Regardless, here are some of the security things I think are interesting:

KPTI on arm64

Will Deacon, Catalin Marinas, and several other folks brought Kernel Page Table Isolation (via CONFIG_UNMAP_KERNEL_AT_EL0) to arm64. While most ARMv8+ CPUs were not vulnerable to the primary Meltdown flaw, the Cortex-A75 does need KPTI to be safe from memory content leaks. It's worth noting, though, that KPTI does protect other ARMv8+ CPU models from having privileged register contents exposed. So, whatever your threat model, it's very nice to have this clean isolation between kernel and userspace page tables for all ARMv8+ CPUs.

hardened usercopy whitelisting
While whole-object bounds checking was implemented in CONFIG_HARDENED_USERCOPY already, David Windsor and I finished another part of the porting work of grsecurity's PAX_USERCOPY protection: usercopy whitelisting. This further tightens the scope of slab allocations that can be copied to/from userspace. Now, instead of allowing all objects in slab memory to be copied, only the whitelisted areas (where a subsystem has specifically marked the memory region allowed) can be copied. For example, only the auxv array out of the larger mm_struct.

As mentioned in the first commit from the series, this reduces the scope of slab memory that could be copied out of the kernel in the face of a bug to under 15%. As can be seen, one area of work remaining are the kmalloc regions. Those are regularly used for copying things in and out of userspace, but they're also used for small simple allocations that aren't meant to be exposed to userspace. Working to separate these kmalloc users needs some careful auditing.

Total Slab Memory: 48074720 Usercopyable Memory: 6367532 13.2% task_struct 0.2% 4480/1630720 RAW 0.3% 300/96000 RAWv6 2.1% 1408/64768 ext4_inode_cache 3.0% 269760/8740224 dentry 11.1% 585984/5273856 mm_struct 29.1% 54912/188448 kmalloc-8 100.0% 24576/24576 kmalloc-16 100.0% 28672/28672 kmalloc-32 100.0% 81920/81920 kmalloc-192 100.0% 96768/96768 kmalloc-128 100.0% 143360/143360 names_cache 100.0% 163840/163840 kmalloc-64 100.0% 167936/167936 kmalloc-256 100.0% 339968/339968 kmalloc-512 100.0% 350720/350720 kmalloc-96 100.0% 455616/455616 kmalloc-8192 100.0% 655360/655360 kmalloc-1024 100.0% 812032/812032 kmalloc-4096 100.0% 819200/819200 kmalloc-2048 100.0% 1310720/1310720

This series took quite a while to land (you can see David's original patch date as back in June of last year). Partly this was due to having to spend a lot of time researching the code paths so that each whitelist could be explained for commit logs, partly due to making various adjustments from maintainer feedback, and partly due to the short merge window in v4.15 (when it was originally proposed for merging) combined with some last-minute glitches that made Linus nervous. After baking in linux-next for almost two full development cycles, it finally landed. (Though be sure to disable CONFIG_HARDENED_USERCOPY_FALLBACK to gain enforcement of the whitelists - by default it only warns and falls back to the full-object checking.)

automatic stack-protector

While the stack-protector features of the kernel have existed for quite some time, it has never been enabled by default. This was mainly due to needing to evaluate compiler support for the feature, and Kconfig didn't have a way to check the compiler features before offering CONFIG_* options. As a defense technology, the stack protector is pretty mature. Having it on by default would have greatly reduced the impact of things like the BlueBorne attack (CVE-2017-1000251), as fewer systems would have lacked the defense.

After spending quite a bit of time fighting with ancient compiler versions (*cough*GCC 4.4.4*cough*), I landed CONFIG_CC_STACKPROTECTOR_AUTO, which is default on, and tries to use the stack protector if it is available. The implementation of the solution, however, did not please Linus, though he allowed it to be merged. In the future, Kconfig will gain the knowledge to make better decisions which lets the kernel expose the availability of (the now default) stack protector directly in Kconfig, rather than depending on rather ugly Makefile hacks.

That's it for now; let me know if you think I should add anything! The v4.17 merge window is open. :)

Edit: added details on ARM register leaks, thanks to Daniel Micay.

© 2018, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

13 Apr 2018 12:04am GMT

The CFP for the 2018 Linux Security Summit North America (LSS-NA) is announced.

LSS will be held this year as two separate events, one in North America
(LSS-NA), and one in Europe (LSS-EU), to facilitate broader participation in
Linux Security development. Note that this CFP is for LSS-NA; a separate CFP
will be announced for LSS-EU in May. We encourage everyone to attend both
events.

LSS-NA 2018 will be held in Vancouver, Canada, co-located with the Open Source Summit.

The CFP closes on June 3rd and the event runs from 27th-28th August.

To make a CFP submission, click here.

11 Apr 2018 11:29pm GMT

Planning for the 2018 Linux Plumbers Conference is well underway at this point. The planning committee will be posting various informational blurbs here, including information on hotels, microconference acceptance, evening events, scheduling, and so on. Next up will be a "call for proposals" that should appear soon.

LPC will be held at the Sheraton Vancouver Wall Center in Vancouver, British Columbia, Canada, November 13-15, colocated with the Linux Kernel Summit.

10 Apr 2018 4:40pm GMT