From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
To: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Florian Weimer <fw@deneb.enyo.de>,
kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, oleg@redhat.com,
x86@kernel.org, libffi-discuss@sourceware.org, luto@kernel.org,
David.Laight@ACULAB.COM, mark.rutland@arm.com, mic@digikod.net,
pavel@ucw.cz
Subject: Re: [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor
Date: Wed, 23 Sep 2020 14:17:30 -0500 [thread overview]
Message-ID: <a742b9cd-4ffb-60e0-63b8-894800009700@linux.microsoft.com> (raw)
In-Reply-To: <20200923091125.GB1240819@rani.riverdale.lan>
On 9/23/20 4:11 AM, Arvind Sankar wrote:
> For libffi, I think the proposed standard trampoline won't actually
> work, because not all ABIs have two scratch registers available to use
> as code_reg and data_reg. Eg i386 fastcall only has one, and register
> has zero scratch registers. I believe 32-bit ARM only has one scratch
> register as well.
The trampoline is invoked as a function call in the libffi case. Any
caller saved register can be used as code_reg, can it not? And the
scratch register is needed only to jump to the code. After that, it
can be reused for any other purpose.
However, for ARM, you are quite correct. There is only one scratch
register. This means that I have to provide two types of trampolines:
- If an architecture has enough scratch registers, use the currently
defined trampoline.
- If the architecture has only one scratch register, but has PC-relative
data references, then embed the code address at the bottom of the
trampoline and access it using PC-relative addressing.
Thanks for pointing this out.
Madhavan
next prev parent reply other threads:[~2020-09-23 19:17 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200916150826.5990-1-madvenka@linux.microsoft.com>
2020-09-17 1:04 ` Florian Weimer
2020-09-17 15:36 ` Madhavan T. Venkataraman
2020-09-17 15:57 ` Madhavan T. Venkataraman
2020-09-17 16:01 ` Florian Weimer
2020-09-23 1:46 ` Arvind Sankar
2020-09-23 9:11 ` Arvind Sankar
2020-09-23 19:17 ` Madhavan T. Venkataraman [this message]
2020-09-23 19:51 ` Arvind Sankar
2020-09-23 23:51 ` Madhavan T. Venkataraman
2020-09-24 20:23 ` Madhavan T. Venkataraman
2020-09-24 20:52 ` Florian Weimer
2020-09-25 22:22 ` Madhavan T. Venkataraman
2020-09-27 18:25 ` Madhavan T. Venkataraman
2020-10-03 9:43 ` Jay K
2020-09-24 22:13 ` Pavel Machek
2020-09-24 23:43 ` Arvind Sankar
2020-09-25 22:44 ` Madhavan T. Venkataraman
2020-09-26 15:55 ` Arvind Sankar
2020-09-27 17:59 ` Madhavan T. Venkataraman
2020-09-23 2:50 ` Jay K
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=a742b9cd-4ffb-60e0-63b8-894800009700@linux.microsoft.com \
--to=madvenka@linux.microsoft.com \
--cc=David.Laight@ACULAB.COM \
--cc=fw@deneb.enyo.de \
--cc=kernel-hardening@lists.openwall.com \
--cc=libffi-discuss@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mic@digikod.net \
--cc=nivedita@alum.mit.edu \
--cc=oleg@redhat.com \
--cc=pavel@ucw.cz \
--cc=x86@kernel.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).