LWN.net Weekly Edition for September 12, 2019 [LWN.net]

Welcome to the LWN.net Weekly Edition for September 12, 2019

This edition contains the following feature content:

Topics from the Open Printing microconference: driverless printing and (someday) scanning for Linux.
What happens to kernel staging-tree code: a look at the fate of driver modules once they enter the kernel's staging tree.
The USB debugging arsenal: tools for monitoring and altering USB transactions.
5.3 Kernel development cycle statistics: where the code in 5.3 came from.
SGX and security modules: making SGX work well with the kernel's security-module subsystem.
How Chrome OS works upstream: a conference talk on how the Chrome OS kernel team gets its job done.

This week's edition also includes these inner pages:

Brief items: Brief news items from throughout the community.
Announcements: Newsletters, conferences, security updates, patches, and more.

Please enjoy this week's edition, and, as always, thank you for supporting LWN.net.

Comments (none posted)

Topics from the Open Printing microconference

By Jake Edge
September 11, 2019

LPC

On day two of the 2019 Linux Plumbers Conference, two of the principals behind the Open Printing project led the very first Open Printing microconference. Project leader Till Kamppeter and program manager Aveek Basu described the current state of printing on Linux and some of the plans for the future, including supporting scanning for multi-function devices. The picture they painted was rosy, at least for printing, which may not quite match the experience of many Linux users. As with many projects, though, Open Printing is starved for contributors—something that was reflected in the sparse attendance at the microconference.

Basu began by pointing out that some attendees had likely printed their boarding passes from Linux, which highlights the importance of printing for Linux. People use it for bank documents, transport tickets, and more. He has been at Lexmark for 11 years, working on printing for Linux, macOS, and other Unix-based systems. Kamppeter said that he has been the Open Printing leader since 2001. The idea of the project is to do everything possible to make printing "just work" with Linux and other operating systems; the goal is "plug and print".

Plug and print

The way printing support has been handled in the past is to get a driver for the printer from the manufacturer, Basu said. That driver effectively sits between the printer firmware and the application that wants to print. In order to get a new printer working, a user has to go to the web site, get the driver, and install it. Those are complicated steps; "it's a pain", he said.

Things have changed, however. Now, printing on Linux is (or can be) all "driverless" using the Internet Printing Protocol (IPP). A printer can simply be connected to the network and then the user can hit control-p, choose the new printer, and print to it. All of that is done without any user intervention: "no hassles". All modern printers are driverless, he said. That is what the project has accomplished over the last few years.

He showed a short video [YouTube] that demonstrated the process. It was run on an Ubuntu system, which has the latest code for IPP driverless support, Kamppeter said, since he is the maintainer of the printing packages for the distribution. The video showed a system that had a single printer available as shown in the CUPS web interface; once the network was enabled, the LibreOffice print dialog simply showed all the new printers without needing to do anything special. Sending the job to one of the new printers would cause it to just show up in the new print queue displayed by CUPS; no configuration was required.

The OpenPrinting project works closely with the IEEE-ISTO Printer Working Group (PWG), Kamppeter said. The PWG is a printing standards body that was started in the late 1990s by a consortium of printer makers. Its most important standard is IPP. Around 2000, CUPS came along and he started working on printing; he got CUPS into Linux. Now, CUPS is the only maintained printing suite for Linux.

The PWG has also worked on multi-function devices (e.g. printer/scanner), which are now more common than single-function printers. There is now a scanner interface in IPP, so driverless scanning is possible as well. That is a free and open standard, he said, as are all of those produced by the PWG. Adding IPP driverless scanning support is targeted as a Google Summer of Code (GSoC) project for 2020. Open Printing has been recruiting students in India every year for GSoC projects, he said; many end up staying with the project.

Apple took CUPS over when it bought the company behind it. For macOS, it still uses CUPS, but has switched to using proprietary filters to turn PDF into the printer's native language. Once that happened, Apple no longer wanted to maintain the free filters, so it turned them over to Open Printing. Kamppeter started the cups-filters project to house the filters along with some other useful CUPS-related code (e.g. cups-browsed).

Scanning

Later in the microconference, Basu described the efforts to make IPP driverless scanning a reality. He started by giving some more detail on how IPP driverless printing works. When a host system (e.g. laptop) is connected to the network, it sends out a multicast DNS (mDNS) query to discover the printers available (among other things). The printers respond to say whether they support driverless operation; if they do, they also send some basic information about their capabilities (e.g. color, resolution, duplex ability).

When the user wants to print something, the application will display the printers available and the user can choose one. Once they do, the host will query the full capabilities of the printer via IPP so that the options can be displayed as part of the print dialog. The user then chooses the settings they want and sends the print job to the device.

When he is wearing his Open Printing hat, Basu said, he strongly advocates that everyone should use driverless printers. It is a little different with his Lexmark hat on; some older printers can have their firmware upgraded so that they can become driverless, but others can't. All modern printers are driverless capable, he said; that includes Android devices. Apple is also strongly promoting driverless printing. CUPS will disable PostScript Printer Description (PPD) files some day (they have been deprecated for some time now)—driverless is clearly the way forward.

He was asked what he meant by "modern". Basu said that Lexmark printers from the last five to seven years either have it or are getting it via a firmware upgrade. He is not sure for other manufacturers but thinks that anything in the last four or five years should work; he suggested checking for firmware upgrades that might be available to add the driverless support. When buying a printer, a good test is whether it can print from a phone, Kamppeter said; Linux supports all four IPP standards for driverless printing, including Apple's AirPrint.

So there is good news on the printing front, Basu said, but he had to report some bad news as well. Nothing like what is available for printing works for scanning in Linux. There is a need for more contributions to get to that point. For now, scanner users need to follow the age-old process of installing drivers from the manufacturer.

A printer driver simply translates what the user wants to what the firmware and the hardware need, he said. If the user chooses to print in color, for example, the driver knows what command(s) it needs to send to the printer to make that happen. For a scanner, it is similar in some ways. A scanning operation gets set up with user-specified options but, instead of sending data to be printed, the scanner driver receives data from the scanner that can be displayed in the user interface or saved.

The idea is to work with the SANE developers to get IPP driverless scanning working on Linux. The standards are already defined, but there is no Linux infrastructure to support them. There are not many people working on Linux printing, so there is a need for more contributions. The collaboration with the SANE project has already started, but unless some people step up, printing will continue to move ahead, while scanning falls behind, Basu said.

Driverless scanning should mostly just work like driverless printing. New scanners should appear in a SANE dialog that would allow the user to pick the scanner of interest, set options, and then initiate the scan. As with printing, there are IPP requests to query capability information, initiate scan jobs, and so on. A multi-function device would provide two URIs (starting with "ipp://HOSTNAME"): "/ipp/print" and "/ipp/scan".

An attendee wondered about device support for driverless scanning. Basu said that device makers are supporting Apple's AirScan, but Kamppeter said he is not sure whether that is using IPP driverless scanning or not. So far, he does not know of any scanner makers that are supporting the standard, however. The other side of that coin is that there are no clients for Linux that support it either, he said in answer to another question. That is the focus of the GSoC project that it is hoped will be chosen by a student next year. There is also a need for mentors for Open Printing GSoC students, Basu said; anyone who might be able to help with mentoring would also be welcome.

They also clarified how driverless printing does away with the driver. Basu said that the host no longer needs device-specific software in order to print; it can get all of the information it needs through IPP requests. There are four standard formats for raster data, so filters that can turn PDF into any of those are sufficient to take the PDF input that is sent to CUPS and turn it into IPP commands plus raster data for printing.

Basu suggested that Open Printing is growing in popularity—it has recently been adopted by Chrome OS. An attendee from Google said that it uses CUPS, but does not use cups-browsed; it has its own mDNS-based discovery mechanism and print dialog. It is an open-source solution, he said, with the code available on the internet. It is IPP based, but still uses PPD files; the company is still working on all of that.

Basu said that having the client side of driverless scanning working for Linux would hopefully help motivate manufacturers to support that in their devices. If there is nothing available on the software side, support might well be slow in coming. Once again, contributor-power is the main gating factor in getting there.

This article only looked at two of the six sessions in the microconference. There was also discussion of common print dialog backends from former GSoC student Rithvik Patibandla, some information from Kamppeter on how non-IPP printers will be supported once PPD files are left behind, how the printer setup tools will be changing, and more. For a small project—but one with a big, important job—Open Printing seems to have made some good progress. No doubt it could be even better with more participation, which seemed like something that Kamppeter and Basu hoped would come out of the microconference. That remains to be seen, but it would be sad to see Linux fall (further) behind in the scanning department if more contributors cannot be found.

