linux-kernel - Re: [PATCH 0/3] Volatile Ranges (v11)

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]

Message-ID: <20140320081359.GB32080@quack.suse.cz>
Date:	Thu, 20 Mar 2014 09:13:59 +0100
From:	Jan Kara <jack@...e.cz>
To:	Minchan Kim <minchan@...nel.org>
Cc:	Jan Kara <jack@...e.cz>, John Stultz <john.stultz@...aro.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Android Kernel Team <kernel-team@...roid.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Robert Love <rlove@...gle.com>, Mel Gorman <mel@....ul.ie>,
	Hugh Dickins <hughd@...gle.com>, Dave Hansen <dave@...1.net>,
	Rik van Riel <riel@...hat.com>,
	Dmitry Adamushko <dmitry.adamushko@...il.com>,
	Neil Brown <neilb@...e.de>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Mike Hommey <mh@...ndium.org>, Taras Glek <tglek@...illa.com>,
	KOSAKI Motohiro <kosaki.motohiro@...il.com>,
	Michel Lespinasse <walken@...gle.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH 0/3] Volatile Ranges (v11)

On Thu 20-03-14 10:09:54, Minchan Kim wrote:
> Hello,
> 
> On Wed, Mar 19, 2014 at 11:12:02AM +0100, Jan Kara wrote:
> > On Wed 19-03-14 09:49:18, Minchan Kim wrote:
> > > On Tue, Mar 18, 2014 at 11:07:50AM -0700, John Stultz wrote:
> > > > On Tue, Mar 18, 2014 at 8:11 AM, Minchan Kim <minchan@...nel.org> wrote:
> > > > > 1) SIGBUS
> > > > >
> > > > > It's one of the arguable issue because some user want to get a
> > > > > SIGBUS(ex, Firefox) while other want a just zero page(ex, Google
> > > > > address sanitizer) without signal so it should be option.
> > > > >
> > > > >         int vrange(start, len, VRANGE_VOLATILE|VRANGE_ZERO, &purged);
> > > > >         int vrange(start, len, VRANGE_VOLATILE|VRANGE_SIGNAL, &purged);
> > > > 
> > > > So, the zero-fill on volatile access feels like a *very* special case
> > > > to me, since a null page could be valid data in many cases. Since
> > > > support/interest for volatile ranges has been middling at best, I want
> > > > to start culling the stranger use cases. I'm open in the future to
> > > > adding a special flag or something if it really make sense, but at
> > > > this point, lets just get the more general volatile range use cases
> > > > supported.
> > > 
> > > I'm not sure it's special case. Because some user could reserve
> > > a big volatile VMA and want to use the range by circle queue for
> > > caching so overwriting could happen easily.
> > > We should call vrange(NOVOLATILE) to prevent SIGBUS right before
> > > overwriting. I feel it's unnecessary overhead and we could avoid
> > > the cost with VRANGE_ZERO.
> > > Do you think this usecase would be rare?
> >   If I understand it correctly the buffer would be volatile all the time
> > and userspace would like to opportunistically access it. Hum, but then with
> > your automatic zero-filling it could see half of the page with data and
> > half of the page zeroed out (the page got evicted in the middle of
> > userspace reading it). I don't think that's a very comfortable interface to
> > work with (you would have to very carefully verify the data you've read is
> > really valid). And frankly in most cases I'm afraid the application would
> > fail to do proper verification and crash randomly under memory pressure. So
> > I wouldn't provide VRANGE_ZERO unless I come across real people for which
> > avoiding marking the range as NONVOLATILE is a big deal and they are OK with
> > handling all the odd situations that can happen.
> 
> Plaes think following usecase.
> 
> Let's assume big volatile cacne.
> If there is request for cache, it should find a object in a cache
> and if it found, it should call vrange(NOVOLATILE) right before
> passing it to the user and investigate it was purged or not.
> If it wasn't purged, cache manager could pass the object to the user.
> But it's circular cache so if there is no request from user, cache manager
> always overwrites objects so it could encounter SIGBUS easily
> so as current sematic, cache manager always should call vrange(NOVOLATILE)
> right before the overwriting. Otherwise, it should register SIGBUS handler
> to unmark volatile by page unit. SIGH.
> 
> If we support VRANGE_ZERO, cache manager could overwrite object without
> SIGBUS handling or vrange(NOVOLATILE) call. Just need is vrange(NOVOLATILE)
> call while cache manager pass it to the user.
  OK, that makes some sense but I don't think we have to implement this
functionality in the beginning...
								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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/