linux-kernel - Re: [PATCH 3/3] x86_32: Document our abuse of ss1 and sp1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK1hOcMg5e3AamWa=XwSLJWEJBOo_DoL3DgC5RcCpXXhkJnuBA@mail.gmail.com>
Date:	Tue, 10 Mar 2015 21:52:48 +0100
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Denys Vlasenko <dvlasenk@...hat.com>, X86 ML <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Borislav Petkov <bp@...en8.de>, Oleg Nesterov <oleg@...hat.com>
Subject: Re: [PATCH 3/3] x86_32: Document our abuse of ss1 and sp1

On Tue, Mar 10, 2015 at 9:06 PM, Andy Lutomirski <luto@...capital.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);
...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/