linux-kernel - Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP

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, 02 Jun 2007 18:42:23 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Jared Hulbert <jaredeh@...il.com>
CC:	carsteno@...ibm.com, Andrew Morton <akpm@...ux-foundation.org>,
	richard.griffiths@...driver.com,
	Richard Griffiths <res07ml0@...izon.net>,
	Linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP

Jared Hulbert wrote:
>> > The current xip stack relies on having struct page behind the memory
>> > segment. This causes few impact on memory management, but occupies some
>> > more memory. The cramfs patch chose to modify copy on write in order to
>> > deal with vmas that don't have struct page behind.
>> > So far, Hugh and Linus have shown strong opposition against copy on
>> > write with no struct page behind. If this implementation is acceptable
>> > to the them, it seems preferable to me over wasting memory. The xip
>> > stack should be modified to use this vma flag in that case.
>>
>> I would rather not :P
>>
>> We can copy on write without a struct page behind the source today, no?
> 
> 
> The existing COW techniques fail on some corner cases.  I'm not up to
> speed on the vm code.  I'll try to look into this a little more but it
> might be useful if I knew what questions I need to answer so you vm
> experts can understand the problem.

Previously I believe we couldn't do COW without a struct page for the
source memory, nor could we COW with a source that is not readable
from the kernel virtual mapping.

Now we can do both. cow_user_page in mm/memory.c does a copy_from_user
if there is no source page, so it uses the user mappings and does not
require a struct page.

The question is, why is that not enough (I haven't looked at these
patches enough to work out if there is anything more they provide).

> 
> Let me give one example.  If you try to debug an XIP application
> without this patch, bad things happen.  XIP in this sense is synomous
> with executing directly out of Flash and you can't just change the
> physical memory to redirect it to the debugger so easily in Flash.
> Now I don't know exactly why yet some, but not all applications,
> trigger this added vm hack.  I'm not sure exactly why it would get
> triggered under normal circumstances.  Why would a read-only map get
> written to?
> 
>> What is insufficient for the XIP code with the current COW?
> 
> 
> So I think the problem may have something to do with the nature of the
> memory in question.   We are using Flash that is ioremap()'ed to a
> usable virtual address.  And yet we go on to try to use it as if it
> were plain old system memory, like any RAM page.  We need it to be
> presented as any other memory page only physically read-only.
> ioremap() seems to be a hacky way of accomplishing that, but I can't
> think of better way.  In ARM we even had to invent ioremap_cached() to
> improve performance.  Thoughts?
> 


-- 
SUSE Labs, Novell Inc.
-
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/