Language Selection

English French German Italian Portuguese Spanish

Kernel Planet

Syndicate content
Kernel Planet -
Updated: 2 hours 49 min ago

Linux Plumbers Conference: Linux Plumbers Conference is Not Sold Out

Friday 3rd of July 2020 05:32:56 PM

We’re really sorry, but apparently the Cvent registration site we use has suffered a bug which is causing it to mark the conference as “Sold Out” and, unfortunately, since today is the beginning of the American Independence day weekend, we can’t get anyone to fix it until Monday. However, rest assured there are plenty of places still available, so if you can wait until Monday, you should be able to register for the conference as soon as the site is fixed.

Again, we’re really sorry for the problem and the fact that fixing it will take a further three days.

Linux Plumbers Conference: Networking and BPF Summit CfP Now Open

Wednesday 1st of July 2020 10:41:18 PM

We are pleased to announce that the Call for Proposals for the Networking and BPF Summit at Linux Plumbers Conference 2020 is now open.

Please submit your proposals here.

Looking forward to seeing your great contributions!

Linux Plumbers Conference: Announcing Town Hall #2: The Kernel Weather Report

Wednesday 1st of July 2020 10:02:35 PM

Thank you to everyone who attended the Linux Plumbers town hall on June 25th. It was successful thanks to your participation. We’re pleased to announce another town hall on July 16th at 8am PST / 11am EST / 3pm GMT. This town hall will feature Jon Corbet of LWN giving “The Kernel Weather Report”.

The Linux kernel is at the core of any Linux system; the performance and capabilities of the kernel will, in the end, place an upper bound on what the system as a whole can do. This talk will review recent events in the kernel development community, discuss the current state of the kernel and the challenges it faces, and look forward to how the kernel may address those challenges. Attendees of any technical ability should gain a better understanding of how the kernel got to its current state and what can be expected in the near future.

Please note that the Plumbers Code of Conduct will be in effect for this event. We also plan to record this event. We will post the URL for the town hall on the LPC blog prior to the event. We hope to see you there and help make Plumbers the best conference for everyone.

Linux Plumbers Conference: How to Join the LPC Town Hall

Thursday 25th of June 2020 12:41:46 AM

Please use the following link on Thursday June 25 2020 at 8am PDT/ 11am EDT/ 3pm GMT to join the LPC Town Hall:
Note that no account is necessary!

Please refer to the previous post about the Town Hall to get more info.
See you there!

Matthew Garrett: Making my doorbell work

Wednesday 24th of June 2020 08:25:43 AM
I recently moved house, and the new building has a Doorbird to act as a doorbell and open the entrance gate for people. There's a documented local control API (no cloud dependency!) and a Home Assistant integration, so this seemed pretty straightforward.

Unfortunately not. The Doorbird is on separate network that's shared across the building, provided by Monkeybrains. We're also a Monkeybrains customer, so our network connection is plugged into the same router and antenna as the Doorbird one. And, as is common, there's port isolation between the networks in order to avoid leakage of information between customers. Rather perversely, we are the only people with an internet connection who are unable to ping my doorbell.

