From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mga14.intel.com ([192.55.52.115]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fDuIi-0006Gc-S2 for speck@linutronix.de; Wed, 02 May 2018 18:08:17 +0200 Date: Wed, 2 May 2018 09:08:13 -0700 From: Andi Kleen Subject: [MODERATED] Re: Updated L1TF native OS patch Message-ID: <20180502160813.GT75137@tassilo.jf.intel.com> References: <20180501234247.GA41910@tassilo.jf.intel.com> <20180502000512.GO75137@tassilo.jf.intel.com> <20180502012112.GQ75137@tassilo.jf.intel.com> <20180502121420.GB31258@dhcp22.suse.cz> <20180502150739.GS75137@tassilo.jf.intel.com> <20180502153554.GK26305@dhcp22.suse.cz> MIME-Version: 1.0 In-Reply-To: <20180502153554.GK26305@dhcp22.suse.cz> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: > > There's nothing the hypervisor can do about this. This > > mitigation has to be done in the guest. > > > > > Patch 3 seems reasonable but I do not feel confident enough to give my > > > ack because I simply have no idea whether some obscure HW depends on the > > > zero page. > > > > Can you expand? How should hardware depend on it? > > > > It certainly cannot write to it, and even reading would be dubious because > > the contents are undefined. > > Yeah, reads is what I would be worried about. I do not have any specific > offender in mind but this is really hard to check for. There's no difference for reads. The memory does not go away. It can still read it. The reservation just guarantees it is never used for any user data. BTW I expect the patch to almost certainly be a noop in most cases, because 0 should be already reserved, but I couldn't convince myself that it happens in all cases. I remember at least when I worked on the original x86_64 code there was an explicit reservation, but it seems to have been removed at some point (or at least I couldn't find it anymore) -Andi