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 ED554ECE587 for ; Mon, 9 Sep 2024 19:49:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:CC:To: Subject:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=BU6pdzSQpo1Z2REi27liLOcnCYhfuvSgn1MJKg76mro=; b=j9wIVeGj6Hbj/0WZ7MC48mZdk7 0t8g0Yl2yKkmkdI81VxWBpE/MA3slClJesyvwfQ9+flspMsaAhYDhIVjWXsVCrHeTYBBdDSzUjGfP 5XLDvXYPy8Xo8vmRI5X212+/SRNo80NmoBqg8ZRZp7o6tb6yiMEk3RoLaGLoLd0uzaXsgv4rLwBeZ EPsXt6i39a0D4DEPnURnaEJEyr8EnGCTlQMRGpk/N2pD7XxsjRecyDeHCagA+51kp4xS1ROnNvCF5 jsYNxhhVrXV33O6m+zGOPnOOD5hE1NtyAyD4fQIZ24wBXvaaL40TMoHD4Yg5m03H01sEzHedV024i eKGRAsFA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1snkOI-0000000393e-2EfL; Mon, 09 Sep 2024 19:49:38 +0000 Received: from mx01.omp.ru ([90.154.21.10]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1snkNH-000000038x3-1Prt for linux-arm-kernel@lists.infradead.org; Mon, 09 Sep 2024 19:48:37 +0000 Received: from [192.168.1.106] (31.173.81.96) by msexch01.omp.ru (10.188.4.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.1258.12; Mon, 9 Sep 2024 22:48:26 +0300 Subject: Re: [PATCH] irqchip/gic: prevent buffer overflow in gic_ipi_send_mask() To: Marc Zyngier CC: Thomas Gleixner , , References: <048ff3bb-09d1-2e60-4f3b-611e2bfde7aa@omp.ru> <87cyli5zj7.ffs@tglx> <86o752v8xs.wl-maz@kernel.org> <87wmjmv632.wl-maz@kernel.org> From: Sergey Shtylyov Organization: Open Mobile Platform Message-ID: <052d20d5-e8e4-3133-4fa0-1c026ffb4209@omp.ru> Date: Mon, 9 Sep 2024 22:48:24 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <87wmjmv632.wl-maz@kernel.org> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [31.173.81.96] X-ClientProxiedBy: msexch01.omp.ru (10.188.4.12) To msexch01.omp.ru (10.188.4.12) X-KSE-ServerInfo: msexch01.omp.ru, 9 X-KSE-AntiSpam-Interceptor-Info: scan successful X-KSE-AntiSpam-Version: 6.1.1, Database issued on: 09/09/2024 19:29:02 X-KSE-AntiSpam-Status: KAS_STATUS_NOT_DETECTED X-KSE-AntiSpam-Method: none X-KSE-AntiSpam-Rate: 59 X-KSE-AntiSpam-Info: Lua profiles 187638 [Sep 09 2024] X-KSE-AntiSpam-Info: Version: 6.1.1.5 X-KSE-AntiSpam-Info: Envelope from: s.shtylyov@omp.ru X-KSE-AntiSpam-Info: LuaCore: 32 0.3.32 766319f57b3d5e49f2c79a76e7d7087b621090df X-KSE-AntiSpam-Info: {rep_avail} X-KSE-AntiSpam-Info: {Tracking_from_domain_doesnt_match_to} X-KSE-AntiSpam-Info: {relay has no DNS name} X-KSE-AntiSpam-Info: {SMTP from is not routable} X-KSE-AntiSpam-Info: {Found in DNSBL: 31.173.81.96 in (user) b.barracudacentral.org} X-KSE-AntiSpam-Info: {Found in DNSBL: 31.173.81.96 in (user) dbl.spamhaus.org} X-KSE-AntiSpam-Info: d41d8cd98f00b204e9800998ecf8427e.com:7.1.1;127.0.0.199:7.1.2;omp.ru:7.1.1 X-KSE-AntiSpam-Info: FromAlignment: s X-KSE-AntiSpam-Info: ApMailHostAddress: 31.173.81.96 X-KSE-AntiSpam-Info: {DNS response errors} X-KSE-AntiSpam-Info: Rate: 59 X-KSE-AntiSpam-Info: Status: not_detected X-KSE-AntiSpam-Info: Method: none X-KSE-AntiSpam-Info: Auth:dmarc=temperror header.from=omp.ru;spf=temperror smtp.mailfrom=omp.ru;dkim=none X-KSE-Antiphishing-Info: Clean X-KSE-Antiphishing-ScanningType: Heuristic X-KSE-Antiphishing-Method: None X-KSE-Antiphishing-Bases: 09/09/2024 19:32:00 X-KSE-Antivirus-Interceptor-Info: scan successful X-KSE-Antivirus-Info: Clean, bases: 9/9/2024 4:30:00 PM X-KSE-Attachment-Filter-Triggered-Rules: Clean X-KSE-Attachment-Filter-Triggered-Filters: Clean X-KSE-BulkMessagesFiltering-Scan-Result: InTheLimit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240909_124835_418473_476B9E17 X-CRM114-Status: GOOD ( 19.77 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 9/8/24 12:37 PM, Marc Zyngier wrote: [...] >>>>> ARM GIC arch v2 spec claims support for just 8 CPU interfaces. However, >>>>> looking at the GIC driver's irq_set_affinity() method, it seems that the >>>>> passed CPU mask may contain the logical CPU #s beyond 8, and that method >>>>> filters them out before reading gic_cpu_map[], bailing out with >>>>> -EINVAL. >>>> >>>> The reasoning is correct in theory, but in reality it's a non problem. >>>> >>>> Simply because processors which use this GIC version cannot have more >>>> than 8 cores. >>>> >>>> That means num_possible_cpus() <= 8 so the cpumask handed in cannot have >>>> bits >= 8 set. Ergo for_each_cpu() can't return a bit which is >= 8. [...] >>> 33de0aa4bae98, the affinity that the driver gets is narrowed to what >>> is actually *online*. >> >> What I haven't quite understood from my (cursory) looking at the GICv2 >> spec (and the GIC driver) is why only one CPU (with a lowest #) is selected >> from *mask_val before writing to GICD_GIC_DIST_TARGET, while the spec holds >> that an IRQ can be forwarded to any set of 8 CPU interfaces... > > Because on all the existing implementations, having more than a single > target in GICD_ITARGETSRn results in all the targeted CPUs to be > interrupted, with the guarantee that only one will see the actual > interrupt (the read from GICC_IAR returns a value that is not 0x3ff), > and everyone else will only see a spurious interrupt (0x3ff). This is > because the distributor does not track which CPU is actually in a > position to handle the interrupt. Ah! Previously I was only familiar with the x86 {I/O,local} APICs, and my recollection was that they somehow manage to negotiate that matter over the APIC bus... but my knowledge it pretty dated, I've had almost no part in the x86 Linux development. :-( > While this can be, under limited circumstances, beneficial from an > interrupt servicing latency, it is always bad from a global throughput > perspective. You end-up thrashing CPU caches, generating odd latencies > in unsuspecting code, and in general with disappointing performance. > > Thankfully, GIC (v1/v2) is a dead horse, and v3 doesn't have this > particular problem (it replaced it with a bigger one in the form of > 1:n distribution). GICv2 spec does talk about 1-N and N-N interrupt handling modes; at the same time, I can't find such words in the GICv3/4 spec. :-) Thanks a lot for your explanations! Despite being involved in the ARM dev't since 2008, I have a limited knowledge of the ARM low-level things... :-( > M. MBR, Sergey