Message-ID: <20150508045117.GA24741@gmail.com>
Date:	Fri, 8 May 2015 06:51:17 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	Dave Hansen <dave@...1.net>, linux-kernel@...r.kernel.org,
	x86@...nel.org
Subject: Re: [PATCH 00/12] [RFC] x86: Memory Protection Keys


* One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk> wrote:

> On Thu, 7 May 2015 21:26:20 +0200
> Ingo Molnar <mingo@...nel.org> wrote:
> 
> > 
> > * One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk> wrote:
> > 
> > > > We could keep heap metadata as R/O and only make it R/W inside of 
> > > > malloc() itself to catch corruption more quickly.
> > > 
> > > If you implement multiple malloc pools you can chop up lots of 
> > > stuff.
> > 
> > I'd say that a 64-bit address space is large enough to hide 
> > buffers in from accidental corruption, without any runtime page 
> > protection flipping overhead?
> 
> I'd say no. [...]

So if putting your buffers anywhere in a byte range of 
18446744073709551616 bytes large (well, 281474976710656 bytes with 
current CPUs) isn't enough to protect from stray writes? Could you 
outline the situations where that isn't enough?

> [...] And from actual real world demand for PK the answer is also 
> no. It's already a problem with very large data sets. [...]

So that's why I asked: what real world demand is there? Is it 
described/documented/reported anywhere public?

> [...] Worse still in many cases its a problem that nobody is 
> actually measuring or doing much about (because mprotect on many 
> gigabytes of data is expensive).

It's not necessarily expensive if the remote TLB shootdown guarantee 
is weakened (i.e. we could have an mprotect() flag that says "I don't 
need remote TLB shootdowns") - and nobody has asked for that yet 
AFAICS.

With 2MB or 1GB pages it would be even cheaper.

Also, the way databases usually protect themselves is by making a 
robust central engine and communicating with (complex) DB users via 
memory sharing and IPC.

> > I think libraries are happy enough to work without bugs - apps 
> > digging around in library data are in a "you keep all the broken 
> > pieces" situation, why would a library want to slow down every 
> > good citizen down with extra protection flipping/unflipping 
> > accesses?
> 
> For debugging, when the library maintained data is sensitive or 
> something you don't want corupted, or because the user puts security 
> first. Protection keys are an awful lot faster than mprotect.

There's no flushing of TLBs involved even locally, a PK 'flip' is just 
a handful of cycles no matter whether protections are narrowed or 
broadened, right?

> [...] You've got no synchronization and shootdowns to do just a CPU 
> register to load to indicate which mask of keys you are happy with. 
> That really changes what it is useful for, because it's cheap. It 
> means you can happily do stuff like
> 
> 	while(data_blocks) {
> 		allow_key_and_source_access();
> 		do_crypto_func();
> 		revoke_key_and_source_access();
> 		do_network_io();  /* Can't accidentally leak keys or
> 					input */
> 	}

That looks useful if it's fast enough. I suspect a similar benefit 
could be gained if we allowed individually randomized anonymous 
mmap()s: the key wouldn't just be part of the heap, but isolated and 
randomized somewhere in a 64-bit (48-bit) address space.

Thanks,

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

Powered by blists - more mailing lists