Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp1148646pxb; Fri, 21 Jan 2022 10:53:59 -0800 (PST) X-Google-Smtp-Source: ABdhPJymftGBQDuoroINHAeBTko+9S/J9TMGDageBOLC5+A79IxYt0MB0UF5QbX/fWPwaizNXIFq X-Received: by 2002:a17:90a:4305:: with SMTP id q5mr2081652pjg.222.1642791239332; Fri, 21 Jan 2022 10:53:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642791239; cv=none; d=google.com; s=arc-20160816; b=VP2gZLkBPFOCdl18PUwDJMAgOjR+qss5Tgjil5WNuO40FgG/qdkC78FNzUDcbOeUTB phZPEXoaasSXwYcQoaYHFRmuFqd3YM3ywayg8qq7aRAe0nTJeNyDn06byAGLxuFVT19m 4RmP8nnUqI60nRCpJ+TwEUV65lVq6MPQbdZNGRtef/cVEbwpPO2w6s+XTAEzmGLskmLf d7j6q/h9hhVC6a1W6QEJHiXaiDzPCWBoibhACNcmDBmXPxX5XcI/yfaFeRyzQXXqmnL8 T9OZUSgmq2qiYflmdtD50NZkCuGUwtFEgXe4M9BYlzPXc/2Kv5vOt8hgfULLUgvrOqz8 Y19A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=qbiJb2UVtirrAHsd/tlBtET4SjB9SQTlHXui+2izr3s=; b=lM/MKskn1FS9A0VX85Zwoq0ob42Sd8jNXPd38tWkq7imrEQzE0XTMp1QmJG6Gaqz0D WKSKSdAsZsfBYj9jc3EZRovIzUbZ8gNkyVXJn5VxwQAhxHtpDwXnXcUujxr4CG0U59gB sYRE9XZpTPbxuQAj7Q1cnYTXRUMqSs0j9iaXZmLhR6vxtkN4HyejMyb5YgAHDgMGzE83 tZfPHtzrBnJW4Vv2lbDdlJRthePUkBUcUDIEvf9eo1WZqqEHA964F/UUkD865mCwSUB+ Oa0R2Xw1J9feYUJZGIoBzTkhbqkZ7JXURlB+No+yUi2MvTnhTyEAtArzIFh+FB6Edgj5 565A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=bP8mpKrU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p24si7319950pfh.148.2022.01.21.10.53.47; Fri, 21 Jan 2022 10:53:59 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=bP8mpKrU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352161AbiASHrb (ORCPT + 99 others); Wed, 19 Jan 2022 02:47:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37192 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352159AbiASHra (ORCPT ); Wed, 19 Jan 2022 02:47:30 -0500 Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BA555C06161C for ; Tue, 18 Jan 2022 23:47:30 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id m21so1819157pfd.3 for ; Tue, 18 Jan 2022 23:47:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qbiJb2UVtirrAHsd/tlBtET4SjB9SQTlHXui+2izr3s=; b=bP8mpKrUKYYcA4KRpX/Iab6PVeCaEBou0Rle0wK4u0oCxHKHJNxK3XOy8B6lcxgvXY FOco+CP1Zd+i3br6c9kACIwlpelrznWTBYQUgGtAv7CIL5/Vnzro9VaR+3UOWqaq8BVB xO6cf+i5UOhU4GoneriU5p5ARzP2ioFnBe4GfgF/C+JvyNABeyjbtY0rfzzo/ABYY++3 iJR1Xxp98BG1ihJUwNmD+zPbT8XFXRlCn6TXC5AqGaP9hKk35oUB0BaIZ9HYjhj8NlBp FAWsGfVPMfQ2g6v6WkTOQ8wNCoRN/d9yFYycIOipiN0vhIS7vAg3sF7aPCVLXrVqbIL7 RxNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qbiJb2UVtirrAHsd/tlBtET4SjB9SQTlHXui+2izr3s=; b=kamUe8orMNW+fxmFQwc1L+8KMrk3HoJRc17VmA1j345XppTe+GUdA359/VKYtBTnbi QvA6Ww/+cMNo+OvmIb8DWdd6KYGDyTi2oFTqrWopysS3zW/vKogBxFH3R63RxwXHIzAi pHUN82nk88ZsRMMUMcQFGn5qf/TToAAltG6hQz6OqLto66VvSrU+XBS7BTqeQMWRtJAW kqhrzayr/uhHxXlt3Yd3CCwndmrsXer+5EGOu9U8VthI2sPigytxprrMVNNNOq9YxbWP L64TltK5Mpg51cxr05U45AsKHaE0gwctlEOKyZ+LVCbT0OrHSyXTWr/A+48m92sE7/R0 fdrQ== X-Gm-Message-State: AOAM531KE2iA/vbfXdgrb6uJ/OSzWuA16Pq9lb6nVSUlaKn8Jd5vjzuE /3rSFasacAdmmC6XFaxvA1LNcfFQCXROkEz0BVsbhA== X-Received: by 2002:a63:7d42:: with SMTP id m2mr26257918pgn.491.1642578450084; Tue, 18 Jan 2022 23:47:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Reiji Watanabe Date: Tue, 18 Jan 2022 23:47:13 -0800 Message-ID: Subject: Re: [RFC PATCH v3 01/11] KVM: Capture VM start To: Sean Christopherson Cc: Raghavendra Rao Ananta , kvm@vger.kernel.org, Marc Zyngier , Peter Shier , linux-kernel@vger.kernel.org, Catalin Marinas , Paolo Bonzini , Will Deacon , kvmarm@lists.cs.columbia.edu, Linux ARM , Jim Mattson Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 18, 2022 at 4:07 PM Sean Christopherson wrote: > > On Fri, Jan 14, 2022, Reiji Watanabe wrote: > > The restriction, with which KVM doesn't need to worry about the changes > > in the registers after KVM_RUN, could potentially protect or be useful > > to protect KVM and simplify future changes/maintenance of the KVM codes > > that consumes the values. > > That sort of protection is definitely welcome, the previously mentioned CPUID mess > on x86 would have benefit greatly by KVM being restrictive in the past. That said, > hooking KVM_RUN is likely the wrong way to go about implementing any restrictions. > Running a vCPU is where much of the vCPU's state is explicitly consumed, but it's > all too easy for KVM to implicity/indirectly consume state via a different ioctl(), > e.g. if there are side effects that are visible in other registers, than an update > can also be visible to userspace via KVM_{G,S}ET_{S,}REGS, at which point disallowing > modifying state after KVM_RUN but not after reading/writing regs is arbitrary and > inconsitent. Thank you for your comments ! I think I understand your concern, and that's a great point. That's not the case for those pseudo registers though at least for now :) BTW, is this concern specific to hooking KVM_RUN ? (Wouldn't it be the same for the option with "if kvm->created_vcpus > 0" ?) > If possible, preventing modification if kvm->created_vcpus > 0 is ideal as it's > a relatively common pattern in KVM, and provides a clear boundary to userpace > regarding what is/isn't allowed. Yes, I agree that would be better in general. For (pseudo) registers, I would think preventing modification if kvm->created_vcpus > 0 might not be a very good option for KVM/ARM though considering usage of KVM_GET_REG_LIST and KVM_{G,S}ET_ONE_REG. Thanks, Reiji