From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com> To: David Laight <David.Laight@ACULAB.COM>, "kernel-hardening@lists.openwall.com" <kernel-hardening@lists.openwall.com>, "linux-api@vger.kernel.org" <linux-api@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>, "linux-integrity@vger.kernel.org" <linux-integrity@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-security-module@vger.kernel.org" <linux-security-module@vger.kernel.org>, "oleg@redhat.com" <oleg@redhat.com>, "x86@kernel.org" <x86@kernel.org> Subject: Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor Date: Tue, 28 Jul 2020 11:32:32 -0500 [thread overview] Message-ID: <f5cfd11b-04fe-9db7-9d67-7ee898636edb@linux.microsoft.com> (raw) In-Reply-To: <c23de6ec47614f489943e1a89a21dfa3@AcuMS.aculab.com> Thanks. See inline.. On 7/28/20 10:13 AM, David Laight wrote: > From: madvenka@linux.microsoft.com >> Sent: 28 July 2020 14:11 > ... >> 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. > Isn't the performance of this going to be horrid? It takes about the same amount of time as getpid(). So, it is one quick trip into the kernel. I expect that applications will typically not care about this extra overhead as long as they are able to run. But I agree that if there is an application that cannot tolerate this extra overhead, then it is an issue. See below for further discussion. In the libffi changes I have included in the cover letter, I have done it in such a way that trampfd is chosen when current security settings don't allow other methods such as loading trampoline code into a file and mapping it. In this case, the application can at least run with trampfd. > > If you don't care that much about performance the fixup can > all be done in userspace within the fault signal handler. I do care about performance. This is a framework to address trampolines. In this initial work, I want to establish one basic way for things to work. In the future, trampfd can be enhanced for performance. For instance, it is easy for an architecture to generate the exact instructions required to load specified registers, push specified values on the stack and jump to a target PC. The kernel can map a page with the generated code with execute permissions. In this case, the performance issue goes away. > Since whatever you do needs the application changed why > not change the implementation of nested functions to not > need on-stack executable trampolines. I kinda agree with your suggestion. But it is up to the GCC folks to change its implementation. I am trying to provide a way for their existing implementation to work in a more secure way. > I can think of other alternatives that don't need much more > than an array of 'push constant; jump trampoline' instructions > be created (all jump to the same place). > > You might want something to create an executable page of such > instructions. Agreed. And that can be done within this framework as I have mentioned above. But it is not just this trampoline type that I have implemented in this patchset. In the future, other types can be implemented and other contexts can be defined. Basically, the approach is for the user to supply a recipe to the kernel and leave it up to the kernel to do it in the best way possible. I am hoping that other forms of dynamic code can be addressed in the future using the same framework. *Purely as a hypothetical example*, a user can supply instructions in a language such as BPF that the kernel understands and have the kernel arrange for that to be executed in user context. Madhavan > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales)
WARNING: multiple messages have this Message-ID (diff)
From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com> To: David Laight <David.Laight@ACULAB.COM>, "kernel-hardening@lists.openwall.com" <kernel-hardening@lists.openwall.com>, "linux-api@vger.kernel.org" <linux-api@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>, "linux-integrity@vger.kernel.org" <linux-integrity@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-security-module@vger.kernel.org" <linux-security-module@vger.kernel.org>, "oleg@redhat.com" <oleg@redhat.com>, "x86@kernel.org" <x86@kernel.org> Subject: Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor Date: Tue, 28 Jul 2020 11:32:32 -0500 [thread overview] Message-ID: <f5cfd11b-04fe-9db7-9d67-7ee898636edb@linux.microsoft.com> (raw) In-Reply-To: <c23de6ec47614f489943e1a89a21dfa3@AcuMS.aculab.com> Thanks. See inline.. On 7/28/20 10:13 AM, David Laight wrote: > From: madvenka@linux.microsoft.com >> Sent: 28 July 2020 14:11 > ... >> 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. > Isn't the performance of this going to be horrid? It takes about the same amount of time as getpid(). So, it is one quick trip into the kernel. I expect that applications will typically not care about this extra overhead as long as they are able to run. But I agree that if there is an application that cannot tolerate this extra overhead, then it is an issue. See below for further discussion. In the libffi changes I have included in the cover letter, I have done it in such a way that trampfd is chosen when current security settings don't allow other methods such as loading trampoline code into a file and mapping it. In this case, the application can at least run with trampfd. > > If you don't care that much about performance the fixup can > all be done in userspace within the fault signal handler. I do care about performance. This is a framework to address trampolines. In this initial work, I want to establish one basic way for things to work. In the future, trampfd can be enhanced for performance. For instance, it is easy for an architecture to generate the exact instructions required to load specified registers, push specified values on the stack and jump to a target PC. The kernel can map a page with the generated code with execute permissions. In this case, the performance issue goes away. > Since whatever you do needs the application changed why > not change the implementation of nested functions to not > need on-stack executable trampolines. I kinda agree with your suggestion. But it is up to the GCC folks to change its implementation. I am trying to provide a way for their existing implementation to work in a more secure way. > I can think of other alternatives that don't need much more > than an array of 'push constant; jump trampoline' instructions > be created (all jump to the same place). > > You might want something to create an executable page of such > instructions. Agreed. And that can be done within this framework as I have mentioned above. But it is not just this trampoline type that I have implemented in this patchset. In the future, other types can be implemented and other contexts can be defined. Basically, the approach is for the user to supply a recipe to the kernel and leave it up to the kernel to do it in the best way possible. I am hoping that other forms of dynamic code can be addressed in the future using the same framework. *Purely as a hypothetical example*, a user can supply instructions in a language such as BPF that the kernel understands and have the kernel arrange for that to be executed in user context. Madhavan > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-07-28 16:32 UTC|newest] Thread overview: 146+ 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 ` madvenka 2020-07-28 13:10 ` [PATCH v1 1/4] [RFC] fs/trampfd: Implement the trampoline file descriptor API madvenka 2020-07-28 13:10 ` madvenka 2020-07-28 14:50 ` Oleg Nesterov 2020-07-28 14:50 ` Oleg Nesterov 2020-07-28 14:58 ` Madhavan T. Venkataraman 2020-07-28 14:58 ` Madhavan T. Venkataraman 2020-07-28 16:06 ` Oleg Nesterov 2020-07-28 16:06 ` Oleg Nesterov 2020-07-28 19:48 ` kernel test robot 2020-07-29 2:33 ` kernel test robot 2020-07-28 13:10 ` [PATCH v1 2/4] [RFC] x86/trampfd: Provide support for the trampoline file descriptor madvenka 2020-07-28 13:10 ` madvenka 2020-07-28 18:38 ` kernel test robot 2020-07-30 9:06 ` Greg KH 2020-07-30 9:06 ` Greg KH 2020-07-30 14:25 ` Madhavan T. Venkataraman 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 ` madvenka 2020-07-28 13:10 ` [PATCH v1 4/4] [RFC] arm/trampfd: " madvenka 2020-07-28 13:10 ` madvenka 2020-07-28 15:13 ` [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor David Laight 2020-07-28 15:13 ` David Laight 2020-07-28 15:13 ` David Laight 2020-07-28 16:32 ` Madhavan T. Venkataraman [this message] 2020-07-28 16:32 ` Madhavan T. Venkataraman 2020-07-28 16:32 ` Madhavan T. Venkataraman 2020-07-28 17:16 ` Andy Lutomirski 2020-07-28 17:16 ` Andy Lutomirski 2020-07-28 17:16 ` Andy Lutomirski 2020-07-28 17:39 ` Madhavan T. Venkataraman 2020-07-29 5:16 ` Andy Lutomirski 2020-07-29 5:16 ` Andy Lutomirski 2020-07-29 5:16 ` Andy Lutomirski 2020-07-28 18:52 ` Madhavan T. Venkataraman 2020-07-28 18:52 ` Madhavan T. Venkataraman 2020-07-28 18:52 ` Madhavan T. Venkataraman 2020-07-29 8:36 ` David Laight 2020-07-29 8:36 ` David Laight 2020-07-29 8:36 ` David Laight 2020-07-29 17:55 ` Madhavan T. Venkataraman 2020-07-29 17:55 ` Madhavan T. Venkataraman 2020-07-29 17:55 ` Madhavan T. Venkataraman 2020-07-28 16:05 ` Casey Schaufler 2020-07-28 16:05 ` Casey Schaufler 2020-07-28 16:49 ` Madhavan T. Venkataraman 2020-07-28 16:49 ` Madhavan T. Venkataraman 2020-07-28 17:05 ` James Morris 2020-07-28 17:05 ` James Morris 2020-07-28 17:08 ` Madhavan T. Venkataraman 2020-07-28 17:08 ` Madhavan T. Venkataraman 2020-07-28 17:31 ` Andy Lutomirski 2020-07-28 17:31 ` Andy Lutomirski 2020-07-28 17:31 ` Andy Lutomirski 2020-07-28 19:01 ` Madhavan T. Venkataraman 2020-07-28 19:01 ` Madhavan T. Venkataraman 2020-07-29 13:29 ` Florian Weimer 2020-07-29 13:29 ` Florian Weimer 2020-07-29 13:29 ` Florian Weimer 2020-07-30 13:09 ` David Laight 2020-07-30 13:09 ` David Laight 2020-08-02 11:56 ` Pavel Machek 2020-08-02 11:56 ` Pavel Machek 2020-08-03 8:08 ` David Laight 2020-08-03 8:08 ` David Laight 2020-08-03 15:57 ` Madhavan T. Venkataraman 2020-08-03 15:57 ` Madhavan T. Venkataraman 2020-07-30 14:24 ` Madhavan T. Venkataraman 2020-07-30 20:54 ` Andy Lutomirski 2020-07-30 20:54 ` Andy Lutomirski 2020-07-30 20:54 ` Andy Lutomirski 2020-07-31 17:13 ` Madhavan T. Venkataraman 2020-07-31 17:13 ` Madhavan T. Venkataraman 2020-07-31 18:31 ` Mark Rutland 2020-07-31 18:31 ` Mark Rutland 2020-08-03 8:27 ` David Laight 2020-08-03 8:27 ` David Laight 2020-08-03 16:03 ` Madhavan T. Venkataraman 2020-08-03 16:03 ` Madhavan T. Venkataraman 2020-08-03 16:57 ` David Laight 2020-08-03 16:57 ` David Laight 2020-08-03 17:00 ` Madhavan T. Venkataraman 2020-08-03 17:00 ` Madhavan T. Venkataraman 2020-08-03 17:58 ` Madhavan T. Venkataraman 2020-08-03 17:58 ` Madhavan T. Venkataraman 2020-08-04 13:55 ` Mark Rutland 2020-08-04 13:55 ` Mark Rutland 2020-08-04 14:33 ` David Laight 2020-08-04 14:33 ` David Laight 2020-08-04 14:44 ` David Laight 2020-08-04 14:44 ` David Laight 2020-08-04 14:48 ` Madhavan T. Venkataraman 2020-08-04 14:48 ` Madhavan T. Venkataraman 2020-08-04 15:46 ` Madhavan T. Venkataraman 2020-08-04 15:46 ` Madhavan T. Venkataraman 2020-08-02 13:57 ` Florian Weimer 2020-08-02 13:57 ` Florian Weimer 2020-08-02 13:57 ` Florian Weimer 2020-07-30 14:42 ` Madhavan T. Venkataraman 2020-07-30 14:42 ` Madhavan T. Venkataraman 2020-08-02 18:54 ` Madhavan T. Venkataraman 2020-08-02 18:54 ` Madhavan T. Venkataraman 2020-08-02 20:00 ` Andy Lutomirski 2020-08-02 20:00 ` Andy Lutomirski 2020-08-02 20:00 ` Andy Lutomirski 2020-08-02 22:58 ` Madhavan T. Venkataraman 2020-08-02 22:58 ` Madhavan T. Venkataraman 2020-08-03 18:36 ` Madhavan T. Venkataraman 2020-08-03 18:36 ` Madhavan T. Venkataraman 2020-08-10 17:20 ` Madhavan T. Venkataraman 2020-08-10 17:34 ` Madhavan T. Venkataraman 2020-08-10 17:34 ` Madhavan T. Venkataraman 2020-08-11 21:12 ` Madhavan T. Venkataraman 2020-08-11 21:12 ` Madhavan T. Venkataraman 2020-08-03 8:23 ` David Laight 2020-08-03 8:23 ` David Laight 2020-08-03 15:59 ` Madhavan T. Venkataraman 2020-08-03 15:59 ` Madhavan T. Venkataraman 2020-07-31 18:09 ` Mark Rutland 2020-07-31 18:09 ` Mark Rutland 2020-07-31 20:08 ` Madhavan T. Venkataraman 2020-07-31 20:08 ` Madhavan T. Venkataraman 2020-08-03 16:57 ` Madhavan T. Venkataraman 2020-08-03 16:57 ` Madhavan T. Venkataraman 2020-08-04 14:30 ` Mark Rutland 2020-08-04 14:30 ` Mark Rutland 2020-08-06 17:26 ` Madhavan T. Venkataraman 2020-08-06 17:26 ` Madhavan T. Venkataraman 2020-08-08 22:17 ` Pavel Machek 2020-08-08 22:17 ` Pavel Machek 2020-08-11 12:41 ` Madhavan T. Venkataraman 2020-08-11 12:41 ` Madhavan T. Venkataraman 2020-08-11 13:08 ` Pavel Machek 2020-08-11 13:08 ` Pavel Machek 2020-08-11 15:54 ` Madhavan T. Venkataraman 2020-08-11 15:54 ` Madhavan T. Venkataraman 2020-08-12 10:06 ` Mark Rutland 2020-08-12 10:06 ` Mark Rutland 2020-08-12 18:47 ` Madhavan T. Venkataraman 2020-08-12 18:47 ` Madhavan T. Venkataraman 2020-08-19 18:53 ` Mickaël Salaün 2020-08-19 18:53 ` Mickaël Salaün 2020-09-01 15:42 ` Mark Rutland 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=f5cfd11b-04fe-9db7-9d67-7ee898636edb@linux.microsoft.com \ --to=madvenka@linux.microsoft.com \ --cc=David.Laight@ACULAB.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=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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.