Re: [PATCH 2/2] x86/asm/entry/64: do not TRACE_IRQS fast SYSRET64 path

[Denys Vlasenko <dvlasenk@redhat.com>]

On 03/25/2015 07:38 PM, Ingo Molnar wrote:
> 
> * Denys Vlasenko <dvlasenk@redhat.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@redhat.com>
>> CC: Linus Torvalds <torvalds@linux-foundation.org>
>> CC: Steven Rostedt <rostedt@goodmis.org>
>> CC: Ingo Molnar <mingo@kernel.org>
>> CC: Borislav Petkov <bp@alien8.de>
>> CC: "H. Peter Anvin" <hpa@zytor.com>
>> CC: Andy Lutomirski <luto@amacapital.net>
>> CC: Oleg Nesterov <oleg@redhat.com>
>> CC: Frederic Weisbecker <fweisbec@gmail.com>
>> CC: Alexei Starovoitov <ast@plumgrid.com>
>> CC: Will Drewry <wad@chromium.org>
>> CC: Kees Cook <keescook@chromium.org>
>> CC: x86@kernel.org
>> CC: linux-kernel@vger.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.