Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp1184461rwr; Fri, 5 May 2023 10:12:50 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6DXqyBh/5d9TubOnj5HenQPVJvS3YR0YMJCIuSHQ7nCwBY66Qu2AoEjkoWZ1ct5jRdaqXz X-Received: by 2002:a17:903:1103:b0:1ab:d89:5ef6 with SMTP id n3-20020a170903110300b001ab0d895ef6mr2276682plh.68.1683306770011; Fri, 05 May 2023 10:12:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683306769; cv=none; d=google.com; s=arc-20160816; b=iHZjXbM+Do0vKerFTrjFJSgMRFwPBcpMbqaPYLj5x50J+lLPKYN2DsfmSCdpeFt0Gs 8fXlT/xGYrcUx566eeua4br9D3XjSv3Pv660k+bwiJmbyxajmkIaRACiJpQbW2cKX2/T 0P4kMJUE2/p1BG68q2e1TkPvItldNvD05WBjm0FHpzucUsb+TFTo6HZVSQWy1a0oJa4U DRerpTHOw5QSpQNQHP7pmAPeNkk7CAAGV3OYDf79ow0A62BKBy2jhLVY2I7msijLxiR2 hrzOVBlj4yhcK9CK6KOh8jDC6QJvNIKrcW7qOT7ZGW5IYg+cEIQIKNmQYx83mYOJveZ0 E80Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=jYQYsb4lzLVu4B46KdH1j3GBO5z0z/A77iiwpzrxUQI=; b=akxyOL3mCAIwe6TGEKEVBO6xGds/k2Td29OE93Cvdw4B+NLK/wyKGM/yyUtmF9KiY1 dDNt6yZ+RB7eHyzQC8eKQu/lCHOq0nX00o1qWpWau5F4nHFBuejYI6B2ut+qQliw6Zu8 jFtgLO9+QDbaHqVCvECDv9ROkgRGRLTkQwBw/zE7U/LcDps5rn0XW/4nivMKRmy75zu3 MpWs4qIPJwrCchbLQaNJgsvd6xBiDeepaPzGTawAjjzvPH/Z/bB487ceCpRYb1Zcw4ef gRrMVK6BKsldXcjld7b7Sc63HIiAEWkSpNlzdqPLg7ept3BFQHZvIOy7GhJDn2LZfDp7 DHEA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@digikod.net header.s=20191114 header.b=0n9dK6yo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w11-20020a170902d70b00b001a65688c863si1966537ply.56.2023.05.05.10.12.36; Fri, 05 May 2023 10:12:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@digikod.net header.s=20191114 header.b=0n9dK6yo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231627AbjEERBd (ORCPT + 99 others); Fri, 5 May 2023 13:01:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46238 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231611AbjEERBa (ORCPT ); Fri, 5 May 2023 13:01:30 -0400 Received: from smtp-42ae.mail.infomaniak.ch (smtp-42ae.mail.infomaniak.ch [IPv6:2001:1600:4:17::42ae]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5E8E630EE for ; Fri, 5 May 2023 10:01:29 -0700 (PDT) Received: from smtp-2-0001.mail.infomaniak.ch (unknown [10.5.36.108]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4QCcQt2Hl7zMqBQp; Fri, 5 May 2023 19:01:26 +0200 (CEST) Received: from unknown by smtp-2-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4QCcQl2DxJzMpxhN; Fri, 5 May 2023 19:01:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digikod.net; s=20191114; t=1683306086; bh=Gz496lWCqtEQGiFhDAnNdISGi/Ti3+4r45rZfW9pMhA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=0n9dK6yocwQrPoCyZhLiYaFRP+Rrc+AesC8U5DRpIAduml7GS9dfUNu27anU/Nq9H X7nX6pZrCIdpSbikNeBpaLS6XS4cxGwP59sL8dmULJe3HbrVsb+7OJzRnuN4Tp0SIU jtv1NK7dS4Wb0Fq0T7+YdNL/W/Ml/YkRAsZVmseM= Message-ID: <39125b11-659f-35f4-ac7a-a3ba31365950@digikod.net> Date: Fri, 5 May 2023 19:01:18 +0200 MIME-Version: 1.0 User-Agent: Subject: Re: [PATCH v1 4/9] KVM: x86: Add new hypercall to set EPT permissions Content-Language: en-US To: Sean Christopherson Cc: Borislav Petkov , Dave Hansen , "H . Peter Anvin" , Ingo Molnar , Kees Cook , Paolo Bonzini , Thomas Gleixner , Vitaly Kuznetsov , Wanpeng Li , Alexander Graf , Forrest Yuan Yu , James Morris , John Andersen , Liran Alon , "Madhavan T . Venkataraman" , Marian Rotariu , =?UTF-8?Q?Mihai_Don=c8=9bu?= , =?UTF-8?B?TmljdciZb3IgQ8OuyJt1?= , Rick Edgecombe , Thara Gopinath , Will Deacon , Zahra Tarkhani , =?UTF-8?Q?=c8=98tefan_=c8=98icleru?= , dev@lists.cloudhypervisor.org, kvm@vger.kernel.org, linux-hardening@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, x86@kernel.org, xen-devel@lists.xenproject.org References: <20230505152046.6575-1-mic@digikod.net> <20230505152046.6575-5-mic@digikod.net> From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Infomaniak-Routing: alpha X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/05/2023 18:44, Sean Christopherson wrote: > On Fri, May 05, 2023, Micka�l Sala�n wrote: >> Add a new KVM_HC_LOCK_MEM_PAGE_RANGES hypercall that enables a guest to >> set EPT permissions on a set of page ranges. > > IMO, manipulation of protections, both for memory (this patch) and CPU state > (control registers in the next patch) should come from userspace. I have no > objection to KVM providing plumbing if necessary, but I think userspace needs to > to have full control over the actual state. By user space, do you mean the host user space or the guest user space? About the guest user space, I see several issues to delegate this kind of control: - These are restrictions only relevant to the kernel. - The threat model is to protect against user space as early as possible. - It would be more complex for no obvious gain. This patch series is an extension of the kernel self-protections mechanisms, and they are not configured by user space. > > One of the things that caused Intel's control register pinning series to stall > out was how to handle edge cases like kexec() and reboot. Deferring to userspace > means the kernel doesn't need to define policy, e.g. when to unprotect memory, > and avoids questions like "should userspace be able to overwrite pinned control > registers". The idea is to authenticate every changes. For kexec, the VMM (or something else) would have to authenticate the new kernel. Do you have something else in mind that could legitimately require such memory or CR changes? > > And like the confidential VM use case, keeping userspace in the loop is a big > beneifit, e.g. the guest can't circumvent protections by coercing userspace into > writing to protected memory . I don't understand this part. Are you talking about the host user space? How the guest could circumvent protections?