linux-kernel - Re: [PATCH 3/5] mips: sanitize restart logics

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 30 Sep 2010 02:50:17 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...esourcery.com>
To:	David Daney <ddaney@...iumnetworks.com>
cc:	Al Viro <viro@....linux.org.uk>, ralf@...ux-mips.org,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	"Maciej W. Rozycki" <macro@...ux-mips.org>
Subject: Re: [PATCH 3/5] mips: sanitize restart logics

On Wed, 29 Sep 2010, David Daney wrote:

> > Put the original syscall number into ->regs[0] when we leave syscall
> > with error.  Use it in restart logics.  Everything else will have
> > it 0 since we pass through SAVE_SOME on all the ways in.  Note that
> > in places like bad_stack and inllegal_syscall we leave it 0 - it's
> > not restartable.
> > 
> 
> IIRC Userspace getcontext/setcontext rely on regs[0] having a value of zero in
> the when the signal handlers are invoked.

 Not exactly.  These GNU C library functions rely on the magic value of 
"1" there to recognise contexts they created themselves and which must 
therefore be handled by themselves internally (these contexts are not 
complete and only preserve the call-saved registers as specified by the 
respective MIPS ABIs, and are therefore unsafe to be passed to the 
rt_sigreturn(2) syscall).  All the other values, including of course "0", 
are not treated specially and the context is passed to rt_sigreturn(2) as 
usually.  This only matters in cases where e.g. setcontext(3) is used to 
exit from or return to a signal handler.

> I haven't fully traced through the code, but I hope that this 'invariant'
> holds both before and after this patch.  I think Maciej did the work on
> getcontext/setcontext, he may know for sure what the requirements are.

 Thanks for the heads-up, David -- I would have surely missed this e-mail 
from the flood I get.  I think the change is safe as MIPS/Linux only uses 
syscall numbers from 4000 up (not sure why such a non-round number was 
chosen; one like 4096 would seem more appropriate to me but there you go), 
so there should be no clash unless an invalid syscall number has a chance 
to be stored there.

 For how exactly the magic value is used please have a look at 
sysdeps/unix/sysv/linux/mips/*context.S in glibc-ports and search for 
"magic flag" (yes, I know these pieces of assembly butchered and mixed 
with CPP mince require some mind-twistedness to parse; sorry about that, 
but I tried my best and put some comments throughout so that the magic 
flag is easy to find ;) ).

  Maciej
--
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/