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;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: [RFC v2 00/27] Kernel Address Space Isolation
From:   Andy Lutomirski <luto@amacapital.net>
In-Reply-To: <3ca70237-bf8e-57d9-bed5-bc2329d17177@oracle.com>
Date:   Fri, 12 Jul 2019 10:45:06 -0600
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Peter Zijlstra <peterz@infradead.org>,
        Dave Hansen <dave.hansen@intel.com>, pbonzini@redhat.com,
        rkrcmar@redhat.com, mingo@redhat.com, bp@alien8.de, hpa@zytor.com,
        dave.hansen@linux.intel.com, luto@kernel.org, kvm@vger.kernel.org,
        x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        konrad.wilk@oracle.com, jan.setjeeilers@oracle.com,
        liran.alon@oracle.com, jwadams@google.com, graf@amazon.de,
        rppt@linux.vnet.ibm.com, Paul Turner <pjt@google.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7FDF08CB-A429-441B-872D-FAE7293858F5@amacapital.net>
References: <1562855138-19507-1-git-send-email-alexandre.chartre@oracle.com> <5cab2a0e-1034-8748-fcbe-a17cf4fa2cd4@intel.com> <alpine.DEB.2.21.1907120911160.11639@nanos.tec.linutronix.de> <61d5851e-a8bf-e25c-e673-b71c8b83042c@oracle.com> <20190712125059.GP3419@hirez.programming.kicks-ass.net> <alpine.DEB.2.21.1907121459180.1788@nanos.tec.linutronix.de> <3ca70237-bf8e-57d9-bed5-bc2329d17177@oracle.com>
To:     Alexandre Chartre <alexandre.chartre@oracle.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Jul 12, 2019, at 10:37 AM, Alexandre Chartre <alexandre.chartre@oracle.=
com> wrote:
>=20
>=20
>=20
>> On 7/12/19 5:16 PM, Thomas Gleixner wrote:
>>> On Fri, 12 Jul 2019, Peter Zijlstra wrote:
>>>> On Fri, Jul 12, 2019 at 01:56:44PM +0200, Alexandre Chartre wrote:
>>>>=20
>>>> I think that's precisely what makes ASI and PTI different and independe=
nt.
>>>> PTI is just about switching between userland and kernel page-tables, wh=
ile
>>>> ASI is about switching page-table inside the kernel. You can have ASI w=
ithout
>>>> having PTI. You can also use ASI for kernel threads so for code that wo=
n't
>>>> be triggered from userland and so which won't involve PTI.
>>>=20
>>> PTI is not mapping         kernel space to avoid             speculation=
 crap (meltdown).
>>> ASI is not mapping part of kernel space to avoid (different) speculation=
 crap (MDS).
>>>=20
>>> See how very similar they are?
>>>=20
>>> Furthermore, to recover SMT for userspace (under MDS) we not only need
>>> core-scheduling but core-scheduling per address space. And ASI was
>>> specifically designed to help mitigate the trainwreck just described.
>>>=20
>>> By explicitly exposing (hopefully harmless) part of the kernel to MDS,
>>> we reduce the part that needs core-scheduling and thus reduce the rate
>>> the SMT siblngs need to sync up/schedule.
>>>=20
>>> But looking at it that way, it makes no sense to retain 3 address
>>> spaces, namely:
>>>=20
>>>   user / kernel exposed / kernel private.
>>>=20
>>> Specifically, it makes no sense to expose part of the kernel through MDS=

>>> but not through Meltdow. Therefore we can merge the user and kernel
>>> exposed address spaces.
>>>=20
>>> And then we've fully replaced PTI.
>>>=20
>>> So no, they're not orthogonal.
>> Right. If we decide to expose more parts of the kernel mappings then that=
's
>> just adding more stuff to the existing user (PTI) map mechanics.
>=20
> If we expose more parts of the kernel mapping by adding them to the existi=
ng
> user (PTI) map, then we only control the mapping of kernel sensitive data b=
ut
> we don't control user mapping (with ASI, we exclude all user mappings).
>=20
> How would you control the mapping of userland sensitive data and exclude t=
hem
> from the user map?

As I see it, if we think part of the kernel is okay to leak to VM guests, th=
en it should think it=E2=80=99s okay to leak to userspace and versa. At the e=
nd of the day, this may just have to come down to an administrator=E2=80=99s=
 choice of how careful the mitigations need to be.

> Would you have the application explicitly identify sensitive
> data (like Andy suggested with a /dev/xpfo device)?

That=E2=80=99s not really the intent of my suggestion. I was suggesting that=
 maybe we don=E2=80=99t need ASI at all if we allow VMs to exclude their mem=
ory from the kernel mapping entirely.  Heck, in a setup like this, we can ma=
ybe even get away with turning PTI off under very, very controlled circumsta=
nces.  I=E2=80=99m not quite sure what to do about the kernel random pools, t=
hough.=