From: Jay K <jayk123@hotmail.com> To: Florian Weimer <fw@deneb.enyo.de>, "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com> Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>, Arvind Sankar <nivedita@alum.mit.edu>, "luto@kernel.org" <luto@kernel.org>, "kernel-hardening@lists.openwall.com" <kernel-hardening@lists.openwall.com>, "linux-api@vger.kernel.org" <linux-api@vger.kernel.org>, "x86@kernel.org" <x86@kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "oleg@redhat.com" <oleg@redhat.com>, "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>, "linux-security-module@vger.kernel.org" <linux-security-module@vger.kernel.org>, "David.Laight@ACULAB.COM" <David.Laight@ACULAB.COM>, "pavel@ucw.cz" <pavel@ucw.cz>, "mic@digikod.net" <mic@digikod.net>, "linux-integrity@vger.kernel.org" <linux-integrity@vger.kernel.org>, "libffi-discuss@sourceware.org" <libffi-discuss@sourceware.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor Date: Sat, 3 Oct 2020 09:43:02 +0000 [thread overview] Message-ID: <CY4PR1401MB1942930DCB5EC5CC62EC3F57E60E0@CY4PR1401MB1942.namprd14.prod.outlook.com> (raw) In-Reply-To: <fdfe73d3-d735-4bdc-4790-7feb7fecece5@linux.microsoft.com> > And this is not just for libffi that we can somehow do this within libffi. > I would like to provide something so that the maintainers of other > dynamic code can use it to convert their dynamic code to static code > when their dynamic code is a lot more complex that the libffi trampoline. Having worked on stuff "like" this -- removing "arbitrary" codegen from a system and replacing with "templatized" codegen, because the runtime banned runtime codegen, and despite being a lover of shared source and shared libraries, I'm afraid to say, this is not an area very amenable to sharing. Specifically I've done this twice. Providing examples is good and people will copy/paste. The problem can be sort of split up into parts: - The management of a pool of thunks. - The thunks. Where I mostly give up is: - Generalizing the thunks, such as to share them. the management of the pool is kinda sorta generalizable, but the thunks, again, it is difficult/impossible to share. I do think, there is *some* opportunity here. Stuff like, for some function f(x,y), produce a new function f2(y,x) that swaps params and calls f or a new function f3(x), that sets y to a constant and calls f. Like my favorite Scheme-ish: Given a static binary function: function add(x, y) (+ x y) Provide for dynamically creating specialized unary functions: function make-add(x): return function addx(y) (+ x y) And then generalized to arbitrary rearrangement and hardcoding of parameters. I believe this is libffi, and might be able to replace some people's codegens. It sounds a bit contrived, but I know this actually resembles real world cases. Consider some library that accepts function pointers but fails to accept an additional void* to pass on to them. qsort/bsearch are the classic broken-ish cases. Wrapping Windows WNDPROCs in C++ are another -- you want a "thunk" to take the Win32-defined parameters, and add a this pointer as well. So you create a new function and when you create the function you give it the this pointer to hardcode within it. i.e. atlthunk. > The kernel based solution gives you the opportunity to make additional > security checks at the time a trampoline is invoked. A purely user level > solution cannot do that. E.g., I would like to prevent even the minimal > trampoline from being used in BOP/ROP chains. Like what? At some point, it is just normal static code. Once libffi is fixed, so that the iOS solution is available on all platforms, it is all just normal code. There are no checks to apply differently to libffi and its output than any other code, right? > Before I implement the user land solution recommended by reviewers, I just want > an opinion on where the code should reside. > > I am thinking glibc. The other choice would be a separate library, say, libtramp. > What do you recommend? What functionality does the user land solution provide? I suggest, other than lobbying the libffi developers to do their part, and perhaps giving in and doing it yourself, identity some other dynamic but non-arbitrary code generations that you wish to fix and work through fixing it. See what patterns emerge. - Jay _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Jay K <jayk123@hotmail.com> To: Florian Weimer <fw@deneb.enyo.de>, "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com> Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>, "linux-security-module@vger.kernel.org" <linux-security-module@vger.kernel.org>, "pavel@ucw.cz" <pavel@ucw.cz>, "kernel-hardening@lists.openwall.com" <kernel-hardening@lists.openwall.com>, "linux-api@vger.kernel.org" <linux-api@vger.kernel.org>, "x86@kernel.org" <x86@kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "oleg@redhat.com" <oleg@redhat.com>, "mic@digikod.net" <mic@digikod.net>, Arvind Sankar <nivedita@alum.mit.edu>, "David.Laight@ACULAB.COM" <David.Laight@ACULAB.COM>, "luto@kernel.org" <luto@kernel.org>, "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>, "linux-integrity@vger.kernel.org" <linux-integrity@vger.kernel.org>, "libffi-discuss@sourceware.org" <libffi-discuss@sourceware.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor Date: Sat, 3 Oct 2020 09:43:02 +0000 [thread overview] Message-ID: <CY4PR1401MB1942930DCB5EC5CC62EC3F57E60E0@CY4PR1401MB1942.namprd14.prod.outlook.com> (raw) In-Reply-To: <fdfe73d3-d735-4bdc-4790-7feb7fecece5@linux.microsoft.com> > And this is not just for libffi that we can somehow do this within libffi. > I would like to provide something so that the maintainers of other > dynamic code can use it to convert their dynamic code to static code > when their dynamic code is a lot more complex that the libffi trampoline. Having worked on stuff "like" this -- removing "arbitrary" codegen from a system and replacing with "templatized" codegen, because the runtime banned runtime codegen, and despite being a lover of shared source and shared libraries, I'm afraid to say, this is not an area very amenable to sharing. Specifically I've done this twice. Providing examples is good and people will copy/paste. The problem can be sort of split up into parts: - The management of a pool of thunks. - The thunks. Where I mostly give up is: - Generalizing the thunks, such as to share them. the management of the pool is kinda sorta generalizable, but the thunks, again, it is difficult/impossible to share. I do think, there is *some* opportunity here. Stuff like, for some function f(x,y), produce a new function f2(y,x) that swaps params and calls f or a new function f3(x), that sets y to a constant and calls f. Like my favorite Scheme-ish: Given a static binary function: function add(x, y) (+ x y) Provide for dynamically creating specialized unary functions: function make-add(x): return function addx(y) (+ x y) And then generalized to arbitrary rearrangement and hardcoding of parameters. I believe this is libffi, and might be able to replace some people's codegens. It sounds a bit contrived, but I know this actually resembles real world cases. Consider some library that accepts function pointers but fails to accept an additional void* to pass on to them. qsort/bsearch are the classic broken-ish cases. Wrapping Windows WNDPROCs in C++ are another -- you want a "thunk" to take the Win32-defined parameters, and add a this pointer as well. So you create a new function and when you create the function you give it the this pointer to hardcode within it. i.e. atlthunk. > The kernel based solution gives you the opportunity to make additional > security checks at the time a trampoline is invoked. A purely user level > solution cannot do that. E.g., I would like to prevent even the minimal > trampoline from being used in BOP/ROP chains. Like what? At some point, it is just normal static code. Once libffi is fixed, so that the iOS solution is available on all platforms, it is all just normal code. There are no checks to apply differently to libffi and its output than any other code, right? > Before I implement the user land solution recommended by reviewers, I just want > an opinion on where the code should reside. > > I am thinking glibc. The other choice would be a separate library, say, libtramp. > What do you recommend? What functionality does the user land solution provide? I suggest, other than lobbying the libffi developers to do their part, and perhaps giving in and doing it yourself, identity some other dynamic but non-arbitrary code generations that you wish to fix and work through fixing it. See what patterns emerge. - Jay
next prev parent reply other threads:[~2020-10-03 9:44 UTC|newest] Thread overview: 111+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <210d7cd762d5307c2aa1676705b392bd445f1baa> 2020-09-16 15:08 ` [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor madvenka 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 ` 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 ` madvenka 2020-09-17 1:10 ` kernel test robot 2020-09-17 3:04 ` kernel test robot 2020-09-16 15:08 ` [PATCH v2 3/4] [RFC] arm64/trampfd: " madvenka 2020-09-16 15:08 ` madvenka 2020-09-16 15:08 ` [PATCH v2 4/4] [RFC] arm/trampfd: " madvenka 2020-09-16 15:08 ` madvenka 2020-09-17 1:04 ` [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor Florian Weimer 2020-09-17 1:04 ` Florian Weimer 2020-09-17 1:04 ` Florian Weimer 2020-09-17 15:36 ` Madhavan T. Venkataraman 2020-09-17 15:36 ` Madhavan T. Venkataraman 2020-09-17 15:57 ` Madhavan T. Venkataraman 2020-09-17 15:57 ` Madhavan T. Venkataraman 2020-09-17 16:01 ` Florian Weimer 2020-09-17 16:01 ` Florian Weimer 2020-09-17 16:01 ` Florian Weimer 2020-09-23 1:46 ` Arvind Sankar 2020-09-23 1:46 ` Arvind Sankar 2020-09-23 9:11 ` Arvind Sankar 2020-09-23 9:11 ` Arvind Sankar 2020-09-23 19:17 ` Madhavan T. Venkataraman 2020-09-23 19:17 ` Madhavan T. Venkataraman 2020-09-23 19:51 ` Arvind Sankar 2020-09-23 19:51 ` Arvind Sankar 2020-09-23 23:51 ` Madhavan T. Venkataraman 2020-09-23 23:51 ` Madhavan T. Venkataraman 2020-09-24 20:23 ` Madhavan T. Venkataraman 2020-09-24 20:23 ` Madhavan T. Venkataraman 2020-09-24 20:52 ` Florian Weimer 2020-09-24 20:52 ` Florian Weimer 2020-09-24 20:52 ` Florian Weimer 2020-09-25 22:22 ` Madhavan T. Venkataraman 2020-09-25 22:22 ` Madhavan T. Venkataraman 2020-09-27 18:25 ` Madhavan T. Venkataraman 2020-09-27 18:25 ` Madhavan T. Venkataraman 2020-10-03 9:43 ` Jay K [this message] 2020-10-03 9:43 ` Jay K 2020-09-24 22:13 ` Pavel Machek 2020-09-24 22:13 ` Pavel Machek 2020-09-24 23:43 ` Arvind Sankar 2020-09-24 23:43 ` Arvind Sankar 2020-09-25 22:44 ` Madhavan T. Venkataraman 2020-09-25 22:44 ` Madhavan T. Venkataraman 2020-09-26 15:55 ` Arvind Sankar 2020-09-26 15:55 ` Arvind Sankar 2020-09-27 17:59 ` Madhavan T. Venkataraman 2020-09-27 17:59 ` Madhavan T. Venkataraman 2020-09-23 2:50 ` Jay K 2020-09-23 2:50 ` Jay K 2020-09-22 21:53 ` madvenka 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 ` 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 ` madvenka 2020-09-23 13:40 ` kernel test robot 2020-09-22 21:53 ` [PATCH v2 3/4] [RFC] arm64/trampfd: " madvenka 2020-09-22 21:53 ` madvenka 2020-09-22 21:53 ` [PATCH v2 4/4] [RFC] arm/trampfd: " madvenka 2020-09-22 21:53 ` madvenka 2020-09-22 21:54 ` [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor Madhavan T. Venkataraman 2020-09-22 21:54 ` Madhavan T. Venkataraman 2020-09-23 8:14 ` Pavel Machek 2020-09-23 8:14 ` Pavel Machek 2020-09-23 9:14 ` Solar Designer 2020-09-23 9:14 ` Solar Designer 2020-09-23 14:11 ` Solar Designer 2020-09-23 14:11 ` Solar Designer 2020-09-23 15:18 ` Pavel Machek 2020-09-23 15:18 ` Pavel Machek 2020-09-23 18:00 ` Solar Designer 2020-09-23 18:00 ` Solar Designer 2020-09-23 18:21 ` Solar Designer 2020-09-23 18:21 ` Solar Designer 2020-09-23 14:39 ` Florian Weimer 2020-09-23 14:39 ` Florian Weimer 2020-09-23 14:39 ` Florian Weimer 2020-09-23 18:09 ` Andy Lutomirski 2020-09-23 18:09 ` Andy Lutomirski 2020-09-23 18:11 ` Solar Designer 2020-09-23 18:11 ` Solar Designer 2020-09-23 18:49 ` Arvind Sankar 2020-09-23 18:49 ` Arvind Sankar 2020-09-23 23:53 ` Madhavan T. Venkataraman 2020-09-23 23:53 ` Madhavan T. Venkataraman 2020-09-23 19:41 ` Madhavan T. Venkataraman 2020-09-23 19:41 ` Madhavan T. Venkataraman 2020-09-23 18:10 ` James Morris 2020-09-23 18:10 ` James Morris 2020-09-23 18:32 ` Madhavan T. Venkataraman 2020-09-23 18:32 ` Madhavan T. Venkataraman 2020-09-23 8:42 ` Pavel Machek 2020-09-23 8:42 ` Pavel Machek 2020-09-23 18:56 ` Madhavan T. Venkataraman 2020-09-23 18:56 ` Madhavan T. Venkataraman 2020-09-23 20:51 ` Pavel Machek 2020-09-23 20:51 ` Pavel Machek 2020-09-23 23:04 ` Madhavan T. Venkataraman 2020-09-23 23:04 ` Madhavan T. Venkataraman 2020-09-24 16:44 ` Mickaël Salaün 2020-09-24 16:44 ` Mickaël Salaün 2020-09-24 22:05 ` Pavel Machek 2020-09-24 22:05 ` Pavel Machek 2020-09-25 10:12 ` Mickaël Salaün 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=CY4PR1401MB1942930DCB5EC5CC62EC3F57E60E0@CY4PR1401MB1942.namprd14.prod.outlook.com \ --to=jayk123@hotmail.com \ --cc=David.Laight@ACULAB.COM \ --cc=fw@deneb.enyo.de \ --cc=kernel-hardening@lists.openwall.com \ --cc=libffi-discuss@sourceware.org \ --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=nivedita@alum.mit.edu \ --cc=oleg@redhat.com \ --cc=pavel@ucw.cz \ --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.