LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Denys Vlasenko <vda.linux@googlemail.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>, X86 ML <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@alien8.de>, Oleg Nesterov <oleg@redhat.com>
Subject: Re: [PATCH 3/3] x86_32: Document our abuse of ss1 and sp1
Date: Tue, 10 Mar 2015 21:52:48 +0100	[thread overview]
Message-ID: <CAK1hOcMg5e3AamWa=XwSLJWEJBOo_DoL3DgC5RcCpXXhkJnuBA@mail.gmail.com> (raw)
In-Reply-To: <CALCETrWLOk=imRQH3r2xq7UviB_Xodq14MMSSht_2aMnjqNSsw@mail.gmail.com>

On Tue, Mar 10, 2015 at 9:06 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> .ss1 also seems to be a write-only field:
>>
>> $ grep -r '[.>]ss1' .
>> ./include/asm/processor.h:      if (unlikely(tss->x86_tss.ss1 != thread->sysenter_cs)) {
>
> This is a read :)

You are right.

>> ./include/asm/processor.h:              tss->x86_tss.ss1 = thread->sysenter_cs;
>> ./include/asm/processor.h:              .ss1            = __KERNEL_CS,                            \
>> ./kernel/cpu/common.c:  tss->x86_tss.ss1 = __KERNEL_CS;

>>> +      * but we need to context switch it because we do
>>> +      * horrible things to the kernel stack in vm86 mode.
>>> +      *
>>> +      * We use SYSENTER_CS to disable sysenter in vm86 mode to avoid
>>> +      * corrupting the stack if we went through the sysenter path
>>> +      * from vm86 mode.
>>> +      */
>>
>> I'm confused how loading ss1/sp1 with anything can disable sysenter.
>> SYSENTER insn does not use those fields.
>>
>> What you _can_ disable is you can make it impossible to enter RING1
>> if tss.ss1 is invalid.
>
> Does it make sense now that I pointed out the read of ss1?  If not,
> I'll improve the comments.

I propose the following comment about tss.ss1:

/*
tss.ss1 is used to avoid redundant wrmsr(MSR_IA32_SYSENTER_CS).
After wrmsr, tss.ss1 is set to the written value. If on future task switches
tss.ss1 already contains the value to be written, wrmsr is skipped.
*/


>>> +      * We use SYSENTER_CS to disable sysenter in vm86 mode to avoid
>>> +      * corrupting the stack if we went through the sysenter path
>>> +      * from vm86 mode.

This appears to be untrue - SYSENTER_CS isn't used to disable sysenter.
Zero is.

Disabling sysenter happens in vm86_32.c here, by setting it to 0:

static void do_sys_vm86(struct kernel_vm86_struct *info, struct
task_struct *tsk)
{
...
        if (cpu_has_sep)
                tsk->thread.sysenter_cs = 0;
        load_sp0(tss, &tsk->thread);   <-- this sets
wrmsr(MSR_IA32_SYSENTER_CS, 0);
...

  reply	other threads:[~2015-03-10 20:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-10 18:05 [PATCH 0/3] sp0, ss1, and sp1 docs and minor fixes Andy Lutomirski
2015-03-10 18:05 ` [PATCH 1/3] x86: Create and use a TOP_OF_KERNEL_STACK_PADDING macro Andy Lutomirski
2015-03-10 19:22   ` Denys Vlasenko
2015-03-10 19:47     ` Andy Lutomirski
2015-03-13 14:08     ` Denys Vlasenko
2015-03-16  8:56   ` Ingo Molnar
2015-03-16 12:08   ` [tip:x86/asm] x86/asm/entry: Create and use a ' TOP_OF_KERNEL_STACK_PADDING' macro tip-bot for Andy Lutomirski
2015-03-17  8:45   ` tip-bot for Andy Lutomirski
2015-03-10 18:05 ` [PATCH 2/3] x86: Unify and fix init sp0 Andy Lutomirski
2015-03-11 11:21   ` Borislav Petkov
2015-03-16 12:09   ` [tip:x86/asm] x86/asm/entry: Unify and fix initial thread_struct: :sp0 values tip-bot for Andy Lutomirski
2015-03-17  8:45   ` tip-bot for Andy Lutomirski
2015-03-10 18:06 ` [PATCH 3/3] x86_32: Document our abuse of ss1 and sp1 Andy Lutomirski
2015-03-10 19:13   ` Denys Vlasenko
2015-03-10 20:06     ` Andy Lutomirski
2015-03-10 20:52       ` Denys Vlasenko [this message]
2015-03-16 12:09   ` [tip:x86/asm] x86/asm/entry/32: Document our abuse of x86_hw_tss: :ss1 and x86_hw_tss::sp1 tip-bot for Andy Lutomirski
2015-03-16 15:36     ` Andy Lutomirski
2015-03-17  8:45   ` tip-bot for Andy Lutomirski

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='CAK1hOcMg5e3AamWa=XwSLJWEJBOo_DoL3DgC5RcCpXXhkJnuBA@mail.gmail.com' \
    --to=vda.linux@googlemail.com \
    --cc=bp@alien8.de \
    --cc=dvlasenk@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=oleg@redhat.com \
    --cc=x86@kernel.org \
    --subject='Re: [PATCH 3/3] x86_32: Document our abuse of ss1 and sp1' \
    /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

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).