From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24841 invoked by alias); 12 Sep 2013 16:05:57 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 24831 invoked by uid 89); 12 Sep 2013 16:05:57 -0000 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 12 Sep 2013 16:05:57 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RDNS_NONE,SPF_HELO_FAIL autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1VK9Oy-0006BH-Mi from joseph_myers@mentor.com ; Thu, 12 Sep 2013 09:05:52 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Sep 2013 09:05:52 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Thu, 12 Sep 2013 17:05:50 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1VK9Ou-0000V9-Vy; Thu, 12 Sep 2013 16:05:49 +0000 Date: Thu, 12 Sep 2013 16:20:00 -0000 From: "Joseph S. Myers" To: Marek Polacek CC: GCC Patches , Jakub Jelinek , Jason Merrill Subject: Re: [PATCH][ubsan] Add VLA bound instrumentation In-Reply-To: Message-ID: References: <20130912122655.GN23899@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-09/txt/msg00951.txt.bz2 On Thu, 12 Sep 2013, Joseph S. Myers wrote: > (Actually, I believe sizes (in bytes) greater than target PTRDIFF_MAX, not > just SIZE_MAX, should be caught, because pointer subtraction cannot work > reliably with larger objects. So it's not just when the size or > multiplication overflow size_t, but when they overflow ptrdiff_t.) And, to add a bit more to the list of possible ubsan features (is this todo list maintained anywhere?), even if the size is such that operations on the array are in principle defined, it's possible that adjusting the stack pointer by too much may take it into other areas of memory and so cause stack overflow that doesn't get detected by the kernel. So maybe ubsan should imply -fstack-check or similar. Everything about VLA checking - checks on the size being positive and on it not being larger than PTRDIFF_MAX, and on avoiding stack overflow - applies equally to alloca: calls to alloca should also be instrumented. (But I think alloca (0) is valid.) -- Joseph S. Myers joseph@codesourcery.com