From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id 8FAA03858D35 for ; Tue, 14 May 2024 19:50:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8FAA03858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=chromium.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8FAA03858D35 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::62b ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715716257; cv=none; b=vAPJUPq0PHSj5SdT1EDy5WcI5vlS2nyzNL4q9Nue/A/MwpGgNL1vSgSr/kF9QU3cyxUUZmmxVvBARN9E0pzYxlN/2serWFLfdxhf+UD9Ps4IlZH9xx2k+foihS+V+lndRuruscKrNqdY0s222PpLTsZYefHNXVWhLFZ2JFL+P9w= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715716257; c=relaxed/simple; bh=LfA+HvP9O6XKyxdhEcO3hxWIGyFqBO9FrEZwk99KqIM=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=NrkDgMvQUdD2ThGicI0loLvWWMY0vURHc/CP6aDBkYvsC3xOqcTFANysMCdwjjyIIJ6ybIRY4XJ02gaRQ255Jw/g+h5twNNWiEQjankck1SHlnUfQ+Mgc8bUaU4i5DxyZHc/poLC6ZBjeCskK89J7sGCLnIBafMwuiDFGZOmrqA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x62b.google.com with SMTP id d9443c01a7336-1ecd9a81966so49222265ad.0 for ; Tue, 14 May 2024 12:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1715716253; x=1716321053; darn=gcc.gnu.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=hH7UYJOP7soju+P8P9iA/0VNcp/PTR0AnEDymjAbxLE=; b=l2UQgpZChMeZiPL4A8kxwfppQ1Yn1qLhDjKCiX87UrWaVKZdFM3rMYRHs9sBbN7aQi 08yu1q9r86imzDbYHH+3/ocM+bQfOfok9kp1Jnvovf18re/M6z/z+HzYNDEVfBJDoDgJ pN/FRCXDGTXvtav4Vemd0fFYvvl3TkNqtTeHk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715716253; x=1716321053; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hH7UYJOP7soju+P8P9iA/0VNcp/PTR0AnEDymjAbxLE=; b=KU1GeDyzG+4UKEUJ/95Ay/M8OUzou+8rOAHtKfYDyhLSvqp0EnQ2wMiB9y35wwbKqN nxK6ht9sYLvzreeboMxCFX5iSmw9fyzLsSNU4oqyv5hR/86s1zINilr76EIvr0X4IzpG HPr739RQ5YK+CiJfq2Rj9v29mS3vSGx9qso6ppttoqxagiiRbDQsjm+Voo9D3rE5e8qy 9qdNTgiDIDzUzqxU1VLSjMBHCNOKX87GN8/tCnwd+xJSu5BT3Erp+dtgW7gt5AKt3Whr kR6TT68ZGftQHvFmz6wfkaL6MiQ++b/7JYvFC2UP0YvO/517nFF/5Lg2DRcmTOm8lh2a tQyA== X-Forwarded-Encrypted: i=1; AJvYcCVItzFZYAXy/TNMTqIvXwB+DrzYFhyu1BLwcb9QyWpXOSlx0t/kO9I9b04Ie3fIQdik1h7dWp1Ead3eHpaeeU4zBslEojUCQQ== X-Gm-Message-State: AOJu0Yy5EU+zQAAdljBroFGnsVPdHptBAW488WsMWxMkCnyH0n5zVKM6 AqERoFPo850APt1vyDEx8X/C0cLF0C90xP3Mnhl//RMttcY7WcJu4IYWLJkrIfuSDARGXWtawP8 = X-Google-Smtp-Source: AGHT+IFjNeCTJOpRJyUhviXxLwIpFUK8ZyFYbpG8lzqJNPD4U2ai9zuB/IEqOgm7P6qkw1cJXQGNUw== X-Received: by 2002:a17:902:d2d0:b0:1e4:59a2:d7c1 with SMTP id d9443c01a7336-1eefa58c6ebmr257245605ad.33.1715716252943; Tue, 14 May 2024 12:50:52 -0700 (PDT) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1ef0c256832sm102146645ad.303.2024.05.14.12.50.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 May 2024 12:50:52 -0700 (PDT) Date: Tue, 14 May 2024 12:50:51 -0700 From: Kees Cook To: Qing Zhao Cc: Richard Biener , "gcc-patches@gcc.gnu.org" , "pinskia@gmail.com" , "dmalcolm@redhat.com" Subject: Re: [RFC][PATCH] PR tree-optimization/109071 - -Warray-bounds false positive warnings due to code duplication from jump threading Message-ID: <202405141238.E787A138@keescook> References: <20240513194830.1676938-1-qing.zhao@oracle.com> <35799652-55op-79os-ro61-56094939s0o2@fhfr.qr> <6BB88011-F888-4949-A65D-FDB351128B0F@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6BB88011-F888-4949-A65D-FDB351128B0F@oracle.com> X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, May 14, 2024 at 02:17:16PM +0000, Qing Zhao wrote: > The current major issue with the warning is: the constant index value 4 > is not in the source code, it’s a compiler generated intermediate value > (even though it’s a correct value -:)). Such warning messages confuse > the end-users with information that cannot be connected directly to the > source code. Right -- this "4" comes from -fsanitize=array-bounds (in "warn but continue" mode). Now, the minimized PoC shows a situation that triggers the situation, but I think it's worth looking at the original code that caused this false positive: for (i = 0; i < sg->num_entries; i++) { gce = &sg->gce[i]; The issue here is that sg->num_entries has already been bounds-checked in a separate function. As a result, the value range tracking for "i" here is unbounded. Enabling -fsanitize=array-bounds means the sg->gce[i] access gets instrumented, and suddenly "i" gains an implicit range, induced by the sanitizer. (I would point out that this is very similar to the problems we've had with -fsanitize=shift[1][2]: the sanitizer induces a belief about a given variable's range this isn't true.) Now, there is an argument to be made that the original code should be doing: for (i = 0; i < 4 && i < sg->num_entries; i++) { But this is: a) logically redundant (Linux maintainers don't tend to like duplicating their range checking) b) a very simple case The point of the sanitizers is to catch "impossible" situations at run-time for the cases where some value may end up out of range. Having it _induce_ a range on the resulting code makes no sense. Could we, perhaps, have sanitizer code not influence the value range tracking? That continues to look like the root cause for these things. -Kees [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306 -- Kees Cook