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: Re: what's papered over by set_fs(USER_DS) in amd64 signal delivery?
Date: Fri, 24 Sep 2010 17:57:16 +0100 [thread overview]
Message-ID: <20100924165716.GR19804@ZenIV.linux.org.uk> (raw)
In-Reply-To: <AANLkTik+1k76vGccjwQWeEWZFng61ZoodDyWbN8wvPgE@mail.gmail.com>
On Fri, Sep 24, 2010 at 09:07:33AM -0700, Linus Torvalds wrote:
> I _think_ it is historical, and probably relates to just restoring all
> the user mode state at signal delivery to a known state. IOW, I think
> it really does go hand-in-hand with the whole "clear bits in the
> eflags register" thing.
>
> x86-64 has historically had some left-over crap that we already
> cleaned up in 32-bit mode, for the simple reason that the original
> x86-64 code was forked from an earlier base, and then hacked up
> somewhat. So I think this "#ifdef CONFIG_X86_64" is just a case of
> that.
Nope - look at the commit that merged them; i386 used to have it as well
right until the merge. And yes, I agree that it's most likely a leftover
from ancient times.
> But maybe we should have a WARN_ON_ONCE() to verify it, rather than
> just kill it outright.
Um... If we do that, I'd suggest taking it in front of setup_...frame()
and doing do_exit() with loud warning along the lines of "someone has
come that -><- close to rooting the box". Anybody who can trigger that
(assuming it can be triggered at all) can overwrite arbitrary parts of
kernel memory.
I'd still like to hear from the x86 maintainers, just in case there's
something more non-trivial to that than "it has always been that way"...
FWIW, looking at the history it seems that the thing has happened almost
by accident; the critical part is
- regs->cs = USER_CS; regs->ss = USER_DS;
- regs->ds = USER_DS; regs->es = USER_DS;
- regs->gs = USER_DS; regs->fs = USER_DS;
+ {
+ unsigned long seg = USER_DS;
+ __asm__("mov %w0,%%fs ; mov %w0,%%gs":"=r" (seg) :"0" (seg));
+ set_fs(seg);
+ regs->xds = seg;
+ regs->xes = seg;
+ regs->xss = seg;
+ regs->xcs = USER_CS;
in 2.1.2. And that's when we had
* fs and gs evicted from pt_regs
* fs and gs not saved restored on kernel entry/exit
* just introduced set_fs() to start with (that went in 2.1.0)
A bit before my time, so I'm not sure what's been going on there...
next prev parent reply other threads:[~2010-09-24 16:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-24 15:52 what's papered over by set_fs(USER_DS) in amd64 signal delivery? Al Viro
2010-09-24 16:07 ` Linus Torvalds
2010-09-24 16:57 ` Al Viro [this message]
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=20100924165716.GR19804@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