* Borislav Petkov: > On Mon, Apr 12, 2021 at 10:30:23PM +0000, Bae, Chang Seok wrote: >> On Mar 26, 2021, at 03:30, Borislav Petkov <bp@xxxxxxxxx> wrote: >> > On Thu, Mar 25, 2021 at 09:56:53PM -0700, Andy Lutomirski wrote: >> >> 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
