Zack's Kernel News

Making System Calls Reject Unknown Flags

Christoph Hellwig was unhappy with the fact that anyone could pass random garbage as input to system calls, without breaking anything. As a result, user code can't test system calls to see if they accept this or that input flag – they accept them all, even if they do nothing with them. He wanted to write a patch that would make system calls reject input flags that weren't actually supported.

Christoph acknowledged that this would be an application binary interface (ABI) change, which was nearly always a no-no for a few important reasons. For one thing, it made it impossible to "bisect" the kernel development tree in order to hunt down bugs that crossed the version that implemented the ABI-breaking change. More importantly, however, it would break existing user code running out in the world on everybody's system and require that code to be recompiled. This is actually a big no-no because in many cases, the people running the binaries don't have the source code anymore!

So, ABI changes are generally hit with hammers by various folks, including Linus Torvalds. In this case, Linus didn't bother addressing the ABI issue, but objected to Christoph's main point, saying:

"Probing for flags is why we *could* add things like O_NOATIME etc. – exactly because it 'just worked' with old kernels, and people could just use the new flags knowing that it was a no-op on old kernels.

The whole concept of 'probing for supported features' is very suspect. It's a bad, bad idea. Don't do it.

What kind of new flag did you even have in mind that would have such broken semantics that it would completely change the other flags? Because now I'm starting to think that the whole series has an even deeper bug: stupid new features that were badly thought out and not even described."

Christoph pointed to the atomic input/output issue as described in Linus was unimpressed, saying that in the typical case, any code that wanted atomic input/output would probably still want to perform input/output without the atomicity guarantee, in which case there were straightforward ways to handle it. He added, "My guess is that there is going to be very few O_ATOMIC users anyway, and they'll very carefully set it once and test it (or not even test it – just make it be a configuration flag and tell people 'don't ask for O_ATOMIC if your system doesn't support it')."

Meanwhile, Florian Weimer said that probing for flags was "vastly preferable to hard-coding kernel version dependencies in source or object code. Particularly if you want to move applications between different kernel versions (which seems to be all the rage right now)."

But the conversation trailed off at that point. Regardless of whether there's a decent justification for probing, it's still an ABI change, which kills it at the starting gate.

The Author

The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching 10,000 messages in a week, and keeping up to date with the entire scope of development is a virtually impossible task for one person. One of the few brave souls to take on this task is Zack Brown.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Kernel News

    Zack Brown reports on fixing printk() bit by bit, kernel internationalization (or not), and kernel encryption and secure boot. 

  • Kernel News

    This month in Kernel News: Shared Processes with Hyper-Threading; Cleaning Up printk(); and Rust in the Kernel.

  • Kernel News

    Chronicler Zack Brown reports on printk() wrangling, persistent memory as a generalized resource, making Kernel headers available on running systems, and Kernel licensing Hell. 

  • Kernel News

    Zack Brown discusses implementing digital rights management in-kernel, improving lighting controls, and updating printk().

  • Kernel News

    Chronicler Zack Brown reports on a stone so large..., a global stats-gathering interface, and the Kernel development process.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More