From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 405AEC47404 for ; Sat, 5 Oct 2019 01:33:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 05647222C0 for ; Sat, 5 Oct 2019 01:33:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="iYBdrZ8t" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 05647222C0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6A2A36B0003; Fri, 4 Oct 2019 21:33:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6533F6B0005; Fri, 4 Oct 2019 21:33:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 541296B0006; Fri, 4 Oct 2019 21:33:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0026.hostedemail.com [216.40.44.26]) by kanga.kvack.org (Postfix) with ESMTP id 2BCDE6B0003 for ; Fri, 4 Oct 2019 21:33:23 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id CB77D180AD7C3 for ; Sat, 5 Oct 2019 01:33:22 +0000 (UTC) X-FDA: 76008008244.30.stamp48_1d70da4a62121 X-HE-Tag: stamp48_1d70da4a62121 X-Filterd-Recvd-Size: 5021 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Sat, 5 Oct 2019 01:33:22 +0000 (UTC) Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BFA86222C9 for ; Sat, 5 Oct 2019 01:33:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570239201; bh=n4aRImq4Lrub/+kEZQaJLf+YSE+YDB6MnfXrB9ePfvk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=iYBdrZ8t8ue68AoQly/xyqB28LRJAXGjFkcdPTNRRNiAcnIRC3V/tmkDJKzJxuCZy V9a4KhIY7/9CzFBCq4b1AH78jgig2473H1G194ofqYcCKkqIYb9wwPok1Yby1quKl8 Q3WBdKX9YRyaVXFM/wKMwQ6t0MJ6DXsN9NEEv0Iw= Received: by mail-wr1-f46.google.com with SMTP id r3so9150731wrj.6 for ; Fri, 04 Oct 2019 18:33:20 -0700 (PDT) X-Gm-Message-State: APjAAAUNtickzdPmZvIz/9MtFR00FUSJ2XHTq4RQJGPNSXnBjdm1ecXa 4wIj4ZsDV7TcG+Oj0o6nhFtY6AZaMD/XtD7NcaebDw== X-Google-Smtp-Source: APXvYqyjhheOmqMgJaDuXYPsAFybWX1peME6BJhrzOo/E8Me2RUlybh6fcihReGSWFe7PARuThdGh065aUJ9r5hsRnc= X-Received: by 2002:a5d:4647:: with SMTP id j7mr14200264wrs.106.1570239199136; Fri, 04 Oct 2019 18:33:19 -0700 (PDT) MIME-Version: 1.0 References: <20191003212400.31130-1-rick.p.edgecombe@intel.com> In-Reply-To: From: Andy Lutomirski Date: Fri, 4 Oct 2019 18:33:07 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 00/13] XOM for KVM guest userspace To: "Edgecombe, Rick P" Cc: "luto@kernel.org" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "peterz@infradead.org" , "keescook@chromium.org" , "Dock, Deneen T" , "Christopherson, Sean J" , "linux-mm@kvack.org" , "x86@kernel.org" , "kristen@linux.intel.com" , "pbonzini@redhat.com" , "Hansen, Dave" Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Oct 4, 2019 at 1:10 PM Edgecombe, Rick P wrote: > > On Fri, 2019-10-04 at 07:56 -0700, Andy Lutomirski wrote: > > On Thu, Oct 3, 2019 at 2:38 PM Rick Edgecombe > > wrote: > > > > > > This patchset enables the ability for KVM guests to create execute-only (XO) > > > memory by utilizing EPT based XO permissions. XO memory is currently > > > supported > > > on Intel hardware natively for CPU's with PKU, but this enables it on older > > > platforms, and can support XO for kernel memory as well. > > > > The patchset seems to sometimes call this feature "XO" and sometimes > > call it "NR". To me, XO implies no-read and no-write, whereas NR > > implies just no-read. Can you please clarify *exactly* what the new > > bit does and be consistent? > > > > I suggest that you make it NR, which allows for PROT_EXEC and > > PROT_EXEC|PROT_WRITE and plain PROT_WRITE. WX is of dubious value, > > but I can imagine plain W being genuinely useful for logging and for > > JITs that could maintain a W and a separate X mapping of some code. > > In other words, with an NR bit, all 8 logical access modes are > > possible. Also, keeping the paging bits more orthogonal seems nice -- > > we already have a bit that controls write access. > > Sorry, yes the behavior of this bit needs to be documented a lot better. I will > definitely do this for the next version. > > To clarify, since the EPT permissions in the XO/NR range are executable, and not > readable or writeable the new bit really means XO, but only when NX is 0 since > the guest page tables are being checked as well. When NR=1, W=1, and NX=0, the > memory is still XO. > > NR was picked over XO because as you say. The idea is that it can be defined > that in the case of KVM XO, NR and writable is not a valid combination, like > writeable but not readable is defined as not valid for the EPT. > Ugh, I see, this is an "EPT Misconfiguration". Oh, well. I guess just keep things as they are and document things better, please. Don't try to emulate. I don't suppose Intel could be convinced to get rid of that in a future CPU and allow write-only memory? BTW, is your patch checking for support in IA32_VMX_EPT_VPID_CAP? I didn't notice it, but I didn't look that hard.