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 4DBAEC4CED1 for ; Fri, 4 Oct 2019 14:57:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 133462133F for ; Fri, 4 Oct 2019 14:57:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZV9Uig7I" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 133462133F 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 856018E0009; Fri, 4 Oct 2019 10:57:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 82D588E0003; Fri, 4 Oct 2019 10:57:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 71BA58E0009; Fri, 4 Oct 2019 10:57:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0163.hostedemail.com [216.40.44.163]) by kanga.kvack.org (Postfix) with ESMTP id 502DD8E0003 for ; Fri, 4 Oct 2019 10:57:14 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id E39DF1269 for ; Fri, 4 Oct 2019 14:57:13 +0000 (UTC) X-FDA: 76006405146.24.pie12_4dcdb766085b X-HE-Tag: pie12_4dcdb766085b X-Filterd-Recvd-Size: 3519 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Fri, 4 Oct 2019 14:57:13 +0000 (UTC) Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) (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 345DB222CC for ; Fri, 4 Oct 2019 14:57:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570201032; bh=crFelfh0Sn/O8mB2YPt3Mozpd1WcKFo0ht7BKzHX6bI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ZV9Uig7IsG0spaw0caqrW3Q2fqYoIacHVBgoYU9FOb8oSapqSp1DIJ4eSjY3x7Djd Y6/w8lYmZotuqGOqt2NQV+emn/oW5jSqjOMytuhXYCjGov35flVZxuxnYUaWGgU4f4 1EZ5D/haZRb8VRyR5cSCjjUDAva2X/lFYafJDhAs= Received: by mail-wr1-f45.google.com with SMTP id r3so7625020wrj.6 for ; Fri, 04 Oct 2019 07:57:12 -0700 (PDT) X-Gm-Message-State: APjAAAUltzskG54N0aRC5QwwLjH0IxS72fD3ZGqx9Q0iYD/tCnn347hi MPqOmZtD/K7PDbH9l5iHQhr3BH/ZRnrQWEnL7eRf+w== X-Google-Smtp-Source: APXvYqwknDFkFaJzo6VOtFntrB9U7DIZ2Bs13Lu1v1o7MImeIR75HTQyzSZPi+TJSharOuJdeBuc1fee3GNxv2jxmGM= X-Received: by 2002:a5d:4647:: with SMTP id j7mr12415523wrs.106.1570201030525; Fri, 04 Oct 2019 07:57:10 -0700 (PDT) MIME-Version: 1.0 References: <20191003212400.31130-1-rick.p.edgecombe@intel.com> In-Reply-To: <20191003212400.31130-1-rick.p.edgecombe@intel.com> From: Andy Lutomirski Date: Fri, 4 Oct 2019 07:56:58 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 00/13] XOM for KVM guest userspace To: Rick Edgecombe Cc: kvm list , LKML , X86 ML , Linux-MM , Andrew Lutomirski , Peter Zijlstra , Dave Hansen , Paolo Bonzini , "Christopherson, Sean J" , Kees Cook , Kristen Carlson Accardi , "Dock, Deneen T" 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 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.