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 1FFE0C433EF for ; Wed, 6 Jul 2022 07:12:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 811B34C05B; Wed, 6 Jul 2022 03:12:49 -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 ncrrYlrJq-3g; Wed, 6 Jul 2022 03:12:48 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 5D3AE4BFA5; Wed, 6 Jul 2022 03:12:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 4B1B44BFA5 for ; Wed, 6 Jul 2022 03:12:47 -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 bfqgHCAQCQuO for ; Wed, 6 Jul 2022 03:12:45 -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 DCF7B4BF9E for ; Wed, 6 Jul 2022 03:12:45 -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 A10DF61DB6; Wed, 6 Jul 2022 07:12:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0252FC3411C; Wed, 6 Jul 2022 07:12:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1657091564; bh=MKCelLRGo19jxP5YyzzSs6MDJt/u2Z/VZUjRwVgwoe4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=axxVzqO41y4qRoNIUf/mTmfLsicFzHjqLDXncKogvoPMRQOzBYkmYW6mvLSrOsYVQ QpHD9X6+hn5uJgzWaaLyDlkpZvF2gB6Z8QZoDTluWRvlDgv3VeKf/Bgc6fj2DgS9Vp MaoQHhsRQD242OMsoADmgvJdgLDahqMLL0vwjXNbLCCT7DednMdlaXJFSBa4oooAjq YhLEGBZkY6NRdctft1uUNxWvaRkbPMhp/tLzUFpaYqbYo4AeVlM+ESdtYcSIJWsHS3 cJCs2ABe9cqlS9ARTJgs+ZOY9Pe7HREj3vElhi5+i/q8KdyYcG6Fmqk4zexqU+yRkg IgmvUPuQ/B2EQ== Received: from ip-185-104-136-29.ptr.icomera.net ([185.104.136.29] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1o8zDF-005YP1-Pa; Wed, 06 Jul 2022 08:12:41 +0100 Date: Wed, 06 Jul 2022 08:11:46 +0100 Message-ID: <87edyyn2a5.wl-maz@kernel.org> From: Marc Zyngier To: Schspa Shi Subject: Re: [PATCH] KVM: arm64: Fix 64 bit mmio handle In-Reply-To: References: <20220630161220.53449-1-schspa@gmail.com> <87mtdu15ok.wl-maz@kernel.org> <87letd0wqm.wl-maz@kernel.org> 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 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.104.136.29 X-SA-Exim-Rcpt-To: schspa@gmail.com, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: will@kernel.org, catalin.marinas@arm.com, linux-kernel@vger.kernel.org, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org 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, 01 Jul 2022 15:22:51 +0100, Schspa Shi wrote: > > > Marc Zyngier writes: > > >> > >> I have running some static code analysis software upon Kernel code. > >> Seeing there is possible overflow. > >> > >> maks << 1U << ((len * 8) -1); > >> > >> The AI don't know, len is only the value of 1, 2, 4, and make this > >> a warnings > >> > >> I tring to analysis this, but didn't realize the real scenario of > >> sign extension, and finally sent this problematic patch. > >> > >> I do see some uninitialized memory reads (the values are not used > >> in the end, just as temporary space for API execution), > >> do we need to fix these? > > > > You need to be more descriptive here. What uninitialised reads? In > > general, pointing at the code and providing a full description of > > what > > you think is incorrect would really help... > > > > M. > One example is > int vgic_v3_has_attr_regs(struct kvm_device *dev, struct > kvm_device_attr *attr) > { > ... > case KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS: { > u64 reg, id; > > id = (attr->attr & KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK); > return vgic_v3_has_cpu_sysregs_attr(vcpu, 0, id, ®); > } > > } > > The funcion vgic_v3_has_cpu_sysregs_attr will read reg's value to > params without initialization. There should have no problems, > because the register value never used. Thanks for pointing this out. I spent some time looking at this, and this is only the tip of the iceberg. The whole userspace interaction with the GIC sysregs is ugly (at best), and needs some love. I've written a small series[1] cleaning things up, which needs testing (I've just checked that it was compiling correctly). I'd appreciate you running your tool on it. M. [1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=kvm-arm64/sysreg-cleanup-5.20 -- 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 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 3A0BAC43334 for ; Wed, 6 Jul 2022 07:13:53 +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:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=PhYGdc/LEV+WZi2zfJWPDh3tol9QS3AQhr6+3ugwD9s=; b=DK2oos2oLcMPji XHnwAKALg8vZW/6AypxQMR72hmbYZVxOu1dXlyjaDI5+TfouaBzkU3ZhA5mg+wZY7PdXY+kRQYwCw DNiHP/yfo8aHmrzPXkeeN4nBFJiEwl4DPkev1X47m22kvGKzgyZzTL1jg8TYjXlkQIsuVAT9bn6wF jGIo+FyQNoH4sRqR5S/0lZ9lqVKdlb8B7qXnTnb9ioFPHclB7SH1qyYVHkDcXR9EkD0JXn2OS1zzR rUtwxuBfbFX1BdHC22AUyzshDBcXJc/YwhHntNyxARJmEzuQ3wINcGr0mYcSdF6kSbBk6+D2YIekx /C8TQJgI1tp19y+3D7IQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o8zDM-0071Cj-BV; Wed, 06 Jul 2022 07:12:48 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1o8zDJ-0071BC-9s for linux-arm-kernel@lists.infradead.org; Wed, 06 Jul 2022 07:12:46 +0000 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 A10DF61DB6; Wed, 6 Jul 2022 07:12:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0252FC3411C; Wed, 6 Jul 2022 07:12:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1657091564; bh=MKCelLRGo19jxP5YyzzSs6MDJt/u2Z/VZUjRwVgwoe4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=axxVzqO41y4qRoNIUf/mTmfLsicFzHjqLDXncKogvoPMRQOzBYkmYW6mvLSrOsYVQ QpHD9X6+hn5uJgzWaaLyDlkpZvF2gB6Z8QZoDTluWRvlDgv3VeKf/Bgc6fj2DgS9Vp MaoQHhsRQD242OMsoADmgvJdgLDahqMLL0vwjXNbLCCT7DednMdlaXJFSBa4oooAjq YhLEGBZkY6NRdctft1uUNxWvaRkbPMhp/tLzUFpaYqbYo4AeVlM+ESdtYcSIJWsHS3 cJCs2ABe9cqlS9ARTJgs+ZOY9Pe7HREj3vElhi5+i/q8KdyYcG6Fmqk4zexqU+yRkg IgmvUPuQ/B2EQ== Received: from ip-185-104-136-29.ptr.icomera.net ([185.104.136.29] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1o8zDF-005YP1-Pa; Wed, 06 Jul 2022 08:12:41 +0100 Date: Wed, 06 Jul 2022 08:11:46 +0100 Message-ID: <87edyyn2a5.wl-maz@kernel.org> From: Marc Zyngier To: Schspa Shi Cc: james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org Subject: Re: [PATCH] KVM: arm64: Fix 64 bit mmio handle In-Reply-To: References: <20220630161220.53449-1-schspa@gmail.com> <87mtdu15ok.wl-maz@kernel.org> <87letd0wqm.wl-maz@kernel.org> 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 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.104.136.29 X-SA-Exim-Rcpt-To: schspa@gmail.com, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220706_001245_467071_43D3D9B2 X-CRM114-Status: GOOD ( 28.05 ) 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, 01 Jul 2022 15:22:51 +0100, Schspa Shi wrote: > > > Marc Zyngier writes: > > >> > >> I have running some static code analysis software upon Kernel code. > >> Seeing there is possible overflow. > >> > >> maks << 1U << ((len * 8) -1); > >> > >> The AI don't know, len is only the value of 1, 2, 4, and make this > >> a warnings > >> > >> I tring to analysis this, but didn't realize the real scenario of > >> sign extension, and finally sent this problematic patch. > >> > >> I do see some uninitialized memory reads (the values are not used > >> in the end, just as temporary space for API execution), > >> do we need to fix these? > > > > You need to be more descriptive here. What uninitialised reads? In > > general, pointing at the code and providing a full description of > > what > > you think is incorrect would really help... > > > > M. > One example is > int vgic_v3_has_attr_regs(struct kvm_device *dev, struct > kvm_device_attr *attr) > { > ... > case KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS: { > u64 reg, id; > > id = (attr->attr & KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK); > return vgic_v3_has_cpu_sysregs_attr(vcpu, 0, id, ®); > } > > } > > The funcion vgic_v3_has_cpu_sysregs_attr will read reg's value to > params without initialization. There should have no problems, > because the register value never used. Thanks for pointing this out. I spent some time looking at this, and this is only the tip of the iceberg. The whole userspace interaction with the GIC sysregs is ugly (at best), and needs some love. I've written a small series[1] cleaning things up, which needs testing (I've just checked that it was compiling correctly). I'd appreciate you running your tool on it. M. [1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=kvm-arm64/sysreg-cleanup-5.20 -- Without deviation from the norm, progress is not possible. _______________________________________________ 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 7FCB3C43334 for ; Wed, 6 Jul 2022 07:12:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229984AbiGFHMs (ORCPT ); Wed, 6 Jul 2022 03:12:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36822 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229459AbiGFHMr (ORCPT ); Wed, 6 Jul 2022 03:12:47 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CE8A321AC for ; Wed, 6 Jul 2022 00:12:46 -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 ams.source.kernel.org (Postfix) with ESMTPS id 75607B81AE7 for ; Wed, 6 Jul 2022 07:12:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0252FC3411C; Wed, 6 Jul 2022 07:12:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1657091564; bh=MKCelLRGo19jxP5YyzzSs6MDJt/u2Z/VZUjRwVgwoe4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=axxVzqO41y4qRoNIUf/mTmfLsicFzHjqLDXncKogvoPMRQOzBYkmYW6mvLSrOsYVQ QpHD9X6+hn5uJgzWaaLyDlkpZvF2gB6Z8QZoDTluWRvlDgv3VeKf/Bgc6fj2DgS9Vp MaoQHhsRQD242OMsoADmgvJdgLDahqMLL0vwjXNbLCCT7DednMdlaXJFSBa4oooAjq YhLEGBZkY6NRdctft1uUNxWvaRkbPMhp/tLzUFpaYqbYo4AeVlM+ESdtYcSIJWsHS3 cJCs2ABe9cqlS9ARTJgs+ZOY9Pe7HREj3vElhi5+i/q8KdyYcG6Fmqk4zexqU+yRkg IgmvUPuQ/B2EQ== Received: from ip-185-104-136-29.ptr.icomera.net ([185.104.136.29] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1o8zDF-005YP1-Pa; Wed, 06 Jul 2022 08:12:41 +0100 Date: Wed, 06 Jul 2022 08:11:46 +0100 Message-ID: <87edyyn2a5.wl-maz@kernel.org> From: Marc Zyngier To: Schspa Shi Cc: james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org Subject: Re: [PATCH] KVM: arm64: Fix 64 bit mmio handle In-Reply-To: References: <20220630161220.53449-1-schspa@gmail.com> <87mtdu15ok.wl-maz@kernel.org> <87letd0wqm.wl-maz@kernel.org> 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 (x86_64-pc-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: 185.104.136.29 X-SA-Exim-Rcpt-To: schspa@gmail.com, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org 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: linux-kernel@vger.kernel.org On Fri, 01 Jul 2022 15:22:51 +0100, Schspa Shi wrote: > > > Marc Zyngier writes: > > >> > >> I have running some static code analysis software upon Kernel code. > >> Seeing there is possible overflow. > >> > >> maks << 1U << ((len * 8) -1); > >> > >> The AI don't know, len is only the value of 1, 2, 4, and make this > >> a warnings > >> > >> I tring to analysis this, but didn't realize the real scenario of > >> sign extension, and finally sent this problematic patch. > >> > >> I do see some uninitialized memory reads (the values are not used > >> in the end, just as temporary space for API execution), > >> do we need to fix these? > > > > You need to be more descriptive here. What uninitialised reads? In > > general, pointing at the code and providing a full description of > > what > > you think is incorrect would really help... > > > > M. > One example is > int vgic_v3_has_attr_regs(struct kvm_device *dev, struct > kvm_device_attr *attr) > { > ... > case KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS: { > u64 reg, id; > > id = (attr->attr & KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK); > return vgic_v3_has_cpu_sysregs_attr(vcpu, 0, id, ®); > } > > } > > The funcion vgic_v3_has_cpu_sysregs_attr will read reg's value to > params without initialization. There should have no problems, > because the register value never used. Thanks for pointing this out. I spent some time looking at this, and this is only the tip of the iceberg. The whole userspace interaction with the GIC sysregs is ugly (at best), and needs some love. I've written a small series[1] cleaning things up, which needs testing (I've just checked that it was compiling correctly). I'd appreciate you running your tool on it. M. [1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=kvm-arm64/sysreg-cleanup-5.20 -- Without deviation from the norm, progress is not possible.