linux-kernel - Re: Regression: Requiring CAP_SYS_ADMIN for /proc/<pid>/pagemap causes application-level breakage

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, 29 Apr 2015 21:24:40 +0100
From:	Mark Williamson <mwilliamson@...o-software.com>
To:	"Kirill A. Shutemov" <kirill@...temov.name>
Cc:	Mark Seaborn <mseaborn@...omium.org>,
	kernel list <linux-kernel@...r.kernel.org>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Pavel Emelyanov <xemul@...allels.com>,
	Konstantin Khlebnikov <khlebnikov@...nvz.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andy Lutomirski <luto@...capital.net>,
	Linux API <linux-api@...r.kernel.org>,
	Finn Grimwood <fgrimwood@...o-software.com>,
	Daniel James <djames@...o-software.com>
Subject: Re: Regression: Requiring CAP_SYS_ADMIN for /proc/<pid>/pagemap
 causes application-level breakage

Hi,

On Wed, Apr 29, 2015 at 8:36 PM, Kirill A. Shutemov
<kirill@...temov.name> wrote:
> On Wed, Apr 29, 2015 at 07:44:57PM +0100, Mark Williamson wrote:
>> Hi all,
 ... snip ...
>> For context, we were previously using pagemap as a cross-platform way
>> to get soft-dirty-like functionality.  Specifically, to ask "did a
>> process write to any pages since fork()" by comparing addresses and
>> deducing where CoW must have occurred.  In the absence of soft-dirty
>> and the physical addresses, it looks like we can't figure that out
>> with the remaining information in pagemap.
>>
>> If the pagemap file included the "writeable" bit from the PTE, we
>> think we'd have all the information required to deduce what we need
>> (although I realise that's a bit of a nasty workaround).  If I
>> proposed including the PTE protection bits in pagemap, would that be
>> controversial?  I'm guessing yes but thought it was worth a shot ;-)
>> Would anybody be able to suggest a more tasteful approach?
>
> Emm.. I have hard time to understand how writable bit is enough to get
> soft-dirty-alike functionality.

In the general case, you are of course correct - in our specific case
I *think* we'd be able to manage OK ...  (see below).

> Let's say we have anon-mapping with COW setup after the fork(). It's not
> writable PTEs to trigger COW on wp faults. But you can easily get to the
> same non-writable PTE after breaking COW: fork() again or
> mprotect(PROT_READ) and mprotect(PROT_READ|PROT_WRITE) back.

I believe we'll be able to get away with this in our particular
usecase.  The process is running in our debugger at the time and so we
can interpose on the system calls that are happening.  That should
give us the opportunity to check for CoW-breaking before the debuggee
is allowed to alter page protections itself.

It ends up not being full soft-dirty behaviour but it's similar enough
to tell us what we need to know.

Cheers,
Mark

> ?
>
>>
>> Thanks,
>> Mark
>>
>> [1] I'd note that using soft-dirty is clearly the right approach for
>> us on x64, where available and that ideally we'd use it on other
>> architectures - cross-arch support for soft-dirty is a slightly
>> different discussion, which I hope to post another thread for.
>
> --
>  Kirill A. Shutemov
--
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/