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: <d991c9c0-ad36-929b-ae1b-05cc97aff19f@linux.intel.com>
Date:   Wed, 1 Nov 2017 11:27:48 -0700
From:   Dave Hansen <dave.hansen@...ux.intel.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        moritz.lipp@...k.tugraz.at, daniel.gruss@...k.tugraz.at,
        michael.schwarz@...k.tugraz.at, luto@...nel.org,
        torvalds@...ux-foundation.org, keescook@...gle.com,
        hughd@...gle.com, x86@...nel.org
Subject: Re: [PATCH 01/23] x86, kaiser: prepare assembly for entry/exit CR3
 switching

On 11/01/2017 11:18 AM, Borislav Petkov wrote:
>> +.macro SAVE_AND_SWITCH_TO_KERNEL_CR3 scratch_reg:req save_reg:req
>> +	movq	%cr3, %r\scratch_reg
>> +	movq	%r\scratch_reg, \save_reg
> 
> So one of the args gets passed as "ax", for example, which then gets
> completed to a register with the "%r" prepended and the other is a full
> register: %r14.
> 
> What for? Can we stick with one format pls?

This allows for a tiny optimization of Andy's that I realize I must have
blown away at some point.  It lets us do a 32-bit-register instruction
(and using %eXX) when checking KAISER_SWITCH_MASK instead of a 64-bit
register via %rXX.

I don't feel strongly about maintaining that optimization it looks weird
and surely doesn't actually do much.

>> diff -puN arch/x86/entry/entry_64_compat.S~kaiser-luto-base-cr3-work arch/x86/entry/entry_64_compat.S
>> --- a/arch/x86/entry/entry_64_compat.S~kaiser-luto-base-cr3-work	2017-10-31 15:03:48.107007348 -0700
>> +++ b/arch/x86/entry/entry_64_compat.S	2017-10-31 15:03:48.113007631 -0700
>> @@ -48,8 +48,13 @@
>>  ENTRY(entry_SYSENTER_compat)
>>  	/* Interrupts are off on entry. */
>>  	SWAPGS_UNSAFE_STACK
>> +
>>  	movq	PER_CPU_VAR(cpu_current_top_of_stack), %rsp
>>  
>> +	pushq	%rdi
>> +	SWITCH_TO_KERNEL_CR3 scratch_reg=%rdi
>> +	popq	%rdi
> 
> So we switch to kernel CR3 right after we've setup kernel stack...
> 
>> +
>>  	/*
>>  	 * User tracing code (ptrace or signal handlers) might assume that
>>  	 * the saved RAX contains a 32-bit number when we're invoking a 32-bit
>> @@ -91,6 +96,9 @@ ENTRY(entry_SYSENTER_compat)
>>  	pushq   $0			/* pt_regs->r15 = 0 */
>>  	cld
>>  
>> +	pushq	%rdi
>> +	SWITCH_TO_KERNEL_CR3 scratch_reg=%rdi
>> +	popq	%rdi
> 
> ... and switch here *again*, after pushing pt_regs?!? What's up?
> 
>>  	/*
>>  	 * SYSENTER doesn't filter flags, so we need to clear NT and AC
>>  	 * ourselves.  To save a few cycles, we can check whether

Thanks for catching that.  We can kill one of these.  I'm inclined to
kill the first one.  Looking at the second one since we've just saved
off ptregs, that should make %rdi safe to clobber without the push/pop
at all.

Does that seem like it would work?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