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 Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5BBF8C433EF for ; Mon, 31 Jan 2022 03:40:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id A9B154B218; Sun, 30 Jan 2022 22:40:34 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id robQ95-SH1Fo; Sun, 30 Jan 2022 22:40:33 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 7AED74B129; Sun, 30 Jan 2022 22:40:33 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id AE6F54B11E for ; Sun, 30 Jan 2022 22:40:32 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyIn8IVIi54I for ; Sun, 30 Jan 2022 22:40:31 -0500 (EST) Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 981B74B11A for ; Sun, 30 Jan 2022 22:40:31 -0500 (EST) Received: by mail-pf1-f176.google.com with SMTP id a19so5836194pfx.4 for ; Sun, 30 Jan 2022 19:40:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=kKkdVczReHlJmEq2mHCzOlF2f9zOsI8Qlek1CLGRtXg=; b=gv2/52IHXhxJ9V+CpUkuE8dj13TXoUzbfqNmRA89Z8RxAggQ29fLbrg/TdohGYCGSN epfA+Wly5u0v1Nx+89fgyFvCuAxqUB1+uAfDYmOdC9BofPSGSqFqKnpQACBXfQlOKKsM +2eRoGjDdz7lRlO+Bp8JWFrK6/khewbv7ZCqyl2edW/X3iTiLFoAruAsFfZ3PcQNyH0Z wr9saZ31sYhvjT2tG2f/gMzb2jo+TJ2r82NuCxKfFVUv0uxjTV8Pjvml3lgYvje/3qjK VWrOQqtFQcpjE+Nei63rhSfgH9jC52UKbOzVjej4FYqNmJEGPiwpu7GUUfoHFjwjD0lQ S11A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=kKkdVczReHlJmEq2mHCzOlF2f9zOsI8Qlek1CLGRtXg=; b=pzdwMBk6xIzsUQWzfq51pBethDko6I409Qzfc03c8FWITp9kzo5kQNW0vmxHFcCU+F f2wG6HDrC5D/bYCZ+jYydBtH6+yuXUEysF7Q4beUS8Iql33SwYw9e10gHsRKywgRBQ18 DP3KGKPf4daJ2tzQeDW/oV9FUSQomkFygMgMXRXsgWYfV7I3dpZnsS7bdqoYRVdHqSH4 cvnAqZ+9uKY8S9t3j9o9+jsrOfxIQ61R3FAzOvJGQBJ2IVYtVzJakt6yMhREEWAElht7 o2+EQrTh+EDDgEghExuPIxOd81GVUSRR2v7KbxsPXOqT5fIdJwXbRWPS9mOgh0CTsF9c jHkA== X-Gm-Message-State: AOAM530zHhKMNH3bHG6IsEGnQ9RwcpuiO+oHUmFfzKW/svwvbN/tdBjV 30BCMV+UypQTN78o2htxxHDeZQ== X-Google-Smtp-Source: ABdhPJw80u0ql8gqDhxSKNzAHP5XbIa8eMWvNhJoZHnaH+q7E1P+ygb864/BAuMsFe+9AhCI1lRiGA== X-Received: by 2002:a05:6a00:1a86:: with SMTP id e6mr18886798pfv.2.1643600430510; Sun, 30 Jan 2022 19:40:30 -0800 (PST) Received: from google.com (150.12.83.34.bc.googleusercontent.com. [34.83.12.150]) by smtp.gmail.com with ESMTPSA id y15sm16663120pfi.87.2022.01.30.19.40.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 30 Jan 2022 19:40:29 -0800 (PST) Date: Sun, 30 Jan 2022 19:40:26 -0800 From: Ricardo Koller To: Reiji Watanabe Subject: Re: [RFC PATCH v4 02/26] KVM: arm64: Save ID registers' sanitized value per guest Message-ID: References: <20220106042708.2869332-1-reijiw@google.com> <20220106042708.2869332-3-reijiw@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: kvm@vger.kernel.org, Marc Zyngier , Peter Shier , Will Deacon , Paolo Bonzini , kvmarm@lists.cs.columbia.edu, Linux ARM X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Fri, Jan 28, 2022 at 09:52:21PM -0800, Reiji Watanabe wrote: > Hi Ricardo, > > > > > > + > > > > > +/* > > > > > + * Set the guest's ID registers that are defined in sys_reg_descs[] > > > > > + * with ID_SANITISED() to the host's sanitized value. > > > > > + */ > > > > > +void set_default_id_regs(struct kvm *kvm) > > > > > +{ > > > > > + int i; > > > > > + u32 id; > > > > > + const struct sys_reg_desc *rd; > > > > > + u64 val; > > > > > + > > > > > + for (i = 0; i < ARRAY_SIZE(sys_reg_descs); i++) { > > > > > + rd = &sys_reg_descs[i]; > > > > > + if (rd->access != access_id_reg) > > > > > + /* Not ID register, or hidden/reserved ID register */ > > > > > + continue; > > > > > + > > > > > + id = reg_to_encoding(rd); > > > > > + if (WARN_ON_ONCE(!is_id_reg(id))) > > > > > + /* Shouldn't happen */ > > > > > + continue; > > > > > + > > > > > + val = read_sanitised_ftr_reg(id); > > > > > > > > I'm a bit confused. Shouldn't the default+sanitized values already use > > > > arm64_ftr_bits_kvm (instead of arm64_ftr_regs)? > > > > > > I'm not sure if I understand your question. > > > arm64_ftr_bits_kvm is used for feature support checkings when > > > userspace tries to modify a value of ID registers. > > > With this patch, KVM just saves the sanitized values in the kvm's > > > buffer, but userspace is still not allowed to modify values of ID > > > registers yet. > > > I hope it answers your question. > > > > Based on the previous commit I was assuming that some registers, like > > id_aa64dfr0, > > would default to the overwritten values as the sanitized values. More > > specifically: if > > userspace doesn't modify any ID reg, shouldn't the defaults have the > > KVM overwritten > > values (arm64_ftr_bits_kvm)? > > arm64_ftr_bits_kvm doesn't have arm64_ftr_reg but arm64_ftr_bits, > and arm64_ftr_bits_kvm doesn't have the sanitized values. > > Thanks, Hey Reiji, Sorry, I wasn't very clear. This is what I meant. If I set DEBUGVER to 0x5 (w/ FTR_EXACT) using this patch on top of the series: static struct arm64_ftr_bits ftr_id_aa64dfr0_kvm[MAX_FTR_BITS_LEN] = { S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64DFR0_PMUVER_SHIFT, 4, 0), - ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_DEBUGVER_SHIFT, 4, 0x6), + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_DEBUGVER_SHIFT, 4, 0x5), it means that userspace would not be able to set DEBUGVER to anything but 0x5. But I'm not sure what it should mean for the default KVM value of DEBUGVER, specifically the value calculated in set_default_id_regs(). As it is, KVM is still setting the guest-visible value to 0x6, and my "desire" to only allow booting VMs with DEBUGVER=0x5 is being ignored: I booted a VM and the DEBUGVER value from inside is still 0x6. I was expecting it to not boot, or to show a warning. I think this has some implications for migrations. It would not be possible to migrate the example VM on the patched kernel from above: you can boot a VM with DEBUGVER=0x5 but you can't migrate it. Thanks, Ricardo _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8957FC433F5 for ; Mon, 31 Jan 2022 03:42:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=if0o3AYgLY459lde0yQ8CMCd1no9o0qO5A75I4yZVUo=; b=zLAgIiV+Hheaai 83n+LOTWgn5+8Is/r/M/AgV/PuGj0AhVblm8TQWHwZgdgFRgMzlavbEpAjZH0T/fNN5JXcbhtp6Hi PVGK0kwMSPjyXZNtoHXHwm0HT/42QgAvBk2iJ+TwunUvpYIJKPMlTXk9TqrQDy6WITOFYf1/4KQC4 OQNzJPJidqdRcRmB82cLRMH0+3K1WPEoxZBqHbfAPpHRTR6SbSy730JaEyWU6sHFJM838PkuhPRFa 9ONuxihgf79Mba2PioEYQWvgMvbTgzQMwe4y9UoVy/BmFchfTdv3SvHw+qd32LA3/uIwyld6Dgx5B hc4w1KzJcXmkHM9XhBxA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nENYV-007wWI-Ki; Mon, 31 Jan 2022 03:40:39 +0000 Received: from mail-pg1-x536.google.com ([2607:f8b0:4864:20::536]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nENYR-007wVc-OS for linux-arm-kernel@lists.infradead.org; Mon, 31 Jan 2022 03:40:37 +0000 Received: by mail-pg1-x536.google.com with SMTP id s16so10977767pgs.13 for ; Sun, 30 Jan 2022 19:40:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=kKkdVczReHlJmEq2mHCzOlF2f9zOsI8Qlek1CLGRtXg=; b=gv2/52IHXhxJ9V+CpUkuE8dj13TXoUzbfqNmRA89Z8RxAggQ29fLbrg/TdohGYCGSN epfA+Wly5u0v1Nx+89fgyFvCuAxqUB1+uAfDYmOdC9BofPSGSqFqKnpQACBXfQlOKKsM +2eRoGjDdz7lRlO+Bp8JWFrK6/khewbv7ZCqyl2edW/X3iTiLFoAruAsFfZ3PcQNyH0Z wr9saZ31sYhvjT2tG2f/gMzb2jo+TJ2r82NuCxKfFVUv0uxjTV8Pjvml3lgYvje/3qjK VWrOQqtFQcpjE+Nei63rhSfgH9jC52UKbOzVjej4FYqNmJEGPiwpu7GUUfoHFjwjD0lQ S11A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=kKkdVczReHlJmEq2mHCzOlF2f9zOsI8Qlek1CLGRtXg=; b=Wp4kZBxSoL0PGaZD4smpU8Id+iRzQmVKpOnujVGF4wPxrf7k+BcfSxOCE3Ehh9Ir54 msJ1gqduy88enUkll114c425/FwPI9Pky6DskFkmwfmHPUZe+yg9uZ4yAgOX0XrWpkBv 2KZWK/mPOHK0ZNm9EHTmeTfMd0CKvmEk1XGvzADDr9kyHc7myuFJOufVyrI0X7PIZBvC 8jt8hGcKqQBGsxvrfvF1t5nyz8zPsRC3v21xeCt/38T8mi7uu6W7fTcAJi6Ju9REHc6K hmzVa/pwqLN1mjBXYlFQOf9IvZ39eYtQv42Nnd2ijNZQMTBbXkKmjlI+f/dlClh11W2H BwIg== X-Gm-Message-State: AOAM531HZiqLvUGz5asvF6LuqvyaDUPSaViDq0jHRNlulmXnyGrjilN8 ReakniOR9ww2Yem1W2vLBRppmg== X-Google-Smtp-Source: ABdhPJw80u0ql8gqDhxSKNzAHP5XbIa8eMWvNhJoZHnaH+q7E1P+ygb864/BAuMsFe+9AhCI1lRiGA== X-Received: by 2002:a05:6a00:1a86:: with SMTP id e6mr18886798pfv.2.1643600430510; Sun, 30 Jan 2022 19:40:30 -0800 (PST) Received: from google.com (150.12.83.34.bc.googleusercontent.com. [34.83.12.150]) by smtp.gmail.com with ESMTPSA id y15sm16663120pfi.87.2022.01.30.19.40.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 30 Jan 2022 19:40:29 -0800 (PST) Date: Sun, 30 Jan 2022 19:40:26 -0800 From: Ricardo Koller To: Reiji Watanabe Cc: Marc Zyngier , kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Linux ARM , James Morse , Alexandru Elisei , Suzuki K Poulose , Paolo Bonzini , Will Deacon , Andrew Jones , Peng Liang , Peter Shier , Oliver Upton , Jing Zhang , Raghavendra Rao Anata Subject: Re: [RFC PATCH v4 02/26] KVM: arm64: Save ID registers' sanitized value per guest Message-ID: References: <20220106042708.2869332-1-reijiw@google.com> <20220106042708.2869332-3-reijiw@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220130_194035_856220_19D6A56A X-CRM114-Status: GOOD ( 32.61 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jan 28, 2022 at 09:52:21PM -0800, Reiji Watanabe wrote: > Hi Ricardo, > > > > > > + > > > > > +/* > > > > > + * Set the guest's ID registers that are defined in sys_reg_descs[] > > > > > + * with ID_SANITISED() to the host's sanitized value. > > > > > + */ > > > > > +void set_default_id_regs(struct kvm *kvm) > > > > > +{ > > > > > + int i; > > > > > + u32 id; > > > > > + const struct sys_reg_desc *rd; > > > > > + u64 val; > > > > > + > > > > > + for (i = 0; i < ARRAY_SIZE(sys_reg_descs); i++) { > > > > > + rd = &sys_reg_descs[i]; > > > > > + if (rd->access != access_id_reg) > > > > > + /* Not ID register, or hidden/reserved ID register */ > > > > > + continue; > > > > > + > > > > > + id = reg_to_encoding(rd); > > > > > + if (WARN_ON_ONCE(!is_id_reg(id))) > > > > > + /* Shouldn't happen */ > > > > > + continue; > > > > > + > > > > > + val = read_sanitised_ftr_reg(id); > > > > > > > > I'm a bit confused. Shouldn't the default+sanitized values already use > > > > arm64_ftr_bits_kvm (instead of arm64_ftr_regs)? > > > > > > I'm not sure if I understand your question. > > > arm64_ftr_bits_kvm is used for feature support checkings when > > > userspace tries to modify a value of ID registers. > > > With this patch, KVM just saves the sanitized values in the kvm's > > > buffer, but userspace is still not allowed to modify values of ID > > > registers yet. > > > I hope it answers your question. > > > > Based on the previous commit I was assuming that some registers, like > > id_aa64dfr0, > > would default to the overwritten values as the sanitized values. More > > specifically: if > > userspace doesn't modify any ID reg, shouldn't the defaults have the > > KVM overwritten > > values (arm64_ftr_bits_kvm)? > > arm64_ftr_bits_kvm doesn't have arm64_ftr_reg but arm64_ftr_bits, > and arm64_ftr_bits_kvm doesn't have the sanitized values. > > Thanks, Hey Reiji, Sorry, I wasn't very clear. This is what I meant. If I set DEBUGVER to 0x5 (w/ FTR_EXACT) using this patch on top of the series: static struct arm64_ftr_bits ftr_id_aa64dfr0_kvm[MAX_FTR_BITS_LEN] = { S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64DFR0_PMUVER_SHIFT, 4, 0), - ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_DEBUGVER_SHIFT, 4, 0x6), + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_DEBUGVER_SHIFT, 4, 0x5), it means that userspace would not be able to set DEBUGVER to anything but 0x5. But I'm not sure what it should mean for the default KVM value of DEBUGVER, specifically the value calculated in set_default_id_regs(). As it is, KVM is still setting the guest-visible value to 0x6, and my "desire" to only allow booting VMs with DEBUGVER=0x5 is being ignored: I booted a VM and the DEBUGVER value from inside is still 0x6. I was expecting it to not boot, or to show a warning. I think this has some implications for migrations. It would not be possible to migrate the example VM on the patched kernel from above: you can boot a VM with DEBUGVER=0x5 but you can't migrate it. Thanks, Ricardo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6F9EEC433F5 for ; Mon, 31 Jan 2022 03:40:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357504AbiAaDke (ORCPT ); Sun, 30 Jan 2022 22:40:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58248 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229885AbiAaDkb (ORCPT ); Sun, 30 Jan 2022 22:40:31 -0500 Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4B7FCC061714 for ; Sun, 30 Jan 2022 19:40:31 -0800 (PST) Received: by mail-pg1-x531.google.com with SMTP id t32so11060755pgm.7 for ; Sun, 30 Jan 2022 19:40:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=kKkdVczReHlJmEq2mHCzOlF2f9zOsI8Qlek1CLGRtXg=; b=gv2/52IHXhxJ9V+CpUkuE8dj13TXoUzbfqNmRA89Z8RxAggQ29fLbrg/TdohGYCGSN epfA+Wly5u0v1Nx+89fgyFvCuAxqUB1+uAfDYmOdC9BofPSGSqFqKnpQACBXfQlOKKsM +2eRoGjDdz7lRlO+Bp8JWFrK6/khewbv7ZCqyl2edW/X3iTiLFoAruAsFfZ3PcQNyH0Z wr9saZ31sYhvjT2tG2f/gMzb2jo+TJ2r82NuCxKfFVUv0uxjTV8Pjvml3lgYvje/3qjK VWrOQqtFQcpjE+Nei63rhSfgH9jC52UKbOzVjej4FYqNmJEGPiwpu7GUUfoHFjwjD0lQ S11A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=kKkdVczReHlJmEq2mHCzOlF2f9zOsI8Qlek1CLGRtXg=; b=Wzrw0m5qPkgmr7Q0Xz7wfyZVy/Sl2CATPpzf6Xg+vqJG2/VY/DJ8BSbQEsqGQxa50J QdpEqb91tBiyd+aLHOX1WwCR8YYYFWKPFxmzPePdyAfppjjCfSe+1frBmRQxc8el03xH RlWoe4RO8/8lOgMHwsgHHJ90+LzOVZMCH0fvuhhDYnbPuZ7/1gvZDnoXcPzaBAJo4sBN wVQoF6npZvNkH4VMR4HnPOf5HlnIXOW9MBwZr5t7/GdM/P/X+9r+mGtRx5EGPdnwgZuB MngWl3r6UuAyLa1fvgbpjwDs09Z/pQG8cBV3dlveyqhG/QpJnAdYuuNo7xr6gt/UL/6a RzPw== X-Gm-Message-State: AOAM533wRCKMME5WfPtu2TVIlNk9pGKFNW3bjrNoSQ1uhCwRDpT/XwWD 1erpfL+grGpVCI2/Tiw0eu4EQA== X-Google-Smtp-Source: ABdhPJw80u0ql8gqDhxSKNzAHP5XbIa8eMWvNhJoZHnaH+q7E1P+ygb864/BAuMsFe+9AhCI1lRiGA== X-Received: by 2002:a05:6a00:1a86:: with SMTP id e6mr18886798pfv.2.1643600430510; Sun, 30 Jan 2022 19:40:30 -0800 (PST) Received: from google.com (150.12.83.34.bc.googleusercontent.com. [34.83.12.150]) by smtp.gmail.com with ESMTPSA id y15sm16663120pfi.87.2022.01.30.19.40.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 30 Jan 2022 19:40:29 -0800 (PST) Date: Sun, 30 Jan 2022 19:40:26 -0800 From: Ricardo Koller To: Reiji Watanabe Cc: Marc Zyngier , kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Linux ARM , James Morse , Alexandru Elisei , Suzuki K Poulose , Paolo Bonzini , Will Deacon , Andrew Jones , Peng Liang , Peter Shier , Oliver Upton , Jing Zhang , Raghavendra Rao Anata Subject: Re: [RFC PATCH v4 02/26] KVM: arm64: Save ID registers' sanitized value per guest Message-ID: References: <20220106042708.2869332-1-reijiw@google.com> <20220106042708.2869332-3-reijiw@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Fri, Jan 28, 2022 at 09:52:21PM -0800, Reiji Watanabe wrote: > Hi Ricardo, > > > > > > + > > > > > +/* > > > > > + * Set the guest's ID registers that are defined in sys_reg_descs[] > > > > > + * with ID_SANITISED() to the host's sanitized value. > > > > > + */ > > > > > +void set_default_id_regs(struct kvm *kvm) > > > > > +{ > > > > > + int i; > > > > > + u32 id; > > > > > + const struct sys_reg_desc *rd; > > > > > + u64 val; > > > > > + > > > > > + for (i = 0; i < ARRAY_SIZE(sys_reg_descs); i++) { > > > > > + rd = &sys_reg_descs[i]; > > > > > + if (rd->access != access_id_reg) > > > > > + /* Not ID register, or hidden/reserved ID register */ > > > > > + continue; > > > > > + > > > > > + id = reg_to_encoding(rd); > > > > > + if (WARN_ON_ONCE(!is_id_reg(id))) > > > > > + /* Shouldn't happen */ > > > > > + continue; > > > > > + > > > > > + val = read_sanitised_ftr_reg(id); > > > > > > > > I'm a bit confused. Shouldn't the default+sanitized values already use > > > > arm64_ftr_bits_kvm (instead of arm64_ftr_regs)? > > > > > > I'm not sure if I understand your question. > > > arm64_ftr_bits_kvm is used for feature support checkings when > > > userspace tries to modify a value of ID registers. > > > With this patch, KVM just saves the sanitized values in the kvm's > > > buffer, but userspace is still not allowed to modify values of ID > > > registers yet. > > > I hope it answers your question. > > > > Based on the previous commit I was assuming that some registers, like > > id_aa64dfr0, > > would default to the overwritten values as the sanitized values. More > > specifically: if > > userspace doesn't modify any ID reg, shouldn't the defaults have the > > KVM overwritten > > values (arm64_ftr_bits_kvm)? > > arm64_ftr_bits_kvm doesn't have arm64_ftr_reg but arm64_ftr_bits, > and arm64_ftr_bits_kvm doesn't have the sanitized values. > > Thanks, Hey Reiji, Sorry, I wasn't very clear. This is what I meant. If I set DEBUGVER to 0x5 (w/ FTR_EXACT) using this patch on top of the series: static struct arm64_ftr_bits ftr_id_aa64dfr0_kvm[MAX_FTR_BITS_LEN] = { S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64DFR0_PMUVER_SHIFT, 4, 0), - ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_DEBUGVER_SHIFT, 4, 0x6), + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_DEBUGVER_SHIFT, 4, 0x5), it means that userspace would not be able to set DEBUGVER to anything but 0x5. But I'm not sure what it should mean for the default KVM value of DEBUGVER, specifically the value calculated in set_default_id_regs(). As it is, KVM is still setting the guest-visible value to 0x6, and my "desire" to only allow booting VMs with DEBUGVER=0x5 is being ignored: I booted a VM and the DEBUGVER value from inside is still 0x6. I was expecting it to not boot, or to show a warning. I think this has some implications for migrations. It would not be possible to migrate the example VM on the patched kernel from above: you can boot a VM with DEBUGVER=0x5 but you can't migrate it. Thanks, Ricardo