linux-kernel - Re: [GIT PULL] x86 setup BIOS workarounds

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, 1 Apr 2009 11:24:10 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>
cc:	"Michael K. Johnson" <johnsonm@...th.com>,
	Justin Forbes <jmforbes@...uxtx.org>,
	Jordan Hargrave <Jordan_Hargrave@...l.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] x86 setup BIOS workarounds

On Wed, 1 Apr 2009, H. Peter Anvin wrote:
> 
> implements handling for the backwards-incompatible(!) E820 handling in 
> ACPI 3.

I am _extremely_ nervous about this one.

You do

	size = sizeof buf;	/* ACPI-3 size */
	asm(.. "+c" (size)	/* size might change */
	..
	if (size > 20 && !(buf.ext_flags & 1))
		continue;

ie you are expecting that _all_ old pre-ACPI-3 BIOSES will always set size 
to 20, or always write a low-bit-set value to that extended flag field 
that doesn't even exist previously.

I don't think that's likely true. Quite frankly, I'd expect a number of 
BIOSen to entirely ignore %ecx, since it's irrelevant (it _has_ to be 
bigger than 20 anyway on entry, and I doubt anybody really ever bothered 
to test that it's 20 on exit).

So at a _minimum_, I'd suggest that we set bug.ext_flags to 1 before the 
call - so that if some random BIOS just leaves %ecx unchanged, it won't 
mean that the area just gets ignored as a ACPI-3 entry.

And if it really _is_ a new ACPI-3 BIOS, it will overwrite ext_flags with 
its own value.

I've pulled you changes, but I really don't like how they seem to be 
designed to be very fragile, and designed to expect BIOSes to actually 
implement documented interfaces without bugs. So please look at it.

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