linux-kernel - RE: [RFC PATCH 07/12] e1000e: debug contention on NVM SWFLAG

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, 2 Oct 2008 09:27:12 -0700
From:	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>
To:	"Olaf Kirch" <okir@...e.de>, "Jiri Kosina" <jkosina@...e.cz>
Cc:	<linux-kernel@...r.kernel.org>, <linux-netdev@...r.kernel.org>,
	<kkeil@...e.de>, <agospoda@...hat.com>, <arjan@...ux.intel.com>,
	"Graham, David" <david.graham@...el.com>,
	"Allan, Bruce W" <bruce.w.allan@...el.com>,
	"Ronciak, John" <john.ronciak@...el.com>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	<chris.jones@...onical.com>, <tim.gardner@...el.com>,
	<airlied@...il.com>
Subject: RE: [RFC PATCH 07/12] e1000e: debug contention on NVM SWFLAG

Olaf Kirch wrote:
> Looks like the e1000 watchdog racing with some dhclient activity
> (upping the interface). 
 
> I just noticed that the driver actually uses register pages. So it
> looks like it's possible to have something like this without the
> mutex: 
> 
> 	process A selects page A
> 	process B selects page B
> 	process A writes to register at offset A'

I think that is possible, which is why the mutex patch would be good for
the future.  However we have not shown that to be happening as a root
cause, but I don't rule it out.

so, why now?  Drivers since before the e1000/e1000e split had this same
code, with no reports of problems.  This code has been heavily tested,
and one of the platforms easily reproducing this has been available for
3 years now (ich8), with code that is basically unchanged in the driver.
 
> So we may end up writing to the wrong register. I think I heard
> Vojtech mention 
> that the e1000e also has a register based interface to erase/rewrite
> the NVM programmatically. Do we know at which offsets these registers
> live? 

The flash control registers are documented in the ICH documentation, and
are located at physical memory location indicated by BAR1 in the config
space of device 0:19.0

I wonder if we couldn't put a check in to see if the value we end up
reading from the register controlling the operation matches the
operation we were expecting (read vs write vs block erase)
--
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/