I spent most of the past few weeks digging myself out from under a pile of boxes, but we'd finally reached the point where spending some time figuring out a solution to this seemed reasonable. I spent a while playing with port forwarding, but that wasn't ideal - the only server I run is in the UK, and having packets round trip almost 11,000 miles so I could speak to something a few metres away seemed like a bad plan. Then I tried tethering an old Android device with a data-only SIM, which worked fine but only in one direction (I could see what the doorbell could see, but I couldn't get notifications that someone had pushed a button, which was kind of the point here).

So I went with the obvious solution - I added a wifi access point to the doorbell network, and my home automation machine now exists on two networks simultaneously (nmcli device modify wlan0 ipv4.never-default true is the magic for "ignore the gateway that the DHCP server gives you" if you want to avoid this), and I could now do link local service discovery to find the doorbell if it changed addresses after a power cut or anything. And then, like magic, everything worked - I got notifications from the doorbell when someone hit our button.

But knowing that an event occurred without actually doing something in response seems fairly unhelpful. I have a bunch of Chromecast targets around the house (a mixture of Google Home devices and Chromecast Audios), so just pushing a message to them seemed like the easiest approach. Home Assistant has a text to speech integration that can call out to various services to turn some text into a sample, and then push that to a media player on the local network. You can group multiple Chromecast audio sinks into a group that then presents as a separate device on the network, so I could then write an automation to push audio to the speaker group in response to the button being pressed.

That's nice, but it'd also be nice to do something in response. The Doorbird exposes API control of the gate latch, and Home Assistant exposes that as a switch. I'm using Home Assistant's Google Assistant integration to expose devices Home Assistant knows about to voice control. Which means when I get a house-wide notification that someone's at the door I can just ask Google to open the door for them.

So. Someone pushes the doorbell. That sends a signal to a machine that's bridged onto that network via an access point. That machine then sends a protobuf command to speakers on a separate network, asking them to stream a sample it's providing. Those speakers call back to that machine, grab the sample and play it. At this point, multiple speakers in the house say "Someone is at the door". I then say "Hey Google, activate the front gate" - the device I'm closest to picks this up and sends it to Google, where something turns my speech back into text. It then looks at my home structure data and realises that the "Front Gate" device is associated with my Home Assistant integration. It then calls out to the home automation machine that received the notification in the first place, asking it to trigger the front gate relay. That device calls out to the Doorbird and asks it to open the gate. And now I have functionality equivalent to a doorbell that completes a circuit and rings a bell inside my home, and a button inside my home that completes a circuit and opens the gate, except it involves two networks inside my building, callouts to the cloud, at least 7 devices inside my home that are running Linux and I really don't want to know how many computational cycles.

The future is wonderful.

(I work for Google. I do not work on any of the products described in this post. Please god do not ask me how to integrate your IoT into any of this)


Linux Plumbers Conference: Registration for Linux Plumbers Conference 2020 is now open

Tuesday 23rd of June 2020 09:30:35 PM

Registration is now open for the 2020 edition of the Linux Plumbers Conference (LPC). It will be held August 24 – 28, virtually. Go to the attend page for more information.

Note that the CFPs for microconferences, refereed track talks, and BoFs are still open, please see this page for more information.

As always, please contact the organizing committee if you have questions.

Linux Plumbers Conference: Kernel Dependability and Assurance Microconference Accepted into 2020 Linux Plumbers Conference

Monday 22nd of June 2020 01:52:18 PM

We are pleased to announce that the Kernel Dependability & Assurance Microconference has been accepted into the 2020 Linux Plumbers Conference!

Linux is now being used in applications that are going to require a high degree of confidence that the kernel is going to behave as expected. Some of the key areas we’re seeing Linux now start to be used are in medical devices, civil infrastructure, caregiving robots, automotives, etc. This brings up a number of concerns that must be addressed. What sort of uptime can we count on? Should safety analysis be reevaluated after a bug fix has been made? Are all the system requirements being satisfied by Linux? What tooling is there to solve these questions?

This microconference is the place that the kernels community can come together and discuss these major issues. Topics to be discussed include:

  • Kernel Quality Assurance beyond Testing and CI
  • Understanding the Users’ Expectations on Software Quality for safety critical systems:
    • Define safety requirements for overall kernel: features, tests etc.
    • Define run-time characteristics and requirements
  • Identify missing features necessary to operate in safety critical environments.
  • Regression Testing for safety: Identify configurations and tests critical and important for safety quality and dependability:
    • Discuss and identify gaps in tests.
    • Add tests and add configurations to existing test rings.
  • Understanding the Kernel Development Organisation and Management
  • Assessing, Measuring and Evaluating the Development Process

Come and join us in making the most popular operating system the most dependable as well. We hope to see you there!

Linux Plumbers Conference: Announcing a Linux Plumbers Virtual Town Hall

Friday 19th of June 2020 04:03:01 PM

The Linux Plumbers Committee is pleased to announce a Town Hall meeting on June 25 at 8am PDT/ 11am EDT/ 3pm GMT. This meeting serves two purposes. The first purpose is to test our remote conference set up. This is the first time we are holding Linux Plumbers virtually and while we can run simulated tests, it’s much more effective to test our setup with actual participants with differing hardware set ups around the world. The second purpose is to present on our planning and give everyone a little bit of an idea of what to expect when we hold Plumbers at the end of August. We plan to have time for questions.

Given this is a test, the number of participants will be capped at 250 people. The purpose of this test is to examine the scale to which the infrastructure can handle the expected demand for a virtual Linux Plumbers Conference. If you can’t make this day or are blocked by the participation cap from joining, we expect to be running more tests in the days to come.

Please note that the Plumbers Code of Conduct will be in effect for this event. We also plan to record this event as we will be recording sessions at the actual conference. We will post the URL for the town hall on the LPC blog prior to the event. We hope to see you there and help make Plumbers the best conference for everyone.

Paul E. Mc Kenney: Stupid RCU Tricks: So you want to torture RCU?

Tuesday 16th of June 2020 08:42:19 PM
Let's face it, using synchronization primitives such as RCU can be frustrating. And it is only natural to wish to get back, somehow, at the source of such frustration. In short, it is quite understandable to want to torture RCU. (And other synchronization primitives as well, but you have to start somewhere!) Another benefit of torturing RCU is that doing so sometimes uncovers bugs in other parts of the kernel. You see, RCU is not always willing to suffer alone.

One long-standing RCU-torture approach is to use modprobe and rmmod to install and remove the rcutorture module, as described in the torture-test documentation. However, this approach requires considerable manual work to check for errors.

On the other hand, this approach avoids any concern about the underlying architecture or virtualization technology. This means that use of modprobe and rmmod is the method of choice if you wish to torture RCU on (say) SPARC or when running on Hyper-V (this last according to people actually doing this). This method is also necessary when you want to torture RCU on a very specific kernel configuration or when you need to torture RCU on bare metal.

But for those of us running mainline kernels on x86 systems supporting virtualization, the approach described in the remainder of this document will usually be more convenient.

Running rcutorture in a Guest OSIf you have an x86 system (or, with luck, an ARMv8 or PowerPC system) set up to run qemu and KVM, you can instead use the rcutorture scripting, which automates running rcutorture over a full set of configurations, as well as automating analysis of the build products and console output. Running this can be as simple as:

As of v5.8-rc1, this will build and run each of nineteen combinations of Kconfig options, with each run taking 30 minutes for a total of 8.5 hours, not including the time required to build the kernel, boot the guest OS, and analyze the test results. Given that a number of the scenarios use only a single CPU, this approach can be quite wasteful, especially on the well-endowed systems of the year 2020.

This waste can be avoided by using the --cpus argument, for example, for the 12-hardware-thread laptop on which I am typing this, you could do the following:

tools/testing/selftests/rcutorture/bin/ --cpus 12
This command would run up to 12 CPUs worth of rcutorture scenarios concurrently, so that the nineteen combinations would be run in eight batches. Because TREE03 and TREE07 each want 16 CPUs, rcutorture will complain in its run summary as follows:

--- Mon Jun 15 10:23:02 PDT 2020 Test summary: Results directory: /home/git/linux/tools/testing/selftests/rcutorture/res/2020.06.15-10.23.02 tools/testing/selftests/rcutorture/bin/ --cpus 12 --duration 5 --trust-make RUDE01 ------- 2102 GPs (7.00667/s) [tasks-rude: g0 f0x0 ] SRCU-N ------- 42229 GPs (140.763/s) [srcu: g549860 f0x0 ] SRCU-P ------- 11887 GPs (39.6233/s) [srcud: g110444 f0x0 ] SRCU-t ------- 59641 GPs (198.803/s) [srcu: g1 f0x0 ] SRCU-u ------- 59209 GPs (197.363/s) [srcud: g1 f0x0 ] TASKS01 ------- 1029 GPs (3.43/s) [tasks: g0 f0x0 ] TASKS02 ------- 1043 GPs (3.47667/s) [tasks: g0 f0x0 ] TASKS03 ------- 1019 GPs (3.39667/s) [tasks: g0 f0x0 ] TINY01 ------- 43373 GPs (144.577/s) [rcu: g0 f0x0 ] n_max_cbs: 34463 TINY02 ------- 46519 GPs (155.063/s) [rcu: g0 f0x0 ] n_max_cbs: 2197 TRACE01 ------- 756 GPs (2.52/s) [tasks-tracing: g0 f0x0 ] TRACE02 ------- 559 GPs (1.86333/s) [tasks-tracing: g0 f0x0 ] TREE01 ------- 8930 GPs (29.7667/s) [rcu: g64765 f0x0 ] TREE02 ------- 17514 GPs (58.38/s) [rcu: g138645 f0x0 ] n_max_cbs: 18010 TREE03 ------- 15920 GPs (53.0667/s) [rcu: g159973 f0x0 ] n_max_cbs: 1025308 CPU count limited from 16 to 12 TREE04 ------- 10821 GPs (36.07/s) [rcu: g70293 f0x0 ] n_max_cbs: 81293 TREE05 ------- 16942 GPs (56.4733/s) [rcu: g123745 f0x0 ] n_max_cbs: 99796 TREE07 ------- 8248 GPs (27.4933/s) [rcu: g52933 f0x0 ] n_max_cbs: 183589 CPU count limited from 16 to 12 TREE09 ------- 39903 GPs (133.01/s) [rcu: g717745 f0x0 ] n_max_cbs: 83002
However, other than these two complaints, this is what the summary of an uneventful rcutorture run looks like.

Whatever is the meaning of all those numbers in the summary???

The console output for each run and much else besides may be found in the /home/git/linux/tools/testing/selftests/rcutorture/res/2020.06.15-10.23.02 directory called out above.

The more CPUs you have, the fewer batches are required:

CPUsBatches 119 216 413 810 166 323 642 1281

If you specify more CPUs than your system actually has, will ignore your fantasies in favor of your system's reality.

Specifying Specific ScenariosSometimes it is useful to take one's ire out on a specific type of RCU, for example, SRCU. You can use the --configs argument to select specific scenarios:

tools/testing/selftests/rcutorture/bin/ --cpus 12 \ --configs "SRCU-N SRCU-P SRCU-t SRCU-u"
This runs in two batches, but the second batch uses only two CPUs, which is again wasteful. Given that SRCU-P requires eight CPUs, SRCU-N four CPUs, and SRCU-t and SRCU-u one each, it would cost nothing to run two instances of each of these scenarios other than SRCU-N as follows:

tools/testing/selftests/rcutorture/bin/ --cpus 12 \ --configs "SRCU-N 2*SRCU-P 2*SRCU-t 2*SRCU-u"
This same notation can be used to run multiple copies of the entire list of scenarios. For example (again, in v5.7), a system with 384 CPUs can use --configs 4*CFLIST to run four copies of of the full set of scenarios as follows:

tools/testing/selftests/rcutorture/bin/ --cpus 384 --configs "4*CFLIST"
Mixing and matching is permissible, for example:

tools/testing/selftests/rcutorture/bin/ --cpus 384 --configs "3*CFLIST 12*TREE02"
A script that is to run on a wide variety of systems can benefit from --allcpus (expected to appear in v5.9), which acts like --cpus N, where N is the number of CPUs on the current system:

tools/testing/selftests/rcutorture/bin/ --allcpus --configs "3*CFLIST 12*TREE02"
Build time can dominate when running a large number of short-duration runs, for example, when chasing down a low-probability non-deterministic boot-time failure. Use of --trust-make can be very helpful in this case:

tools/testing/selftests/rcutorture/bin/ --cpus 384 --duration 2 \ --configs "1000*TINY01" --trust-make
Without --trust-make, rcutorture will play it safe by forcing your source tree to a known state between each build. In addition to --trust-make, there are a number of tools such as ccache that can also greatly reduce build times.

Locating Test FailuresAlthough the ability to automatically run many tens of scenarios can be very convenient, it can also cause significant eyestrain staring through a long “summary” checking for test failures. Therefore, if there are failures, this is noted at the end of the summary, for example, as shown in the following abbreviated output from a --configs "28*TREE03" run:

TREE03.8 ------- 1195094 GPs (55.3284/s) [rcu: g11475633 f0x0 ] n_max_cbs: 1449125 TREE03.9 ------- 1202936 GPs (55.6915/s) [rcu: g11572377 f0x0 ] n_max_cbs: 1514561 3 runs with runtime errors.
Of course, picking the three errors out of the 28 runs can also cause eyestrain, so there is yet another useful little script:

tools/testing/selftests/rcutorture/bin/ \ /home/git/linux/tools/testing/selftests/rcutorture/res/2020.06.15-10.23.02
This will run your editor on the make output for each build error and on the console output for each runtime failure, greatly reducing eyestrain. Users of vi can also edit a summary of the runtime errors from each failing run as follows:

vi /home/git/linux/tools/testing/selftests/rcutorture/res/2020.06.15-10.23.02/*/console.log.diags
Enlisting Torture AssistanceIf rcutorture produces a failure-free run, that is a failure on the part of rcutorture. After all, there are bugs in there somewhere, and rcutorture failed to find them!

One approach is to increase the duration, for example, to 12 hours (also known as 720 minutes):

tools/testing/selftests/rcutorture/bin/ --cpus 12 --duration 720
Another approach is to enlist the help of other in-kernel torture features, for example, lockdep. The --kconfig parameter to can be used to this end:

tools/testing/selftests/rcutorture/bin/ --cpus 12 --configs "TREE03" \ --kconfig "CONFIG_DEBUG_LOCK_ALLOC=y CONFIG_PROVE_LOCKING=y"
The aid of the kernel address sanitizer (KASAN) can be enlisted using the --kasan argument:

tools/testing/selftests/rcutorture/bin/ --cpus 12 --kasan
The kernel concurrency sanitizer (KCSAN) can also be brought to bear, but proper use of KCSAN requires some thought (see part 1 and part 2 of the LWN “Concurrency bugs should fear the big bad data-race detector” article) and also version 11 or later of Clang/LLVM (and a patch for GCC has been accepted). Once you have all of that in place, the --kcsan argument invokes KCSAN and also generates a summary as described in part 1 of the aforementioned LWN article. Note again that only very recent compiler versions (such as Clang-11) support KCSAN, so a --kmake "CC=clang-11" or similar argument might also be necessary.

Selective TorturingSometimes enlisting debugging aid is the best approach, but other times greater selectivity is the best way forward.

Sometimes simply building a kernel is torture enough, especially when building with unusual Kconfig options (see the discussion of --kconfig above). In this case, specifying the --buildonly argument will build the kernels, but refrain from running them. This approach can also be useful for running multiple copies of the resulting binaries on multiple systems: You can use the --buildonly to build the kernels and qemu-cmd scripts, and then run these files on the other systems, given suitable adjustments to the qemu-cmd scripts.

Other times it is useful to torture some specific portion of RCU. For example, one wishing to vent their ire solely on expedited grace periods could add --bootargs "rcutorture.gp_exp=1" to the command line. This argument causes rcutorture to run a stress test using only expedited RCU grace periods, which can be helpful when attempting to work out whether a too-short RCU grace period is due to a bug in the normal or the expedited grace-period code. Similarly, the callback-flooding aspects of rcutorture stress testing can be disabled using --bootargs "rcutorture.fwd_progress=0". It is possible to specify both in one run using --bootargs "rcutorture.gp_exp=1 rcutorture.fwd_progress=0".

Enlisting Debugging AssistanceStill other times, it is helpful to enable event tracing. For example, if the rcu_barrier() event traces are of interest, use --bootargs "trace_event=rcu:rcu_barrier". The trace buffer will be dumped automatically upon specific rcutorture failures. If the failure mode is instead a non-rcutorture-specific oops, use this: --bootargs "trace_event=rcu:rcu_barrier ftrace_dump_on_oops". If it is also necessary to dump the trace buffers on warnings, a (heavy handed) way to achieve this is to use --bootargs "trace_event=rcu:rcu_barrier ftrace_dump_on_oops panic_on_warn".

If you have many tens of rcutorture instances that all decide to flush their trace buffers at about the same time, the combined flushing operations can take considerable time, especially if the underlying system features rotating rust. If only the most recent activity is of interest, specifying a small trace buffer can help: --bootargs "trace_event=rcu:rcu_barrier ftrace_dump_on_oops panic_on_warn trace_buf_size=3k".

If only the oopsing/warning CPU's traces are relevant, the orig_cpu modifier can be helpful: --bootargs "trace_event=rcu:rcu_barrier ftrace_dump_on_oops=orig_cpu panic_on_warn trace_buf_size=3k".

More information on tracing can be found in Documentation/trace, and more on kernel boot parameters in general may be found in kernel-parameters.txt. Given the multi-thousand-line heft of this latter, there is clearly great scope for tweaking your torturing of RCU!

Why Stop at Torturing RCU?After all, locking can sometimes be almost as annoying as RCU. And it is possible to torture locking:

tools/testing/selftests/rcutorture/bin/ --allcpus --torture lock
This locktorture stress test does not get as much love and attention as does rcutorture, but it is at least a start.

There are also a couple of RCU performance tests and an upcoming smp_call_function*() stress test that use this same torture-test infrastructure. Please note that the details of the summary output varies from test to test.

In short, you can do some serious torturing of RCU, and much else besides! So show them no mercy!!! :-)

James Morris: Linux Security Summit North America 2020: Online Schedule

Tuesday 16th of June 2020 01:28:07 AM

Just a quick update on the Linux Security Summit North America (LSS-NA) for 2020.

The event will take place over two days as an online event, due to COVID-19.  The dates are now July 1-2, and the full schedule details may be found here.

The main talks are:

There are also short (30 minute) topics:

This year we will also have a Q&A panel at the end of each day, moderated by Elena Reshetova. The panel speakers are:

  • Nayna Jain
  • Andrew Lutomirski
  • Dmitry Vyukov
  • Emily Ratliff
  • Alexander Popov
  • Christian Brauner
  • Allison Marie Naaktgeboren
  • Kees Cook
  • Mimi Zohar

LSS-NA this year is included with OSS+ELC registration, which is USD $50 all up.  Register here.

Hope to see you soon!

Linux Plumbers Conference: Linux Plumbers Conference Registration Opening Postponed

Monday 15th of June 2020 05:20:49 PM

The committee is relentlessly working on recreating online the Linux Plumbers Conference (LPC) experience that we have all come to appreciate, and take for granted, over the past few years.

We had initially planned to open registration on June 15th. While travel planning is not one, there are still very many aspects of the conference being worked on. We are now aiming to open registration for Linux Plumbers Conference (LPC) on June 23rd.

Right now we have shortlisted BigBlueButton as our online conferencing solution. One of our objectives is to run LPC 2020 online on a full open software stack.

We anticipate running our usual set of parallel tracks, including microconferences per day. With our globally distributed participants, identifying the timezone most convenient is still work in progress. There will be a timezone question on our registration form, please make sure to answer it.

To help us test part of the online platform, and offer transparency about where things stand with LPC 2020 preparation, the committee is currently planning the first ever “LPC Town Hall Meeting”. We hope to host it very soon. More information will be made available very soon.

As previously announced, we are reducing the conference registration fee to US$50. Registration availability has been an issue in past years. We have no way to anticipate what the uptake will be for LPC 2020 registration. The committee will try its best to meet registration demand. Also, several Call for Proposals are open and awaiting your contributions.

We will be sharing more information with everyone here soon. Looking forward to LPC 2020 together with you.

Linux Plumbers Conference: Real-time Microconference Accepted into 2020 Linux Plumbers Conference

Monday 15th of June 2020 02:19:59 PM

We are pleased to announce that the Real-time Microconference has been accepted into the 2020 Linux Plumbers Conference!

After another successful Real-time microconference at LPC last year, there’s still more to work to be done. The PREEMPT_RT patch set (aka “The Real-Time Patch”) was created in 2004 in the effort to make Linux into a hard real-time designed operating system. Over the years much of the RT patch has made it into mainline Linux, which includes: mutexes, lockdep, high resolution timers, Ftrace, RCU_PREEMPT, priority inheritance, threaded interrupts and much more. There’s just a little left to get RT fully into mainline, and the light at the end of the tunnel is finally in view. It is expected that the RT patch will be in mainline within a year (and possibly before Plumbers begins!), which changes the topics of discussion. Once it is in Linus’s tree, a whole new set of issues must be handled.

The focus on this years Plumbers events will include:

  • Status of the PREEMPT_RT Merge
  • Merge – what is missing and who can help?
  • New tools for PREEMPT_RT analysis.
  • How do we teach the rest of the kernel developers how not to break PREEMPT_RT?
  • Stable maintainers tools discussion & improvements.
  • The usage of PREEMPT_RT on safety critical-systems: what do we need to do?
  • Interrupt threads are RT and are not protected by the RT Throttling. How can we prevent interrupt thread starvation from a rogue RT task?

Linux Plumbers Conference: Scheduler Microconference Accepted into 2020 Linux Plumbers Conference

Thursday 11th of June 2020 02:11:22 PM

We are pleased to announce that the Scheduler Microconference has been accepted into the 2020 Linux Plumbers Conference!

The scheduler is an important functionality of the Linux kernel as it decides what gets to run, when and for how long. With different topologies and workloads this is no easy task to give the user the best experience possible. During the Scheduler microconference at LPC last year, we started the work to make SCHED_DEADLINE safe for kthreads and improving load balancing. This year, we continue working on core scheduling, unifying the interface for TurboSched and task latency nice, and continue the discussion on proxy execution.

Topics to be discussed include:

  • Core Scheduling – How do we merge?
  • Capacity Awareness – For busy systems
  • Interrupt Awareness
  • Proxy Execution – More cases
  • Latency Nice – What interfaces do our use cases like?
  • Load Balancing
  • NUMA load balancing
  • Formal specification of SCHED_DEADLINE
  • Flattening CPU RQ hierarchy

Come and join us in the discussion of controlling what tasks get to run on your machine and when. We hope to see you there!

Michael Kerrisk (manpages): man-pages-5.07 is released

Tuesday 9th of June 2020 05:09:11 PM
I've released man-pages-5.07. The release tarball is available on The browsable online pages can be found on The Git repository for man-pages is available on

This release resulted from patches, bug reports, reviews, and comments from more than 80 contributors. The release includes more than 380 commits that change more than 380 pages. One new page was added in this release, and one page was removed.

The most notable of the changes in man-pages-5.07 are the following:
  • A new ioctl_fslabel(2) page, written by Eric Sandeen, adds documentation of ioctl() operations for getting and setting filesystem labels.
  • The ioctl_list(2) page has been removed. This page was first added more than 20 years ago, and provided a minimal amount of information about the ioctl() operations available at that time. Since that time it has seen hardly any updates, and is by now very much out of date. The fact that I received few complaints about the page is indicative that no-one really cares about its contents, and it seems appropriate to remove it.
  • The adjtimex(2) page adds documentation of the clock_adjtime() system call; thanks to Arnd Bergmann.
  • Many updates to the fanotify manual pages, thanks to Amir Goldstein.

Kees Cook: security things in Linux v5.5

Wednesday 27th of May 2020 08:04:24 PM

Previously: v5.4.

I got a bit behind on this blog post series! Let’s get caught up. Here are a bunch of security things I found interesting in the Linux kernel v5.5 release:

restrict perf_event_open() from LSM
Given the recurring flaws in the perf subsystem, there has been a strong desire to be able to entirely disable the interface. While the kernel.perf_event_paranoid sysctl knob has existed for a while, attempts to extend its control to “block all perf_event_open() calls” have failed in the past. Distribution kernels have carried the rejected sysctl patch for many years, but now Joel Fernandes has implemented a solution that was deemed acceptable: instead of extending the sysctl, add LSM hooks so that LSMs (e.g. SELinux, Apparmor, etc) can make these choices as part of their overall system policy.

generic fast full refcount_t
Will Deacon took the recent refcount_t hardening work for both x86 and arm64 and distilled the implementations into a single architecture-agnostic C version. The result was almost as fast as the x86 assembly version, but it covered more cases (e.g. increment-from-zero), and is now available by default for all architectures. (There is no longer any Kconfig associated with refcount_t; the use of the primitive provides full coverage.)

linker script cleanup for exception tables
When Rick Edgecombe presented his work on building Execute-Only memory under a hypervisor, he noted a region of memory that the kernel was attempting to read directly (instead of execute). He rearranged things for his x86-only patch series to work around the issue. Since I’d just been working in this area, I realized the root cause of this problem was the location of the exception table (which is strictly a lookup table and is never executed) and built a fix for the issue and applied it to all architectures, since it turns out the exception tables for almost all architectures are just a data table. Hopefully this will help clear the path for more Execute-Only memory work on all architectures. In the process of this, I also updated the section fill bytes on x86 to be a trap (0xCC, int3), instead of a NOP instruction so functions would need to be targeted more precisely by attacks.

KASLR for 32-bit PowerPC
Joining many other architectures, Jason Yan added kernel text base-address offset randomization (KASLR) to 32-bit PowerPC.

seccomp for RISC-V
After a bit of long road, David Abdurachmanov has added seccomp support to the RISC-V architecture. The series uncovered some more corner cases in the seccomp self tests code, which is always nice since then we get to make it more robust for the future!

seccomp USER_NOTIF continuation
When the seccomp SECCOMP_RET_USER_NOTIF interface was added, it seemed like it would only be used in very limited conditions, so the idea of needing to handle “normal” requests didn’t seem very onerous. However, since then, it has become clear that the overhead of a monitor process needing to perform lots of “normal” open() calls on behalf of the monitored process started to look more and more slow and fragile. To deal with this, it became clear that there needed to be a way for the USER_NOTIF interface to indicate that seccomp should just continue as normal and allow the syscall without any special handling. Christian Brauner implemented SECCOMP_USER_NOTIF_FLAG_CONTINUE to get this done. It comes with a bit of a disclaimer due to the chance that monitors may use it in places where ToCToU is a risk, and for possible conflicts with SECCOMP_RET_TRACE. But overall, this is a net win for container monitoring tools.

Some EFI systems provide a Random Number Generator interface, which is useful for gaining some entropy in the kernel during very early boot. The arm64 boot stub has been using this for a while now, but Dominik Brodowski has now added support for x86 to do the same. This entropy is useful for kernel subsystems performing very earlier initialization whre random numbers are needed (like randomizing aspects of the SLUB memory allocator).

As has been enabled on many other architectures, Dmitry Korotin got MIPS building with CONFIG_FORTIFY_SOURCE, so compile-time (and some run-time) buffer overflows during calls to the memcpy() and strcpy() families of functions will be detected.

limit copy_{to,from}_user() size to INT_MAX
As done for VFS, vsnprintf(), and strscpy(), I went ahead and limited the size of copy_to_user() and copy_from_user() calls to INT_MAX in order to catch any weird overflows in size calculations.

Other things
Alexander Popov pointed out some more v5.5 features that I missed in this blog post. I’m repeating them here, with some minor edits/clarifications. Thank you Alexander!

Edit: added Alexander Popov’s notes

That’s it for v5.5! Let me know if there’s anything else that I should call out here. Next up: Linux v5.6.

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

Rusty Russell: 57 Varieties of Pyrite: Exchanges Are Now The Enemy of Bitcoin

Wednesday 27th of May 2020 12:49:34 AM

TL;DR: exchanges are casinos and don’t want to onboard anyone into bitcoin. Avoid.

There’s a classic scam in the “crypto” space: advertize Bitcoin to get people in, then sell suckers something else entirely. Over the last few years, this bait-and-switch has become the core competency of “bitcoin” exchanges.

I recently visited the homepage of Australian exchange what a mess. There was a list of dozens of identical-looking “cryptos”, with bitcoin second after something called “XRP”; seems like it was sorted by volume?

Incentives have driven exchanges to become casinos, and they’re doing exactly what you’d expect unregulated casinos to do. This is no place you ever want to send anyone.

Incentives For Exchanges

Exchanges make money on trading, not on buying and holding. Despite the fact that bitcoin is the only real attempt to create an open source money, scams with no future are given false equivalence, because more assets means more trading. Worse than that, they are paid directly to list new scams (the crappier, the more money they can charge!) and have recently taken the logical step of introducing and promoting their own crapcoins directly.

It’s like a gold dealer who also sells 57 varieties of pyrite, which give more margin than selling actual gold.

For a long time, I thought exchanges were merely incompetent. Most can’t even give out fresh addresses for deposits, batch their outgoing transactions, pay competent fee rates, perform RBF or use segwit.

But I misunderstood: they don’t want to sell bitcoin. They use bitcoin to get you in the door, but they want you to gamble. This matters: you’ll find subtle and not-so-subtle blockers to simply buying bitcoin on an exchange. If you send a friend off to buy their first bitcoin, they’re likely to come back with something else. That’s no accident.

Looking Deeper, It Gets Worse.

Regrettably, looking harder at specific exchanges makes the picture even bleaker.

Consider Binance: this mainland China backed exchange pretending to be a Hong Kong exchange appeared out of nowhere with fake volume and demonstrated the gullibility of the entire industry by being treated as if it were a respected member. They lost at least 40,000 bitcoin in a known hack, and they also lost all the personal information people sent them to KYC. They aggressively market their own coin. But basically, they’re just MtGox without Mark Karpales’ PHP skills or moral scruples and much better marketing.

Coinbase is more interesting: an MBA-run “bitcoin” company which really dislikes bitcoin. They got where they are by spending big on regulations compliance in the US so they could operate in (almost?) every US state. (They don’t do much to dispel the wide belief that this regulation protects their users, when in practice it seems only USD deposits have any guarantee). Their natural interest is in increasing regulation to maintain that moat, and their biggest problem is Bitcoin.

They have much more affinity for the centralized coins (Ethereum) where they can have influence and control. The anarchic nature of a genuine open source community (not to mention the developers’ oft-stated aim to improve privacy over time) is not culturally compatible with a top-down company run by the Big Dog. It’s a running joke that their CEO can’t say the word “Bitcoin”, but their recent “what will happen to cryptocurrencies in the 2020s” article is breathtaking in its boldness: innovation is mainly happening on altcoins, and they’re going to overtake bitcoin any day now. Those scaling problems which the Bitcoin developers say they don’t know how to solve? This non-technical CEO knows better.

So, don’t send anyone to an exchange, especially not a “market leading” one. Find some service that actually wants to sell them bitcoin, like CashApp or Swan Bitcoin.

Dave Airlie (blogspot): DirectX on Linux - what it is/isn't

Wednesday 20th of May 2020 12:01:59 AM
This morning I saw two things that were Microsoft and Linux graphics related.

a) DirectX on Linux for compute workloads
b) Linux GUI apps on Windows

At first I thought these were related, but it appears at least presently these are quite orthogonal projects.

First up clarify for the people who jump to insane conclusions:

The DX on Linux is a WSL2 only thing. Microsoft are not any way bringing DX12 to Linux outside of the Windows environment. They are also in no way open sourcing any of the DX12 driver code. They are recompiling the DX12 userspace drivers (from GPU vendors) into Linux shared libraries, and running them on a kernel driver shim that transfers the kernel interface up to the closed source Windows kernel driver. This is in no way useful for having DX12 on Linux baremetal or anywhere other than in a WSL2 environment. It is not useful for Linux gaming.

Microsoft have submitted to the upstream kernel the shim driver to support this. This driver exposes their D3DKMT kernel interface from Windows over virtual channels into a Linux driver that provides an ioctl interface. The kernel drivers are still all running on the Windows side.

Now I read the Linux GUI apps bit and assumed that these things were the same, well it turns out the DX12 stuff doesn't address presentation at all. It's currently only for compute/ML workloads using CUDA/DirectML. There isn't a way to put the results of DX12 rendering from the Linux guest applications onto the screen at all. The other project is a wayland/RDP integration server, that connects Linux apps via wayland to RDP client on Windows display, integrating that with DX12 will be a tricky project, and then integrating that upstream with the Linux stack another step completely.

Now I'm sure this will be resolved, but it has certain implications on how the driver architecture works and how much of the rest of the Linux graphics ecosystem you have to interact with, and that means that the current driver might not be a great fit in the long run and upstreaming it prematurely might be a bad idea.

From my point of view the kernel shim driver doesn't really bring anything to Linux, it's just a tunnel for some binary data between a host windows kernel binary and a guest linux userspace binary. It doesn't enhance the Linux graphics ecosystem in any useful direction, and as such I'm questioning why we'd want this upstream at all.

Linux Plumbers Conference: Containers and Checkpoint/Restore Microconference Accepted into 2020 Linux Plumbers Conference

Tuesday 19th of May 2020 04:19:24 PM

We are pleased to announce that the Containers and Checkpoint/Restore Microconference has been accepted into the 2020 Linux Plumbers Conference!

After another successful Containers Microconference last year , there’s still a lot more work to be done. Last year we discussed the intersection between the new mount api and containers, various new vfs features including a strong and fruitful discussion about id shifting, several new security hardening aspects, and improvements when restarting syscalls during checkpoint/restore. Last year’s microconference topics led to quite a few patches that have since landed in the upstream kernel with others actively being discussed. This includes, various improvements to seccomp syscall interceptions, the implementation of a new process creation syscall, the implementation of pidfds, and the addition of time namespaces.

This year’s topics include:

Come join us and participate in the discussion with what holds “The Cloud” together.

We hope to see you there!

Christian, Mike, Stéphane

Linux Plumbers Conference: Linux Plumbers Conference 2020 Goes Virtual

Friday 15th of May 2020 04:08:02 PM

As previously promised, we are announcing today that we have decided to hold the the Linux Plumbers Conference 2020 virtually instead of in person. We value the safety and health of our community and do not wish to expose anyone to unnecessary risks.

We do appreciate that it is the in-person aspect of plumbers (the hallway track) which attendees find the most valuable. An online Linux Plumbers Conference will clearly be different from past events. We are working hard to find ways to preserve as much of the LPC experience as we can while also taking advantage of any new opportunities that the online setting offers us. Since we no longer have many of the fixed expenses of an in-person conference, we are able to reduce the registration fee to $50. In addition we are pushing back the opening of registration to June 15 2020.

We’ll provide more details as we figure them out, thanks for your patience and support.

Do not forget to send your contribution.

We do have great proposals and if you have submitted, thank you very much. Our microconference capacity is filling up quickly, if you want your microconference to be considered, act now! We are still looking for proposals for refereed talks as well.


The LPC 2020 Planning Committee

Linux Plumbers Conference: Call for Microconferences and Refereed Talks track reopened

Thursday 14th of May 2020 07:15:40 PM

We are pleased to announce that we have reopened the call for both refereed talks and microconferences. Due to the current global situation with the Covid-19 pandemic we wanted to give everybody a longer time window to submit proposals.

Submit your proposals here:

Stay tuned for further upcoming communications and updates about Linux Plumbers Conference 2020.


More in Tux Machines

Android Leftovers

Dillo: Does This Ultra-Lightweight Browser Still Work in 2020?

Before jumping in, you should know exactly what Dillo doesn’t include, just to temper your expectations. Dillo does not include Flash, Java, or Javascript and only has limited support for frames. It also doesn’t allow you to create a user profile. Presumably, that will be most of the modern Internet out of the picture, but who knows? We’ll see. The advantage of all that feature-cutting is that it will run on almost anything – even a 486 with dial-up Internet. Running at idle, Dillo was using 2.9 MB of RAM and 9.5 MB of shared memory, which is microscopic compared to the gigs of RAM used by modern browsers. If you’re willing to trawl the Internet, people have run it on Mac, DOS, and a bunch of Unix variants, but now the website just has source tarballs, mostly focusing on Linux. It can also run on Windows, but the Dillo team actively dislikes the platform! Read more

Will LibreOffice 7.0 be only Personal Edition for individual use???

Look at LibreOffice logo with "Personal Edition" phrase, look at sidebar in Start Center with the same phrase and note to "The Personal edition is supported by volunteers and intended for individual use." And what is mean? Where is any public announcement? They say it was in marketing mail list. How many people read that mail list? Five? It means that I can't install LibreOffice 7.0 in any organization in Russia, because our controlling people will be see very simple to legality in this case: open the About dialog -> read that "intended for individual use" and LibreOffice logo with "Personal Edition" -> you can't use LibreOffice here! Nobody will check what say MPL 2.0 license about it or why TDF made it, they just point a finger at it and they will be right! It will close for LibreOffice any education organizations like schools or colleges or universities. I wont popularize LibreOffice for young people because they will never see LibreOffice in them schools. I against these changes. Please revoke it! Read more

Security 101: Beginning with Kali Linux

I’ve found a lot of people who are new to security, particularly those with an interest in penetration testing or red teaming, install Kali Linux™1 as one of their first forays into the “hacking” world. In general, there’s absolutely nothing wrong with that. Unfortunately, I also see many who end up stuck on this journey: either stuck in the setup/installation phase, or just not knowing what to do once they get into Kali. This isn’t going to be a tutorial about how to use the tools within Kali (though I hope to get to some of them eventually), but it will be a tour of the operating system’s basic options and functionality, and hopefully will help those new to the distribution get more oriented. Read more