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); ...
next prev parent 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 an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.