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 B16A5C25B75 for ; Fri, 31 May 2024 04:59:21 +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=TxwuMLvjSizvJyoFLMPCqQlZoSL3P10OtJoBEFMExuk=; b=VDyQYR8j7toy1W vbVaj7xfuUkO8nnD8IkJ3+uKQYxUeCAtZOlclwyR6uvi4l0mQ/WHLIk4Laeo2GEW8BulVi5CN8SfK o7E1nXtI5H+zKSRxBEQ6VmjAiV90Lg7DAiJKU7EXcPkaH7UQ1o8onrDf6mXHitn87vv9xBq6WKGwB 9EYxbIqtyzCTybKffsqd3ppqSAfyHXigOFBxCOCXv9johgpqo2CMdLr3ezJ2n2B+FibyHrAjkRtFl 8h5SLUa0ha9Wai934k4Dh1QMUWtrcdnW9WKZ/V2TYtZtFmom1i3gZyN0h9KN3JsKIrhXRAPPkQOKr 9AeeO8OiZCYzhls2Itwg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sCuMB-00000009FYS-1xhu; Fri, 31 May 2024 04:59:11 +0000 Received: from smtp-fw-6001.amazon.com ([52.95.48.154]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sCuM7-00000009FXx-35Em for linux-arm-kernel@lists.infradead.org; Fri, 31 May 2024 04:59:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1717131548; x=1748667548; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=BHHQNm4rjPB4mXDmlcn3ohEO7va2GBW9i7NGinzyc08=; b=X2L8kwFGcJjwuztMROKNu7ZFlhFHnKijLJIOBQd22RtsEuynqUkzPNAb keKIJlww9gKGkTJJshLyl8xBGzmvGcMkr3KPdjEj9F2/PDIMpNryiFtH2 oNid3yb1glMppCDOeO29FSvWbTLYZwm1L28CQExaFzwc/FY9CWJ6ppBoW o=; X-IronPort-AV: E=Sophos;i="6.08,203,1712620800"; d="scan'208";a="400131024" Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO smtpout.prod.us-west-2.prod.farcaster.email.amazon.dev) ([10.43.8.2]) by smtp-border-fw-6001.iad6.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 May 2024 04:59:01 +0000 Received: from EX19MTAEUB001.ant.amazon.com [10.0.10.100:34081] by smtpin.naws.eu-west-1.prod.farcaster.email.amazon.dev [10.0.33.99:2525] with esmtp (Farcaster) id a7488b13-720c-486c-8330-1930378f6073; Fri, 31 May 2024 04:58:59 +0000 (UTC) X-Farcaster-Flow-ID: a7488b13-720c-486c-8330-1930378f6073 Received: from EX19D002EUA001.ant.amazon.com (10.252.50.66) by EX19MTAEUB001.ant.amazon.com (10.252.51.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Fri, 31 May 2024 04:58:59 +0000 Received: from EX19MTAUWB001.ant.amazon.com (10.250.64.248) by EX19D002EUA001.ant.amazon.com (10.252.50.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Fri, 31 May 2024 04:58:59 +0000 Received: from dev-dsk-hagarhem-1b-b868d8d5.eu-west-1.amazon.com (10.253.65.58) by mail-relay.amazon.com (10.250.64.254) with Microsoft SMTP Server id 15.2.1258.28 via Frontend Transport; Fri, 31 May 2024 04:58:57 +0000 Received: by dev-dsk-hagarhem-1b-b868d8d5.eu-west-1.amazon.com (Postfix, from userid 23002382) id 5CC2520AC2; Fri, 31 May 2024 04:58:57 +0000 (UTC) Date: Fri, 31 May 2024 04:58:57 +0000 From: Hagar Hemdan To: Marc Zyngier CC: Maximilian Heyne , Norbert Manthey , Thomas Gleixner , Eric Auger , , , Subject: Re: [PATCH] irqchip/gic-v3-its: Fix potential race condition in its_vlpi_prop_update() Message-ID: <20240531045857.GA14712@amazon.com> References: <20240530105713.18552-1-hagarhem@amazon.com> <86v82vl34a.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <86v82vl34a.wl-maz@kernel.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240530_215907_974796_EBA31BB9 X-CRM114-Status: GOOD ( 38.81 ) 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 Thu, May 30, 2024 at 04:40:37PM +0100, Marc Zyngier wrote: Hi Marc, yes, you are right. The lock should be moved to its_irq_set_vcpu_affinity(). I will update the patch and the commit message in rev2. Thanks, Hagar > Hi Hagar, > > On Thu, 30 May 2024 11:57:13 +0100, > Hagar Hemdan wrote: > > > > Similar to commit 046b5054f566 ("irqchip/gic-v3-its: Lock VLPI map array > > before translating it"), its_vlpi_prop_update() calls lpi_write_config() > > which obtains the mapping information for a VLPI. > > This should always be done with vlpi_lock for this device held. Otherwise, > > its_vlpi_prop_update() could race with its_vlpi_unmap(). > > Thanks for reporting this. Note that this issue is not the same as the > one you refer to (what you have here is a total absence of locking, > while 046b5054f566 fixed a call to get_vlpi_map() outside of an > existing critical section). > > > > > This bug was discovered and resolved using Coverity Static Analysis > > Security Testing (SAST) by Synopsys, Inc. > > Should we get a scrolling banner for this kind of advertisements? ;-) > > > > > Fixes: 015ec0386ab6 ("irqchip/gic-v3-its: Add VLPI configuration handling") > > Signed-off-by: Hagar Hemdan > > --- > > drivers/irqchip/irq-gic-v3-its.c | 12 +++++++++--- > > 1 file changed, 9 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c > > index 40ebf1726393..ecaad1786345 100644 > > --- a/drivers/irqchip/irq-gic-v3-its.c > > +++ b/drivers/irqchip/irq-gic-v3-its.c > > @@ -1970,9 +1970,13 @@ static int its_vlpi_unmap(struct irq_data *d) > > static int its_vlpi_prop_update(struct irq_data *d, struct its_cmd_info *info) > > { > > struct its_device *its_dev = irq_data_get_irq_chip_data(d); > > + int ret = 0; > > > > - if (!its_dev->event_map.vm || !irqd_is_forwarded_to_vcpu(d)) > > - return -EINVAL; > > + raw_spin_lock(&its_dev->event_map.vlpi_lock); > > + if (!its_dev->event_map.vm || !irqd_is_forwarded_to_vcpu(d)) { > > + ret = -EINVAL; > > + goto out; > > + } > > > > if (info->cmd_type == PROP_UPDATE_AND_INV_VLPI) > > lpi_update_config(d, 0xff, info->config); > > @@ -1980,7 +1984,9 @@ static int its_vlpi_prop_update(struct irq_data *d, struct its_cmd_info *info) > > lpi_write_config(d, 0xff, info->config); > > its_vlpi_set_doorbell(d, !!(info->config & LPI_PROP_ENABLED)); > > > > - return 0; > > +out: > > + raw_spin_unlock(&its_dev->event_map.vlpi_lock); > > + return ret; > > } > > > > static int its_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu_info) > > As it turns out, all the calls from its_irq_set_vcpu_affinity() > require the same lock to be held. So instead of peppering the locking > all over the place, we could (should?) hoist the locking into > its_irq_set_vcpu_affinity() and avoid future bugs. It also results in > a negative diffstat. > > Something like the hack below (compile-tested only), which I'm sure > the "Coverity Static Analysis Security Testing (SAST) by Synopsys, > Inc" will be able to verify... > > M. > > diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c > index 40ebf1726393..abc1fb360ce4 100644 > --- a/drivers/irqchip/irq-gic-v3-its.c > +++ b/drivers/irqchip/irq-gic-v3-its.c > @@ -1851,23 +1851,18 @@ static int its_vlpi_map(struct irq_data *d, struct its_cmd_info *info) > if (!info->map) > return -EINVAL; > > - raw_spin_lock(&its_dev->event_map.vlpi_lock); > - > if (!its_dev->event_map.vm) { > struct its_vlpi_map *maps; > > maps = kcalloc(its_dev->event_map.nr_lpis, sizeof(*maps), > GFP_ATOMIC); > - if (!maps) { > - ret = -ENOMEM; > - goto out; > - } > + if (!maps) > + return -ENOMEM; > > its_dev->event_map.vm = info->map->vm; > its_dev->event_map.vlpi_maps = maps; > } else if (its_dev->event_map.vm != info->map->vm) { > - ret = -EINVAL; > - goto out; > + return -EINVAL; > } > > /* Get our private copy of the mapping information */ > @@ -1899,8 +1894,6 @@ static int its_vlpi_map(struct irq_data *d, struct its_cmd_info *info) > its_dev->event_map.nr_vlpis++; > } > > -out: > - raw_spin_unlock(&its_dev->event_map.vlpi_lock); > return ret; > } > > @@ -1910,20 +1903,14 @@ static int its_vlpi_get(struct irq_data *d, struct its_cmd_info *info) > struct its_vlpi_map *map; > int ret = 0; > > - raw_spin_lock(&its_dev->event_map.vlpi_lock); > - > map = get_vlpi_map(d); > > - if (!its_dev->event_map.vm || !map) { > - ret = -EINVAL; > - goto out; > - } > + if (!its_dev->event_map.vm || !map) > + return -EINVAL; > > /* Copy our mapping information to the incoming request */ > *info->map = *map; > > -out: > - raw_spin_unlock(&its_dev->event_map.vlpi_lock); > return ret; > } > > @@ -1933,12 +1920,8 @@ static int its_vlpi_unmap(struct irq_data *d) > u32 event = its_get_event_id(d); > int ret = 0; > > - raw_spin_lock(&its_dev->event_map.vlpi_lock); > - > - if (!its_dev->event_map.vm || !irqd_is_forwarded_to_vcpu(d)) { > - ret = -EINVAL; > - goto out; > - } > + if (!its_dev->event_map.vm || !irqd_is_forwarded_to_vcpu(d)) > + return -EINVAL; > > /* Drop the virtual mapping */ > its_send_discard(its_dev, event); > @@ -1962,8 +1945,6 @@ static int its_vlpi_unmap(struct irq_data *d) > kfree(its_dev->event_map.vlpi_maps); > } > > -out: > - raw_spin_unlock(&its_dev->event_map.vlpi_lock); > return ret; > } > > @@ -1987,29 +1968,41 @@ static int its_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu_info) > { > struct its_device *its_dev = irq_data_get_irq_chip_data(d); > struct its_cmd_info *info = vcpu_info; > + int ret; > > /* Need a v4 ITS */ > if (!is_v4(its_dev->its)) > return -EINVAL; > > + raw_spin_lock(&its_dev->event_map.vlpi_lock); > + > /* Unmap request? */ > - if (!info) > - return its_vlpi_unmap(d); > + if (!info) { > + ret = its_vlpi_unmap(d); > + goto out; > + } > > switch (info->cmd_type) { > case MAP_VLPI: > - return its_vlpi_map(d, info); > + ret = its_vlpi_map(d, info); > + break; > > case GET_VLPI: > - return its_vlpi_get(d, info); > + ret = its_vlpi_get(d, info); > + break; > > case PROP_UPDATE_VLPI: > case PROP_UPDATE_AND_INV_VLPI: > - return its_vlpi_prop_update(d, info); > + ret = its_vlpi_prop_update(d, info); > + break; > > default: > - return -EINVAL; > + ret = -EINVAL; > } > + > +out: > + raw_spin_unlock(&its_dev->event_map.vlpi_lock); > + return ret; > } > > static struct irq_chip its_irq_chip = { > > -- > 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel