From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mga17.intel.com ([192.55.52.151]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fBU0q-0001X9-Lu for speck@linutronix.de; Thu, 26 Apr 2018 01:39:49 +0200 Date: Wed, 25 Apr 2018 16:39:45 -0700 From: Andi Kleen Subject: [MODERATED] Re: [PATCH 1/6] Patch 1 Message-ID: <20180425233945.GQ14273@tassilo.jf.intel.com> References: <20180425173619.GJ14273@tassilo.jf.intel.com> <20180425181152.GK14273@tassilo.jf.intel.com> <20180425185140.GL14273@tassilo.jf.intel.com> <20180425211901.GN14273@tassilo.jf.intel.com> <20180425231238.GO14273@tassilo.jf.intel.com> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Wed, Apr 25, 2018 at 04:21:24PM -0700, speck for Linus Torvalds wrote: > > > On Wed, 25 Apr 2018, speck for Andi Kleen wrote: > > > > I haven't see Hocko's patch, but I assume it just inverts the complete > > swap entry except P while it is stored. > > No, it only inverted offset. That's the easiest thing. > > > Two more corner cases: > > > > - How about the case when you have more than MAX_PA/2 physical > > memory? For this case we would need a flag to disable the > > invert (and clear the reporting), otherwise it will be attackable. > > No. In some random theoretical situation that doesn't matter, maybe. > > But it's completely not attackable, because you need to swap out literally > terabytes of memory, and you have no control over what the allocations > will even be. For the >MAX_PA/2 case it would be any swapout, right? Because any offset inversion is still pointing to valid memory then. We could actually not have any check for this in the VM code (because it's vulnerable anyways), but only invert the BUG bit so that sysfs reports vulnerability. That would be localized purely in the initialization code. Would that be ok? > > So forget about it. We're not going to add any complexity over an attack > that is not realistic. That's for the >3.5TB swapfile case? So you don't want the check in swapon, correct? > > > > These are always shared. It's not entirely clear that anybody even uses > > > PROT_NONE on them. We may be able to just disallow PROT_NONE entirely, > > > or we can just zap the mapping instead of trying to "save" it, since > > > there really isn't anythign to save. > > > > Ok. So disallow PROT_NONE until someone complains. > > It's an option. I actually would prefer the "just zap the mapping and > populate it again" model, but the "just disallow" might be simpler and Ok. I will see if that's easily implementable. Otherwise forbid PROT_NONE. > might be acceptable. But it _does_ have the potential of people finding it > a regression. Maybe people play games with PROT_NONE. User space often > does really really odd things. Thanks, -Andi