linux-kernel - Re: e1000e NVM corruption issue status

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: <m3wsgx77hm.fsf@maximus.localdomain>
Date:	Sat, 27 Sep 2008 20:45:41 +0200
From:	Krzysztof Halasa <khc@...waw.pl>
To:	"Brandeburg\, Jesse" <jesse.brandeburg@...el.com>
Cc:	"Tim Gardner" <timg@....com>,
	"Jesse Barnes" <jbarnes@...tuousgeek.org>,
	"Arjan van de Ven" <arjan@...ux.intel.com>,
	"Jiri Kosina" <jkosina@...e.cz>,
	"LKML" <linux-kernel@...r.kernel.org>, <agospoda@...hat.com>,
	"Ronciak\, John" <john.ronciak@...el.com>,
	"Allan\, Bruce W" <bruce.w.allan@...el.com>,
	"Graham\, David" <david.graham@...el.com>, <kkiel@...e.de>,
	<tglx@...utronix.de>, <chris.jones@...onical.com>,
	<arjan@...ux.jf.intel.com>
Subject: Re: e1000e NVM corruption issue status

"Brandeburg, Jesse" <jesse.brandeburg@...el.com> writes:

> ICH 8/9/10 machines with Intel gigabit part integrated (82566/82567)
> share the system Flash space with all the other system devices, BIOS,
> etc.  The gigabit region is the currently only "unprotected" region I
> know of.  It is never directly memory mapped, but the registers that
> program to it are memory mapped from our BAR1, like Tim said, possibly
> only requiring an errant write of a few bits of ones, to erase it (I've
> been trying to confirm that)

I don't know the ICH 8/9/10 very well but it seems typical, i.e., the
flash is a X Mbit device usually mapped at some really high address
and then copied/decompressed to RAM ("shadow ROM" at the usual
locations 0xC0000 for VGA, 0xF0000 or so for system BIOS, something
between the two for Ethernet PXE).

Is the protection you write about the hardware flash region
protection? It can be easily removed by another command (another
write).

Anyway the problem in question is EEPROM, not flash?


I'm sure that simply erasing the PXE flash region would not prevent
the machine from booting. The BIOS requires a valid signature (55AA or
so) at the start of a BIOS extension block, and there is a checksum.

I also think that blindly erasing some regions of flash, or blindly
writing to it wouldn't kill the machine completely - there is a
boot block which is almost certainly protected (requires a command to
unblock). The boot block should notice the main BIOS image is
corrupted and should allow reflashing (using a DOS diskette and
perhaps without VGA output).
-- 
Krzysztof Halasa
--
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/