linux-kernel - Re: [GIT] Sparc

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]

Message-ID: <20100923045921.GJ19804@ZenIV.linux.org.uk>
Date:	Thu, 23 Sep 2010 05:59:22 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	David Miller <davem@...emloft.net>, akpm@...ux-foundation.org,
	sparclinux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT] Sparc

On Wed, Sep 22, 2010 at 12:08:53PM -0700, Linus Torvalds wrote:
> On Wed, Sep 22, 2010 at 11:53 AM, Al Viro <viro@...iv.linux.org.uk> wrote:
> >
> > Um, no. ?You've *already* called get_signal_to_deliver(). ?There had been
> > no SIGSEGV in sight. ?You happily went on to set a sigframe for e.g.
> > SIGHUP, but ran out of stack. ?At that point you get force_sigsegv()
> > from handle_signal(). ?_NOW_ you have a pending SIGSEGV
> 
> Ahh. Ok. Different case from the one I thought you were worried about.
> And yeah, I guess that one does require us to mess with the low-level
> asm code (although I do wonder if we could not make the whole
> do_notify_resume + reschedule code be generic C code - it's a lot of
> duplicated subtle asm as it is).

BTW, there's an interesting idea in s390 implementation (and I have to say
that I'm bloody impressed by them - it's the only architecture besides x86
where I haven't found serious holes in signal handling yet; there are QOI
issues, but that's it so far).  What they do with syscall restarts is unusual
and they might have a good point there.

1) They deal with restart immediately on the entry to do_signal(); if
restarts are not suppressed and if the error is one of the restart-worthy
ones, they do what should be done for no-handler case.

2) They store the pre-restart address, post-restart address and error.  Then
they call get_signal_to_deliver().  Of course, it may return us a positive
signal number.  In that case they may need to discard the restart they'd
done.  And they do it, but only if the address has remained equal to
post-restart one.

3) They ignore ERESTART_RESTARTBLOCK if the address has changed.  Actually,
I suspect that they might need to clear the ->restart_block.fn in that case,
but I haven't done analysis of that yet.

They do have a reason for doing it that way and it's worth considering on
other platforms.  Think what happens if we are getting traced.  We'll be
stopped and tracer will be notified.  Normally it'll tell us to continue
execution, possibly with a different signal *AND* with a different userland
address to return to.  Suppose we've got a different return address set
for us (e.g. with PTRACE_POKEUSR).  Should we ever shift it back by what
hopefully is a size of syscall insn?
--
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/