From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31626 invoked by alias); 6 Nov 2012 17:22:36 -0000 Received: (qmail 31617 invoked by uid 22791); 6 Nov 2012 17:22:33 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-pb0-f47.google.com (HELO mail-pb0-f47.google.com) (209.85.160.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 06 Nov 2012 17:22:25 +0000 Received: by mail-pb0-f47.google.com with SMTP id ro12so513493pbb.20 for ; Tue, 06 Nov 2012 09:22:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=pY/GH0SR/cNehJPaX+HgrvpIo/uG0L3NVQCFE4p3CkI=; b=XNUJVAu7Mwl+EPS/B4VhcQVYJ85bhIRw5Fjd/0NVVKQBFQfUW7i4YR1sqtRbBzIjVD 7Jx5WtioSfB5/W59MMxf0VDfuwe2ZhcT/UOHZV0Byqc/PfiTQQsoOL5WMQ2HMVZYeWKo ZCxkoItb5s9CMbxPmyREEUKQNVz5LHaVNZ9MyL5ttF5qamWGrU+vKGqSV4D78p68TZy7 mx2YtEBCtbr6NsTn2gmdkRXnqktUgDeZQdFGXh3AzMWvPbey2Cjjemm0QSgtLVXj6vM9 ry4w7uphVFZfZUUmSf71DqHDsOcmOzUUI6tK3bjkIaDs/V+hARFrGd6nanLIS14gUqJE 705w== Received: by 10.68.222.234 with SMTP id qp10mr5189371pbc.127.1352222544669; Tue, 06 Nov 2012 09:22:24 -0800 (PST) Received: from dhcp-172-19-69-220.mtv.corp.google.com ([2620:0:1000:3304:580d:61e8:e1cd:466]) by mx.google.com with ESMTPS id ok3sm12634462pbb.11.2012.11.06.09.22.22 (version=SSLv3 cipher=OTHER); Tue, 06 Nov 2012 09:22:23 -0800 (PST) Message-ID: <5099474D.6050609@google.com> Date: Tue, 06 Nov 2012 17:22:00 -0000 From: Diego Novillo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Dodji Seketeli CC: gcc-patches@gcc.gnu.org, jakub@redhat.com, wmi@google.com, davidxl@google.com, konstantin.s.serebryany@gmail.com Subject: Re: [PATCH 05/10] Implement protection of stack variables References: <1351799566-31447-1-git-send-email-dodji@redhat.com> <87pq3v8vmi.fsf@redhat.com> <871ugb8vax.fsf_-_@redhat.com> In-Reply-To: <871ugb8vax.fsf_-_@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmAewQJbRE4kpHpcMDMQI0uUMLQgZc2KLQpdBeg1//z8hcfbc/0O05xkkakbIC1be212AKQr0xuvnqVIvohOGhmeSvKoqmTaQHyHFFXtugBxaigz39s4PjDPfKkrDWsfq0LlrxMMF5NnfWGbCi9H7cQ0yn+VP+LJDGLjHIS2nDtjk7Y3g2zxrVCQpSoLlTDDf2T2BYr X-IsSubscribed: yes 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 X-SW-Source: 2012-11/txt/msg00538.txt.bz2 On 2012-11-02 16:00 , Dodji Seketeli wrote: > This patch implements the protection of stack variables. > > To understand how this works, lets look at this example on x86_64 > where the stack grows downward: > > int > foo () > { > char a[23] = {0}; > int b[2] = {0}; > > a[5] = 1; > b[1] = 2; > > return a[5] + b[1]; > } > > For this function, the stack protected by asan will be organized as > follows, from the top of the stack to the bottom: > > Slot 1/ [red zone of 32 bytes called 'RIGHT RedZone'] > > Slot 2/ [24 bytes for variable 'a'] > > Slot 3/ [8 bytes of red zone, that adds up to the space of 'a' to make > the next slot be 32 bytes aligned; this one is called Partial > Redzone; this 32 bytes alignment is an asan constraint] > > Slot 4/ [red zone of 32 bytes called 'Middle RedZone'] > > Slot 5/ [8 bytes for variable 'b'] > > Slot 6/ [24 bytes of Partial Red Zone (similar to slot 3] > > Slot 7/ [32 bytes of Red Zone at the bottom of the stack, called 'LEFT > RedZone'] > > [A cultural question I've kept asking myself is Why has address > sanitizer authors called these red zones (LEFT, MIDDLE, RIGHT) > instead of e.g, (BOTTOM, MIDDLE, TOP). Maybe they can step up and > educate me so that I get less confused in the future. :-)] I believe they layout the stack from right to left (top is to the right). Feels like reading a middle earth map. Kostya, is my recollection correct? > The 32 bytes of LEFT red zone at the bottom of the stack can be > decomposed as such: > > 1/ The first 8 bytes contain a magical asan number that is always > 0x41B58AB3. > > 2/ The following 8 bytes contains a pointer to a string (to be > parsed at runtime by the runtime asan library), which format is > the following: > > " > (<32-bytes-aligned-offset-in-bytes-of-variable> > ){n} " > > where '(...){n}' means the content inside the parenthesis occurs 'n' > times, with 'n' being the number of variables on the stack. > > 3/ The following 16 bytes of the red zone have no particular > format. > > The shadow memory for that stack layout is going to look like this: > > - content of shadow memory 8 bytes for slot 7: 0xFFFFFFFFF1F1F1F1. > The F1 byte pattern is a magic number called > ASAN_STACK_MAGIC_LEFT and is a way for the runtime to know that > the memory for that shadow byte is part of a the LEFT red zone > intended to seat at the bottom of the variables on the stack. > > - content of shadow memory 8 bytes for slots 6 and 5: > 0xFFFFFFFFF4F4F400. The F4 byte pattern is a magic number > called ASAN_STACK_MAGIC_PARTIAL. It flags the fact that the > memory region for this shadow byte is a PARTIAL red zone > intended to pad a variable A, so that the slot following > {A,padding} is 32 bytes aligned. > > Note that the fact that the least significant byte of this > shadow memory content is 00 means that 8 bytes of its > corresponding memory (which corresponds to the memory of > variable 'b') is addressable. > > - content of shadow memory 8 bytes for slot 4: 0xFFFFFFFFF2F2F2F2. > The F2 byte pattern is a magic number called > ASAN_STACK_MAGIC_MIDDLE. It flags the fact that the memory > region for this shadow byte is a MIDDLE red zone intended to > seat between two 32 aligned slots of {variable,padding}. > > - content of shadow memory 8 bytes for slot 3 and 2: > 0xFFFFFFFFF4000000. This represents is the concatenation of > variable 'a' and the partial red zone following it, like what we > had for variable 'b'. The least significant 3 bytes being 00 > means that the 3 bytes of variable 'a' are addressable. > > - content of shadow memory 8 bytes for slot 1: 0xFFFFFFFFF3F3F3F3. > The F3 byte pattern is a magic number called > ASAN_STACK_MAGIC_RIGHT. It flags the fact that the memory > region for this shadow byte is a RIGHT red zone intended to seat > at the top of the variables of the stack. > This is a great summary. Please put it at the top of asan.c or in some other prominent place. > - offset = alloc_stack_frame_space (stack_vars[i].size, alignb); > + if (flag_asan && pred) > + { > + HOST_WIDE_INT prev_offset = frame_offset; > + tree repr_decl = NULL_TREE; > + > + offset > + = alloc_stack_frame_space (stack_vars[i].size > + + ASAN_RED_ZONE_SIZE, > + MAX (alignb, ASAN_RED_ZONE_SIZE)); > + VEC_safe_push (HOST_WIDE_INT, heap, data->asan_vec, > + prev_offset); > + VEC_safe_push (HOST_WIDE_INT, heap, data->asan_vec, > + offset + stack_vars[i].size); Oh, gee, thanks. More VEC() code for me to convert ;) The patch is OK. Diego.