From: Stas Sergeev <stsp@list.ru>
To: Andy Lutomirski <luto@kernel.org>
Cc: "Bae, Chang Seok" <chang.seok.bae@intel.com>,
X86 ML <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Borislav Petkov <bpetkov@suse.de>,
Brian Gerst <brgerst@gmail.com>,
Bart Oldeman <bartoldeman@users.sourceforge.net>
Subject: Re: FSGSBASE ABI considerations
Date: Tue, 8 Aug 2017 00:32:29 +0300 [thread overview]
Message-ID: <31548334-01bf-caac-75ac-a4a70faca07a@list.ru> (raw)
In-Reply-To: <CALCETrVdt3FARBvfJyOtP2x=_yu8iakBLnELf_X6hk43Fx-gtA@mail.gmail.com>
07.08.2017 19:20, Andy Lutomirski пишет:
>> I think
>> this is the half-step. It clearly shows that you don't want
>> such state to ever exist, but why not to go a step further
>> and just make the bases to be reset not only by any
>> unrelated modify_ldt() call, but always on schedule?
>> You can state that using wrgsbase on non-zero selector
>> is invalid, reset it to LDT state and maybe send a signal
>> to the program so that it knows it did something wrong.
>> This may sound too rough, but I really don't see how it
>> differs from resetting all LDT bases on some unrelated
>> modify_ldt() that was done for read, not write.
>> Or you may want to reset selector to 0 rather than
>> base to LDT.
> Windows does something sort of like this (I think), but I don't like
> this solution. I fully expect that someone will write a program that
> does:
>
> old = rdgsbase();
> wrgsbase(new);
> call_very_fast_function();
> wrgsbase(old);
>
> This will work if GS == 0, which is fine. The problem is that it will
> *also* work if GS != 0 with very high probability, especially if this
> code sequence is right after some operation that sleeps. And then
> we'll get random crashes with very low probability, depending on where
> the scheduler hits.
So, as Linus already pointed, if the fixup is to
zero out the selector, then this will still work fine.
>> I am far from the kernel development so my thoughts
>> may be naive, but IMHO you should just disallow this
>> by some means (like by doing a fixup on schedule() and
>> sending a signal). No one will suffer, people will just
>> write 0 to segreg first. Note that such a problem can
>> be provoked by the fact that the sighandler does not
>> reset the segregs to their default values, and someone
>> may simply forget to reset it to 0. You need to remind
>> him to do so rather than to invent the tricky code to
>> do something theoretically correct.
> I would *love* to disallow it. The problem is that I don't believe it
> to be possible in a way that doesn't cause more problems than it
> solves.
I wonder if sending a signal (after doing a fixup)
is too much of a punishment?
> I'm trying to avoid a situation where we implement that policy and the
> interaction with modify_ldt() becomes very strange.
IMHO if you do the fixup on schedule (like setting
the selector to zero), then the interaction with
modify_ldt() is completely avoided, i.e. modify_ldt()
should then never special-case the threads that
did wrgsbase. So if something inconsistent comes
out, then it was likely there already without wrgsbase.
prev parent reply other threads:[~2017-08-07 22:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-31 3:05 FSGSBASE ABI considerations Andy Lutomirski
2017-07-31 4:38 ` Linus Torvalds
2017-07-31 14:14 ` Andy Lutomirski
2017-07-31 10:55 ` Kirill A. Shutemov
2017-07-31 14:16 ` Andy Lutomirski
2017-07-31 21:23 ` Bae, Chang Seok
2017-08-07 16:14 ` Andy Lutomirski
2017-08-07 8:06 ` Stas Sergeev
2017-08-07 16:20 ` Andy Lutomirski
2017-08-07 16:49 ` Christopher Lameter
2017-08-07 17:35 ` Linus Torvalds
2017-08-07 19:07 ` Andy Lutomirski
2017-08-07 21:32 ` Stas Sergeev [this message]
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=31548334-01bf-caac-75ac-a4a70faca07a@list.ru \
--to=stsp@list.ru \
--cc=bartoldeman@users.sourceforge.net \
--cc=bpetkov@suse.de \
--cc=brgerst@gmail.com \
--cc=chang.seok.bae@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.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;
as well as URLs for NNTP newsgroup(s).