From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: tglx@linutronix.de, mingo@redhat.com, linux-kernel@vger.kernel.org
Subject: what's papered over by set_fs(USER_DS) in amd64 signal delivery?
Date: Fri, 24 Sep 2010 16:52:31 +0100 [thread overview]
Message-ID: <20100924155231.GQ19804@ZenIV.linux.org.uk> (raw)
What the hell is going on in amd64 handle_signal()? We do
#ifdef CONFIG_X86_64
/*
* This has nothing to do with segment registers,
* despite the name. This magic affects uaccess.h
* macros' behavior. Reset it to the normal setting.
*/
set_fs(USER_DS);
#endif
in the end of sigframe creation; first of all, we'd just done a bunch of
copying to user-controlled addresses, protected only by access_ok(), so
if we *did* have something different we are already fucked badly. Moreover,
if we had been on our way to userland (and we wouldn't have reached that
code otherwise) with wrong ->addr_limit and would *not* get a signal, we'd
be left with the same ->addr_limit for the next syscall to be done. Fucked
again?
I've tried to find amd64-specific magic that would require that, but so far
I've found nothing of that kind. It looks like until the i386/amd64 merge
*both* used to have that thing and during the merge it has suddenly grown
that ifdef, so another way to put it is "why the reasons allowing to kill
it on i386 do not apply to amd64?"
next reply other threads:[~2010-09-24 15:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-24 15:52 Al Viro [this message]
2010-09-24 16:07 ` what's papered over by set_fs(USER_DS) in amd64 signal delivery? Linus Torvalds
2010-09-24 16:57 ` Al Viro
2010-09-25 2:25 ` Brian Gerst
2010-09-25 2:48 ` Al Viro
2010-09-25 3:51 ` Brian Gerst
2010-09-25 5:20 ` Al Viro
2010-09-25 9:54 ` Brian Gerst
2010-09-26 9:13 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100924155231.GQ19804@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox