From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: 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
Subject: Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor
Date: Fri, 31 Jul 2020 15:08:04 -0500 [thread overview]
Message-ID: <4e96a3f6-1995-404c-ed44-45200a4ee582@linux.microsoft.com> (raw)
In-Reply-To: <20200731180955.GC67415@C02TD0UTHF1T.local>
Thanks for the comments. I will respond to these and your next
email on Monday.
Madhavan
On 7/31/20 1:09 PM, Mark Rutland wrote:
> Hi,
>
> On Tue, Jul 28, 2020 at 08:10:46AM -0500, madvenka@linux.microsoft.com wrote:
>> From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
>> Trampoline code is placed either in a data page or in a stack page. In
>> order to execute a trampoline, the page it resides in needs to be mapped
>> with execute permissions. Writable pages with execute permissions provide
>> an attack surface for hackers. Attackers can use this to inject malicious
>> code, modify existing code or do other harm.
> For the purpose of below, IIUC this assumes the adversary has an
> arbitrary write.
>
>> To mitigate this, LSMs such as SELinux may not allow pages to have both
>> write and execute permissions. This prevents trampolines from executing
>> and blocks applications that use trampolines. To allow genuine applications
>> to run, exceptions have to be made for them (by setting execmem, etc).
>> In this case, the attack surface is just the pages of such applications.
>>
>> An application that is not allowed to have writable executable pages
>> may try to load trampoline code into a file and map the file with execute
>> permissions. In this case, the attack surface is just the buffer that
>> contains trampoline code. However, a successful exploit may provide the
>> hacker with means to load his own code in a file, map it and execute it.
> It's not clear to me what power the adversary is assumed to have here,
> and consequently it's not clear to me how the proposal mitigates this.
>
> For example, if the attack can control the arguments to syscalls, and
> has an arbitrary write as above, what prevents them from creating a
> trampfd of their own?
>
> [...]
>
>> GCC has traditionally used trampolines for implementing nested
>> functions. The trampoline is placed on the user stack. So, the stack
>> needs to be executable.
> IIUC generally nested functions are avoided these days, specifically to
> prevent the creation of gadgets on the stack. So I don't think those are
> relevant as a cased to care about. Applications using them should move
> to not using them, and would be more secure generally for doing so.
>
> [...]
>
>> Trampoline File Descriptor (trampfd)
>> --------------------------
>>
>> I am proposing a kernel API using anonymous file descriptors that
>> can be used to create and execute trampolines with the help of the
>> kernel. In this solution also, the kernel does the work of the trampoline.
> What's the rationale for the kernel emulating the trampoline here?
>
> In ther case of EMUTRAMP this was necessary to work with existing
> application binaries and kernel ABIs which placed instructions onto the
> stack, and the stack needed to remain RW for other reasons. That
> restriction doesn't apply here.
>
> Assuming trampfd creation is somehow authenticated, the code could be
> placed in a r-x page (which the kernel could refuse to add write
> permission), in order to prevent modification. If that's sufficient,
> it's not much of a leap to allow userspace to generate the code.
>
>> The kernel creates the trampoline mapping without any permissions. When
>> the trampoline is executed by user code, a page fault happens and the
>> kernel gets control. The kernel recognizes that this is a trampoline
>> invocation. It sets up the user registers based on the specified
>> register context, and/or pushes values on the user stack based on the
>> specified stack context, and sets the user PC to the requested target
>> PC. When the kernel returns, execution continues at the target PC.
>> So, the kernel does the work of the trampoline on behalf of the
>> application.
>>
>> In this case, the attack surface is the context buffer. A hacker may
>> attack an application with a vulnerability and may be able to modify the
>> context buffer. So, when the register or stack context is set for
>> a trampoline, the values may have been tampered with. From an attack
>> surface perspective, this is similar to Trampoline Emulation. But
>> with trampfd, user code can retrieve a trampoline's context from the
>> kernel and add defensive checks to see if the context has been
>> tampered with.
> Can you elaborate on this: what sort of checks would be applied, and
> how?
>
> Why is this not possible in a r-x user page?
>
> [...]
>
>> - trampfd provides a basic framework. In the future, new trampoline types
>> can be implemented, new contexts can be defined, and additional rules
>> can be implemented for security purposes.
> >From a kernel developer perspective, this reads as "this ABI will become
> more complex", which I think is worrisome.
>
> I'm also worried that this is liable to have nasty interaction with HW
> CFI mechanisms (e.g. PAC+BTI on arm64) either now or in future, and that
> we bake incompatibility into ABI.
>
>> - For instance, trampfd defines an "Allowed PCs" context in this initial
>> work. As an example, libffi can create a read-only array of all ABI
>> handlers for an architecture at build time. This array can be used to
>> set the list of allowed PCs for a trampoline. This will mean that a hacker
>> cannot hack the PC part of the register context and make it point to
>> arbitrary locations.
> I'm not exactly sure what's meant here. Do you mean that this prevents
> userspace from branching into the middle of a trampoline, or that the
> trampfd code prevents where the trampoline itself can branch to?
>
> Both x86 and arm64 have upcoming HW CFI (CET and BTI) to deal with the
> former, and I believe the latter can also be implemented in userspace
> with defensive checks in the trampolines, provided that they are
> protected read-only.
>
>> - An SELinux setting called "exectramp" can be implemented along the
>> lines of "execmem", "execstack" and "execheap" to selectively allow the
>> use of trampolines on a per application basis.
>>
>> - User code can add defensive checks in the code before invoking a
>> trampoline to make sure that a hacker has not modified the context data.
>> It can do this by getting the trampoline context from the kernel and
>> double checking it.
> As above, without examples it's not clear to me what sort of chacks are
> possible nor where they wouild need to be made. So it's difficult to see
> whether that's actually possible or subject to TOCTTOU races and
> similar.
>
>> - In the future, if the kernel can be enhanced to use a safe code
>> generation component, that code can be placed in the trampoline mapping
>> pages. Then, the trampoline invocation does not have to incur a trip
>> into the kernel.
>>
>> - Also, if the kernel can be enhanced to use a safe code generation
>> component, other forms of dynamic code such as JIT code can be
>> addressed by the trampfd framework.
> I don't see why it's necessary for the kernel to generate code at all.
> If the trampfd creation requests can be trusted, what prevents trusting
> a sealed set of instructions generated in userspace?
>
>> - Trampolines can be shared across processes which can give rise to
>> interesting uses in the future.
> This sounds like the use-case of a sealed memfd. Is a sealed executable
> memfd not sufficient?
>
> Thanks,
> Mark.
next prev parent reply other threads:[~2020-07-31 20:08 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <aefc85852ea518982e74b233e11e16d2e707bc32>
2020-07-28 13:10 ` [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor madvenka
2020-07-28 13:10 ` [PATCH v1 1/4] [RFC] fs/trampfd: Implement the trampoline file descriptor API madvenka
2020-07-28 14:50 ` Oleg Nesterov
2020-07-28 14:58 ` Madhavan T. Venkataraman
2020-07-28 16:06 ` Oleg Nesterov
2020-07-28 13:10 ` [PATCH v1 2/4] [RFC] x86/trampfd: Provide support for the trampoline file descriptor madvenka
2020-07-30 9:06 ` Greg KH
2020-07-30 14:25 ` Madhavan T. Venkataraman
2020-07-28 13:10 ` [PATCH v1 3/4] [RFC] arm64/trampfd: " madvenka
2020-07-28 13:10 ` [PATCH v1 4/4] [RFC] arm/trampfd: " madvenka
2020-07-28 15:13 ` [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor David Laight
2020-07-28 16:32 ` Madhavan T. Venkataraman
2020-07-28 17:16 ` Andy Lutomirski
2020-07-28 18:52 ` Madhavan T. Venkataraman
2020-07-29 8:36 ` David Laight
2020-07-29 17:55 ` Madhavan T. Venkataraman
[not found] ` <81d744c0-923e-35ad-6063-8b186f6a153c@linux.microsoft.com>
2020-07-29 5:16 ` Andy Lutomirski
2020-07-28 16:05 ` Casey Schaufler
2020-07-28 16:49 ` Madhavan T. Venkataraman
2020-07-28 17:05 ` James Morris
2020-07-28 17:08 ` Madhavan T. Venkataraman
2020-07-28 17:31 ` Andy Lutomirski
2020-07-28 19:01 ` Madhavan T. Venkataraman
2020-07-29 13:29 ` Florian Weimer
2020-07-30 13:09 ` David Laight
2020-08-02 11:56 ` Pavel Machek
2020-08-03 8:08 ` David Laight
2020-08-03 15:57 ` Madhavan T. Venkataraman
2020-07-30 14:42 ` Madhavan T. Venkataraman
[not found] ` <6540b4b7-3f70-adbf-c922-43886599713a@linux.microsoft.com>
2020-07-30 20:54 ` Andy Lutomirski
2020-07-31 17:13 ` Madhavan T. Venkataraman
2020-07-31 18:31 ` Mark Rutland
2020-08-03 8:27 ` David Laight
2020-08-03 16:03 ` Madhavan T. Venkataraman
2020-08-03 16:57 ` David Laight
2020-08-03 17:00 ` Madhavan T. Venkataraman
2020-08-03 17:58 ` Madhavan T. Venkataraman
2020-08-04 13:55 ` Mark Rutland
2020-08-04 14:33 ` David Laight
2020-08-04 14:44 ` David Laight
2020-08-04 14:48 ` Madhavan T. Venkataraman
2020-08-04 15:46 ` Madhavan T. Venkataraman
2020-08-02 13:57 ` Florian Weimer
2020-08-02 18:54 ` Madhavan T. Venkataraman
2020-08-02 20:00 ` Andy Lutomirski
2020-08-02 22:58 ` Madhavan T. Venkataraman
2020-08-03 18:36 ` Madhavan T. Venkataraman
2020-08-10 17:34 ` Madhavan T. Venkataraman
2020-08-11 21:12 ` Madhavan T. Venkataraman
2020-08-03 8:23 ` David Laight
2020-08-03 15:59 ` Madhavan T. Venkataraman
2020-07-31 18:09 ` Mark Rutland
2020-07-31 20:08 ` Madhavan T. Venkataraman [this message]
2020-08-03 16:57 ` Madhavan T. Venkataraman
2020-08-04 14:30 ` Mark Rutland
2020-08-06 17:26 ` Madhavan T. Venkataraman
2020-08-08 22:17 ` Pavel Machek
2020-08-11 12:41 ` Madhavan T. Venkataraman
2020-08-11 13:08 ` Pavel Machek
2020-08-11 15:54 ` Madhavan T. Venkataraman
2020-08-12 10:06 ` Mark Rutland
2020-08-12 18:47 ` Madhavan T. Venkataraman
2020-08-19 18:53 ` Mickaël Salaün
2020-09-01 15:42 ` Mark Rutland
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=4e96a3f6-1995-404c-ed44-45200a4ee582@linux.microsoft.com \
--to=madvenka@linux.microsoft.com \
--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=mark.rutland@arm.com \
--cc=oleg@redhat.com \
--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 NNTP newsgroup(s).