linux-kernel - Re: Bug#584846: Detects only 64MB and fails to boot on Intel Green City board if e820 hooked by GRUB2

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:	Thu, 24 Jun 2010 07:18:34 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Josh Triplett <josh@...htriplett.org>
CC:	Ben Hutchings <ben@...adent.org.uk>, x86@...nel.org,
	584846@...s.debian.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: Bug#584846: Detects only 64MB and fails to boot on Intel Green
 City board if e820 hooked by GRUB2

On 06/24/2010 12:27 AM, Josh Triplett wrote:
> 
> The following patch fixes GRUB; with this patch, I can reserve memory
> (such as with drivemap), boot 2.6.35-rc3 successfully, and it detects
> all of my RAM.
> 

Congratulations!  You have just committed the single most common BIOS
implementation bug.  (Sorry for the sarcasm, but this seems to be a bug
that almost everyone who tries to implement BIOS makes at one point or
another... even the original IBM BIOS had it in at least one place.)

You *must not* use "lret $2" to return to the caller, because the INT
instruction will have cleared IF after pushing the registers to the
stack.  You have to restore the original IF, which "lret $2" will not do.

The best way to do this is to clobber the low byte of the flags register
on the stack.  Since CF is bit 0, and the low byte only contains
arithmetic flags anyway, you can simply overwrite the low byte with 0
for CF=0 and 1 for CF=1.  This will zero SF, ZF, AF and PF as side
effect, which is OK for almost all uses (including e820/e801/88.)

If you don't already have a pointer to the stack, you have to make one,
since it is not possible in 16-bit mode to access the stack directly.
One option is to replace each iret with a jump to the following common code:

carry_cf_iret:
	pushw	%bp
	movw	%sp, %bp
	setc	6(%bp)		/* Set CF on stack based on EFLAGS */
	popw	%bp
	iret

> 
> I don't see any trivial way Linux could work around this bug.  If the
> e820 call left CF=0 on entry, then the error case would get incorrectly
> treated as a valid e820 entry (albeit a final one, since bx=0).
> 

More importantly, it makes the error direction the wrong one.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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