linux-kernel - Re: [PATCH -mm] utrace: nommu fixup support utrace

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] [day] [month] [year] [list]

Message-ID: <29185.1173440504@redhat.com>
Date:	Fri, 09 Mar 2007 11:41:44 +0000
From:	David Howells <dhowells@...hat.com>
To:	Roland McGrath <roland@...hat.com>
Cc:	bryan.wu@...log.com, Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH -mm] utrace: nommu fixup support utrace 

Roland McGrath <roland@...hat.com> wrote:

> What I meant to suggest is that I would start from a safety point of view
> with get_user_pages/access_process_vm refusing to do force&&write to
> MAP_PRIVATE pages that are in fact being shared (ETXTBSY or something).

That's a good idea.  The other possibility I've thought of is maintaining a
list of the changes made to such a region and deapplying them / reapplying
them as the processes get scheduled.  That's probably fine as long as it's
just a few breakpoints and it's a single-CPU system.

But this is irrelevant as it doesn't address the sharing-prevention issue.

> (When it's not being shared, it should do whatever is necessary to make sure
> that page is known dirty and not hand it out for later mappings.)

NOMMU doesn't with pages at this level, but deals with regions of memory
instead.  A mapping may be part of a page, a whole page, or several pages.
NOMMU private file mmap() allocates using kmalloc(), so if you allocate a
1-byte buffer, that's all you're guaranteed to get.

As it happens, when the code sees PT_PTRACED, the VMA is marked as being
unshareable by the simple expedient of turning off VM_MAYSHARE, meaning that it
neither shares with already existing mappings, nor will it be shareable by
mappings that have yet to be made - even within the same process.

> Then you can go about trying to make the safe (no sharing) case come about
> when you want it.

Which brings us back to the if-statement you objected to.  Its presence is
still required so as to prevent sharing of the executable and loader, and this
seems a good a way to do it as any as far as I can see.  Remember that it has
be controlled by something that can be set before the binfmt load_binary() op
runs.

David
-
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/