linux-kernel - Re: bad rss-counter message in 3.14rc5

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:	Tue, 18 Mar 2014 19:37:01 -0700 (PDT)
From:	Hugh Dickins <hughd@...gle.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Hugh Dickins <hughd@...gle.com>, Dave Jones <davej@...hat.com>,
	Cyrill Gorcunov <gorcunov@...il.com>,
	Sasha Levin <sasha.levin@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	linux-mm <linux-mm@...ck.org>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Bob Liu <bob.liu@...cle.com>,
	Konstantin Khlebnikov <koct9i@...il.com>
Subject: Re: bad rss-counter message in 3.14rc5

On Tue, 18 Mar 2014, Linus Torvalds wrote:
> On Tue, Mar 18, 2014 at 7:06 PM, Hugh Dickins <hughd@...gle.com> wrote:
> >
> > I'd love that, if we can get away with it now: depends very
> > much on whether we then turn out to break userspace or not.
> 
> Right. I suspect we can, though, but it's one of those "we can try it
> and see". Remind me early in the 3.15 merge window, and we can just
> turn the "force" case into an error case and see if anybody hollers.

Super, I'll do that, thanks.

For 3.15, and probably 3.16 too, we should keep in place whatever
partial accommodations we have for the case (such as allowing for
anon and swap in fremap's zap_pte), in case we do need to revert;
but clean those away later on.  (Not many, I think: it was mainly
a guilty secret that VM accounting didn't really hold together.)

> 
> > If I remember correctly, it's been that way since early days,
> > in case ptrace were used to put a breakpoint into a MAP_SHARED
> > mapping of an executable: to prevent that modification from
> > reaching the file, if the file happened to be opened O_RDWR.
> > Usually it's not open for writing, and mapped MAP_PRIVATE anyway.
> 
> Yes, it's been that way since the very beginning, I think it goes back
> pretty much as far as MAP_SHARED does.
> 
> We used to play lots of games wrt MAP_SHARED - in fact I think we used
> to silently turn a MAP_SHARED RO mapping into MAP_PRIVATE because for
> the longest time there was no "true" writable MAP_SHARED at all, but
> we did have a coherent MAP_PRIVATE and something like the indexer for
> nntpd wanted a read-only shared mapping of the nntp spool or something
> like that. I forget the details, it's a _loong_ time ago.
> 
> So the whole "force turns a MAP_SHARED page into MAP_PRIVATE" all used
> to make a lot more sense in that kind of situation, when MAP_SHARED vs
> MAP_PRIVATE was much less of a black-and-white thing.
> 
> I really suspect nobody cares wrt ptrace, especially since presumably
> other systems haven't had those kinds of games (although who knows -
> HP-UX in particular had some of the shittiest mmap() implementations
> on the planet - it made even the original Linux mmap hacks look like a
> thing of pure beauty in comparison).

:)  That fits with what I heard of HP-UX mmap,
but I never had the pleasure of dealing with it.

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