public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Halasa <khc@pm.waw.pl>
To: "Brandeburg\, Jesse" <jesse.brandeburg@intel.com>
Cc: "Tim Gardner" <timg@tpi.com>,
	"Jesse Barnes" <jbarnes@virtuousgeek.org>,
	"Arjan van de Ven" <arjan@linux.intel.com>,
	"Jiri Kosina" <jkosina@suse.cz>,
	"LKML" <linux-kernel@vger.kernel.org>, <agospoda@redhat.com>,
	"Ronciak\, John" <john.ronciak@intel.com>, "Allan\,
	Bruce W" <bruce.w.allan@intel.com>, "Graham\,
	David" <david.graham@intel.com>, <kkiel@suse.de>,
	<tglx@linutronix.de>, <chris.jones@canonical.com>,
	<arjan@linux.jf.intel.com>
Subject: Re: e1000e NVM corruption issue status
Date: Sat, 27 Sep 2008 20:45:41 +0200	[thread overview]
Message-ID: <m3wsgx77hm.fsf@maximus.localdomain> (raw)
In-Reply-To: <36D9DB17C6DE9E40B059440DB8D95F5206446B4E@orsmsx418.amr.corp.intel.com> (Jesse Brandeburg's message of "Fri\, 26 Sep 2008 15\:23\:39 -0700")

"Brandeburg, Jesse" <jesse.brandeburg@intel.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

  reply	other threads:[~2008-09-27 18:45 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <987CEB09A2567F4A963E1E226364E2D33A685B4B@orsmsx418.amr.corp.intel.com>
2008-09-26  1:50 ` e1000e NVM corruption issue status Brandeburg, Jesse
2008-09-26  1:58   ` Chris Snook
2008-09-26  2:04     ` Brandeburg, Jesse
2008-09-26  2:01   ` Brandeburg, Jesse
2008-09-26  2:09     ` Brandeburg, Jesse
2008-09-26  7:12       ` Ingo Molnar
2008-09-26  2:09     ` Brandeburg, Jesse
2008-09-26  2:10     ` Brandeburg, Jesse
2008-09-26  2:10     ` Brandeburg, Jesse
2008-09-26  2:10     ` Brandeburg, Jesse
2008-09-26  2:11     ` Brandeburg, Jesse
2008-09-26  2:11     ` Brandeburg, Jesse
2008-09-26  2:12     ` Brandeburg, Jesse
2008-09-26  2:12     ` Brandeburg, Jesse
2008-09-26  2:13     ` Brandeburg, Jesse
2008-09-26  2:13     ` Brandeburg, Jesse
2008-09-29 15:52       ` Jiri Kosina
2008-09-29 16:20         ` Jiri Kosina
2008-09-29 16:24           ` Brandeburg, Jesse
2008-09-29 17:18             ` Jiri Kosina
2008-09-29 17:36               ` Jiri Kosina
2008-09-29 22:43                 ` Jiri Kosina
2008-09-26  6:13     ` Jiri Kosina
2008-09-26 11:49       ` Arjan van de Ven
2008-09-26 17:52         ` Jesse Barnes
2008-09-26 18:23           ` Jesse Barnes
2008-09-26 18:39             ` Jesse Barnes
2008-09-26 18:43               ` Jesse Barnes
2008-09-26 18:53             ` Tim Gardner
2008-09-26 22:04               ` Krzysztof Halasa
2008-09-26 22:23                 ` Brandeburg, Jesse
2008-09-27 18:45                   ` Krzysztof Halasa [this message]
2008-09-27  0:05               ` Brandeburg, Jesse
2008-09-27  4:20                 ` Tim Gardner
2008-09-26 14:23     ` Karsten Keil
2008-09-26  5:44   ` Jesse Brandeburg
2008-09-26  7:19   ` Karsten Keil
2008-10-18 19:13   ` James Courtier-Dutton
2008-10-18 22:49     ` Jiri Kosina

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3wsgx77hm.fsf@maximus.localdomain \
    --to=khc@pm.waw.pl \
    --cc=agospoda@redhat.com \
    --cc=arjan@linux.intel.com \
    --cc=arjan@linux.jf.intel.com \
    --cc=bruce.w.allan@intel.com \
    --cc=chris.jones@canonical.com \
    --cc=david.graham@intel.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=jesse.brandeburg@intel.com \
    --cc=jkosina@suse.cz \
    --cc=john.ronciak@intel.com \
    --cc=kkiel@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=timg@tpi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox