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: <Pine.WNT.4.63.0809261316310.4052@jbrandeb-desk.amr.corp.intel.com>
Date:	Fri, 26 Sep 2008 17:05:15 -0700 (Pacific Daylight Time)
From:	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>
To:	Tim Gardner <timg@....com>
cc:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Arjan van de Ven <arjan@...ux.jf.intel.com>,
	Jiri Kosina <jkosina@...e.cz>,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	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

On Fri, 26 Sep 2008, Tim Gardner wrote:
> > Ok here's an updated one.  Jesse (Br) can you add it to your list?  If the X 
> > driver really is mapping too much this should catch it, as long as it goes 
> > through sysfs.

I have, am testing with it now.

> I've been experimenting with unmapping flash space until its actually
> needed, e.g., in the functions that use the E1000_READ_FLASH and
> E1000_WRITE_FLASH macros. Along the way I looked at how flash write

That sounds like a good patch set.  I had thought of trying that but 
hadn't gotten to it yet, so if you have something to look at in diff 
format just post it and we'll take a look.

> cycles are initiated because I was having a hard time believing that
> having flash space mapped was part of the root cause. However, it looks
> like its pretty simple to initiate a write or erase cycle. All of the
> required action bits in ICH_FLASH_HSFSTS and ICH_FLASH_HSFCTL must be 1,
> and these 2 register are in the correct order if X was writing 0xff in
> ascending order.

Seems simple but when I tried it for a couple of hours yesterday I 
couldn't get anything to happen to my flash.  This included putting 
ew16flash writes in the e1000e driver, and writing those magic bits.
--
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/