From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com> To: Andy Lutomirski <luto@kernel.org> Cc: Kernel Hardening <kernel-hardening@lists.openwall.com>, Linux API <linux-api@vger.kernel.org>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, Linux FS Devel <linux-fsdevel@vger.kernel.org>, linux-integrity <linux-integrity@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, LSM List <linux-security-module@vger.kernel.org>, Oleg Nesterov <oleg@redhat.com>, X86 ML <x86@kernel.org> Subject: Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor Date: Mon, 10 Aug 2020 12:34:26 -0500 [thread overview] Message-ID: <5f4e024b-cc14-8fe9-dc4a-df09da2a98ae@linux.microsoft.com> (raw) In-Reply-To: <CALCETrUJ2hBmJujyCtEqx4=pknRvjvi1-Gj9wfRcMMzejjKQsQ@mail.gmail.com> Resending because of mailer problems. Some of the recipients did not receive my email. I apologize. Sigh. Here is a redefinition of trampfd based on review comments. I wanted to address dynamic code in 3 different ways: Remove the need for dynamic code where possible -------------------------------------------------------------------- If the kernel itself can perform the work of some dynamic code, then the code can be replaced by the kernel. This is what I implemented in the patchset. But reviewers objected to the performance impact. One trip to the kernel was needed for each trampoline invocation. So, I have decided to defer this approach. Convert dynamic code to static code where possible ---------------------------------------------------------------------- This is possible with help from the kernel. This has no performance impact and can be used in libffi, GCC nested functions, etc. I have described the approach below. Deal with code generation ----------------------------------- For cases like generating JIT code from Java byte code, I wanted to establish a framework. However, reviewers felt that details are missing. Should the kernel generate code or should it use a user-level code generator? How do you make sure that a user level code generator can be trusted? How would the communication work? ABI details? Architecture support? Support for different types - JIT, DBT, etc? I have come to the conclusion that this is best done separately. My main interest is to provide a way to convert dynamic code such as trampolines to static code without any special architecture support. This can be done with the kernel's help. Any code that gets written in the future can conform to this as well. So, in version 2 of the Trampfd RFC, I would like to simplify trampfd and just address item 2. I will reimplement the support in libffi and present it. Convert dynamic code to static code ------------------------------------------------ One problem with dynamic code is that it cannot be verified or authenticated by the kernel. The kernel cannot tell the difference between genuine dynamic code and an attacker's code. Where possible, dynamic code should be converted to static code and placed in the text segment of a binary file. This allows the kernel to verify the code by verifying the signature of the file. The other problem is using user-level methods to load and execute dynamic code can potentially be exploited by an attacker to inject his code and have it be executed. To prevent this, a system may enforce W^X. If W^X is enforced properly, genuine dynamic code will not be able to run. This is another reason to convert dynamic code to static code. The issue in converting dynamic code to static code is that the data is dynamic. The code does not know before hand where the data is going to be at runtime. Some architectures support PC-relative data references. So, if you co-locate code and data, then the code can find the data at runtime. But this is not supported on all architectures. When supported, there may be limitations to deal with. Plus you have to take the trouble to co-locate code and data. And, to deal with W^X, code and data need to be in different pages. All architectures must be supported without any limitations. Fortunately, the kernel can solve this problem quite easily. I suggest the following: Convert dynamic code to static code like this: - Decide which register should point to the data that the code needs. Call it register R. - Write the static code assuming that R already points to the data. - Use trampfd and pass the following to the kernel: - pointers to the code and data - the name of the register R The kernel will write the following instructions in a trampoline page mapped into the caller's address space with R-X. - Load the data address in register R - Jump to the static code Basically, the kernel provides a trampoline to jump to the user's code and returns the kernel-provided trampoline's address to the user. It is trivial to implement a trampoline table in the trampoline page to conserve memory. Issues raised previously ------------------------------- I believe that the following issues that were raised by reviewers is not a problem in this scheme. Please rereview. - Florian mentioned the libffi trampoline table. Trampoline tables can be implemented in this scheme easily. - Florian mentioned stack unwinders. I am not an expert on unwinders. But I don't see an issue with unwinders. - Mark Rutland mentioned Intel's CET and CFI. Don't see a problem there. - Mark Rutland mentioned PAC+BTI on ARM64. Don't see a problem there. If I have missed addressing any previously raised issue, I apologize. Please let me know. Thanks! Madhavan
WARNING: multiple messages have this Message-ID (diff)
From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com> To: Andy Lutomirski <luto@kernel.org> Cc: Kernel Hardening <kernel-hardening@lists.openwall.com>, Linux API <linux-api@vger.kernel.org>, X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>, Oleg Nesterov <oleg@redhat.com>, LSM List <linux-security-module@vger.kernel.org>, Linux FS Devel <linux-fsdevel@vger.kernel.org>, linux-integrity <linux-integrity@vger.kernel.org>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor Date: Mon, 10 Aug 2020 12:34:26 -0500 [thread overview] Message-ID: <5f4e024b-cc14-8fe9-dc4a-df09da2a98ae@linux.microsoft.com> (raw) In-Reply-To: <CALCETrUJ2hBmJujyCtEqx4=pknRvjvi1-Gj9wfRcMMzejjKQsQ@mail.gmail.com> Resending because of mailer problems. Some of the recipients did not receive my email. I apologize. Sigh. Here is a redefinition of trampfd based on review comments. I wanted to address dynamic code in 3 different ways: Remove the need for dynamic code where possible -------------------------------------------------------------------- If the kernel itself can perform the work of some dynamic code, then the code can be replaced by the kernel. This is what I implemented in the patchset. But reviewers objected to the performance impact. One trip to the kernel was needed for each trampoline invocation. So, I have decided to defer this approach. Convert dynamic code to static code where possible ---------------------------------------------------------------------- This is possible with help from the kernel. This has no performance impact and can be used in libffi, GCC nested functions, etc. I have described the approach below. Deal with code generation ----------------------------------- For cases like generating JIT code from Java byte code, I wanted to establish a framework. However, reviewers felt that details are missing. Should the kernel generate code or should it use a user-level code generator? How do you make sure that a user level code generator can be trusted? How would the communication work? ABI details? Architecture support? Support for different types - JIT, DBT, etc? I have come to the conclusion that this is best done separately. My main interest is to provide a way to convert dynamic code such as trampolines to static code without any special architecture support. This can be done with the kernel's help. Any code that gets written in the future can conform to this as well. So, in version 2 of the Trampfd RFC, I would like to simplify trampfd and just address item 2. I will reimplement the support in libffi and present it. Convert dynamic code to static code ------------------------------------------------ One problem with dynamic code is that it cannot be verified or authenticated by the kernel. The kernel cannot tell the difference between genuine dynamic code and an attacker's code. Where possible, dynamic code should be converted to static code and placed in the text segment of a binary file. This allows the kernel to verify the code by verifying the signature of the file. The other problem is using user-level methods to load and execute dynamic code can potentially be exploited by an attacker to inject his code and have it be executed. To prevent this, a system may enforce W^X. If W^X is enforced properly, genuine dynamic code will not be able to run. This is another reason to convert dynamic code to static code. The issue in converting dynamic code to static code is that the data is dynamic. The code does not know before hand where the data is going to be at runtime. Some architectures support PC-relative data references. So, if you co-locate code and data, then the code can find the data at runtime. But this is not supported on all architectures. When supported, there may be limitations to deal with. Plus you have to take the trouble to co-locate code and data. And, to deal with W^X, code and data need to be in different pages. All architectures must be supported without any limitations. Fortunately, the kernel can solve this problem quite easily. I suggest the following: Convert dynamic code to static code like this: - Decide which register should point to the data that the code needs. Call it register R. - Write the static code assuming that R already points to the data. - Use trampfd and pass the following to the kernel: - pointers to the code and data - the name of the register R The kernel will write the following instructions in a trampoline page mapped into the caller's address space with R-X. - Load the data address in register R - Jump to the static code Basically, the kernel provides a trampoline to jump to the user's code and returns the kernel-provided trampoline's address to the user. It is trivial to implement a trampoline table in the trampoline page to conserve memory. Issues raised previously ------------------------------- I believe that the following issues that were raised by reviewers is not a problem in this scheme. Please rereview. - Florian mentioned the libffi trampoline table. Trampoline tables can be implemented in this scheme easily. - Florian mentioned stack unwinders. I am not an expert on unwinders. But I don't see an issue with unwinders. - Mark Rutland mentioned Intel's CET and CFI. Don't see a problem there. - Mark Rutland mentioned PAC+BTI on ARM64. Don't see a problem there. If I have missed addressing any previously raised issue, I apologize. Please let me know. Thanks! Madhavan _______________________________________________ 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-08-10 17:34 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 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 [this message] 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=5f4e024b-cc14-8fe9-dc4a-df09da2a98ae@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=luto@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.