public inbox for libffi-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Anthony Green <green@moxielogic.com>
To: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
Cc: libffi-discuss <libffi-discuss@sourceware.org>,
	fweimer@redhat.com,  DJ Delorie <dj@redhat.com>
Subject: Re: [RFC PATCH v3 0/5] Libffi Static Trampolines
Date: Wed, 27 Jan 2021 13:00:48 -0500	[thread overview]
Message-ID: <CACxje5_WshA6Zi6pBjeCFChfw5zFr+kS763aX0Te5SC2_WFmtw@mail.gmail.com> (raw)
In-Reply-To: <849643ba-5c3e-31e6-b784-d0fc2345ce00@linux.microsoft.com>

Thanks, Madhaven.   I think I understand now.   Are these statements true?:

(a) These patches implement trampoline tables, similar to what is
implemented in the iOS port.  This hardens the library by eliminating the
requirement for writable executable memory.
(b) These patches expose a new public API for hardened trampolines.  (a)
uses (b), but doesn't require that (b) be public.
(c) We can release libffi with (a) and not (b).

Is this correct?

AG

On Wed, Jan 27, 2021 at 12:20 PM Madhavan T. Venkataraman <
madvenka@linux.microsoft.com> wrote:

>
>
> On 1/26/21 5:41 PM, Anthony Green wrote:
> > Madhaven,
> >
> >   Thank you for your continued efforts here.
> >
> > On Fri, Jan 15, 2021 at 1:47 PM <madvenka@linux.microsoft.com <mailto:
> madvenka@linux.microsoft.com>> wrote:
> >
> >     Trampoline API
> >     ==============
> >
> >     There is a lot of dynamic code out there. They all have the same
> security
> >     issue. Dynamic code can be re-written into static code provided the
> data
> >     required by the static code can be passed to it just like we pass
> the closure
> >     pointer to an ABI handler.
> >
> >     So, the same trampoline functions used by libffi internally need to
> be
> >     made available to the rest of the world in the form of an API. The
> >     following API has been defined in this solution:
> >
> >
> >
> > I need a better explanation around why this new API is required, and
> this new capability isn't just an implementation detail supporting the old
> API.
> >
>
> Example 1
> =========
>
> Let us say that an application or a library has a simple trampoline - load
> a value or
> an address in a register or the stack and transfer control to some target
> function.
> It would have dynamic code to do that just like libffi currently does.
>
> Dynamic code has a security issue as I have explained in the cover letter.
> It needs
> to be loaded in an executable page. A clever hacker may be able to inject
> his code
> in that page. To prevent that, dynamic code has to be converted into
> static code
> so that it is in a read-only text segment.
>
> I have solved this problem for libffi and I have provided statically
> defined trampolines.
>
> The application or library that is currently using dynamic code for its
> trampoline could
> instead use the libffi API and replace its trampoline. This would
> eliminate dynamic code
> from that application or library and make it more secure.
>
> The only thing is that the target function should now expect its data in
> the libffi
> designated scratch register instead of whatever it was using. This is
> trivial to do.
>
> Example 2
> ==========
>
> Let us say that an application or library uses something more complicated
> than the
> libffi trampoline. For example, a piece of dynamic code that unmarshalls
> parameters
> from a structure and calls a target function.
>
> The application developer is interested in eliminating this piece of
> dynamic code
> for security purposes. The developer could rewrite the dynamic code into
> static
> code. The only thing is that the structure pointer needs to be passed to
> the static
> code. Either the application developer can write his own code (using
> PC-relative
> accesses, etc) to pass data. Or, he can use the libffi API to do it.
>
> So, the only effort for the developer/maintainer of the
> application/library is to
> rewrite the unmarshalling dynamic code into static code. That should be
> straight forward.
>
> Example 3
> =========
>
> Let us say that an application or library has a piece of dynamic code to
> perform
> some computation and produce results. It is written as dynamic code because
> the exact set of arguments and the exact computation is known only at
> runtime.
> So, the dynamic code is generated at runtime accordingly. When the code is
> generated, the data needed by the code is embedded in the generated code.
>
> In this case, the developer needs to do a little extra work. E.g.,
>
> - Define a union of structures with each structure defining a particular
>   computation and set of arguments.
>
> - Write static code to accept a pointer to the union and perform
>   different computations and return results in that union.
>
> - Then, the static code can be invoked using the libffi API and the union
>   pointer can be passed to it.
>
> Summary
> =======
>
> There are a lot of applications that use dynamic code out there. Dynamic
> code
> should be eliminated as far as possible for security purposes.
>
> I believe most of them can be converted to static code by the maintainers.
> All
> they need is a method to pass data to their static code without having to
> implement
> the method themselves. The libffi API provides that.
>
> The libffi API can also be supported easily for multiple architectures so
> that
> applications can use the API in an architecture-independent way.
>
> Is this sufficient justification for the API?
>
> Madhavan
>

  reply	other threads:[~2021-01-27 18:01 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1ef5c7e1c9a6ebb140a476ba555ec955681f4fba>
2021-01-15 18:46 ` madvenka
2021-01-15 18:46   ` [RFC PATCH v3 1/5] " madvenka
2021-01-27  3:31     ` DJ Delorie
2021-01-27 21:51       ` Madhavan T. Venkataraman
2021-01-27 22:15         ` DJ Delorie
2021-01-27 22:43           ` Madhavan T. Venkataraman
2021-01-15 18:46   ` [RFC PATCH v3 2/5] x86: Support for " madvenka
2021-01-27  3:31     ` DJ Delorie
2021-01-28 21:59       ` Madhavan T. Venkataraman
2021-01-28 22:17         ` DJ Delorie
2021-01-28 23:25           ` Madhavan T. Venkataraman
2021-01-29  2:09             ` DJ Delorie
2021-01-29  2:38               ` Madhavan T. Venkataraman
2021-01-29  2:48                 ` DJ Delorie
2021-01-29  3:24                   ` Madhavan T. Venkataraman
2021-01-29  6:07                     ` DJ Delorie
2021-02-01 19:46                 ` DJ Delorie
2021-01-15 18:46   ` [RFC PATCH v3 3/5] i386: " madvenka
2021-01-15 18:46   ` [RFC PATCH v3 4/5] arm64: " madvenka
2021-01-15 18:46   ` [RFC PATCH v3 5/5] arm: " madvenka
2021-01-26 23:41   ` [RFC PATCH v3 0/5] Libffi " Anthony Green
2021-01-27 17:20     ` Madhavan T. Venkataraman
2021-01-27 18:00       ` Anthony Green [this message]
2021-01-27 19:45         ` Madhavan T. Venkataraman
2021-01-28 14:21           ` Anthony Green
2021-01-28 17:01             ` Madhavan T. Venkataraman
2021-02-05 18:20               ` Madhavan T. Venkataraman
2021-02-05 18:46                 ` Anthony Green
2021-02-05 19:38                   ` Madhavan T. Venkataraman
2021-02-07 16:09                     ` Madhavan T. Venkataraman

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=CACxje5_WshA6Zi6pBjeCFChfw5zFr+kS763aX0Te5SC2_WFmtw@mail.gmail.com \
    --to=green@moxielogic.com \
    --cc=dj@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=libffi-discuss@sourceware.org \
    --cc=madvenka@linux.microsoft.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).