From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2423 invoked by alias); 13 Dec 2013 15:57:03 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 2412 invoked by uid 89); 13 Dec 2013 15:57:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com 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; Fri, 13 Dec 2013 15:57:02 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rBDFv0PG024595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Dec 2013 10:57:00 -0500 Received: from [10.3.113.84] (ovpn-113-84.phx2.redhat.com [10.3.113.84]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rBDFuxfk013586; Fri, 13 Dec 2013 10:56:59 -0500 Message-ID: <52AB2E4B.50708@redhat.com> Date: Fri, 13 Dec 2013 15:57:00 -0000 From: "Carlos O'Donell" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Will Newton , libc-ports@sourceware.org CC: Patch Tracking Subject: Re: [PATCH] ARM: Don't apply pointer encryption to the frame pointer References: <52A74F24.8000805@linaro.org> In-Reply-To: <52A74F24.8000805@linaro.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00019.txt.bz2 On 12/10/2013 12:28 PM, Will Newton wrote: > > The frame pointer register is rarely used for that purpose on ARM and > applications that look at the contents of the jmp_buf may be relying > on reading the value. Ruby uses the contents of jmp_buf to find the > root set for garbage collection so relies on this pointer value being > unencrypted. > > ports/ChangeLog.arm: > > 2013-12-10 Will Newton > > * sysdeps/arm/__longjmp.S: Don't apply pointer encryption > to fp register. > * sysdeps/arm/setjmp.S: Likewise. > * sysdeps/arm/include/bits/setjmp.h (JMP_BUF_REGLIST): Add > fp to register list, remove a4. > * sysdeps/unix/sysv/linux/arm/sysdep.h: (PTR_MANGLE_LOAD): > New macro. This looks good to me. I agree that because fp might not be used for a frame pointer, and the AEABI doesn't mandate it, that it might have useful required information that the ruby GC might need. So while ruby is wrong in inspecting jmp_buf, we're actually encrypting a general register which ruby might need to to scan to correctly support dynamic GC. As David Miller points out this structure might have been on the stack and the gc would be scanning the stack looking for valid pointers and need this information. Cheers, Carlos.