Re: [RFC PATCH for 5.8 3/4] rseq: Introduce RSEQ_FLAG_RELIABLE_CPU_ID

[ Context for Linus: I am dropping this RFC patch, but am curious to
  hear your point of view on exposing to user-space which system call
  behavior fixes are present in the kernel, either through feature
  flags or system-call versioning. The intent is to allow user-space
  to make better decisions on whether it should use a system call or
  rely on fallback behavior. ]

----- On Jul 7, 2020, at 3:55 PM, Florian Weimer fw@deneb.enyo.de wrote:

* Carlos O'Donell:

quoted

It's not a great fit IMO. Just let the kernel version be the arbiter of
correctness.

For manual review, sure.  But checking it programmatically does not
yield good results due to backports.  Even those who use the stable
kernel series sometimes pick up critical fixes beforehand, so it's not
reliable possible for a program to say, “I do not want to run on this
kernel because it has a bad version”.  We had a recent episode of this
with the Go runtime, which tried to do exactly this.

FWIW, the kernel fix backport issue would also be a concern if we exposed
a numeric "fix level version" with specific system calls: what should
we do if a distribution chooses to include one fix in the sequence,
but not others ? Identifying fixes are "feature flags" allow
cherry-picking specific fixes in a backport, but versions would not
allow that.

That being said, maybe it's not such a bad thing to _require_ the
entire series of fixes to be picked in backports, which would be a
fortunate side-effect of the per-syscall-fix-version approach.

But I'm under the impression that such a scheme ends up versioning
a system call, which I suspect will be a no-go from Linus' perspective.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com