From: Madhavan T. Venkataraman

Sent: 02 August 2020 19:55
To: Andy Lutomirski <luto@kernel.org>
Cc: Kernel Hardening <redacted>; Linux API <redacted>;
linux-arm-kernel [off-list ref]; Linux FS Devel <linux-
fsdevel@vger.kernel.org>; linux-integrity [off-list ref]; LKML <linux-
kernel@vger.kernel.org>; LSM List [off-list ref]; Oleg Nesterov
[off-list ref]; X86 ML [off-list ref]
Subject: Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor

More responses inline..

On 7/28/20 12:31 PM, Andy Lutomirski wrote:

quoted

quoted

On Jul 28, 2020, at 6:11 AM, madvenka@linux.microsoft.com wrote:

From: "Madhavan T. Venkataraman" [off-list ref]

2. Use existing kernel functionality.  Raise a signal, modify the
state, and return from the signal.  This is very flexible and may not
be all that much slower than trampfd.

Let me understand this. You are saying that the trampoline code
would raise a signal and, in the signal handler, set up the context
so that when the signal handler returns, we end up in the target
function with the context correctly set up. And, this trampoline code
can be generated statically at build time so that there are no
security issues using it.

Have I understood your suggestion correctly?

I was thinking that you'd just let the 'not executable' page fault
signal happen (SIGSEGV?) when the code jumps to on-stack trampoline
is executed.

The user signal handler can then decode the faulting instruction
and, if it matches the expected on-stack trampoline, modify the
saved registers before returning from the signal.

No kernel changes and all you need to add to the program is
an architecture-dependant signal handler.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)