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 D5A15C433F5 for ; Tue, 26 Apr 2022 04:07:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 443284B159; Tue, 26 Apr 2022 00:07:53 -0400 (EDT) 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=@kernel.org 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 EGWYXr7VELco; Tue, 26 Apr 2022 00:07:51 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id D9F134B137; Tue, 26 Apr 2022 00:07:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id A50864B10A for ; Tue, 26 Apr 2022 00:07:50 -0400 (EDT) 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 ydpwRwqKO8yU for ; Tue, 26 Apr 2022 00:07:49 -0400 (EDT) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 38EFE4B0CB for ; Tue, 26 Apr 2022 00:07:49 -0400 (EDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3EADC617F7; Tue, 26 Apr 2022 04:07:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1935C385A0; Tue, 26 Apr 2022 04:07:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1650946067; bh=SDHs3zTqIo9VsMzOH0uSwrAJvVTROZ4UuNBe+gEwAkk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ZrS5lFE8KIGJ15khhlW+CvSqUAUqM154cGvtoZqj10fgwmm5v1Pg0NCwhUn+nCvAt SBGuMdyawRIRaqRLceGYGRQaLnSxBTICKUDuSl9QrngAyslwslR5R8oY71NGJRlTfZ 1nJ7/4D7y6HohyMuNYKcDnJIANqiZiD2CojbilQk4iat84P4OLjonnzN8cMxYBd1W6 5Xr6YYEYCubSw2r92NVUhl0gPepWd8sMrjMC3EiEOqz6zEK+0+xwR3KhU0RW660V5l +aB7v0fQ5hp3NQmXhq90asX0A/JplLLxKqYubKiOdYIiC4tB+4ZQ5vom5qwm8/QVtA cR3gY6x8bo80g== Received: from [64.125.41.58] (helo=billy-the-mountain.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1njCUK-006wPU-PO; Tue, 26 Apr 2022 05:07:45 +0100 Date: Tue, 26 Apr 2022 05:07:40 +0100 Message-ID: <871qxkcws3.wl-maz@kernel.org> From: Marc Zyngier To: Ricardo Koller Subject: Re: [PATCH 1/4] KVM: arm64: vgic: Check that new ITEs could be saved in guest memory In-Reply-To: <20220425185534.57011-2-ricarkol@google.com> References: <20220425185534.57011-1-ricarkol@google.com> <20220425185534.57011-2-ricarkol@google.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 64.125.41.58 X-SA-Exim-Rcpt-To: ricarkol@google.com, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, pbonzini@redhat.com, andre.przywara@arm.com, drjones@redhat.com, alexandru.elisei@arm.com, eric.auger@redhat.com, oupton@google.com, reijiw@google.com, pshier@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: kvm@vger.kernel.org, andre.przywara@arm.com, pshier@google.com, pbonzini@redhat.com, kvmarm@lists.cs.columbia.edu 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 Mon, 25 Apr 2022 19:55:31 +0100, Ricardo Koller wrote: > > A command that adds an entry into an ITS table that is not in guest > memory should fail, as any command should be treated as if it was > actually saving entries in guest memory (KVM doesn't until saving). > Add the corresponding check for the ITT when adding ITEs. > > Signed-off-by: Ricardo Koller > --- > arch/arm64/kvm/vgic/vgic-its.c | 34 ++++++++++++++++++++++++++++++++++ > 1 file changed, 34 insertions(+) > > diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c > index 2e13402be3bd..d7c1a3a01af4 100644 > --- a/arch/arm64/kvm/vgic/vgic-its.c > +++ b/arch/arm64/kvm/vgic/vgic-its.c > @@ -976,6 +976,37 @@ static bool vgic_its_check_id(struct vgic_its *its, u64 baser, u32 id, > return ret; > } > > +/* > + * Check whether an event ID can be stored in the corresponding Interrupt > + * Translation Table, which starts at device->itt_addr. > + */ > +static bool vgic_its_check_ite(struct vgic_its *its, struct its_device *device, > + u32 event_id) > +{ > + const struct vgic_its_abi *abi = vgic_its_get_abi(its); > + int ite_esz = abi->ite_esz; > + gpa_t gpa; > + gfn_t gfn; > + int idx; > + bool ret; > + > + /* max table size is: BIT_ULL(device->num_eventid_bits) * ite_esz */ > + if (event_id >= BIT_ULL(device->num_eventid_bits)) > + return false; We have already checked this condition, it seems. > + > + gpa = device->itt_addr + event_id * ite_esz; > + gfn = gpa >> PAGE_SHIFT; > + > + idx = srcu_read_lock(&its->dev->kvm->srcu); > + ret = kvm_is_visible_gfn(its->dev->kvm, gfn); > + srcu_read_unlock(&its->dev->kvm->srcu, idx); > + return ret; Why should we care? If the guest doesn't give us the memory that is required, that's its problem. The only architectural requirement is that the EID fits into the device table. There is no guarantee that the ITS will actually write to the memory. And if you feel that there is a strong need to have this, surely you can reuse some of the vgic_its_check_id() code. > +} > + > +/* > + * Adds a new collection into the ITS collection table. > + * Returns 0 on success, and a negative error value for generic errors. Not only. A positive error can also be returned for an out of range condition. > + */ > static int vgic_its_alloc_collection(struct vgic_its *its, > struct its_collection **colp, > u32 coll_id) > @@ -1076,6 +1107,9 @@ static int vgic_its_cmd_handle_mapi(struct kvm *kvm, struct vgic_its *its, > if (find_ite(its, device_id, event_id)) > return 0; > > + if (!vgic_its_check_ite(its, device, event_id)) > + return E_ITS_MAPTI_ID_OOR; > + > collection = find_collection(its, coll_id); > if (!collection) { > int ret = vgic_its_alloc_collection(its, &collection, coll_id); > -- > 2.36.0.rc2.479.g8af0fa9b8e-goog > > Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E327FC433FE for ; Tue, 26 Apr 2022 04:07:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229885AbiDZEK4 (ORCPT ); Tue, 26 Apr 2022 00:10:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55552 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243728AbiDZEKz (ORCPT ); Tue, 26 Apr 2022 00:10:55 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CEA9417A8B for ; Mon, 25 Apr 2022 21:07:48 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 56829617F5 for ; Tue, 26 Apr 2022 04:07:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1935C385A0; Tue, 26 Apr 2022 04:07:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1650946067; bh=SDHs3zTqIo9VsMzOH0uSwrAJvVTROZ4UuNBe+gEwAkk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ZrS5lFE8KIGJ15khhlW+CvSqUAUqM154cGvtoZqj10fgwmm5v1Pg0NCwhUn+nCvAt SBGuMdyawRIRaqRLceGYGRQaLnSxBTICKUDuSl9QrngAyslwslR5R8oY71NGJRlTfZ 1nJ7/4D7y6HohyMuNYKcDnJIANqiZiD2CojbilQk4iat84P4OLjonnzN8cMxYBd1W6 5Xr6YYEYCubSw2r92NVUhl0gPepWd8sMrjMC3EiEOqz6zEK+0+xwR3KhU0RW660V5l +aB7v0fQ5hp3NQmXhq90asX0A/JplLLxKqYubKiOdYIiC4tB+4ZQ5vom5qwm8/QVtA cR3gY6x8bo80g== Received: from [64.125.41.58] (helo=billy-the-mountain.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1njCUK-006wPU-PO; Tue, 26 Apr 2022 05:07:45 +0100 Date: Tue, 26 Apr 2022 05:07:40 +0100 Message-ID: <871qxkcws3.wl-maz@kernel.org> From: Marc Zyngier To: Ricardo Koller Cc: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, pbonzini@redhat.com, andre.przywara@arm.com, drjones@redhat.com, alexandru.elisei@arm.com, eric.auger@redhat.com, oupton@google.com, reijiw@google.com, pshier@google.com Subject: Re: [PATCH 1/4] KVM: arm64: vgic: Check that new ITEs could be saved in guest memory In-Reply-To: <20220425185534.57011-2-ricarkol@google.com> References: <20220425185534.57011-1-ricarkol@google.com> <20220425185534.57011-2-ricarkol@google.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 64.125.41.58 X-SA-Exim-Rcpt-To: ricarkol@google.com, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, pbonzini@redhat.com, andre.przywara@arm.com, drjones@redhat.com, alexandru.elisei@arm.com, eric.auger@redhat.com, oupton@google.com, reijiw@google.com, pshier@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Mon, 25 Apr 2022 19:55:31 +0100, Ricardo Koller wrote: > > A command that adds an entry into an ITS table that is not in guest > memory should fail, as any command should be treated as if it was > actually saving entries in guest memory (KVM doesn't until saving). > Add the corresponding check for the ITT when adding ITEs. > > Signed-off-by: Ricardo Koller > --- > arch/arm64/kvm/vgic/vgic-its.c | 34 ++++++++++++++++++++++++++++++++++ > 1 file changed, 34 insertions(+) > > diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c > index 2e13402be3bd..d7c1a3a01af4 100644 > --- a/arch/arm64/kvm/vgic/vgic-its.c > +++ b/arch/arm64/kvm/vgic/vgic-its.c > @@ -976,6 +976,37 @@ static bool vgic_its_check_id(struct vgic_its *its, u64 baser, u32 id, > return ret; > } > > +/* > + * Check whether an event ID can be stored in the corresponding Interrupt > + * Translation Table, which starts at device->itt_addr. > + */ > +static bool vgic_its_check_ite(struct vgic_its *its, struct its_device *device, > + u32 event_id) > +{ > + const struct vgic_its_abi *abi = vgic_its_get_abi(its); > + int ite_esz = abi->ite_esz; > + gpa_t gpa; > + gfn_t gfn; > + int idx; > + bool ret; > + > + /* max table size is: BIT_ULL(device->num_eventid_bits) * ite_esz */ > + if (event_id >= BIT_ULL(device->num_eventid_bits)) > + return false; We have already checked this condition, it seems. > + > + gpa = device->itt_addr + event_id * ite_esz; > + gfn = gpa >> PAGE_SHIFT; > + > + idx = srcu_read_lock(&its->dev->kvm->srcu); > + ret = kvm_is_visible_gfn(its->dev->kvm, gfn); > + srcu_read_unlock(&its->dev->kvm->srcu, idx); > + return ret; Why should we care? If the guest doesn't give us the memory that is required, that's its problem. The only architectural requirement is that the EID fits into the device table. There is no guarantee that the ITS will actually write to the memory. And if you feel that there is a strong need to have this, surely you can reuse some of the vgic_its_check_id() code. > +} > + > +/* > + * Adds a new collection into the ITS collection table. > + * Returns 0 on success, and a negative error value for generic errors. Not only. A positive error can also be returned for an out of range condition. > + */ > static int vgic_its_alloc_collection(struct vgic_its *its, > struct its_collection **colp, > u32 coll_id) > @@ -1076,6 +1107,9 @@ static int vgic_its_cmd_handle_mapi(struct kvm *kvm, struct vgic_its *its, > if (find_ite(its, device_id, event_id)) > return 0; > > + if (!vgic_its_check_ite(its, device, event_id)) > + return E_ITS_MAPTI_ID_OOR; > + > collection = find_collection(its, coll_id); > if (!collection) { > int ret = vgic_its_alloc_collection(its, &collection, coll_id); > -- > 2.36.0.rc2.479.g8af0fa9b8e-goog > > Thanks, M. -- Without deviation from the norm, progress is not possible.