linux-kernel - Re: [PATCH] xen: x86_32: do not enable iterrupts when returning from exception in interrupt context

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: <4E5F3FF7.8010805@redhat.com>
Date:	Thu, 01 Sep 2011 10:19:03 +0200
From:	Igor Mammedov <imammedo@...hat.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
CC:	linux-kernel@...r.kernel.org, xen-devel@...ts.xensource.com,
	konrad.wilk@...cle.com
Subject: Re: [PATCH] xen: x86_32: do not enable iterrupts when returning from
 exception in interrupt context

On 09/01/2011 12:37 AM, Jeremy Fitzhardinge wrote:
> On 08/31/2011 04:47 PM, Igor Mammedov wrote:
>> If vmalloc page_fault happens inside of interrupt handler with interrupts
>> disabled then on exit path from exception handler when there is no pending
>> interrupts, the following code (arch/x86/xen/xen-asm_32.S:112):
>>
>> 	cmpw $0x0001, XEN_vcpu_info_pending(%eax)
>> 	sete XEN_vcpu_info_mask(%eax)
>>
>> will enable interrupts even if they has been previously disabled according to
>> eflags from the bounce frame (arch/x86/xen/xen-asm_32.S:99)
>>
>> 	testb $X86_EFLAGS_IF>>8, 8+1+ESP_OFFSET(%esp)
>> 	setz XEN_vcpu_info_mask(%eax)
>>
>> Solution is in setting XEN_vcpu_info_mask only when it should be set
>> according to
>> 	cmpw $0x0001, XEN_vcpu_info_pending(%eax)
>> but not clearing it if there isn't any pending events.
>
> Wow, that's a great find.  I guess it shows how rarely we end up doing
> an exception return with interrupts disabled, since that's been there
> since, erm, 2.6.23?
>
> But this could definitely explain some bugs where interrupts became
> unexpectedly re-enabled.  Were you tracking one down when you found this?
>
>> Signed-off-by: Igor Mammedov<imammedo@...hat.com>
>> ---
>>   arch/x86/xen/xen-asm_32.S |    6 +++++-
>>   1 files changed, 5 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/x86/xen/xen-asm_32.S b/arch/x86/xen/xen-asm_32.S
>> index 22a2093..313dca7 100644
>> --- a/arch/x86/xen/xen-asm_32.S
>> +++ b/arch/x86/xen/xen-asm_32.S
>> @@ -113,10 +113,14 @@ xen_iret_start_crit:
>>
>>   	/*
>>   	 * If there's something pending, mask events again so we can
>> -	 * jump back into xen_hypervisor_callback
>> +	 * jump back into xen_hypervisor_callback. Otherwise do not
>> +	 * touch XEN_vcpu_info_mask.
>>   	 */
>> +	jne ignore_vcpu_info_mask
>>   	sete XEN_vcpu_info_mask(%eax)
>>
>> +ignore_vcpu_info_mask:
>> +
>
> This should be:
>
> 	jne 1f
> 	movb $1, XEN_vcpu_info_mask(%eax)
>
> 1:	popl %eax
>
>
> There's no point in using sete if we're already using a conditional jump
> to avoid the write, and it's better to use local labels for little
> control flow changes like this.
>
> Thanks,
>
       J
Jeremy,

Thanks for review, I'll re-post it soon.
--
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/