linux-kernel - Re: [PATCH 2/2] x86/asm/entry/64: do not TRACE

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]

Date:	Wed, 25 Mar 2015 20:15:59 +0100
From:	Denys Vlasenko <dvlasenk@...hat.com>
To:	Ingo Molnar <mingo@...nel.org>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Borislav Petkov <bp@...en8.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andy Lutomirski <luto@...capital.net>,
	Oleg Nesterov <oleg@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Alexei Starovoitov <ast@...mgrid.com>,
	Will Drewry <wad@...omium.org>,
	Kees Cook <keescook@...omium.org>, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] x86/asm/entry/64: do not TRACE_IRQS fast SYSRET64
 path

On 03/25/2015 07:38 PM, Ingo Molnar wrote:
> 
> * Denys Vlasenko <dvlasenk@...hat.com> wrote:
> 
>> SYSRET code path has a small irq-off block.
>> On this code path, TRACE_IRQS_ON can't be called right before interrupts
>> are enabled for real, we can't clobber registers there.
>> So current code does it earlier, in a safe place.
>>
>> But with this, TRACE_IRQS_OFF/ON frames just two fast instructions,
>> which is ridiculous: now most of irq-off block is _outside_ of the framing.
>>
>> Do the same thing that we do on SYSCALL entry: do not track this irq-off block,
>> it is very small to ever cause noticeable irq latency.
>>
>> Be careful: make sure that "jnz int_ret_from_sys_call_irqs_off" now does
>> invoke TRACE_IRQS_OFF - move int_ret_from_sys_call_irqs_off label before
>> TRACE_IRQS_OFF.
>>
>> Signed-off-by: Denys Vlasenko <dvlasenk@...hat.com>
>> CC: Linus Torvalds <torvalds@...ux-foundation.org>
>> CC: Steven Rostedt <rostedt@...dmis.org>
>> CC: Ingo Molnar <mingo@...nel.org>
>> CC: Borislav Petkov <bp@...en8.de>
>> CC: "H. Peter Anvin" <hpa@...or.com>
>> CC: Andy Lutomirski <luto@...capital.net>
>> CC: Oleg Nesterov <oleg@...hat.com>
>> CC: Frederic Weisbecker <fweisbec@...il.com>
>> CC: Alexei Starovoitov <ast@...mgrid.com>
>> CC: Will Drewry <wad@...omium.org>
>> CC: Kees Cook <keescook@...omium.org>
>> CC: x86@...nel.org
>> CC: linux-kernel@...r.kernel.org
>> ---
>>
>> Changes in v2: added comment
>>
>>  arch/x86/kernel/entry_64.S | 13 +++++++------
>>  1 file changed, 7 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
>> index 9c8661c..658cf2e 100644
>> --- a/arch/x86/kernel/entry_64.S
>> +++ b/arch/x86/kernel/entry_64.S
>> @@ -269,8 +269,11 @@ system_call_fastpath:
>>   * Has incompletely filled pt_regs.
>>   */
>>  	LOCKDEP_SYS_EXIT
>> +	/*
>> +	 * We do not frame this tiny irq-off block with TRACE_IRQS_OFF/ON,
>> +	 * it is too small to ever cause noticeable irq latency.
> 
>          * ... but if we enter the slowpath from here, we'll execute a 
>          * proper TRACE_IRQS_OFF call.
> 
>> @@ -298,6 +298,7 @@ system_call_fastpath:
>>  	 * 64bit SYSRET restores rip from rcx,
>>  	 * rflags from r11 (but RF and VM bits are forced to 0),
>>  	 * cs and ss are loaded from MSRs.
>> +	 * Restoration of rflags re-enables interrupts.
>>  	 */
>>  	USERGS_SYSRET64
> 
> Is that true even if user-space disabled irqs (via CLI) and executed a 
> syscall while having irqs off?

sysret restore "interrupt enable" state as it was before syscall.

Userspace normally can't disable interrupts. Therefore
usually sysret will enable interrupts because they were enabled
before syscall.

Userspace (root) can disable interrupts after it executed sys_iopl(3).
Then CLI starts working. In this case, sysret won't enable interrupts.
This is a very untypical use case.

--
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/