linux-kernel - Re: 2.6.25-mm1

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:	Sat, 19 Apr 2008 11:21:27 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Joseph Fannin <jfannin@...il.com>, linux-kernel@...r.kernel.org,
	Andres Salomon <dilinger@...ued.net>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: 2.6.25-mm1

On Fri, 18 Apr 2008 20:29:25 -0700
Andrew Morton <akpm@...ux-foundation.org> wrote:

> That's
> 
>                 WARN_ON_ONCE(is_ram);
> 
> the changelog for the patch which added that warning is
> information-free 

it got added with a full changelog, then temporary removed and then added back ;(

> and there's no code comment explaining what went
> wrong, which makes things rather harder than they ought to be.
> 
> Yes it's due to the new OLPC code.  olpc_init() has
> 
> 	romsig = ioremap(0xffffffc0, 16);
> 
> which we probably just shouldn't do this at all unless we're running
> on the OLPC hardware.  But we need to do this to find out if we're
> running on the OLPC hardware!  Perhaps the warning should just be
> removed. --

calling ioremap() on something which COULD be ram is... REALLY nasty.
The kernel has to mark that page uncached, for all users and mappings of that memory.
A second hard case then is to find out when the last ioremap() user has
released that memory (since there's several cases where different parts of the same
4K page can be ioremapped) before it can map it cached again. The good news is that
until this olpc patch got in, there were no users of this capability....
Instead of outright forbidding it though we added a warn_on to find out if the
assumption of no users was correct... 
seems it caught some new code which is trying to do this here.

this code should probably be a lot more careful and check that
1) there is no actual kernel memory or something else at this region
   (what if there's some other device there? this code could blow up)
2) the machine won't tripple fault or otherwise throw tantrums if
   this hardcoded value is accessed (not automatic on x86!!)
3) it only runs if there's a really high degree of confidence that this really is
   an OLPC device.
or maybe
4) get this address from some other table or system provided resource

-- 
If you want to reach me at my work email, use arjan@...ux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
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/