On Fri, Aug 21, 2020 at 10:10:16PM -0700, Peter Collingbourne wrote:

[ Add a new siginfo member sa_xflags, for fault signals. ]

This field will contain flags that may be used by signal handlers to
determine whether other fields in the _sigfault portion of siginfo are
valid. An example use case is the following patch, which introduces
the si_addr_ignored_bits{,_mask} fields.

A new sigcontext flag, SA_XFLAGS, is introduced in order to allow
a signal handler to require the kernel to set the field (but note
that the field will be set anyway if the kernel supports the flag,
regardless of its value). In combination with the previous patches,
this allows a userspace program to determine whether the kernel will
set the field.

It is possible for an si_xflags-unaware program to cause a signal
handler in an si_xflags-aware program to be called with a provided
siginfo data structure by using one of the following syscalls:

- ptrace(PTRACE_SETSIGINFO)
- pidfd_send_signal
- rt_sigqueueinfo
- rt_tgsigqueueinfo

So we need to prevent the si_xflags-unaware program from causing an
uninitialized read of si_xflags in the si_xflags-aware program when
it uses one of these syscalls.

The last three cases can be handled by observing that each of these
syscalls fails if si_code >= 0, so we define si_xflags to only be
valid if si_code >= 0.

I would say >.  0 is SI_USER, and the fact that those other interfaces
reject SI_USER seems inconsistent or a bug.

We can always relax the rule later.

Since si_xflags only makes sense for "real" fault signals, it would
never be applicable in combination with SI_USER.  Or am I missing
something?

Either way, I think this is just a documentation ossue in practice.

There is no such check on si_code in ptrace(PTRACE_SETSIGINFO), so
we make ptrace(PTRACE_SETSIGINFO) clear the si_xflags field if it
detects that the signal would use the _sigfault layout, and introduce
a new ptrace request type, PTRACE_SETSIGINFO2, that a si_xflags-aware
program may use to opt out of this behavior.

Will we need to introduce PTRACE_SETSIGINFO3, 4 etc., every time a new
field comes up?

I wonder whether we should make this more flexible, say accepting some
flags argument to say which fields the caller understands (and so
doesn't want clobbered).  Maybe we can (ab)use the sa_flags bit
definitions for indicating which extensions the caller understands.

It is also possible for the kernel to inject a signal specified to
use _sigfault by calling force_sig (e.g. there are numerous calls to
force_sig(SIGSEGV)). In this case si_code is set to SI_KERNEL and the
_kill union member is used, so document that si_code must be < SI_KERNEL.

Ack.  I'm still wondering if some of those SIGSEGV/SI_KERNEL instances
should be changed to one of the standard SIGSEGV codes, but either way,
having si_xflags validity require si_code < SI_KERNEL seems appropriate.

Ideally this field could have just been named si_flags, but that
name was already taken by ia64, so a different name was chosen.

Alternatively, we may consider making ia64's si_flags a generic field
and having it appear at the end of _sigfault (in the same place as
this patch has si_xflags) on non-ia64, keeping it in the same place
on ia64. ia64's si_flags is a 32-bit field with only one flag bit
allocated, so we would have 31 bits to use if we do this.

Hmm, that might be an idea.

It would mean that x86 would have different rules from other
architectures regarding how to know when the field is valid, which might
lull x86-first projects into a false sense of security.  Perhaps we could
refuse to expose any of the arch-independent flags in si_flags unless
explicitly requested via SA_XFLAGS, but that would be a departure from
what this series implements today.

So maybe it's simpler to keep the two fields separate, unless somebody
objects.

(Yuk, but at least you make this no worse.)

Should we have the same type here for native and compat?

I don't have a very strong opinion on this, but currently native on
64-bit arches will have 32 extra bits in _xflags that can never be used
(or have to be defined differently for compat).

6?

Obviously we'll need something here, but I'm curious as to where this
value came from.

(Same for compat.)

Maybe "valid for fault signals (SIGSEGV etc.)"

[...]

Otherwise, this looks sensible overall to me.

Cheers
---Dave

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel