* Borislav Petkov:

On Mon, Apr 12, 2021 at 10:30:23PM +0000, Bae, Chang Seok wrote:

quoted

On Mar 26, 2021, at 03:30, Borislav Petkov [off-list ref] wrote:

quoted

On Thu, Mar 25, 2021 at 09:56:53PM -0700, Andy Lutomirski wrote:

quoted

We really ought to have a SIGSIGFAIL signal that's sent, double-fault
style, when we fail to send a signal.

Yeap, we should be able to tell userspace that we couldn't send a
signal, hohumm.

Hi Boris,

Let me clarify some details as preparing to include this in a revision.

So, IIUC, a number needs to be assigned for this new SIGFAIL. At a glance, not
sure which one to pick there in signal.h -- 1-31 fully occupied and the rest
for 33 different real-time signals.

Also, perhaps, force_sig(SIGFAIL) here, instead of return -1 -- to die with
SIGSEGV.

I think this needs to be decided together with userspace people so that
they can act accordingly and whether it even makes sense to them.

Florian, any suggestions?

Is this discussion about better behavior (at least diagnostics) for
existing applications, without any code changes?  Or an alternative
programming model?

Does noavx512 acutally reduce the XSAVE size to AVX2 levels?  Or would
you need noxsave?

One possibility is that the sigaltstack size check prevents application
from running which work just fine today because all they do is install a
stack overflow handler, and stack overflow does not actually happen.  So
if sigaltstack fails and the application checks the result of the system
call, it probably won't run at all.  Shifting the diagnostic to the
pointer where the signal would have to be delivered is perhaps the only
thing that can be done.

As for SIGFAIL in particular, I don't think there are any leftover
signal numbers.  It would need a prctl to assign the signal number, and
I'm not sure if there is a useful programming model because signals do
not really compose well even today.  SIGFAIL adds another point where
libraries need to collaborate, and we do not have a mechanism for that.
(This is about what Rich Felker termed “library-safe code”, proper
maintenance of process-wide resources such as the current directory.)

Thanks,
Florian