Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751259AbbEGTS7 (ORCPT ); Thu, 7 May 2015 15:18:59 -0400 Received: from 251.110.2.81.in-addr.arpa ([81.2.110.251]:44900 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750776AbbEGTS6 (ORCPT ); Thu, 7 May 2015 15:18:58 -0400 Date: Thu, 7 May 2015 20:18:43 +0100 From: One Thousand Gnomes To: Dave Hansen Cc: Ingo Molnar , linux-kernel@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH 00/12] [RFC] x86: Memory Protection Keys Message-ID: <20150507201843.0ccf0938@lxorguk.ukuu.org.uk> In-Reply-To: <554BAA68.6000508@sr71.net> References: <20150507174132.34AF8FAF@viggo.jf.intel.com> <20150507175707.GA22172@gmail.com> <554BAA68.6000508@sr71.net> Organization: Intel Corporation X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1796 Lines: 42 > Data structures like logs or journals that are only written to in very > limited code paths, but that you want to protect from "stray" writes. Anything with lots of data where you want to minimise the risk of stray accesses even if just as a debug aid (consider things like memcached). > > Maybe even a database where a query operation will never need to write > to memory, but an insert would. You could keep the data R/O during the > entire operation except when an insert is actually in progress. It > narrows the window where data might be corrupted. This becomes even > more valuable if a stray write to memory is guaranteed to hit storage... > like with persistent memory. > > Someone mentioned to me that valgrind does lots of mprotect()s and might > benefit from this. You can also use it for certain types of emulator trickery, and I suspect even for things like interpreters and controlling access to "tainted" values. Other obvious uses are making it a shade harder for SSL or ssh type errors to leak things like key data by reducing the damage done by out of bound accesses. > 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. In library land it isn't just stuff like malloc, you can use it as a debug weapon to protect library private data from naughty application code. There are some other debug uses when catching faults - fast ways to do range access breakpoints for example. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/