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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Mon, 26 Feb 2007 00:03:40 +0100 (MET)
From:	Mikael Pettersson <mikpe@...uu.se>
To:	ak@...e.de
Cc:	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org
Subject: Re: [PATCH 2.6.21-rc1] x86 signal number delivery fixes

On Sun, 25 Feb 2007 23:39:48 +0100, Andi Kleen wrote:
> On Sunday 25 February 2007 12:47, Mikael Pettersson wrote:
> > The invokation of signal handlers on x86 has several bugs
> > in its treatment of the signal number parameter:
> > 
> > - the i386 kernel passes the raw not the translated signal number
> >   in EAX to non-SA_SIGINFO handlers compiled with -mregparm=3;
> >   the value passed on the stack is correct, and SA_SIGINFO handlers
> >   are also invoked correctly
> > - the x86-64 kernel's ia32 emulation for SA_SIGINFO handlers also
> >   passes the wrong (untranslated) signal number in EAX; the value
> >   on the stack is correct
> > - the x86-64 kernel's ia32 emulation for non-SA_SIGINFO handlers
> >   passes the wrong (untranslated) signal number both on the stack 
> >   and in EAX
> 
> 
> Nobody should be using that signal translation code anymore. Certainly
> nothing in tree. Perhaps it would be better to just rip it out.
> 
> If you have a user you should submit it.

The reason I noticed these issues was that I was studying the signal
delivery code for a virtualisation project, and these discrepancies
were immediately obvious just from reading the code.

I'm definitely not using that signal number translation feature; heck
I didn't even know it existed until a few days ago.

If it's dead as you say then it really ought to be removed. It currently
seems to make a mess in every arch's signal delivery code.

/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