From: Florian Weimer <fweimer@redhat.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: gnu-gabi@sourceware.org,
IA32 System V Application Binary Interface
<ia32-abi@googlegroups.com>,
"x86-64-abi@googlegroups.com" <x86-64-abi@googlegroups.com>
Subject: Re: RFC: Update x86 psABI to support shadow stac
Date: Sun, 01 Jan 2017 00:00:00 -0000 [thread overview]
Message-ID: <53356291-bb6d-3a69-3dc7-4a1f011942bd@redhat.com> (raw)
In-Reply-To: <CAMe9rOqEDh=xhGBOYaqek2LsV8=UxE9VB2UUEsRx5yozEKPrsw@mail.gmail.com>
On 06/22/2017 03:01 PM, H.J. Lu wrote:
> On Thu, Jun 22, 2017 at 5:51 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 06/21/2017 05:25 PM, H.J. Lu wrote:
>>> GNU_PROPERTY_X86_FEATURE_1_SHSTK is set on output only if it is set on
>>> all relocatable inputs, which means that the C library must be compiled
>>> with SHSTK-enabled compiler.
>>
>> I don't think this is sufficiently detailed for an ABI specification.
>> It needs to say what an SHSTK-enabled compiler does.
>
> Compilers just need to make return address popped from shadow
> stack match return address popped from normal stack.
Nothing else? Would a writable GOT still be fine?
The responsibilities for compliance are split between caller and callee,
which can live in different shared objects. I think it would be prudent
to formulate the requirement in such a way that compliance can be
checked by looking at one DSO in isolation.
Is there a requirement that the return address is popped from the same
stack location where it was pushed by the call instruction? Or could
you return with an elevated stack pointer if you copied the address first?
Thanks,
Florian
next prev parent reply other threads:[~2017-06-22 13:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-01 0:00 H.J. Lu
2017-01-01 0:00 ` Florian Weimer
2017-01-01 0:00 ` H.J. Lu
2017-01-01 0:00 ` Florian Weimer [this message]
2017-01-01 0:00 ` H.J. Lu
2017-01-01 0:00 ` Shanbhogue, Vedvyas
2017-01-01 0:00 ` Florian Weimer
2017-01-01 0:00 ` H.J. Lu
2017-01-01 0:00 ` Florian Weimer
2017-01-01 0:00 ` H.J. Lu
2017-01-01 0:00 ` Florian Weimer
2017-01-01 0:00 ` H.J. Lu
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=53356291-bb6d-3a69-3dc7-4a1f011942bd@redhat.com \
--to=fweimer@redhat.com \
--cc=gnu-gabi@sourceware.org \
--cc=hjl.tools@gmail.com \
--cc=ia32-abi@googlegroups.com \
--cc=x86-64-abi@googlegroups.com \
/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).