Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp375157imm; Fri, 31 Aug 2018 02:52:53 -0700 (PDT) X-Google-Smtp-Source: ANB0Vda/kBOji/fowfGsuQAvLrhypu3wOrSxF1Ooh3opMku7I8cUD/yvk6jCiqe8tIRN59mq54wi X-Received: by 2002:a62:b604:: with SMTP id j4-v6mr15046360pff.199.1535709173073; Fri, 31 Aug 2018 02:52:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535709173; cv=none; d=google.com; s=arc-20160816; b=tbRkcuBeVZj5LxWJqNzkEFaCrmo21odjtZfqxUi6s6o0FbD0GzOBh/MhoLZtq3U9EY GsmQma5Ci6NQGYZoXFlDQ2RUA5lvOde0aY30jsAN1EPQwBUHzhOg/NXewyl/OYQqxJD8 EzQnB1IBkDZnBMTZ/kavtRizBVejwGU1k0Kq3n916bf77ytkoQRts4/+0mxASC4NISyz c5BxGilY5K7Es4cHJrGmGmveYH8I+fZa5Dv7oaTlA6A7wgYSpjeXc4Ib9WAvnN2sSFlZ J4ROy42cV3Qo5ui4aC/cyCM6QrnuU5+mHyNSJikrcfNMLUGdGXqwOmLjWtHw8pPg0hFs +ljA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :dkim-signature:arc-authentication-results; bh=YIKoXrJoo9BdMlFhl9DYYtjKrjbFVhtj/nQr/lwurmA=; b=MQyrRisDxtQB/PBN3zlMeA7kBgh72dKe4yv9OsTaD3ZlKUVFpgcw+k2FKj4a5v9rLb US9T1ntJd9LA4uFf6VbKgrfCR9KkizH692WMMDUCvQoGVssnPHZEg6WoKPbkyZ+HOFrk dANCdU3Y1sX8HU8+K+iWcgZjqKa6Ogh7YRRu8e2oTj7ivGpk1ibYgzxv3RHiuyeg9Jza /f9d5oeaNL1YFUEJnQOLNcFWsgiPYhkYAFXhQNnShU/6a42ea+F/K3XrsKrDR85sELLA 8blbNs22jfFRo/8vGq5beGdkSzCnRVy3dJDWvNmxJEQcS/bKe6qB17H1pH/2hy0q+xTh +ORg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=qzDiXdcW; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hansenpartnership.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x3-v6si9202127pgo.542.2018.08.31.02.52.38; Fri, 31 Aug 2018 02:52:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=qzDiXdcW; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hansenpartnership.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728014AbeHaMuT (ORCPT + 99 others); Fri, 31 Aug 2018 08:50:19 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:39650 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727263AbeHaMuT (ORCPT ); Fri, 31 Aug 2018 08:50:19 -0400 Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 081D18EE1F4; Fri, 31 Aug 2018 01:43:56 -0700 (PDT) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7aNlxD4mMhQ; Fri, 31 Aug 2018 01:43:55 -0700 (PDT) Received: from jarvis.home (unknown [81.145.101.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id 46EA68EE101; Fri, 31 Aug 2018 01:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=20151216; t=1535705035; bh=Ajnnt3X7ChJnYfHHLUrrPQ7QHlFZHmrVsnci/KqWD1o=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=qzDiXdcWv3F5lB0oysbVVZ7p/jszVT/lz1vdAstkmAPMomAU39baWqnLlsXY+RjPf ijC50n9UUSYGZwoABC1s2CPb95tF/9frNRaUuPeF6AHO64urgajkNx50eW3LVOclbd XUsarWLZ7XCra1TOKmVdw0DvtTS4m7xcamYiHDI4= Message-ID: <1535705027.3085.5.camel@HansenPartnership.com> Subject: Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU) From: James Bottomley To: "Woodhouse, David" , "torvalds@linux-foundation.org" , "konrad.wilk@oracle.com" Cc: "juerg.haefliger@hpe.com" , "deepa.srinivasan@oracle.com" , "jmattson@google.com" , "andrew.cooper3@citrix.com" , "linux-kernel@vger.kernel.org" , "boris.ostrovsky@oracle.com" , "linux-mm@kvack.org" , "tglx@linutronix.de" , "joao.m.martins@oracle.com" , "pradeep.vincent@oracle.com" , "ak@linux.intel.com" , "khalid.aziz@oracle.com" , "kanth.ghatraju@oracle.com" , "liran.alon@oracle.com" , "keescook@google.com" , "jsteckli@os.inf.tu-dresden.de" , "kernel-hardening@lists.openwall.com" , "chris.hyser@oracle.com" , "tyhicks@canonical.com" , "john.haxby@oracle.com" , "jcm@redhat.com" Date: Fri, 31 Aug 2018 09:43:47 +0100 In-Reply-To: <1534801939.10027.24.camel@amazon.co.uk> References: <20180820212556.GC2230@char.us.oracle.com> <1534801939.10027.24.camel@amazon.co.uk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2018-08-20 at 21:52 +0000, Woodhouse, David wrote: > On Mon, 2018-08-20 at 14:48 -0700, Linus Torvalds wrote: > > > > Of course, after the long (and entirely unrelated) discussion about > > the TLB flushing bug we had, I'm starting to worry about my own > > competence, and maybe I'm missing something really fundamental, and > > the XPFO patches do something else than what I think they do, or my > > "hey, let's use our Meltdown code" idea has some fundamental > > weakness > > that I'm missing. > > The interesting part is taking the user (and other) pages out of the > kernel's 1:1 physmap. > > It's the *kernel* we don't want being able to access those pages, > because of the multitude of unfixable cache load gadgets. A long time ago, I gave a talk about precisely this at OLS (2005 I think). On PA-RISC we have a problem with inequivalent aliasing in the page cache (same physical page with two different virtual addresses modulo 4MB) which causes a machine check if it occurs. Architecturally, PA can move into the cache any page for which it has a mapping and the kernel offset map of every page causes an inequivalency if the same page is in use in user space. Of course, practically the caching machinery is too busy moving in and out pages we reference to have an interest in speculating on other pages it has a mapping for, so it almost never (the almost being a set of machine checks we see very occasionally in the latest and most aggressively cached and speculating CPUs). If this were implemented, we'd be interested in using it. James