netdev - Re: [PATCH 2/3] e1000e: Useset_memory_ro()/set_memory

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:	Wed, 24 Sep 2008 01:45:53 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	David Miller <davem@...emloft.net>
cc:	jeffrey.t.kirsher@...el.com, jeff@...zik.org, mingo@...e.hu,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	jesse.brandeburg@...el.com, john.ronciak@...el.com,
	bruce.w.allan@...el.com
Subject: Re: [PATCH 2/3] e1000e: Useset_memory_ro()/set_memory_rw() to protect
 flash memory

On Tue, 23 Sep 2008, David Miller wrote:

> > A number of users have reported NVM corruption on various ICHx platform
> > LOMs.  One possible reasons for this could be unexpected and/or malicious
> > writes to the flash memory area mapped into kernel memory.  Once the
> > interface is up, there should be very few reads/writes of the mapped flash
> > memory.  This patch makes use of the x86 set_memory_*() functions to set
> > the mapped memory read-only and temporarily set it writable only when the
> > driver needs to write to it.  With the memory set read-only, any unexpected
> > write will be logged with a stack dump indicating the offending code.
> > Since these LOMs are only on x86 ICHx platforms, it does not matter that
> > this API is not yet available on other architectures, however it is
> > dependent on a previous patch that exports these function name symbols.
> If the X server or similar is causing this problem, this patch won't 
> help. The X server maps MMIO space using mmap() in userspace, and you're 
> only protecting the kernel side mapping.

Yes, probably not a vanilla kernel material, but could be very well used 
for testing to further isolate whether it is kernel or userspace 
corrupting the memory mapped eeprom.

At least I will build suse kernel package with these patches applied and 
ask users who are able to reproduce the problem and willing to test (if 
there are any that have backported their EEPROM properly before running 
new kernel :) ) to give it a try.

-- 
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html