linux-kernel - Re: [PATCH] x86 efi: bugfix interrupt disabling sequence

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] [day] [month] [year] [list]

Message-ID: <1379928463.1953.30.camel@dhcp-128-237.ams.redhat.com>
Date:	Mon, 23 Sep 2013 11:27:43 +0200
From:	Bart Kuivenhoven <bemk@...hat.com>
To:	Matt Fleming <matt@...sole-pimps.org>
Cc:	matt.fleming@...el.com, hpa@...or.com, tglx@...utronix.de,
	mingo@...hat.com, x86@...nel.org, linux-efi@...r.kernel.org,
	linux-kernel@...r.kernel.org, jcm@...hat.com, msalter@...hat.com
Subject: Re: [PATCH] x86 efi: bugfix interrupt disabling sequence

On Sat, 2013-09-21 at 16:41 +0100, Matt Fleming wrote:
> On Fri, 20 Sep, at 10:21:26PM, Bart Kuivenhoven wrote:
> > Well, isn't it so, that the kernel expects a setup in which interrupts
> > are disabled before the decompressed image is loaded?
>  
> Yes, but I wasn't advocating leaving interrupts enabled, rather, because
> interrupts are disabled we don't need to build an empty IDT, which will
> never be used.

Ah, well in that case I think you'll like the new version of my patch
that I'll send out soon.

> > What we can do is remove the lidt instruction and IDT pointer, but that
> > still doesn't change anything with regards to the kernels expectations.
> > 
> > And no, I haven't witnessed a triple fault, this is purely theoretical,
> > with a very slim chance of it actually happening. That does not mean
> > that it can't happen though.
>  
> Right, but the answer to my question will dictate how aggressively we
> apply your patch - whether it goes in the 'urgent' queue to be pushed
> quickly or whether we give it more testing. Patches that fix serious
> issues that users are hitting tend to make it into the next release. For
> patches that fix theoretical bugs, we'll usually put it through more
> strenuous testing first.

I haven't seen it happen.

Even if it happens, the CPU will just reset and try again, with a very
high likelihood that it will succeed that time.

Given these circumstances, I'd say you're more than welcome to put my
work through some serious tests rather than giving it 'urgent' status.

-- 
Kind regards/Met vriendelijke groet,
Bart Kuivenhoven.

Intern Fedora ARM,
Red Hat.

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