Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 12 Jul 2021 11:41:35 -0400
From: Rich Felker <>
To: Vincent Donnefort <>
Cc: Samuel Holland <>,,
	jason <>
Subject: Re: [PATCH v3] sysconf: add _SC_NPROCESSORS_CONF support

On Mon, Jul 12, 2021 at 02:08:42PM +0100, Vincent Donnefort wrote:
> On Sat, Jul 10, 2021 at 03:44:50PM -0400, Rich Felker wrote:
> > On Sat, Jul 10, 2021 at 12:29:34PM -0500, Samuel Holland wrote:
> > > Hi all,
> > > 
> > > While this topic is being discussed, I'd like to bring up another possible
> > > method for consideration. It turns out that some files in procfs have contents
> > > depending on the number of {possible,online} CPUs; we can parse them to get the
> > > count we need.
> > > 
> > > The benefits are:
> > >  - procfs is more likely to be mounted than sysfs, and it is already
> > >    documented as being required by musl.
> > >  - Some of the procfs interfaces have been around longer than the
> > >    sysfs interface.
> > >  - The parsing logic is somewhat simpler than for the files in
> > >    /sys/devices/system/cpu, because we are just counting the number
> > >    of occurrences of some string.
> > > 
> > > The downsides are:
> > >  - It depends on the stability of the procfs file formats.
> > >  - The kernel uses more CPU to generate the contents of these files.
> > 
> > My understanding is that the procfs files have stronger stability
> > mandate than sysfs if anything (originally, only procfs was stable and
> > sysfs was not). So I think it's perfectly acceptable to use and prefer
> > procfs. And indeed it's more likely to be mounted; some
> > container/sandbox setups I use bind-mount (or mount a new) procfs but
> > do not expose any sysfs.
> Only to cover the case where a user needs _CONF and doesn't have the sysfs
> mounted, which is very unlikely, we are losing a lot.

Can you quantify what we're "losing"? As I understood the proposal,
nothing at all is lost.

> The masks, found in the
> CPU subsystem are well documented, widely available, describe precisely the CPU
> topology (which is what we want) and are "easy" to decode without fscanf.

fscanf is not available here. The same can be done without it, if
needed, though.

> Moreover, in the case of a non-available sysfs, the fallback to sched_getaffinity
> would help and at least align _CONF with _ONL (which is the current behavior).
> Reading /proc/stat and /proc/softirq looks like a hack. They just happen to
> align on the _ONL/_CONF and doesn't produce a machine-readable output. While
> the CPU sysfs subsys is really meant to describe CPUs.

If they're mandated stable interfaces that "happen" to have the exact
data we need, I don't see what the objection to using them is. A
better question would be whether access to them is restricted in any
hardening profiles. At least they don't seem to be hidden by the
hidepid mount option.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.