linux-kernel - Re: [PATCHv2 0/6] efi: detect erroneous firmware IRQ manipulation

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:	Mon, 25 Apr 2016 12:21:18 +0200
From:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:	Matt Fleming <matt@...eblueprint.co.uk>,
	Laszlo Ersek <lersek@...hat.com>
Cc:	Mark Rutland <mark.rutland@....com>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	Catalin Marinas <catalin.marinas@....com>,
	"hpa@...or.com" <hpa@...or.com>,
	Leif Lindholm <leif.lindholm@...aro.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	Will Deacon <will.deacon@....com>
Subject: Re: [PATCHv2 0/6] efi: detect erroneous firmware IRQ manipulation

(+ Laszlo)

On 25 April 2016 at 12:15, Matt Fleming <matt@...eblueprint.co.uk> wrote:
> On Sun, 24 Apr, at 10:22:41PM, Matt Fleming wrote:
>>
>> I like this series a lot (well, ignoring the fact that the firmware is
>> trying to eat itself). The runtime call code is much cleaner now, and
>> this is a great precedent for any future multi-architecture quirks we
>> may need.
>>
>> Queued for v4.7, thanks everyone!
>
> Hmm... Booting this series with Qemu and OVMF results in lots of
> warnings,
>
> [ 0.102173] ------------[ cut here ]------------
> [ 0.103000] WARNING: CPU: 0 PID: 0 at /dev/shm/mfleming/git/efi/drivers/firmware/efi/runtime-wrappers.c:30 efi_call_virt_check_flags+0x69/0x90
> [ 0.103505] Modules linked in:
> [ 0.104519] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc4+ #1
> [    0.105000]  0000000000000000 ffffffff81e03e30 ffffffff8132206f 0000000000000000
> [    0.105000]  0000000000000000 ffffffff81e03e70 ffffffff8105a47c 0000001e0000000a
> [    0.105000]  0000000000000246 0000000000000286 ffffffff81bed975 ffffffff81e03f10
> [    0.105000] Call Trace:
> [    0.105000]  [<ffffffff8132206f>] dump_stack+0x4d/0x6e
> [    0.105000]  [<ffffffff8105a47c>] __warn+0xcc/0xf0
> [    0.105000]  [<ffffffff8105a558>] warn_slowpath_null+0x18/0x20
> [    0.105000]  [<ffffffff8164e5a9>] efi_call_virt_check_flags+0x69/0x90
> [    0.105000]  [<ffffffff8164f9d2>] virt_efi_set_variable+0x82/0x190
> [    0.105000]  [<ffffffff81054555>] efi_delete_dummy_variable+0x75/0x80
> [    0.105000]  [<ffffffff81f599f6>] efi_enter_virtual_mode+0x463/0x472
> [    0.105000]  [<ffffffff81f41f82>] start_kernel+0x38f/0x415
> [    0.105000]  [<ffffffff81f419e1>] ? set_init_arg+0x55/0x55
> [    0.105000]  [<ffffffff81f415ee>] x86_64_start_reservations+0x2a/0x2c
> [    0.105000]  [<ffffffff81f416da>] x86_64_start_kernel+0xea/0xed
> [    0.107181] ---[ end trace 0081cc453369d969 ]---
> [    0.107499] Disabling lock debugging due to kernel taint
> [    0.108226] [Firmware Bug]: IRQ flags corrupted (0x00000246=>0x00000286) by EFI set_variable
>
> Has anyone tested this series on x86 to ensure that this is a rare
> case? I'll go and test some physical x86 machines now.

I suppose that it is quite likely that this issue occurs in the wild
if it is present in OVMF. Could anyone check which flag is actually
clobbered here?