Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Solar Designer <solar@openwall.com>
Cc: Pavel Machek <pavel@ucw.cz>,
	madvenka@linux.microsoft.com,
	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, luto@kernel.org, David.Laight@ACULAB.COM,
	mark.rutland@arm.com, mic@digikod.net,
	Rich Felker <dalias@libc.org>
Subject: Re: [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor
Date: Wed, 23 Sep 2020 16:39:31 +0200	[thread overview]
Message-ID: <87wo0ko8v0.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <20200923091456.GA6177@openwall.com> (Solar Designer's message of "Wed, 23 Sep 2020 11:14:57 +0200")

* Solar Designer:

> While I share my opinion here, I don't mean that to block Madhavan's
> work.  I'd rather defer to people more knowledgeable in current userland
> and ABI issues/limitations and plans on dealing with those, especially
> to Florian Weimer.  I haven't seen Florian say anything specific for or
> against Madhavan's proposal, and I'd like to.  (Have I missed that?)

There was a previous discussion, where I provided feedback (not much
different from the feedback here, given that the mechanism is mostly the
same).

I think it's unnecessary for the libffi use case.  Precompiled code can
be loaded from disk because the libffi trampolines are so regular.  On
most architectures, it's not even the code that's patched, but some of
the data driving it, which happens to be located on the same page due to
a libffi quirk.

The libffi use case is a bit strange anyway: its trampolines are
type-generic, and the per-call adjustment is data-driven.  This means
that once you have libffi in the process, you have a generic
data-to-function-call mechanism available that can be abused (it's even
fully CET compatible in recent versions).  And then you need to look at
the processes that use libffi.  A lot of them contain bytecode
interpreters, and those enable data-driven arbitrary code execution as
well.  I know that there are efforts under way to harden Python, but
it's going to be tough to get to the point where things are still
difficult for an attacker once they have the ability to make mprotect
calls.

It was pointed out to me that libffi is doing things wrong, and the
trampolines should not be type-generic, but generated so that they match
the function being called.  That is, the marshal/unmarshal code would be
open-coded in the trampoline, rather than using some generic mechanism
plus run-time dispatch on data tables describing the function type.
That is a very different design (and typically used by compilers (JIT or
not JIT) to implement native calls).  Mapping some code page with a
repeating pattern would no longer work to defeat anti-JIT measures
because it's closer to real JIT.  I don't know if kernel support could
make sense in this context, but it would be a completely different
patch.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill


  parent reply	other threads:[~2020-09-23 14:39 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <210d7cd762d5307c2aa1676705b392bd445f1baa>
2020-09-16 15:08 ` madvenka
2020-09-16 15:08   ` [PATCH v2 1/4] [RFC] fs/trampfd: Implement the trampoline file descriptor API madvenka
2020-09-16 15:08   ` [PATCH v2 2/4] [RFC] x86/trampfd: Provide support for the trampoline file descriptor madvenka
2020-09-16 15:08   ` [PATCH v2 3/4] [RFC] arm64/trampfd: " madvenka
2020-09-16 15:08   ` [PATCH v2 4/4] [RFC] arm/trampfd: " madvenka
2020-09-17  1:04   ` [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor 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
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-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-22 21:53 ` madvenka
2020-09-22 21:53   ` [PATCH v2 1/4] [RFC] fs/trampfd: Implement the trampoline file descriptor API madvenka
2020-09-22 21:53   ` [PATCH v2 2/4] [RFC] x86/trampfd: Provide support for the trampoline file descriptor madvenka
2020-09-22 21:53   ` [PATCH v2 3/4] [RFC] arm64/trampfd: " madvenka
2020-09-22 21:53   ` [PATCH v2 4/4] [RFC] arm/trampfd: " madvenka
2020-09-22 21:54   ` [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor Madhavan T. Venkataraman
2020-09-23  8:14   ` Pavel Machek
2020-09-23  9:14     ` Solar Designer
2020-09-23 14:11       ` Solar Designer
2020-09-23 15:18         ` Pavel Machek
2020-09-23 18:00           ` Solar Designer
2020-09-23 18:21             ` Solar Designer
2020-09-23 14:39       ` Florian Weimer [this message]
2020-09-23 18:09         ` Andy Lutomirski
2020-09-23 18:11         ` Solar Designer
2020-09-23 18:49           ` Arvind Sankar
2020-09-23 23:53         ` Madhavan T. Venkataraman
2020-09-23 19:41       ` Madhavan T. Venkataraman
2020-09-23 18:10     ` James Morris
2020-09-23 18:32     ` Madhavan T. Venkataraman
2020-09-23  8:42   ` Pavel Machek
2020-09-23 18:56     ` Madhavan T. Venkataraman
2020-09-23 20:51       ` Pavel Machek
2020-09-23 23:04         ` Madhavan T. Venkataraman
2020-09-24 16:44         ` Mickaël Salaün
2020-09-24 22:05           ` Pavel Machek
2020-09-25 10:12             ` Mickaël Salaün

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=87wo0ko8v0.fsf@oldenburg2.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=dalias@libc.org \
    --cc=kernel-hardening@lists.openwall.com \
    --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=madvenka@linux.microsoft.com \
    --cc=mark.rutland@arm.com \
    --cc=mic@digikod.net \
    --cc=oleg@redhat.com \
    --cc=pavel@ucw.cz \
    --cc=solar@openwall.com \
    --cc=x86@kernel.org \
    --subject='Re: [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor' \
    /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

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 NNTP newsgroup(s).