public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
From: "Carlos O'Donell" <carlos@redhat.com>
To: Will Newton <will.newton@linaro.org>, libc-ports@sourceware.org
Cc: Patch Tracking <patches@linaro.org>
Subject: Re: [PATCH] ARM: Don't apply pointer encryption to the frame pointer
Date: Fri, 13 Dec 2013 15:57:00 -0000	[thread overview]
Message-ID: <52AB2E4B.50708@redhat.com> (raw)
In-Reply-To: <52A74F24.8000805@linaro.org>

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  <will.newton@linaro.org>
> 
> 	* 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.

      parent reply	other threads:[~2013-12-13 15:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-10 17:28 Will Newton
2013-12-10 18:07 ` Joseph S. Myers
2013-12-10 18:57   ` Carlos O'Donell
2013-12-10 20:05     ` Will Newton
2013-12-10 20:11       ` Carlos O'Donell
2013-12-13 15:57 ` Carlos O'Donell [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52AB2E4B.50708@redhat.com \
    --to=carlos@redhat.com \
    --cc=libc-ports@sourceware.org \
    --cc=patches@linaro.org \
    --cc=will.newton@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).