lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 15 Apr 2018 14:12:06 +0100 From: Russell King - ARM Linux <linux@...linux.org.uk> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Dave Martin <Dave.Martin@....com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, "Dmitry V. Levin" <ldv@...linux.org>, "Eric W. Biederman" <ebiederm@...ssion.com>, sparclinux <sparclinux@...r.kernel.org>, ppc-dev <linuxppc-dev@...ts.ozlabs.org>, linux-arm-kernel <linux-arm-kernel@...ts.infradead.org> Subject: Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid On Fri, Apr 13, 2018 at 12:53:49PM -0700, Linus Torvalds wrote: > On Fri, Apr 13, 2018 at 11:45 AM, Dave Martin <Dave.Martin@....com> wrote: > > > > Most uses I've seen do nothing more than use the FPE_xyz value to > > format diagnostic messages while dying. I struggled to find code that > > made a meaningful functional decision based on the value, though that's > > not proof... > > Yeah. I've seen code that cares about SIGFPE deeply, but it's almost > invariably about some emulated environment (eg Java VM, or CPU > emulation). > > And the siginfo data is basically never good enough for those > environments anyway on its own, so they will go and look at the actual > instruction that caused the fault and the register state instead, > because they need *all* the information. > > The cases that use si_code are the ones that just trapped signals in > order to give a more helpful abort message. > > So I could certainly imagine that si_code is actually used by somebody > who then decides to actuall act differently on it, but aside from > perhaps printing out a different message, it sounds far-fetched. Okay, in that case let's just use FPE_FLTINV. That makes the patch easily back-portable for stable kernels. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up
Powered by blists - more mailing lists