From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9868 invoked by alias); 12 Sep 2013 16:29:07 -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 9858 invoked by uid 89); 12 Sep 2013 16:29:07 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 12 Sep 2013 16:29:07 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r8CGT14k009181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Sep 2013 12:29:02 -0400 Received: from redhat.com (ovpn-116-91.ams2.redhat.com [10.36.116.91]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r8CGSvBa022457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 12 Sep 2013 12:29:00 -0400 Date: Thu, 12 Sep 2013 17:15:00 -0000 From: Marek Polacek To: "Joseph S. Myers" Cc: GCC Patches , Jakub Jelinek , Jason Merrill Subject: Re: [PATCH][ubsan] Add VLA bound instrumentation Message-ID: <20130912162857.GQ23899@redhat.com> References: <20130912122655.GN23899@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-SW-Source: 2013-09/txt/msg00955.txt.bz2 On Thu, Sep 12, 2013 at 04:05:48PM +0000, Joseph S. Myers wrote: > 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 No, I don't have such a list (at least nothing online/public). > 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. Works for me. > 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.) Yes, good idea. I've just checked and clang doesn't check the size passed to alloca, I think it'd be good addition to have it. And yeah - alloca (0) seems to be valid; when expanding __builtin_alloca we call allocate_dynamic_stack_space and that contains /* If we're asking for zero bytes, it doesn't matter what we point to since we can't dereference it. But return a reasonable address anyway. */ if (size == const0_rtx) return virtual_stack_dynamic_rtx; Thanks, Marek