[I would like to thank LWN's travel sponsor, the Linux Foundation, for travel assistance to Lisbon for LPC.]

Comments (47 posted)

What happens to kernel staging-tree code

By Jonathan Corbet
September 5, 2019

The staging tree was added to the kernel in 2008 for the 2.6.28 development cycle as a way to ease the process of getting substandard device drivers into shape and merged into the mainline. It has been followed by controversy for just about as long. The recent disagreements over the EROFS and exFAT filesystems have reignited many of the arguments over whether the staging tree is beneficial to the kernel community or not. LWN cannot answer that question, but we can look into what has transpired in the staging tree in its first eleven years to see if there are any conclusions to be drawn there.

The core idea behind the staging tree is that it is open to code that does not live up to the normal standards for inclusion into the kernel. Once a driver is added there, it is available to anybody who is brave enough to try to make use of it, but the real purpose is to allow developers to improve the code to the point that it is ready to go into the kernel proper. It serves as an easy place for new developers to try out simple changes and, when it works well, it helps the kernel to gain hardware support that might otherwise languish out-of-tree indefinitely.

Not everybody agrees that putting code into the staging tree is the best way to improve it; many of the developers who are concerned about the proposal to add exFAT to the staging tree argue that it will improve more quickly outside of staging. To quote Dave Chinner:

That's stuff that is much more easily done and reviewed by patches on a mailing list. You don't need the code in the staging tree to get this sort of thing done and, really, having it already merged gets in the way of doing major structural change as it cannot be rapidly iterated independently of the kernel dev cycle.

Greg Kroah-Hartman, the maintainer of the staging tree, replied that putting the code there gives it a common place for developers to cooperate on it. He acknowledged that it may slow the process somewhat, but argued that this cost was worth it for groups that wish to cooperate in that way.

It occurred to your editor that nobody has apparently looked at what fate has befallen the modules that have entered into staging over the last eleven years. A simple bit of scripting and brute-force Git work yielded a list of when each module entered and left the staging tree. All that was left was a huge amount of tedious manual work to figure out why each module was removed from the staging tree. It was one of those projects that, about halfway through, doesn't seem like such a good idea anymore. But now it is done; results follow.

Graduations

In the end, 247 modules were tracked from their entry into the staging tree. Of those, 52 "graduated" from the staging tree into the mainline kernel — 21% of the total. Those modules were:

Module Entry Exit Releases Fate

altera-stapl v3.0 v3.2 3 Graduated

ath6kl v2.6.37 v3.2 5 Graduated

batman-adv v2.6.33 v2.6.38 6 Graduated

brcm80211 v2.6.37 v3.2 5 Graduated

ccree v4.12 v4.17 6 Graduated

cx25821 v2.6.32 v3.2 10 Graduated

dwc2 v3.10 v3.14 5 Graduated

echo v2.6.28 v3.15 27 Graduated

et131x v2.6.28 v3.18 30 Graduated

fsl-mc v4.1 v4.19 19 Graduated

gma500 v3.0 v3.3 4 Graduated

hv v2.6.32 v3.4 12 Graduated

iio/dac v2.6.38 v3.6 8 Graduated

iio/imu v2.6.35 v3.9 14 Graduated

iio/light v2.6.32 v4.18 46 Graduated

iio/magnetometer v2.6.35 v4.6 31 Graduated

imx-drm v3.7 v3.19 13 Graduated

ipack v3.5 v3.8 4 Graduated

line6 v2.6.30 v4.0 30 Graduated

media/as102 v3.2 v3.18 17 Graduated

media/cec v4.8 v4.10 3 Graduated

media/cxd2099 v3.2 v4.17 36 Graduated

media/dt3155v4l v2.6.35 v4.2 27 Graduated

media/go7007 v2.6.28 v3.17 29 Graduated

media/mn88472 v3.19 v4.8 10 Graduated

media/mn88473 v3.19 v4.6 8 Graduated

media/msi3101 v3.12 v3.17 6 Graduated

media/pulse8-cec v4.8 v4.10 3 Graduated

media/rtl2832u_sdr v3.15 v3.17 3 Graduated

media/s5p-cec v4.8 v4.12 5 Graduated

media/solo6x10 v2.6.36 v3.17 21 Graduated

media/st-cec v4.9 v4.12 4 Graduated

mei v3.0 v3.5 6 Graduated

mrst-touchscreen v2.6.35 v2.6.37 3 Graduated

mt7621-gpio v4.17 v4.19 3 Graduated

mt7621-spi v4.17 v5.2 7 Graduated

omapdrm v3.3 v3.9 7 Graduated

panel v2.6.29 v4.6 37 Graduated

rar_register v2.6.32 v2.6.36 5 Graduated

rdma/hfi1 v4.3 v4.7 5 Graduated

samsung-laptop v2.6.33 v3.0 7 Graduated

sm7xxfb v2.6.33 v4.3 31 Graduated

ti-soc-thermal v3.6 v3.11 6 Graduated

ti-st v2.6.35 v3.0 5 Graduated

tm6000 v2.6.35 v3.2 7 Graduated

typec v4.12 v4.19 8 Graduated

udlfb v2.6.31 v2.6.38 8 Graduated

usbip v2.6.28 v3.17 29 Graduated

vboxvideo v4.13 v5.2 11 Graduated

xillybus v3.12 v3.18 7 Graduated

zram v2.6.33 v3.14 21 Graduated

zsmalloc v3.4 v3.14 11 Graduated

Module	Entry	Exit	Releases	Fate
altera-stapl	v3.0	v3.2	3	Graduated
ath6kl	v2.6.37	v3.2	5	Graduated
batman-adv	v2.6.33	v2.6.38	6	Graduated
brcm80211	v2.6.37	v3.2	5	Graduated
ccree	v4.12	v4.17	6	Graduated
cx25821	v2.6.32	v3.2	10	Graduated
dwc2	v3.10	v3.14	5	Graduated
echo	v2.6.28	v3.15	27	Graduated
et131x	v2.6.28	v3.18	30	Graduated
fsl-mc	v4.1	v4.19	19	Graduated
gma500	v3.0	v3.3	4	Graduated
hv	v2.6.32	v3.4	12	Graduated
iio/dac	v2.6.38	v3.6	8	Graduated
iio/imu	v2.6.35	v3.9	14	Graduated
iio/light	v2.6.32	v4.18	46	Graduated
iio/magnetometer	v2.6.35	v4.6	31	Graduated
imx-drm	v3.7	v3.19	13	Graduated
ipack	v3.5	v3.8	4	Graduated
line6	v2.6.30	v4.0	30	Graduated
media/as102	v3.2	v3.18	17	Graduated
media/cec	v4.8	v4.10	3	Graduated
media/cxd2099	v3.2	v4.17	36	Graduated
media/dt3155v4l	v2.6.35	v4.2	27	Graduated
media/go7007	v2.6.28	v3.17	29	Graduated
media/mn88472	v3.19	v4.8	10	Graduated
media/mn88473	v3.19	v4.6	8	Graduated
media/msi3101	v3.12	v3.17	6	Graduated
media/pulse8-cec	v4.8	v4.10	3	Graduated
media/rtl2832u_sdr	v3.15	v3.17	3	Graduated
media/s5p-cec	v4.8	v4.12	5	Graduated
media/solo6x10	v2.6.36	v3.17	21	Graduated
media/st-cec	v4.9	v4.12	4	Graduated
mei	v3.0	v3.5	6	Graduated
mrst-touchscreen	v2.6.35	v2.6.37	3	Graduated
mt7621-gpio	v4.17	v4.19	3	Graduated
mt7621-spi	v4.17	v5.2	7	Graduated
omapdrm	v3.3	v3.9	7	Graduated
panel	v2.6.29	v4.6	37	Graduated
rar_register	v2.6.32	v2.6.36	5	Graduated
rdma/hfi1	v4.3	v4.7	5	Graduated
samsung-laptop	v2.6.33	v3.0	7	Graduated
sm7xxfb	v2.6.33	v4.3	31	Graduated
ti-soc-thermal	v3.6	v3.11	6	Graduated
ti-st	v2.6.35	v3.0	5	Graduated
tm6000	v2.6.35	v3.2	7	Graduated
typec	v4.12	v4.19	8	Graduated
udlfb	v2.6.31	v2.6.38	8	Graduated
usbip	v2.6.28	v3.17	29	Graduated
vboxvideo	v4.13	v5.2	11	Graduated
xillybus	v3.12	v3.18	7	Graduated
zram	v2.6.33	v3.14	21	Graduated
zsmalloc	v3.4	v3.14	11	Graduated

(Lest somebody complain that your editor's math is off, the "releases" column includes the release in which the module was removed from the staging tree, since it was a part of that development cycle).

Some modules clearly pass through staging more quickly than others do. The altera-stapl driver zipped through in three release cycles. On the other hand, the industrial I/O light module sat there for 46 development cycles — nearly nine years. Regardless of how long it took, though, each of those modules was improved to the point that the appropriate subsystem maintainer was willing to accept it.

A 21% success rate may not seem all that high, but that is not the full story. A surprising number of staging drivers were deleted because their functionality was provided by another driver in the mainline. These "superseded" modules were:

Module Entry Exit Releases Fate

adis16255 v2.6.35 v2.6.38 4 Superseded

android/switch v3.3 v3.5 3 Superseded

at76_usb v2.6.28 v2.6.32 5 Superseded

cpc-usb v2.6.31 v2.6.32 2 Superseded

cptm1217 v2.6.38 v4.0 22 Superseded

cs5535_gpio v2.6.38 v3.1 3 Superseded

dt3155 v2.6.34 v2.6.36 3 Superseded

me4000 v2.6.28 v2.6.32 5 Superseded

media/easycap v2.6.36 v3.7 11 Superseded

media/tw686x-kh v4.7 v4.9 3 Superseded

meilhaus v2.6.29 v2.6.32 4 Superseded

mimio v2.6.29 v2.6.34 6 Superseded

msm v2.6.35 v3.1 6 Superseded

mt29f_spinand v3.13 v5.0 29 Superseded

mt7621-eth v4.17 v5.1 6 Superseded

otus v2.6.29 v2.6.37 9 Superseded

pata_rdc v2.6.31 v2.6.32 2 Superseded

quatech_usb2 v2.6.32 v3.5 13 Superseded

rt2860 v2.6.29 v3.0 11 Superseded

rt2870 v2.6.29 v3.0 11 Superseded

rt3070 v2.6.30 v2.6.36 7 Superseded

rt3090 v2.6.32 v2.6.34 3 Superseded

rtl8187se v2.6.29 v3.15 26 Superseded

rtl8192ee v3.16 v3.18 3 Superseded

rtl8192su v2.6.31 v2.6.37 7 Superseded

rtl8723au v3.15 v4.9 15 Superseded

rtl8821ae v3.14 v3.18 5 Superseded

rtlwifi v4.14 v5.2 10 Superseded

rts5139 v3.2 v3.16 15 Superseded

rts_pstor v3.0 v3.8 9 Superseded

serqt_usb v2.6.30 v2.6.31 2 Superseded

slicoss v2.6.28 v4.10 42 Superseded

ste_rmi4 v2.6.38 v4.6 28 Superseded

stlc45xx v2.6.30 v2.6.32 3 Superseded

uc2322 v2.6.30 v2.6.31 2 Superseded

usbvideo v2.6.38 v3.0 2 Superseded

zcache v3.0 v3.12 13 Superseded

Module	Entry	Exit	Releases	Fate
adis16255	v2.6.35	v2.6.38	4	Superseded
android/switch	v3.3	v3.5	3	Superseded
at76_usb	v2.6.28	v2.6.32	5	Superseded
cpc-usb	v2.6.31	v2.6.32	2	Superseded
cptm1217	v2.6.38	v4.0	22	Superseded
cs5535_gpio	v2.6.38	v3.1	3	Superseded
dt3155	v2.6.34	v2.6.36	3	Superseded
me4000	v2.6.28	v2.6.32	5	Superseded
media/easycap	v2.6.36	v3.7	11	Superseded
media/tw686x-kh	v4.7	v4.9	3	Superseded
meilhaus	v2.6.29	v2.6.32	4	Superseded
mimio	v2.6.29	v2.6.34	6	Superseded
msm	v2.6.35	v3.1	6	Superseded
mt29f_spinand	v3.13	v5.0	29	Superseded
mt7621-eth	v4.17	v5.1	6	Superseded
otus	v2.6.29	v2.6.37	9	Superseded
pata_rdc	v2.6.31	v2.6.32	2	Superseded
quatech_usb2	v2.6.32	v3.5	13	Superseded
rt2860	v2.6.29	v3.0	11	Superseded
rt2870	v2.6.29	v3.0	11	Superseded
rt3070	v2.6.30	v2.6.36	7	Superseded
rt3090	v2.6.32	v2.6.34	3	Superseded
rtl8187se	v2.6.29	v3.15	26	Superseded
rtl8192ee	v3.16	v3.18	3	Superseded
rtl8192su	v2.6.31	v2.6.37	7	Superseded
rtl8723au	v3.15	v4.9	15	Superseded
rtl8821ae	v3.14	v3.18	5	Superseded
rtlwifi	v4.14	v5.2	10	Superseded
rts5139	v3.2	v3.16	15	Superseded
rts_pstor	v3.0	v3.8	9	Superseded
serqt_usb	v2.6.30	v2.6.31	2	Superseded
slicoss	v2.6.28	v4.10	42	Superseded
ste_rmi4	v2.6.38	v4.6	28	Superseded
stlc45xx	v2.6.30	v2.6.32	3	Superseded
uc2322	v2.6.30	v2.6.31	2	Superseded
usbvideo	v2.6.38	v3.0	2	Superseded
zcache	v3.0	v3.12	13	Superseded

That is 37 superseded drivers overall, or 15% of the total. Whether these modules should be considered success stories will vary on a case-by-case basis. Some staging drivers were sufficiently ugly that they motivated desperate developers to write something better from scratch; some may say that the merging of such a driver into staging has achieved its intended goal. In other cases, the companies behind the hardware finally started providing proper drivers; many of the Realtek drivers in the above list fall into that category. In yet others, the staging driver may have provided needed information that enabled a proper driver to be written — also a useful role.

In each case, the support provided by these staging drivers did eventually find its way into the mainline. How much help was given by putting any given driver into staging is hard to determine, but the addition of this support seems like a success for the community overall.

Failures

Then, there is a long list of drivers that were simply deleted from the staging tree with no equivalent functionality being provided elsewhere:

Module Entry Exit Releases Fate

agnx v2.6.29 v2.6.32 4 Failed

altpciechdma v2.6.29 v2.6.34 6 Failed

arlan v2.6.33 v2.6.35 3 Failed

asus_oled v2.6.29 v3.12 23 Failed

b3dfg v2.6.30 v2.6.34 5 Failed

bcm v2.6.37 v3.19 22 Failed

btmtk_usb v3.11 v3.14 4 Failed

ccg v3.5 v3.10 6 Failed

ced1401 v3.7 v3.17 11 Failed

crystalhd v2.6.34 v3.17 23 Failed

csr v3.6 v3.11 6 Failed

cxt1e1 v2.6.35 v3.17 22 Failed

dabusb v2.6.38 v3.0 2 Failed

dgap v3.12 v4.6 15 Failed

dgnc v3.12 v4.20 29 Failed

dgrp v3.7 v3.17 11 Failed

dream v2.6.32 v2.6.37 6 Failed

dst v2.6.30 v2.6.33 4 Failed

epl v2.6.29 v2.6.32 4 Failed

frontier v2.6.29 v3.17 28 Failed

ft1000 v2.6.37 v4.4 27 Failed

gdm72xx v3.5 v4.6 22 Failed

heci v2.6.30 v2.6.32 3 Failed

i2o v4.0 v4.2 3 Failed

i4l v4.6 v4.11 6 Failed

iio/gyro v2.6.35 v4.19 44 Failed

iio/trigger v2.6.32 v4.17 45 Failed

intel_sst v2.6.37 v3.3 6 Failed

keucr v2.6.37 v3.17 20 Failed

lttng v2.6.33 v2.6.33 1 Failed

lustre v3.11 v4.18 28 Failed

media/atomisp v4.12 v4.18 7 Failed

memrar v2.6.35 v3.0 5 Failed

mt7621-mmc v4.17 v5.2 7 Failed

net v3.5 v3.10 6 Failed

netwave v2.6.33 v2.6.35 3 Failed

nokia_h4p v3.15 v3.18 4 Failed

ozwpan v3.4 v4.3 20 Failed

p9auth v2.6.30 v2.6.34 5 Failed

phison v2.6.30 v3.17 27 Failed

poch v2.6.28 v2.6.35 8 Failed

pohmelfs v2.6.30 v3.3 13 Failed

quickstart v2.6.36 v3.17 21 Failed

rspiusb v2.6.29 v2.6.32 4 Failed

sb105x v3.8 v3.15 8 Failed

sbe-2t3e3 v2.6.37 v3.16 19 Failed

sep v2.6.38 v3.17 19 Failed

serqt_usb2 v2.6.31 v3.17 26 Failed

silicom v3.7 v3.17 11 Failed

skein v3.16 v4.19 24 Failed

spectra v2.6.36 v3.3 7 Failed

strip v2.6.33 v2.6.35 3 Failed

sxg v2.6.28 v2.6.32 5 Failed

tidspbridge v2.6.36 v3.17 21 Failed

wavelan v2.6.33 v2.6.35 3 Failed

westbridge v2.6.37 v3.1 4 Failed

winbond v2.6.28 v3.17 29 Failed

wlags49_h2 v2.6.33 v3.17 24 Failed

wlags49_h25 v2.6.33 v3.17 24 Failed

xgifb v2.6.35 v5.1 47 Failed

Module	Entry	Exit	Releases	Fate
agnx	v2.6.29	v2.6.32	4	Failed
altpciechdma	v2.6.29	v2.6.34	6	Failed
arlan	v2.6.33	v2.6.35	3	Failed
asus_oled	v2.6.29	v3.12	23	Failed
b3dfg	v2.6.30	v2.6.34	5	Failed
bcm	v2.6.37	v3.19	22	Failed
btmtk_usb	v3.11	v3.14	4	Failed
ccg	v3.5	v3.10	6	Failed
ced1401	v3.7	v3.17	11	Failed
crystalhd	v2.6.34	v3.17	23	Failed
csr	v3.6	v3.11	6	Failed
cxt1e1	v2.6.35	v3.17	22	Failed
dabusb	v2.6.38	v3.0	2	Failed
dgap	v3.12	v4.6	15	Failed
dgnc	v3.12	v4.20	29	Failed
dgrp	v3.7	v3.17	11	Failed
dream	v2.6.32	v2.6.37	6	Failed
dst	v2.6.30	v2.6.33	4	Failed
epl	v2.6.29	v2.6.32	4	Failed
frontier	v2.6.29	v3.17	28	Failed
ft1000	v2.6.37	v4.4	27	Failed
gdm72xx	v3.5	v4.6	22	Failed
heci	v2.6.30	v2.6.32	3	Failed
i2o	v4.0	v4.2	3	Failed
i4l	v4.6	v4.11	6	Failed
iio/gyro	v2.6.35	v4.19	44	Failed
iio/trigger	v2.6.32	v4.17	45	Failed
intel_sst	v2.6.37	v3.3	6	Failed
keucr	v2.6.37	v3.17	20	Failed
lttng	v2.6.33	v2.6.33	1	Failed
lustre	v3.11	v4.18	28	Failed
media/atomisp	v4.12	v4.18	7	Failed
memrar	v2.6.35	v3.0	5	Failed
mt7621-mmc	v4.17	v5.2	7	Failed
net	v3.5	v3.10	6	Failed
netwave	v2.6.33	v2.6.35	3	Failed
nokia_h4p	v3.15	v3.18	4	Failed
ozwpan	v3.4	v4.3	20	Failed
p9auth	v2.6.30	v2.6.34	5	Failed
phison	v2.6.30	v3.17	27	Failed
poch	v2.6.28	v2.6.35	8	Failed
pohmelfs	v2.6.30	v3.3	13	Failed
quickstart	v2.6.36	v3.17	21	Failed
rspiusb	v2.6.29	v2.6.32	4	Failed
sb105x	v3.8	v3.15	8	Failed
sbe-2t3e3	v2.6.37	v3.16	19	Failed
sep	v2.6.38	v3.17	19	Failed
serqt_usb2	v2.6.31	v3.17	26	Failed
silicom	v3.7	v3.17	11	Failed
skein	v3.16	v4.19	24	Failed
spectra	v2.6.36	v3.3	7	Failed
strip	v2.6.33	v2.6.35	3	Failed
sxg	v2.6.28	v2.6.32	5	Failed
tidspbridge	v2.6.36	v3.17	21	Failed
wavelan	v2.6.33	v2.6.35	3	Failed
westbridge	v2.6.37	v3.1	4	Failed
winbond	v2.6.28	v3.17	29	Failed
wlags49_h2	v2.6.33	v3.17	24	Failed
wlags49_h25	v2.6.33	v3.17	24	Failed
xgifb	v2.6.35	v5.1	47	Failed

That is 60 modules, or 24% of the total. For most of these modules, the final commit reads something like "nobody has worked on this for years, it's time to give up". A few of them were for hardware that never actually made it into production, or which was so old and obsolete that nobody could obtain it to make the driver work properly. In some cases, as with the LTTng tracing subsystem, the code was pushed out almost immediately due to developer opposition to its presence. At least one was removed due to licensing issues.

Regardless of the reason, each of the above modules reflects an effort that did not eventually bear fruit. By its nature, the staging tree was never going to be 100% successful at graduating modules into the mainline; whether a 24% failure rate is too high will certainly be a matter of personal opinion.

Staging out

One role of the staging tree that was not anticipated back in 2008 is to be a final resting place for code that developers want to get rid of. If it appears that nobody is using a particular driver, it can be moved to the staging tree for a few releases; if nobody complains, it will eventually be deleted. These drivers have been "staged out" in that way:

Module Entry Exit Releases Fate

autofs v2.6.37 v3.0 3 Staged out

cpia v2.6.37 v2.6.38 2 Staged out

generic_serial v3.0 v3.1 2 Staged out

ipx v4.16 v4.18 3 Staged out

irda v4.14 v4.17 4 Staged out

media/lirc v2.6.36 v4.16 40 Staged out

media/mx2 v4.6 v4.8 3 Staged out

media/mx3 v4.6 v4.8 3 Staged out

media/omap1 v4.6 v4.8 3 Staged out

media/omap24xx v3.14 v3.19 6 Staged out

media/parport v3.19 v4.0 2 Staged out

media/sn9c102 v3.14 v3.17 4 Staged out

media/soc_camera v5.1 -- 3 Staging out

media/timb v4.6 v4.8 3 Staged out

media/tlg2300 v3.19 v4.0 2 Staged out

media/vino v3.19 v4.0 2 Staged out

media/zoran v4.18 v5.2 6 Staged out

ncpfs v4.16 v4.18 3 Staged out

rdma/amso1100 v4.3 v4.5 3 Staged out

rdma/ehca v4.3 v4.5 3 Staged out

rdma/ipath v4.3 v4.5 3 Staged out

se401 v2.6.38 v3.0 2 Staged out

serial v3.2 v3.5 4 Staged out

smbfs v2.6.37 v3.0 3 Staged out

stradis v2.6.37 v2.6.38 2 Staged out

telephony v3.4 v3.8 5 Staged out

tty v3.0 v3.1 2 Staged out

Module	Entry	Exit	Releases	Fate
autofs	v2.6.37	v3.0	3	Staged out
cpia	v2.6.37	v2.6.38	2	Staged out
generic_serial	v3.0	v3.1	2	Staged out
ipx	v4.16	v4.18	3	Staged out
irda	v4.14	v4.17	4	Staged out
media/lirc	v2.6.36	v4.16	40	Staged out
media/mx2	v4.6	v4.8	3	Staged out
media/mx3	v4.6	v4.8	3	Staged out
media/omap1	v4.6	v4.8	3	Staged out
media/omap24xx	v3.14	v3.19	6	Staged out
media/parport	v3.19	v4.0	2	Staged out
media/sn9c102	v3.14	v3.17	4	Staged out
media/soc_camera	v5.1	--	3	Staging out
media/timb	v4.6	v4.8	3	Staged out
media/tlg2300	v3.19	v4.0	2	Staged out
media/vino	v3.19	v4.0	2	Staged out
media/zoran	v4.18	v5.2	6	Staged out
ncpfs	v4.16	v4.18	3	Staged out
rdma/amso1100	v4.3	v4.5	3	Staged out
rdma/ehca	v4.3	v4.5	3	Staged out
rdma/ipath	v4.3	v4.5	3	Staged out
se401	v2.6.38	v3.0	2	Staged out
serial	v3.2	v3.5	4	Staged out
smbfs	v2.6.37	v3.0	3	Staged out
stradis	v2.6.37	v2.6.38	2	Staged out
telephony	v3.4	v3.8	5	Staged out
tty	v3.0	v3.1	2	Staged out

Thus, 27 modules — 11% of those to enter the staging tree — came initially from the rest of the kernel and were eventually deleted. The removal of unwanted code is clearly a good thing, so these cases should be seen as successes for the staging tree. The unfortunate part, perhaps, is that the amount of code staged out in this manner is so small; there are doubtless many other drivers in the kernel that are not actually in use anymore.

Hangers-on

There remains one last group: the modules that are still in the staging tree as of the 5.3-rc7 kernel:

Module Entry Exit Releases Fate

android/ion v3.14 -- 31

android/uapi v3.14 -- 31

axis-fifo v4.19 -- 6

bcm2835-audio v4.11 -- 11 (now in vc04_services)

board v3.17 -- 28

clocking-wizard v3.19 -- 26

comedi v2.6.29 -- 55

emxx_udc v3.17 -- 28

erofs v4.19 -- 6

fbtft v4.0 -- 25

fieldbus v5.2 -- 2

fsl-dpaa2 v4.12 -- 13

fwserial v3.8 -- 37

gasket v4.19 -- 6

gdm724x v3.12 -- 33

goldfish v3.9 -- 36

greybus v4.9 -- 16

gs_fpgaboot v3.15 -- 30

iio v2.6.32 -- 52

iio/accel v2.6.32 -- 52

iio/adc v2.6.32 -- 52

iio/addac v2.6.38 -- 46

iio/cdc v3.2 -- 43

iio/frequency v2.6.38 -- 46

iio/impedance-analyzer v3.2 -- 43

iio/meter v2.6.38 -- 46

iio/resolver v2.6.38 -- 46

isdn v5.3 -- 1

kpc2000 v5.2 -- 2

ks7010 v4.8 -- 17

media/allegro-dvt v5.3 -- 1

media/bcm2048 v3.14 -- 31

media/davinci_vpfe v3.9 -- 36

media/hantro v5.0 -- 4

media/imx v4.13 -- 12

media/imx074 v4.17 -- 8

media/ipu3 v5.0 -- 4

media/meson v5.3 -- 1

media/mt9t031 v4.17 -- 8

media/omap4iss v3.14 -- 31

media/platform v4.11 -- 15 (now in vc04_services)

media/sunxi v4.20 -- 5

media/tegra-vde v4.16 -- 9

most v4.3 -- 22

mt7621-dma v4.17 -- 8

mt7621-dts v4.17 -- 8

mt7621-pci v4.17 -- 8

mt7621-pci-phy v5.1 -- 3

mt7621-pinctrl v4.17 -- 8

netlogic v3.10 -- 35

nvec v3.0 -- 45

octeon v2.6.31 -- 53

octeon-usb v3.11 -- 34

olpc_dcon v2.6.37 -- 47

pi433 v4.14 -- 11

ralink-gdma v5.1 -- 3

rtl8188eu v3.12 -- 33

rtl8192e v2.6.32 -- 52

rtl8192u v2.6.33 -- 51

rtl8712 v2.6.37 -- 47

rtl8723bs v4.12 -- 13

rts5208 v3.14 -- 31

sm750fb v4.1 -- 24

speakup v2.6.37 -- 47

unisys v3.15 -- 30

vc04_services v4.9 -- 16

vme v2.6.32 -- 52

vt6655 v2.6.31 -- 53

vt6656 v2.6.32 -- 52

wilc1000 v4.2 -- 23

wlan-ng v2.6.28 -- 56

Module	Entry	Exit	Releases	Fate
android/ion	v3.14	--	31
android/uapi	v3.14	--	31
axis-fifo	v4.19	--	6
bcm2835-audio	v4.11	--	11	(now in vc04_services)
board	v3.17	--	28
clocking-wizard	v3.19	--	26
comedi	v2.6.29	--	55
emxx_udc	v3.17	--	28
erofs	v4.19	--	6
fbtft	v4.0	--	25
fieldbus	v5.2	--	2
fsl-dpaa2	v4.12	--	13
fwserial	v3.8	--	37
gasket	v4.19	--	6
gdm724x	v3.12	--	33
goldfish	v3.9	--	36
greybus	v4.9	--	16
gs_fpgaboot	v3.15	--	30
iio	v2.6.32	--	52
iio/accel	v2.6.32	--	52
iio/adc	v2.6.32	--	52
iio/addac	v2.6.38	--	46
iio/cdc	v3.2	--	43
iio/frequency	v2.6.38	--	46
iio/impedance-analyzer	v3.2	--	43
iio/meter	v2.6.38	--	46
iio/resolver	v2.6.38	--	46
isdn	v5.3	--	1
kpc2000	v5.2	--	2
ks7010	v4.8	--	17
media/allegro-dvt	v5.3	--	1
media/bcm2048	v3.14	--	31
media/davinci_vpfe	v3.9	--	36
media/hantro	v5.0	--	4
media/imx	v4.13	--	12
media/imx074	v4.17	--	8
media/ipu3	v5.0	--	4
media/meson	v5.3	--	1
media/mt9t031	v4.17	--	8
media/omap4iss	v3.14	--	31
media/platform	v4.11	--	15	(now in vc04_services)
media/sunxi	v4.20	--	5
media/tegra-vde	v4.16	--	9
most	v4.3	--	22
mt7621-dma	v4.17	--	8
mt7621-dts	v4.17	--	8
mt7621-pci	v4.17	--	8
mt7621-pci-phy	v5.1	--	3
mt7621-pinctrl	v4.17	--	8
netlogic	v3.10	--	35
nvec	v3.0	--	45
octeon	v2.6.31	--	53
octeon-usb	v3.11	--	34
olpc_dcon	v2.6.37	--	47
pi433	v4.14	--	11
ralink-gdma	v5.1	--	3
rtl8188eu	v3.12	--	33
rtl8192e	v2.6.32	--	52
rtl8192u	v2.6.33	--	51
rtl8712	v2.6.37	--	47
rtl8723bs	v4.12	--	13
rts5208	v3.14	--	31
sm750fb	v4.1	--	24
speakup	v2.6.37	--	47
unisys	v3.15	--	30
vc04_services	v4.9	--	16
vme	v2.6.32	--	52
vt6655	v2.6.31	--	53
vt6656	v2.6.32	--	52
wilc1000	v4.2	--	23
wlan-ng	v2.6.28	--	56

Thus, of the 247 modules to enter staging, 71 (29%) have yet to leave. The undisputed king of the long-term staging residents is the comedi subsystem. Since it was added in November 2008, this module has been the target of 8,673 of the 53,512 commits to the staging tree over its history — 16% of all activity in drivers/staging. There are quite a few other modules that have lived in the staging tree for a long time, though. If there was ever intended to be a time limit for residency in staging, it does not appear to have been enforced.

Some of those are close to being ready for graduation; in the above-linked message, Kroah-Hartman named comedi, greybus, and speakup as needing "just a bit more work". The Greybus drivers, in fact, are currently queued to move in 5.4. Others are certainly in need of deletion: "Yes, there is code in there that probably should be dropped now as I haven't done a sweep in a few years". And others will probably hang on for a while yet.

Exit stage right

To summarize, here are the conclusions on what happened to modules that were added to staging:

Fate Count Percent

Graduated 52 21%

Superseded 37 15%

Failed 60 24%

Staged out 27 11%

Still present 71 29%

Fate	Count	Percent
Graduated	52	21%
Superseded	37	15%
Failed	60	24%
Staged out	27	11%
Still present	71	29%

None of this is likely to answer the question of whether the staging tree is a good thing for kernel development or not; as is so often the case, it has almost certainly been helpful for some modules and less so for others. What is clear is that a lot of code has passed through this part of the kernel tree and has helped to shape the mainline kernel as a whole. Like it or not, the staging tree is a part of the kernel development process; its role may evolve in response to pressure from developers, but it seems likely to be a significant part of our process for some time to come.

Comments (24 posted)

The USB debugging arsenal

By Jake Edge
September 11, 2019

ELC NA

At the 2019 Embedded Linux Conference North America, which was held in San Diego in August, Krzysztof Opasiak gave a presentation on demystifying the ways to monitor—and even change—USB traffic on a Linux system. He started with the basics of the USB protocol and worked up into software and hardware tools to observe, modify, and fuzz the messages that get sent. Those tools are part of the arsenal that is available to those interested in looking deeply into USB.

Opasiak works in Poland for what he called a "small Korean company" (Samsung). He noted that it is not that easy to sniff USB traffic and that the ways to do so are not well known. But "there are no dragons"; nothing bad will happen if you do so. In some ways, USB is like the internet and some of the same tools can be used for both.

USB basics

A USB device provides one or more services (e.g. printing, storage, network interface, camera) to the USB host. Each device can only have a single host, but a host can have multiple client devices at any given time. In the USB model, "endpoints" serve the same role as ports do for the internet. Devices can have up to 31 endpoints, each providing a separate channel for the device. Endpoint zero (ep0) is required and is the only bidirectional endpoint; all of the rest are either IN (from device to host) or OUT (from host to device).

There are four types of endpoints: control, bulk, interrupt, and isochronous. The control endpoint is ep0, which is used for the enumeration of other aspects of the device. It could be used for services as well, but typically is not, because of various bugs in the implementations. A bulk endpoint is used to transfer a large amount of data that is not time sensitive; no reservation of bus bandwidth is done for these transfers. Unlike bulk, the interrupt endpoint type does reserve bus bandwidth; it is for small amounts of low-latency data. Finally, the isochronous endpoint is for large amounts of time-sensitive data, but delivery is not guaranteed; it is better to drop a frame than to delay this data.

There is a need for a way to discover the endpoints that a device provides, which is done via enumeration on ep0. Endpoints are organized into two higher-level constructs. The endpoints themselves are grouped into "interfaces"; those interfaces are then grouped into "configurations". Only one configuration can be active for a device; so a device may have multiple functions (services) available via different configurations, but only one of them is available at any given time. The ep0 control endpoint is always available, however, so that devices can be switched to a new active configuration.

The USB bus is host controlled; the host initiates all data exchange and there is no device-to-device communication. At the link layer, the host will send an IN token to the device; if the device has data ready to send, it will send it, otherwise it will send a NAK. The host will then retry the IN token until it times out.

For an OUT endpoint, the host will send an OUT token, followed by the data, to the device; if the device was ready to receive the data, it does so and sends an ACK, otherwise it NAKs the data and the host will retry sending until a timeout is reached. That is not particularly bandwidth-efficient—the OUT token is eight bits but the data is around 500 bits—so there is a way for the host to ping the device to see if it is ready to accept data rather than to blindly send it over and over.

Those are the low-level USB "transactions", but repeating the code to implement that in all of the drivers is not a good idea, Opasiak said. So drivers act at the level of USB "transfers", which consist of one or more transactions; typically the device or host hardware implement the transactions directly.

The Linux kernel provides a hardware-independent API for drivers that is based around the USB request block (URB), which provides a kind of envelope for the data. The API is asynchronous; transfers are initiated and a completion function is called when the transfer has finished. Since the kernel only works with URBs, and not the link-layer transactions, that is the layer at which any kernel-side USB sniffing can be done.

Sniffing USB

The first tool he described for looking at USB traffic is usbmon, which is a kind of in-kernel logger for URB-related events; it shows URB submission, completion, and error events. He noted that the data buffer in a URB is only valid in an event depending on the direction of the endpoint. OUT transfer buffers are valid for submit events, while IN transfer buffers are only valid as part of completion events.

There is both binary and text output available from usbmon, but instead you can use Wireshark to capture and parse the URB event data. He gave a short demo, starting with loading the usbmon kernel module. That sets up various devices in debugfs, one per USB bus in the system; there is also a device that can be used to capture the traffic from all of the buses. He then plugged in a USB device and checked the kernel log to see which bus it had connected to. He used Wireshark to capture data from the binary interface for the bus of interest and then further filtered the data by the device ID of the newly connected device.

Using usbmon is a simple, no-cost solution, but it does have some limitations. You cannot see the low-level transaction packets, just the URB transfers, for one thing. In addition, you need to be able to run code on the host that talks to the device, so you cannot see the traffic between the device and, say, a PlayStation, he said.

A hardware solution is one way around those limitations. USBProxy is code that runs on a single-board computer (SBC) of some sort, which can sit in between the device and the host and, as the name implies, proxies the data between them. In theory, it should work on any SBC that has the proper interfaces, but he was only able to get it working on a BeagleBone Black with a custom kernel. Using that, an attacker could inject malware into an Android device by doing a man-in-the-middle attack on adb, for example. USBProxy is not an out-of-the-box solution for USB interception, though; it "needs some love" to make it work.

The idea of using a logic analyzer for USB capture is often raised. They can be used to capture the traffic as well, he said, but typically only for low-speed or full-speed traffic. The newer high-speed signaling is done at 480Mbps, which, due to the Nyquist-Shannon theorem, means that it would need to be sampled at 1Ghz—something that is not common for reasonably priced logic analyzers.

OpenVizsla is a low-cost, open-hardware USB analyzer that connects between the host and device of interest. It cannot inject USB traffic, but it can capture data from any kind of hosts and devices without either side knowing that it has been done. It has an FPGA that writes the captured data to on-board RAM, which can then be retrieved over USB by an analysis host. There are tools that can be run on the analysis host to retrieve the data, including a Python script to retrieve the data and display it on the console, which is available in the OpenVizsla GitHub repository linked above. The Virtual USB Analyzer can be used to view the data, but Opasiak is skeptical that anyone will maintain a separate project just to view that USB data.

A better choice is the Wireshark integration that he and a student added. It can parse all of the traffic; it reuses the URB parsing that is already present and adds parsing for the low-level USB transactions. So, without expensive hardware, one can easily capture and analyze all of the data that flows between a USB device and the host it is connected to. He demonstrated the use of Wireshark to get the data from the OpenVizsla and showed it dissecting the traffic between two devices. He noted that if the higher-level traffic being handled is something that has a dissector available (e.g. adb), everything from the low-level to the actual application protocol data will be decoded and displayed.

Fuzzing

He then moved on to the FaceDancer device that can be used to do fuzz testing against host USB stacks. It has a custom USB stack in Python that is run on the host, which turns the FaceDancer into a researcher-controlled—or attacker-controlled—USB device. Using two FaceDancers—one emulating a host and the other emulating a device—allows a system to sit in between a USB host and device like the USBProxy. It can perform man-in-the-middle attacks against both ends of the connection.

Two other, related hardware devices are the GreatFET and the GreatFET Rhododendron. The GreatFET was originally used for radio hacking, he said. Each is compatible with the Python stack used by FaceDancer.

The Umap2 tool has been developed for FaceDancer, GreatFET, and a few other devices. It will emulate USB devices of various sorts, scan hosts to determine what types of USB devices are supported, and do some basic fuzzing using the Kitty framework.

Another fuzzing approach does not require any additional hardware. The Linux USB stack can be fuzzed with syzkaller on a Linux system using dummy_hcd, which acts as a kind of USB loopback device. With it, you can generate and handle USB traffic under the control of syzkaller to find problems in the USB stack. There are more tools out in the wild to do various kinds of USB fuzzing, he said.

Opasiak summarized his talk by noting that you can investigate USB in various ways without spending a lot of money. The OpenVizsla and GreatFET-based boards are on the order of $100, he said during the Q&A after the talk. There are various open-source-software and open-hardware projects that can be used, but the precise architecture needed is dependent on what you are trying to do; there is no perfect solution for everyone. USB is everywhere these days—cars, phones, laptops, etc.—so it is important to ensure that it is functioning correctly. He hopes to see much more effort put into USB testing and fuzzing in the future.

[I would like to thank LWN's travel sponsor, the Linux Foundation, for funding to travel to San Diego for ELC.]

Comments (5 posted)

5.3 Kernel development cycle statistics

By Jonathan Corbet
September 9, 2019

It's that time of the development cycle again: work on the 5.3 kernel is winding down with an expected final release date of September 15. Read on for LWN's traditional look at where the code in 5.3 came from in this relatively busy development cycle.

As of this writing, 14,435 non-merge changesets have been pulled into the mainline repository for 5.3; these changes were contributed by 1,846 developers. That makes 5.3 one of the busier cycles in recent times:

Release Changesets Developers

4.15 14,866 1,801

4.16 13,630 1,805

4.17 13,541 1,713

4.18 13,283 1,728

4.19 14,043 1,752

4.20 13,884 1,749

5.0 12,808 1,757

5.1 13,034 1,737

5.2 14,024 1,783

5.3 14,435 1,846

Release	Changesets	Developers
4.15	14,866	1,801
4.16	13,630	1,805
4.17	13,541	1,713
4.18	13,283	1,728
4.19	14,043	1,752
4.20	13,884	1,749
5.0	12,808	1,757
5.1	13,034	1,737
5.2	14,024	1,783
5.3	14,435	1,846

The traffic in 5.3 thus did not set a new record; indeed, 4.9, with 16,214 changesets merged, seems likely to hold that record for a while yet. The 1,846 developers contributing during this cycle is a new high, though, suggesting that the kernel community is still growing; 256 of those developers were first-time contributors.

Those 1,846 developers deleted an impressive 389,000 lines of code from the kernel during this cycle. They also added 973,000 lines, though, so the kernel grew by 584,000 lines of code. The most active developers this time around were:

Most active 5.3 developers

By changesets

Kuninori Morimoto 271 1.9%

Christoph Hellwig 262 1.8%

Mauro Carvalho Chehab 205 1.4%

Nishka Dasgupta 162 1.1%

Chris Wilson 160 1.1%

Greg Kroah-Hartman 145 1.0%

Yue Haibing 137 0.9%

Masahiro Yamada 130 0.9%

Gustavo A. R. Silva 128 0.9%

Geert Uytterhoeven 120 0.8%

Takashi Sakamoto 113 0.8%

Wolfram Sang 101 0.7%

Arnaldo Carvalho de Melo 99 0.7%

Colin Ian King 98 0.7%

Arnd Bergmann 96 0.7%

Adrian Hunter 96 0.7%

Russell King 94 0.7%

David Howells 92 0.6%

Hawking Zhang 90 0.6%

Maxime Ripard 84 0.6%

By changed lines

Hawking Zhang 364371 31.2%

Arnd Bergmann 84993 7.3%

Mauro Carvalho Chehab 34041 2.9%

Harry Wentland 33568 2.9%

Jason Gunthorpe 22421 1.9%

Chris Wilson 17382 1.5%

Richard Fitzgerald 15791 1.4%

Linus Walleij 13392 1.1%

Greg Kroah-Hartman 11713 1.0%

Bernard Metzler 10963 0.9%

Christoph Hellwig 10844 0.9%

Pawel Laszczak 7702 0.7%

Hannes Reinecke 7255 0.6%

Andrii Nakryiko 7143 0.6%

Maxime Ripard 6709 0.6%

David Ahern 6557 0.6%

Daniele Ceraolo Spurio 5781 0.5%

Darrick J. Wong 5776 0.5%

Kuninori Morimoto 4717 0.4%

Thomas Zimmermann 4706 0.4%

The biggest contributor of changesets this time around was Kuninori Morimoto, who did a lot of work updating code in the sound subsystem. Christoph Hellwig made significant improvements across the core kernel and the block subsystem, Mauro Carvalho Chehab converted a vast number of documentation files to the restructured text format, Nishka Dasgupta fixed a large number of Coccinelle warnings, and Chris Wilson worked extensively on the Intel i915 graphics driver.

Hawking Zhang was responsible for nearly one-third of the changed lines in 5.3; as is so often the case, the new code is yet another set of register definitions for the amdgpu graphics driver. Arnd Bergmann removed the old ISDN subsystem and, as usual, made improvements across the kernel tree. Harry Wentland also contributed AMD graphics driver changes, and Jason Gunthorpe removed some obsolete RDMA code.

The top testers and reviewers this time around were:

Test and review credits in 5.3

Tested-by

Andrew Bowers 115 12.0%

Arnaldo Carvalho de Melo 27 2.8%

Leo Yan 24 2.5%

Tony Lindgren 24 2.5%

Tim Schumacher 19 2.0%

Aaron Brown 18 1.9%

Andre Przywara 18 1.9%

Keerthy 17 1.8%

Nick Desaulniers 16 1.7%

Hans de Goede 16 1.7%

Shijith Thotton 16 1.7%

Reviewed-by

Alex Deucher 193 3.3%

Rob Herring 167 2.8%

Chris Wilson 115 1.9%

Christoph Hellwig 108 1.8%

Hawking Zhang 100 1.7%

Simon Horman 93 1.6%

Darrick J. Wong 91 1.5%

Andrew Lunn 90 1.5%

Tvrtko Ursulin 79 1.3%

Geert Uytterhoeven 78 1.3%

Maarten Lankhorst 77 1.3%

The biggest collector of Tested-by credits is Andrew Bowers, a developer who has never contributed a patch to the kernel, but who seemingly does extensive testing of changes to various Intel drivers. Review credits are more evenly spread out, though still concentrated on subsystems that require reviews before merging. 4,824 Patches in 5.3 (33% of the total) carried Reviewed-by tags; that is higher than the long-term average but slightly less than the number seen in 5.2.

The Reported-by tags, applied to give credit to the reporter of a problem, are worth a quick look as well. There were 687 patches with such tags merged for 5.3, with the top reporters being:

Reported-by credits in 5.3

Hulk Robot 89 10.7%

kbuild test robot 62 7.5%

Stephen Rothwell 37 4.4%

Dan Carpenter 24 2.9%

syzbot 18 2.2%

Randy Dunlap 11 1.3%

Geert Uytterhoeven 9 1.1%

Guenter Roeck 9 1.1%

kernel test robot 9 1.1%

Arnd Bergmann 8 1.0%

Reported-by credits in 5.3
Hulk Robot	89	10.7%
kbuild test robot	62	7.5%
Stephen Rothwell	37	4.4%
Dan Carpenter	24	2.9%
syzbot	18	2.2%
Randy Dunlap	11	1.3%
Geert Uytterhoeven	9	1.1%
Guenter Roeck	9	1.1%
kernel test robot	9	1.1%
Arnd Bergmann	8	1.0%

Of the top five bug reporters, three are automated testing systems, one is the linux-next maintainer (linux-next being the first point of integration testing for many patches), and one is a developer who aggressively looks for (and fixes) bugs with a static-analysis tool. In other words, it is fair to say that the testing mechanisms that have slowly been built up around the kernel process are having an effect, catching bugs before they can affect users.

That said, it's worth noting that 2,026 changes in 5.3 — 14% of the total — carry Fixes: tags, implying that they are fixes for bugs that did make it into the mainline. Many fixes undoubtedly are merged without the addition of a Fixes: tag, so the actual percentage of bug fixes is certain to be significantly higher than that. Clearly, there is plenty of scope for improving our testing infrastructure and procedures still.

Finally, 233 companies (that we were able to identify) supported work on the 5.3 kernel. The most active of these companies were:

Most active 5.3 employers

By changesets

Intel 1545 10.7%

AMD 966 6.7%

(Unknown) 963 6.7%

Red Hat 925 6.4%

(None) 865 6.0%

Google 638 4.4%

Renesas Electronics 638 4.4%

Linaro 548 3.8%

IBM 460 3.2%

Mellanox 440 3.0%

(Consultant) 410 2.8%

Huawei Technologies 372 2.6%

SUSE 337 2.3%

Samsung 311 2.2%

NXP Semiconductors 309 2.1%

Linux Foundation 291 2.0%

ARM 280 1.9%

Facebook 188 1.3%

Oracle 170 1.2%

BayLibre 170 1.2%

By lines changed

AMD 432537 37.0%

Linaro 115926 9.9%

Intel 76950 6.6%

Mellanox 46732 4.0%

Samsung 37869 3.2%

Google 31666 2.7%

(Unknown) 31310 2.7%

Red Hat 31089 2.7%

IBM 29449 2.5%

(None) 27803 2.4%

SUSE 18928 1.6%

Cirrus Logic 16509 1.4%

(Consultant) 14192 1.2%

Facebook 13723 1.2%

Linux Foundation 13405 1.1%

ARM 12755 1.1%

Pengutronix 12398 1.1%

NXP Semiconductors 12202 1.0%

Renesas Electronics 11345 1.0%

Huawei Technologies 10165 0.9%

As usual, there are few surprises to be found in the above table. The list of the most active companies does not tend to vary much from one development cycle to the next.

Overall, the picture that emerges is of a development community that continues to integrate massive numbers of changes on a predictable schedule, and which continues to grow slowly. For all its faults, the kernel development community is clearly doing some things right.

Comments (4 posted)

SGX and security modules

September 11, 2019

This article was contributed by Marta Rybczyńska

Software Guard Extensions (SGX) is a set of security-related instructions for Intel processors; it allows the creation of private regions of memory, called "enclaves". The aim of this feature is to work like an inverted sandbox: instead of protecting the system from malicious code, it protects an application from a compromised kernel hypervisor, or other application. Linux support for SGX has existed out-of-tree for years, and the effort of upstreaming it has reached an impressive version 22 of the patch set. During the upstreaming discussion, the kernel developers discovered that the proposed SGX API did not play nicely with existing security mechanisms, including Linux security modules (LSMs).

SGX and enclaves

SGX allows creation of memory regions that are expected to host a sensitive part of an application, such as the handling of private keys. Both the sensitive data and the code that manages it live within the enclave; except for defined entry points, they are inaccessible outside of it. In addition, the enclave code and data are encrypted in memory with ephemeral keys.

The enclaves have their own page-protection regime, as they are isolated from the rest of the system. The memory used by the enclave is handled separately from main system memory and the enclave must fit into a single contiguous linear virtual-memory range. With those constraints, loading the enclave requires specific preparations, including some assembly code. Interested readers can find an example in the SGX self-test code.

The enclave is managed, from the Linux side, by a device driver (LWN looked into it in April and, in 2016, in the context of memory encryption). It handles memory management within the enclave. The management API for SGX enclaves includes a mix of ioctl() calls to create an enclave, to add a page, and to initialize the enclave; it works along with with a few special SGX CPU instructions.

SGX and LSMs

In the discussion about the SGX security model, Greg Wettstein pointed out that the SGX API did not provide verification of the enclave code. He also mentioned an attack [PDF] using SGX that allows malicious code running inside an enclave to steal data from an application. That makes the enclave code a possible security threat in its own right.

Preventing such attacks requires that the kernel have control over which code can be run within an enclave. Andy Lutomirski pointed out that software verification is already available in Linux in the form of LSM policies and noted that there might be a bigger issue as well. While security policies in many systems do not allow applications to create executable memory regions with arbitrary content, the SGX API does allow exactly that. He wrote:

There are many, many Linux systems that enforce a policy that *all* executable text needs to come from a verified source. On these systems, you can't mmap some writable memory, write to it, and then change it to executable. [...] Unless I'm missing it, the current SGX API is entirely incompatible with this model.

This conclusion (reasonably) upset the kernel developers, adding to the list of known issues with SGX in general (the SGX Wikipedia page contains a list of other problems). Linus Torvalds agreed that circumventing LSM policies was a fatal flaw:

And if the current setup basically is "you have to disable reasonable SELinux protections that lots of distros use today", I think it's entirely reasonable saying "the downsides are bigger than the upsides".

The consensus among the developers was that the control over enclave page loading must be given to the LSMs. An extensive discussion on the linux-security-module mailing list explored the interactions between the LSMs and SGX in great detail.

Details of the problem

In the SGX driver implementation, all enclaves are backed by the same device file (/dev/sgx/enclave). This allows SGX users to use ordinary system calls (including mmap() and ioctl()) to move pages to and from the SGX-specific hardware module called the "enclave page cache" (EPC). The pages in the EPC differ from typical pages because of the hardware restrictions: they are shared by processes at the hardware level and there is one-to-one mapping between virtual and physical addresses within an enclave. The enclaves also need specific SGX read, write, and execute permissions to the EPC pages.

Without the needed LSM hooks, and with SGX active, the LSMs are unable to apply policies with the granularity they need — they could deny all access to SGX (by blocking access to /dev/sgx/enclave), but could not control the mapping of pages as writable and executable, or loading code from anonymous memory. As the enclaves are backed by the same file, any restrictions would apply to all enclaves.

The developers also found out that, because the SGX hardware bypasses the standard page permissions, user space could use SGX to gain access it could normally not have. The known case is the following: a hostile process can add a read-only page backed by a file lacking execute permission to the enclave, then call mprotect() to change the permissions in the enclave to gain execute rights on that memory. A solution to the issue is to require specifying enclave page protection in advance, allowing the kernel to apply its policies regarding executable pages within enclaves.

Toward a solution

Sean Christopherson entered the discussion with a patch set attempting to reconcile SGX with LSMs. It included an mprotect() hook in the vm_ops structure meant to be implemented by LSMs. The SGX code, when building an enclave, would call that hook to oversee the permissions for each page. This approach did not work, though, due to problems with auditing. The developers were unable to make sure that this hook would not generate false positives from the checks made at enclave loading time. The other option was to do checks at the time of mprotect(), but that could cause false alerts when the system configuration changes. For example, alerts could result when a file is moved between the loading of the enclave and the change of protection, or when the LSM policy is modified.

The next version tracked the page protection of the enclave separately from the virtual memory areas (VMAs) mapping the source files and from the hardware protections. The API requires user space to declare the protections of each page when it is added by specifying a combination of the PROT_READ, PROT_WRITE, and PROT_EXEC flags. Those flags define the maximal permissions that user space may request when mapping the page. As a result, when a process tries to mmap() or mprotect() on an enclave page, the call will fail if the protections in the VMA would be more permissive than the enclave page permissions. This tracking allows the SGX code to call into LSMs when the enclave is being built. The LSMs can then enforce their own policies on enclave pages.

During the discussion, Cedric Xing sent a different patch set addressing the same issue. He used a different method: tracking the correspondence between the enclave pages and their origin (for example the files they were loaded from). That correspondence is kept in the LSM data structures.

The twist

All the proposed solutions were complicated, hindering their acceptance. A shift toward a consensus happened, though, when the developers came back to the basic requirements. Lutomirski explained that the only real requirement for SGX LSM support is to not allow the execution of arbitrary code, making the scope of the problem much simpler than what had been considered before. Jarkko Sakkinen, the original poster of the SGX patches, proposed deferring the complexity of loading the enclaves to user space and, in particular, splitting the roles of loading and running the enclaves. Finally, Stephen Smalley summarized an off-list discussion concluding that the solution only requires a decision of the policies to be used by SELinux for SGX.

Christopherson noted that there is still some work to do, but it can be done without affecting the SGX API, after the new code is upstreamed. The code will have some drawbacks, as Xing explained, such as the inability to support self-modifying code in the enclaves.

Summary

This discussion took over two months and touched the low-level details of the kernel's memory-management and security primitives. The apparent solution is much simpler than what was proposed in the discussion, even though the exact details still need to be worked out. However, it seems that the developers can now concentrate on the remaining SGX upstreaming challenges.

Comments (10 posted)

How Chrome OS works upstream

September 6, 2019

This article was contributed by Sean Kerner

OSS NA

Google has a long and interesting history contributing to the upstream Linux kernel. With Chrome OS, Google has tried to learn from some of the mistakes of its past and is now working with the upstream Linux kernel as much as it can. In a session at the 2019 Open Source Summit North America, Google software engineer Doug Anderson detailed how and why Chrome OS developers work upstream. It is an effort intended to help the Linux community as well as Google.

The Chrome OS kernel is at the core of Google's Chromebook devices, and is based on a Linux long-term support (LTS) kernel. Anderson explained that Google picks an LTS kernel every year and all devices produced in that year will use the selected kernel. At least once during a device's lifetime, Google expects to be able to "uprev" (switch to a newer kernel version). Anderson emphasized that if Google didn't upstream its own patches from the Chrome OS kernel, it would make the uprev process substantially more difficult.

Simply saying that you'll work upstream and actually working upstream can be two different things. The process by which Chrome OS developers get their patches upstream is similar to how any other patches land in the mainline Linux kernel. What is a bit interesting is the organizational structure and process of how Google has tasked Chrome OS developers to work with upstream. Anderson explained that developers need to submit patches to the kernel mailing list and then be a little patient, giving some time for upstream to respond. A key challenge, however, is when there is no response from upstream. "When developing an upstream-first culture, the biggest problem anyone can face is silence," Anderson said.

Anderson emphasized that when submitting a patch to the mailing list, what a developer is looking for is some kind of feedback; whether it's good or bad doesn't matter, but it does matter that someone cares enough to review it. What the Chrome OS team does in the event that there is no community review is it will have other Chrome OS engineers publicly review the patch. The risk and worry of having Chrome OS engineers comment on Chrome OS patches is that the whole process might look a little scripted and there could be the perception of some bias as well. Anderson noted that it is important that only honest feedback and review is given for a patch.

Yak shaving

While feedback from the mailing list is what the developers want, there can be situations where that feedback gets into what Anderson referred to as "yak shaving". It means that a small patch is submitted and the feedback that comes back covers more than just the patch itself, asking the developer to, for example, clean up a related subsystem or redo an API. "Basically, your little patch ends up being someone requesting you to do a month's worth of work," Anderson said.

Sometimes if a yak shaving request is not a lot of work; he suggested that the best thing is to just do the work in that case. Other times, the work is far outside the scope of a Chrome OS developer's efforts and it's not something that the developer is able to do. Anderson said that there are times that upstream will allow a developer to land a patch without completing all of the yak shaving, while there are other times when that doesn't happen.

The Chrome OS kernel tree

Even with a stated policy of trying to be upstream first, the Chrome OS kernel tree isn't entirely pulled from the mainline kernel. Anderson explained that developers generally try to tag all the commits in the Chrome OS tree with some information about where the commits came from. He emphasized that whenever Google has something in its Chrome OS kernel tree, developers are pushing hard for it to go upstream into Linus Torvalds's tree or into the right maintainer's tree.

The UPSTREAM tag is used to identify a commit that was pulled directly from Torvalds's tree, while the FROMGIT tag refers to a commit that was picked from a maintainer's tree that will eventually feed the mainline. The FROMLIST tag is used by Chrome OS developers for commits that are picked from a mailing list. The CHROMIUM tag is a bit different than the others, in that it refers to a commit that is not going to go upstream and, ideally, is just for Chrome-OS-specific configuration items.

Fundamentally, Anderson argued that it is a win-win for both the overall kernel development community and Chrome OS to work upstream. He noted that working upstream provides extra testing and review bandwidth, as well as pushing hardware vendors that work with Chrome OS devices to work upstream as well. For example, Anderson said that the Rockchip rk3288 and rk3399 Arm systems-on-chip (SoCs) are fairly well supported upstream because of Chrome OS.

Learning from the mistakes of Android

Google hasn't always had an upstream-first approach for its operating systems, which is something that Chrome OS developers are aiming not to repeat. "We're trying not to do what Android did 10 years ago," Anderson said. Android phones tended to have large stacks of patches that had not been upstreamed, he said. In addition, Android devices had come up with all kinds of different ways of doing things that were not aligned with the upstream kernel. Rather than follow the path of Android, Chrome OS developers want to get as much as possible into the mainline, giving kernel developers the chance to comment and review along the way.

During the question-and-answer segment that followed the session, a member of the audience pointed out that even today Android development has lots of code that isn't upstream. They asked if in fact the Chrome OS kernel is basically the same as the upstream kernel. Anderson explained that Google has a full fork of the mainline kernel. So for example, there is a Chrome OS 4.19 tree, where patches are picked and tagged so it's clear where the patches come from. "So it's totally a whole fork of the upstream kernel, but the idea is that we try to keep posting things upstream and landing them there," he said. "And in a perfect world, our Chrome OS 4.19 would be just pure 4.19 with a whole bunch of upstream bits from newer kernels, but it doesn't always work out that way."

Keeping everything upstream, as Anderson explained more than once, during his session, isn't easy. But it seems clear that Google's Chrome OS development team is committed to that path, and has a well-defined process that will hopefully keep them from straying too far.

Comments (7 posted)

Critical vulnerability in Exim

Anybody running the Exim mail system will want to apply the updates that are being released today; there is a remote code-execution vulnerability in its TLS-handling code with a known proof-of-concept exploit. As the advisory says: "If your Exim server accepts TLS connections, it is vulnerable".

Comments (38 posted)

Security quote of the week

Crown Sterling is complete and utter snake oil. The company sells "TIME AI," "the world's first dynamic 'non-factor' based quantum AI encryption software," "utilizing multi-dimensional encryption technology, including time, music's infinite variability, artificial intelligence, and most notably mathematical constancies to generate entangled key pairs." Those sentence fragments tick three of my snake-oil warning signs -- from 1999! -- right there: pseudo-math gobbledygook (warning sign #1), new mathematics (warning sign #2), and extreme cluelessness (warning sign #4).

— Bruce Schneier

Comments (none posted)

Kernel release status

The current development kernel is 5.3-rc8, released on September 8. "So we probably didn't strictly need an rc8 this release, but with LPC and the KS conference travel this upcoming week it just makes everything easier."

Stable updates: 5.2.12, 4.19.70, 4.14.142, 4.9.191, and 4.4.191 were released on September 6; 5.2.13 and 4.19.71 followed immediately thereafter with a single regression fix. 5.2.14, 4.19.72, 4.14.143, 4.9.192, and 4.4.192 came out on September 10.

Comments (none posted)

Quote of the week

I've also contributed significantly to a MUA, and my observation is that email is a massively distributed fuzzing project for email software that allows message transmission in the sideband.

— Jani Nikula

Comments (none posted)

Distribution quote of the week

In fact if the change ever did get made then probably the Exim fans would complain loudly about the move away from Exim and the Sendmail and Courier fans would complain loudly that the move is not to Sendmail or Courier, so it's a good thing to keep this one in reserve in case all of the other gratuitous flame wars on the Debian lists ever fizzle out.

— anselm

Comments (none posted)

Google's differential privacy library

Google has announced the release of a new library for applications using differential privacy techniques. "Differentially-private data analysis is a principled approach that enables organizations to learn from the majority of their data while simultaneously ensuring that those results do not allow any individual's data to be distinguished or re-identified. This type of analysis can be implemented in a wide variety of ways and for many different purposes. For example, if you are a health researcher, you may want to compare the average amount of time patients remain admitted across various hospitals in order to determine if there are differences in care. Differential privacy is a high-assurance, analytic means of ensuring that use cases like this are addressed in a privacy-preserving manner."

Comments (5 posted)

Development quote of the week

Looking at the active contributors to Open Source, the primary model is that either your job description includes working on designated open source projects so you’re paid to contribute as your day job or you were hired because of what you’ve already done in open source and contributing more is a tolerated use of your employer’s time, a third, and by far smaller group is people who work full-time on Open Source but fund themselves either by shared contributions like patreon or tidelift or by actively consulting on their projects. However, these models cover existing contributors and they’re not really a route to becoming a contributor because employers like certainty so they’re unlikely to hire someone with no track record to work on open source, and are probably not going to tolerate use of their time for developing random open source projects. This means that the route to becoming a contributor, like the route to becoming an artist, is to begin in your own time.

— James Bottomley (Thanks to Paul Wise)

Comments (2 posted)

CodeWeavers mourns Józef Kucia

The CodeWeavers blog carries the sad news that Józef Kucia died last month. "Józef first contributed to Wine in March of 2012, showing remarkable skill with Wine’s D3D technology. He became a key contributor to Wine, submitting over 2,500 patches. He also contributed to other open source projects including Mesa and Debian. Józef founded and led the vkd3d project and provided insight and guidance to the Vulkan working group. Józef joined CodeWeavers in 2015, and quickly became one of our most valued employees."

Comments (2 posted)

DistroWatch Weekly (September 9)

Lunar Linux Weekly News (September 6)

openSUSE Tumbleweed Review of the Week (September 6)

Tails Report (August)

Ubuntu Weekly Newsletter (September 7)

Emacs News (September 9)

What's cooking in git.git (September 7)

LLVM Weekly (September 9)

LXC/LXD/LXCFS Weekly Status (September 9)

OCaml Weekly News (September 10)

Perl Weekly (September 9)

Weekly changes in and around Perl 6 (September 9)

PostgreSQL Weekly News (September 8)

Python Weekly Newsletter (September 5)

Ruby Weekly News (September 5)

This Week in Rust (September 10)

Wikimedia Tech News (September 9)

Fedora FESCO meeting minutes (September 9)

GNOME Foundation Board Minutes (August 5)

GNOME Foundation Board Minutes (August 12)

Free Software Supporter (September)

Sonoj Convention 2019

The third annual Sonoj Convention will take place October 26-27 in Cologne, Germany. The convention is focused on the combination of music production and open source software with a priority on practical music production. The call for talks, demonstrations, and workshops is open; no deadline is given.

Full Story (comments: none)

Call For Papers - Extended Deadline - Tcl/Tk Conference (Tcl'2019)

The call for papers for Tcl'2019 has been extended until September 16. The conference will take place November 5-8 in Houston, TX.

Full Story (comments: none)

CFP Deadlines: September 12, 2019 to November 11, 2019

The following listing of CFP deadlines is taken from the LWN.net CFP Calendar.

Deadline	Event Dates	Event	Location
September 13	October 26	The Future is Open	Rochester, NY, USA
September 14	October 31	Real-time Linux Summit - At ELCE 2019	Lyon, France
September 16	November 4 November 8	Tcl 2019 - 26th Annual Tcl/Tk Conference	Houston, TX, USA
September 22	December 9	Open FinTech Forum	New York, NY, USA
October 2	November 2 November 3	OpenFest 2019	Sofia, Bulgaria
October 4	November 2 November 3	Konference OpenAlt	Brno, Czechia
October 6	November 16 November 17	Capitole du Libre 2019	Toulouse, France
October 25	March 23 March 27	[CANCELED] SUSECON 2020	was Dublin, Online only
November 8	February 1 February 2	FOSDEM 2020	Brussels, Belgium

If the CFP deadline for your event does not appear here, please tell us about it.

International Day Against DRM

The Free Software Foundation's Defective by Design campaign has announced that the International Day Against DRM (IDAD) will be on October 12. "This year we will be focusing specifically on everyone's right to read, particularly by urging publishers to free students and educators from the unnecessary and cumbersome restrictions that make their access to necessary course materials far more difficult."

Full Story (comments: none)

Events: September 12, 2019 to November 11, 2019

The following event listing is taken from the LWN.net Calendar.

Date(s)	Event	Location
September 7 September 13	Akademy 2019	Milan, Italy
September 11 September 12	Cloud Foundry Summit Europe	The Hague, The Netherlands
September 11 September 13	PostgresOpen	Orlando, FL, USA
September 11 September 13	LibreOffice Conference	Almeria, Spain
September 12	Kernel Maintainer Summit	Lisbon, Portugal
September 12 September 15	GNU Tools Cauldron	Montreal, Canada
September 16 September 20	GNU Radio Conference 2019	Huntsville, AL, USA
September 19 September 20	DPDK Userspace 2019	Bordeaux, France
September 20 September 22	All Systems Go! 2019	Berlin, Germany
September 21	Central Pennsylvania Open Source Conference	Lancaster, PA, USA
September 21 September 23	State of the Map	Heidelberg, Germany
September 23 September 24	Lustre Administrator and Developer Workshop 2019	Paris, France
September 23 September 25	Open Networking Summit	Antwerp, Belgium
September 25 September 27	Kernel Recipes	Paris, France
October 1 October 4	Alpine Linux Persistence and Storage Summit	Lizumerhütte, Tyrol, Austria
October 2 October 4	X.Org Developer's Conference	Montreal, Canada
October 2	OpenInfra Days Italy 2019	Milan, Italy
October 3	OpenInfra Days Italy 2019	Rome, Italy
October 4 October 5	Linux Piter 2019	Saint Petersburg, Russia
October 5 October 6	openSUSE.Asia Summit	Bali, Indonesia
October 7 October 9	LinuxConf [ZA]	Johannesburg, South Africa
October 8	Introduction to Coccinelle	Munich, Germany
October 8 October 9	PostgresConf South Africa 2019	Johannesburg, South Africa
October 8 October 11	Zeek Week (formerly BroCon)	Seattle, WA, USA
October 10 October 13	Ubucon Europe 2019	Sintra, Portugal
October 10 October 11	PyCon ZA 2019	Johannesburg, South Africa
October 12 October 13	WineConf 2019	Toronto, Canada
October 13 October 15	All Things Open	Raleigh, NC, USA
October 15 October 18	PostgreSQL Conference Europe	Milan, Italy
October 19 October 20	OGGCAMP 19	Manchester, UK
October 19	GNU/LinuxDay in Vorarlberg	Dornbirn, Austria
October 22 October 23	LLVM Dev Mtg	San Jose, CA, USA
October 25 October 27	NixCon	Brno, Czech Republic
October 26	FOSS XR Conference	Amsterdam, The Netherlands
October 26	The Future is Open	Rochester, NY, USA
October 26 October 27	Sonoj Convention	Cologne, Germany
October 27 October 30	27th ACM Symposium on Operating Systems Principles	Huntsville, Ontario, Canada
October 28 October 30	Open Source Summit Europe	Lyon, France
October 28 October 30	Embedded Linux Conference	Lyon, France
October 28 October 30	USENIX 33rd Large Installation System Administration Conference	Portland, OR, USA
October 30 November 1	KVM Forum 2019	Lyon, France
October 31	Real-time Linux Summit - At ELCE 2019	Lyon, France
October 31	Automated Testing Summit 2019	Lyon, France
October 31 November 1	Linux Security Summit	Lyon, France
October 31 November 1	GStreamer Conference 2019	Lyon, France
November 1 November 2	Ohio LinuxFest 2019	Columbus, OH, USA
November 2 November 3	OpenFest 2019	Sofia, Bulgaria
November 2 November 3	North Bay Python 2019	Petaluma, CA, USA
November 2 November 3	Konference OpenAlt	Brno, Czechia
November 4 November 6	Open Infrastructure Summit	Shanghai, China
November 4 November 7	Open Source Monitoring Conference	Nuremberg, Germany
November 4 November 8	Tcl 2019 - 26th Annual Tcl/Tk Conference	Houston, TX, USA
November 7	Open Source Camp \| #4 Foreman	Nuremberg, Germany
November 9 November 10	VideoLAN Dev Days 2019	Tokyo, Japan

If your event does not appear here, please tell us about it.

Alert summary September 5, 2019 to September 11, 2019

Dist.	ID	Release	Package	Date
Debian	DSA-4521-1	stable	docker.io	2019-09-09
Debian	DLA-1911-1	LTS	exim4	2019-09-06
Debian	DSA-4517-1	stable	exim4	2019-09-06
Debian	DLA-1912-1	LTS	expat	2019-09-06
Debian	DLA-1910-1	LTS	firefox-esr	2019-09-06
Debian	DSA-4516-1	stable	firefox-esr	2019-09-05
Debian	DLA-1915-1	LTS	ghostscript	2019-09-09
Debian	DSA-4518-1	stable	ghostscript	2019-09-07
Debian	DLA-1914-1	LTS	icedtea-web	2019-09-09
Debian	DSA-4519-1	stable	libreoffice	2019-09-08
Debian	DLA-1913-1	LTS	memcached	2019-09-07
Debian	DSA-4520-1	stable	trafficserver	2019-09-09
Debian	DSA-4515-1	stable	webkit2gtk	2019-09-04
Fedora	FEDORA-2019-e08f78d4a6	F29	SDL	2019-09-08
Fedora	FEDORA-2019-446ca9f695	F30	SDL	2019-09-08
Fedora	FEDORA-2019-5d2420030c	F30	chromium	2019-09-09
Fedora	FEDORA-2019-77d612eab4	F29	grafana	2019-09-08
Fedora	FEDORA-2019-0bb6b876da	F30	grafana	2019-09-08
Fedora	FEDORA-2019-0811a88d77	F30	kea	2019-09-08
Fedora	FEDORA-2019-c1dac1b3b8	F29	lxc	2019-09-06
Fedora	FEDORA-2019-2baa1f7b19	F30	lxc	2019-09-06
Fedora	FEDORA-2019-c1dac1b3b8	F29	lxcfs	2019-09-06
Fedora	FEDORA-2019-2baa1f7b19	F30	lxcfs	2019-09-06
Fedora	FEDORA-2019-96fe76e02b	F30	nsd	2019-09-08
Fedora	FEDORA-2019-6fa01d12b4	F29	pdfbox	2019-09-09
Fedora	FEDORA-2019-9e91afa2be	F30	pdfbox	2019-09-09
Fedora	FEDORA-2019-80e5e20cf8	F29	pdfresurrect	2019-09-06
Fedora	FEDORA-2019-e01bc28777	F30	pdfresurrect	2019-09-06
Fedora	FEDORA-2019-c1dac1b3b8	F29	python3-lxc	2019-09-06
Fedora	FEDORA-2019-2baa1f7b19	F30	python3-lxc	2019-09-06
Fedora	FEDORA-2019-d58eb75449	F29	python38	2019-09-11
Fedora	FEDORA-2019-a457303ffc	F29	rdesktop	2019-09-06
Fedora	FEDORA-2019-baff775841	F30	rdesktop	2019-09-06
Fedora	FEDORA-2019-d9c2f1ec70	F29	roundcubemail	2019-09-08
Fedora	FEDORA-2019-7f7489dc8c	F30	seamonkey	2019-09-06
Fedora	FEDORA-2019-d5bd5f0aa4	F31	systemd	2019-09-04
Gentoo	201909-04		apache	2019-09-06
Gentoo	201909-08		dbus	2019-09-08
Gentoo	201909-06		exim	2019-09-07
Gentoo	201909-07		libsdl2	2019-09-08
Gentoo	201909-03		pango	2019-09-06
Gentoo	201909-01		perl	2019-09-06
Gentoo	201909-02		vlc	2019-09-06
Gentoo	201909-05		webkit-gtk	2019-09-06
Mageia	MGASA-2019-0254	6, 7	SDL12	2019-09-06
Mageia	MGASA-2019-0261	6, 7	dovecot	2019-09-08
Mageia	MGASA-2019-0252	6	giflib	2019-09-06
Mageia	MGASA-2019-0251	6, 7	golang	2019-09-06
Mageia	MGASA-2019-0242	6, 7	icedtea-web	2019-09-06
Mageia	MGASA-2019-0255	7	irssi	2019-09-06
Mageia	MGASA-2019-0241	6, 7	java-1.8.0-openjdk	2019-09-06
Mageia	MGASA-2019-0256	7	libgcrypt	2019-09-06
Mageia	MGASA-2019-0248	6	libmspack	2019-09-06
Mageia	MGASA-2019-0250	6, 7	mercurial	2019-09-06
Mageia	MGASA-2019-0246	6	monit	2019-09-06
Mageia	MGASA-2019-0253	7	php	2019-09-06
Mageia	MGASA-2019-0244	6	poppler	2019-09-06
Mageia	MGASA-2019-0245	7	poppler	2019-09-06
Mageia	MGASA-2019-0258	6	python-urllib3	2019-09-06
Mageia	MGASA-2019-0259	7	python-urllib3	2019-09-06
Mageia	MGASA-2019-0247	6, 7	rdesktop	2019-09-06
Mageia	MGASA-2019-0239	6, 7	sdl2	2019-09-06
Mageia	MGASA-2019-0249	6, 7	sigil	2019-09-06
Mageia	MGASA-2019-0240	6	sqlite3	2019-09-06
Mageia	MGASA-2019-0243	6, 7	subversion	2019-09-06
Mageia	MGASA-2019-0260	7	tomcat	2019-09-08
Mageia	MGASA-2019-0257	6	zstd	2019-09-06
openSUSE	openSUSE-SU-2019:2108-1		SDL2_image	2019-09-10
openSUSE	openSUSE-SU-2019:2070-1	15.0 15.1	SDL2_image	2019-09-05
openSUSE	openSUSE-SU-2019:2109-1		SDL_image	2019-09-10
openSUSE	openSUSE-SU-2019:2071-1	15.0 15.1	SDL_image	2019-09-05
openSUSE	openSUSE-SU-2019:2094-1		chromium	2019-09-08
openSUSE	openSUSE-SU-2019:2081-1	15.0	chromium	2019-09-07
openSUSE	openSUSE-SU-2019:2080-1	15.1	chromium	2019-09-07
openSUSE	openSUSE-SU-2019:2093-1	15.0 15.1	exim	2019-09-08
openSUSE	openSUSE-SU-2019:2072-1	15.0 15.1	go1.11	2019-09-05
openSUSE	openSUSE-SU-2019:2085-1	15.1	go1.12	2019-09-07
openSUSE	openSUSE-SU-2019:2089-1		httpie	2019-09-07
openSUSE	openSUSE-SU-2019:2077-1		libmirage	2019-09-06
openSUSE	openSUSE-SU-2019:2095-1	15.0	libmirage	2019-09-09
openSUSE	openSUSE-SU-2019:2096-1	15.1	libmirage	2019-09-09
openSUSE	openSUSE-SU-2019:2120-1	15.1	nginx	2019-09-11
openSUSE	openSUSE-SU-2019:2114-1	15.0 15.1	nodejs10	2019-09-11
openSUSE	openSUSE-SU-2019:2115-1	15.0 15.1	nodejs8	2019-09-11
openSUSE	openSUSE-SU-2019:2107-1	15.0 15.1	opera	2019-09-10
openSUSE	openSUSE-SU-2019:2078-1		python-SQLAlchemy	2019-09-06
openSUSE	openSUSE-SU-2019:2110-1		python-Twisted	2019-09-10
openSUSE	openSUSE-SU-2019:2068-1	15.0 15.1	python-Twisted	2019-09-05
openSUSE	openSUSE-SU-2019:2118-1	15.0	python-Werkzeug	2019-09-11
openSUSE	openSUSE-SU-2019:2083-1	15.1	srt	2019-09-07
openSUSE	openSUSE-SU-2019:2121-1	15.1	util-linux and shadow	2019-09-11
openSUSE	openSUSE-SU-2019:2067-1	15.0 15.1	wavpack	2019-09-05
Oracle	ELSA-2019-2694	OL6	firefox	2019-09-10
Oracle	ELSA-2019-2663	OL8	firefox	2019-09-06
Oracle	ELSA-2019-2591	OL8	ghostscript	2019-09-06
Oracle	ELSA-2019-2606	OL7	kdelibs and kde-settings	2019-09-04
Oracle	ELSA-2019-4775	OL6	kernel	2019-09-06
Oracle	ELSA-2019-4777	OL6	kernel	2019-09-06
Oracle	ELSA-2019-2600	OL7	kernel	2019-09-04
Oracle	ELSA-2019-4775	OL7	kernel	2019-09-06
Oracle	ELSA-2019-2692	OL8	nghttp2	2019-09-10
Oracle	ELSA-2019-2607	OL7	qemu-kvm	2019-09-04
Red Hat	RHSA-2019:2732-01	EL7	.NET Core	2019-09-11
Red Hat	RHSA-2019:2731-01	EL8	.NET Core	2019-09-11
Red Hat	RHSA-2019:2698-01	EL7.4	bind	2019-09-10
Red Hat	RHSA-2019:2670-01	EL6	chromium-browser	2019-09-05
Red Hat	RHSA-2019:2694-01	EL6	firefox	2019-09-10
Red Hat	RHSA-2019:2729-01	EL7	firefox	2019-09-11
Red Hat	RHSA-2019:2663-01	EL8	firefox	2019-09-04
Red Hat	RHSA-2019:2726-01	EL8	go-toolset:rhel8	2019-09-10
Red Hat	RHSA-2019:2695-01	EL6.5	kernel	2019-09-10
Red Hat	RHSA-2019:2696-01	EL7.4	kernel	2019-09-10
Red Hat	RHSA-2019:2703-01	EL8	kernel	2019-09-10
Red Hat	RHSA-2019:2722-01	EL8	libwmf	2019-09-11
Red Hat	RHSA-2019:2692-01	EL8	nghttp2	2019-09-09
Red Hat	RHSA-2019:2720-01	EL8	pki-deps:10.6	2019-09-11
Red Hat	RHSA-2019:2699-01	EL7.4	polkit	2019-09-10
Red Hat	RHSA-2019:2713-01	EL8	poppler	2019-09-11
Scientific Linux	SLSA-2019:2694-1	SL6	firefox	2019-09-10
Slackware	SSA:2019-247-01		seamonkey	2019-09-04
SUSE	SUSE-SU-2019:2312-1		SUSE Manager Client Tools	2019-09-05
SUSE	SUSE-SU-2019:14163-1	SLE11	SUSE Manager Client Tools	2019-09-05
SUSE	SUSE-SU-2019:2317-1	SLE15	SUSE Manager Client Tools	2019-09-06
SUSE	SUSE-SU-2019:2329-1	SLE12	apache2	2019-09-06
SUSE	SUSE-SU-2019:2341-1	SLE15	buildah	2019-09-10
SUSE	SUSE-SU-2019:2339-1		curl	2019-09-10
SUSE	SUSE-SU-2019:2347-1	SLE12	ghostscript	2019-09-10
SUSE	SUSE-SU-2019:2348-1	SLE15	ghostscript	2019-09-10
SUSE	SUSE-SU-2019:2336-1	OS7 OS8 SLE12 SES4 SES5	java-1_7_1-ibm	2019-09-09
SUSE	SUSE-SU-2019:2291-1	SLE15	java-1_8_0-ibm	2019-09-04
SUSE	SUSE-SU-2019:2299-1	OS7 SLE12 SES4	kernel	2019-09-05
SUSE	SUSE-SU-2019:2349-1	SLE15	libgcrypt	2019-09-10
SUSE	SUSE-SU-2019:2330-1	OS9 SLE12	mariadb, mariadb-connector-c	2019-09-06
SUSE	SUSE-SU-2019:2309-1	SLE15	nginx	2019-09-05
SUSE	SUSE-SU-2019:2346-1	SLE15	podman	2019-09-10
SUSE	SUSE-SU-2019:2158-1	OS7 SLE12 SES4	postgresql94	2019-09-07
SUSE	SUSE-SU-2019:2335-1	OS9	python-Django1	2019-09-09
SUSE	SUSE-SU-2019:2334-1	OS7 SES4	python-Pillow	2019-09-09
SUSE	SUSE-SU-2019:2350-1	OS7 SES4	python-SQLAlchemy	2019-09-10
SUSE	SUSE-SU-2019:2308-1	SLE15	python-Werkzeug	2019-09-05
SUSE	SUSE-SU-2019:2300-1	OS8	python-urllib3	2019-09-05
SUSE	SUSE-SU-2019:2331-1	SLE15	python-urllib3	2019-09-09
SUSE	SUSE-SU-2019:2332-1	SLE15	python-urllib3	2019-09-09
SUSE	SUSE-SU-2019:2157-1	OS7 SLE12 SES4	qemu	2019-09-06
SUSE	SUSE-SU-2019:2353-1	SLE12	qemu	2019-09-11
SUSE	SUSE-SU-2019:2340-1	SLE15	skopeo	2019-09-10
SUSE	SUSE-SU-2019:2307-1	SLE15	util-linux and shadow	2019-09-05
SUSE	SUSE-SU-2019:2345-1	SLE12	webkit2gtk3	2019-09-10
Ubuntu	USN-4129-1	16.04 18.04 19.04	curl	2019-09-11
Ubuntu	USN-4124-1	16.04 18.04 19.04	exim4	2019-09-06
Ubuntu	USN-4122-1	16.04 18.04 19.04	firefox	2019-09-04
Ubuntu	USN-4126-2	12.04 14.04	freetype	2019-09-09
Ubuntu	USN-4126-1	16.04	freetype	2019-09-09
Ubuntu	USN-4115-2	16.04 18.04	linux-hwe, linux-kvm, linux-oracle, linux-raspi2	2019-09-10
Ubuntu	USN-4125-1	16.04 18.04 19.04	memcached	2019-09-09
Ubuntu	USN-4123-1	18.04 19.04	npm/fstream	2019-09-05
Ubuntu	USN-4127-2	12.04 14.04	python2.7, python3.4	2019-09-10
Ubuntu	USN-4127-1	16.04 18.04 19.04	python2.7, python3.5, python3.6, python3.7	2019-09-09
Ubuntu	USN-4120-2	18.04 19.04	systemd	2019-09-10
Ubuntu	USN-4128-1	16.04 18.04	tomcat8	2019-09-10

Full Story (comments: none)

Linus Torvalds Linux 5.3-rc8 Sep 08

Greg KH Linux 5.2.14 Sep 10

Greg KH Linux 5.2.13 Sep 06

Greg KH Linux 5.2.12 Sep 06

Greg KH Linux 4.19.72 Sep 10

Greg KH Linux 4.19.71 Sep 06

Greg KH Linux 4.19.70 Sep 06

Greg KH Linux 4.14.143 Sep 10

Greg KH Linux 4.14.142 Sep 06

Greg KH Linux 4.9.192 Sep 10

Greg KH Linux 4.9.191 Sep 06

Greg KH Linux 4.4.192 Sep 10

Greg KH Linux 4.4.191 Sep 06

Pavel Tatashin arm64: MMU enabled kexec relocation Sep 09

David Howells Keyrings, Block and USB notifications [ver #8] Sep 04

Miroslav Benes livepatch: Clear relocation targets on a module removal Sep 05

Daniel Jordan padata: use unbound workqueues for parallel jobs Sep 05

Matthias Maennich Symbol Namespaces Sep 06

Alex Kogan Add NUMA-awareness to qspinlock Sep 06

Rik van Riel sched,fair: flatten CPU controller runqueues Sep 06

Carlos Neira BPF: New helper to obtain namespace data from current task Sep 06

Pi-Hsun Shih Add support for mt8183 SCP. Sep 05

Jonathan Chocron Amazon's Annapurna Labs DT-based PCIe host controller driver Sep 05

Vladimir Oltean Deterministic SPI latency with NXP DSPI driver Sep 05

dongchun.zhu@mediatek.com media: i2c: add support for DW9768 VCM driver Sep 05

Jerry-ch Chen media: platform: Add support for Face Detection (FD) on mt8183 SoC Sep 06

frederic.chen@mediatek.com media: platform: Add support for Digital Image Processing (DIP) on mt8183 SoC Sep 10

Alexandre Courbot media: mtk-vcodec: support for MT8183 decoder Sep 06

Ben Chuang Add Genesys Logic GL975x support Sep 06

Vinod Koul UFS: Add support for SM8150 UFS Sep 06

Roger Lu PM / AVS: SVS: Introduce SVS engine Sep 06

Jacopo Mondi [PATCH v4 0/9 drm: rcar-du: Add Color Management Module (CMM) Sep 06

Corentin Labbe crypto: add sun8i-ce driver for Allwinner crypto engine Sep 06

dongchun.zhu@mediatek.com media: i2c: Add support for OV02A10 sensor Sep 07

Guido Günther drm: bridge: Add NWL MIPI DSI host controller support Sep 08

Talel Shenhar Amazon's Annapurna Labs POS Driver Sep 09

Jean-Jacques Hiblot Add a generic driver for LED-based backlight Sep 10

Nuno Sá iio: temperature: Add support for LTC2983 Sep 09

Thara Gopinath Introduce Power domain based warming device driver Sep 10

Geert Uytterhoeven gpio: Add GPIO Aggregator Driver Sep 11

Lu Baolu iommu: Bounce page for untrusted devices Sep 06

Peter Ujfalusi dmaengine: Support for DMA domain controllers Sep 06

John Stultz DMA-BUF Heaps (destaging ION) Sep 06

Dmitry Torokhov software node: add support for reference properties Sep 09

Eugen.Hristev@microchip.com i2c: add support for filters Sep 11

Ben Hutchings Documentation: kbuild: Add document about reproducible builds Sep 11

Aleksa Sarai namei: openat2(2) path resolution restrictions Sep 05

Darrick J. Wong fs: New zonefs file system Sep 04

Omar Sandoval Btrfs: add interface for writing compressed extents directly Sep 04

Tejun Heo blk-iocost: Implement absolute debt handling Sep 04

Goldwyn Rodrigues CoW support for iomap Sep 05

Allison Collins XFS Delayed Attributes Sep 05

Qu Wenruo btrfs: Introduce new rescue= mount options Sep 06

Mickaël Salaün Add support for O_MAYEXEC Sep 06

Matthew Bobrowski ext4: port direct IO to iomap infrastructure Sep 09

Peter Xu mm: Page fault enhancements Sep 05

Roman Gushchin The new slab memory controller Sep 05

Matthew Wilcox Large pages in the page cache Sep 05

Stephen Boyd Read-only memremap() Sep 10

Mina Almasry hugetlb_cgroup: Add hugetlb_cgroup reservation limits Sep 10

Dave Taht more IPv4 unicast extensions Sep 09

Alan Maguire bpf: packet capture helpers, bpftool support Sep 07

Sabrina Dubroca ipsec: add TCP encapsulation support (RFC 8229) Sep 11

Alexei Starovoitov capability: introduce CAP_BPF and CAP_TRACING Sep 04

James Bottomley add integrity and security to TPM2 transactions Sep 09

KP Singh Kernel Runtime Security Instrumentation Sep 10

Liu Yi L vfio_pci: wrap pci device as a mediated device Sep 05

Alexander Duyck [PATCH v8 0/7] mm / virtio: Provide support for unused page reporting Sep 06

Miklos Szeredi virtio-fs: shared file system for virtual machines Sep 10

David Sterba Btrfs progs release 5.2.2 Sep 05

LWN.net Weekly Edition for September 12, 2019

Plug and print

Scanning

Graduations

Failures

Staging out

Hangers-on

Exit stage right

USB basics

Sniffing USB

Fuzzing

SGX and enclaves

SGX and LSMs

Details of the problem

Toward a solution

The twist

Summary

Yak shaving

The Chrome OS kernel tree

Learning from the mistakes of Android

Brief items

Security

Kernel development

Distributions

Development

Miscellaneous

Announcements

Newsletters

Distributions and system administration

Development

Meeting minutes

Miscellaneous

Calls for Presentations

CFP Deadlines: September 12, 2019 to November 11, 2019

Upcoming Events

Events: September 12, 2019 to November 11, 2019

Security updates

Kernel patches of interest

Kernel releases

Architecture-specific

Core kernel

Device drivers

Device-driver infrastructure

Documentation

Filesystems and block layer

Memory management

Networking

Security-related

Virtualization and containers

Miscellaneous