# Re: \[PATCH v2 0/4\] \[RFC\] Implement Trampoline File Descriptor - List: linux-api - 5 messages, 5 authors - Page: https://ratatoskr.run/linux-api/2020/09/189459/t ## Re: \[PATCH v2 0/4\] \[RFC\] Implement Trampoline File Descriptor - From: Florian Weimer \ - Date: 2020-09-23 14:39:49 - Message: https://ratatoskr.run/linux-api/2020/09/189459.md ```text * Solar Designer: > While I share my opinion here, I don't mean that to block Madhavan's > work. I'd rather defer to people more knowledgeable in current userland > and ABI issues/limitations and plans on dealing with those, especially > to Florian Weimer. I haven't seen Florian say anything specific for or > against Madhavan's proposal, and I'd like to. (Have I missed that?) There was a previous discussion, where I provided feedback (not much different from the feedback here, given that the mechanism is mostly the same). I think it's unnecessary for the libffi use case. Precompiled code can be loaded from disk because the libffi trampolines are so regular. On most architectures, it's not even the code that's patched, but some of the data driving it, which happens to be located on the same page due to a libffi quirk. The libffi use case is a bit strange anyway: its trampolines are type-generic, and the per-call adjustment is data-driven. This means that once you have libffi in the process, you have a generic data-to-function-call mechanism available that can be abused (it's even fully CET compatible in recent versions). And then you need to look at the processes that use libffi. A lot of them contain bytecode interpreters, and those enable data-driven arbitrary code execution as well. I know that there are efforts under way to harden Python, but it's going to be tough to get to the point where things are still difficult for an attacker once they have the ability to make mprotect calls. It was pointed out to me that libffi is doing things wrong, and the trampolines should not be type-generic, but generated so that they match the function being called. That is, the marshal/unmarshal code would be open-coded in the trampoline, rather than using some generic mechanism plus run-time dispatch on data tables describing the function type. That is a very different design (and typically used by compilers (JIT or not JIT) to implement native calls). Mapping some code page with a repeating pattern would no longer work to defeat anti-JIT measures because it's closer to real JIT. I don't know if kernel support could make sense in this context, but it would be a completely different patch. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ``` ## Re: \[PATCH v2 0/4\] \[RFC\] Implement Trampoline File Descriptor - From: Andy Lutomirski \ - Date: 2020-09-23 18:09:48 - Message: https://ratatoskr.run/linux-api/2020/09/189478.md ```text On Wed, Sep 23, 2020 at 7:39 AM Florian Weimer [ref] wrote: > > * Solar Designer: > > > While I share my opinion here, I don't mean that to block Madhavan's > > work. I'd rather defer to people more knowledgeable in current userland > > and ABI issues/limitations and plans on dealing with those, especially > > to Florian Weimer. I haven't seen Florian say anything specific for or > > against Madhavan's proposal, and I'd like to. (Have I missed that?) > > There was a previous discussion, where I provided feedback (not much > different from the feedback here, given that the mechanism is mostly the > same). > > I think it's unnecessary for the libffi use case. Precompiled code can > be loaded from disk because the libffi trampolines are so regular. On > most architectures, it's not even the code that's patched, but some of > the data driving it, which happens to be located on the same page due to > a libffi quirk. > > The libffi use case is a bit strange anyway: its trampolines are > type-generic, and the per-call adjustment is data-driven. This means > that once you have libffi in the process, you have a generic > data-to-function-call mechanism available that can be abused (it's even > fully CET compatible in recent versions). And then you need to look at > the processes that use libffi. A lot of them contain bytecode > interpreters, and those enable data-driven arbitrary code execution as > well. I know that there are efforts under way to harden Python, but > it's going to be tough to get to the point where things are still > difficult for an attacker once they have the ability to make mprotect > calls. > > It was pointed out to me that libffi is doing things wrong, and the > trampolines should not be type-generic, but generated so that they match > the function being called. That is, the marshal/unmarshal code would be > open-coded in the trampoline, rather than using some generic mechanism > plus run-time dispatch on data tables describing the function type. > That is a very different design (and typically used by compilers (JIT or > not JIT) to implement native calls). Mapping some code page with a > repeating pattern would no longer work to defeat anti-JIT measures > because it's closer to real JIT. I don't know if kernel support could > make sense in this context, but it would be a completely different > patch. I would very much like to see a well-designed kernel facility for helping userspace do JIT in a safer manner, but designing such a thing is likely to be distinctly nontrivial. To throw a half-backed idea out there, suppose a program could pre-declare a list of JIT verifiers: static bool ffi_trampoline_verifier(void *target_address, size_t target_size, void *source_data, void *context); struct jit_verifier { .magic = 0xMAGIC_HERE, .verifier = ffi_trampoline_verifier, } my_verifier __attribute((section("something special here?))); and then a system call something like: instantiate_jit_code(target, source, size, &my_verifier, context); The idea being that even an attacker that can force a call to instantiate_jit_code() can only create code that passes verification by one of the pre-declared verifiers in the process. ``` ## Re: \[PATCH v2 0/4\] \[RFC\] Implement Trampoline File Descriptor - From: Solar Designer \ - Date: 2020-09-23 18:11:46 - Message: https://ratatoskr.run/linux-api/2020/09/189479.md ```text On Wed, Sep 23, 2020 at 04:39:31PM +0200, Florian Weimer wrote: > * Solar Designer: > > > While I share my opinion here, I don't mean that to block Madhavan's > > work. I'd rather defer to people more knowledgeable in current userland > > and ABI issues/limitations and plans on dealing with those, especially > > to Florian Weimer. I haven't seen Florian say anything specific for or > > against Madhavan's proposal, and I'd like to. (Have I missed that?) [...] > I think it's unnecessary for the libffi use case. [...] > I don't know if kernel support could > make sense in this context, but it would be a completely different > patch. Thanks. Are there currently relevant use cases where the proposed trampfd would be useful and likely actually made use of by userland - e.g., specific userland project developers saying they'd use it, or Madhavan intending to develop and contribute userland patches? Alexander ``` ## Re: \[PATCH v2 0/4\] \[RFC\] Implement Trampoline File Descriptor - From: Arvind Sankar \ - Date: 2020-09-23 18:49:38 - Message: https://ratatoskr.run/linux-api/2020/09/189484.md ```text On Wed, Sep 23, 2020 at 08:11:36PM +0200, Solar Designer wrote: > On Wed, Sep 23, 2020 at 04:39:31PM +0200, Florian Weimer wrote: > > * Solar Designer: > > > > > While I share my opinion here, I don't mean that to block Madhavan's > > > work. I'd rather defer to people more knowledgeable in current userland > > > and ABI issues/limitations and plans on dealing with those, especially > > > to Florian Weimer. I haven't seen Florian say anything specific for or > > > against Madhavan's proposal, and I'd like to. (Have I missed that?) > > [...] > > I think it's unnecessary for the libffi use case. > [...] > > > I don't know if kernel support could > > make sense in this context, but it would be a completely different > > patch. > > Thanks. Are there currently relevant use cases where the proposed > trampfd would be useful and likely actually made use of by userland - > e.g., specific userland project developers saying they'd use it, or > Madhavan intending to develop and contribute userland patches? > > Alexander The trampoline it provides in this version can be implemented completely in userspace. The kernel part of it is essentially just providing a way to do text relocations without needing a WX mapping, but the text relocations would be unnecessary in the first place if the trampoline was position-independent code. ``` ## Re: \[PATCH v2 0/4\] \[RFC\] Implement Trampoline File Descriptor - From: Madhavan T. Venkataraman \ - Date: 2020-09-23 23:53:29 - Message: https://ratatoskr.run/linux-api/2020/09/189503.md ```text On 9/23/20 9:39 AM, Florian Weimer wrote: > * Solar Designer: > >> While I share my opinion here, I don't mean that to block Madhavan's >> work. I'd rather defer to people more knowledgeable in current userland >> and ABI issues/limitations and plans on dealing with those, especially >> to Florian Weimer. I haven't seen Florian say anything specific for or >> against Madhavan's proposal, and I'd like to. (Have I missed that?) > > There was a previous discussion, where I provided feedback (not much > different from the feedback here, given that the mechanism is mostly the > same). > > I think it's unnecessary for the libffi use case. Precompiled code can > be loaded from disk because the libffi trampolines are so regular. On > most architectures, it's not even the code that's patched, but some of > the data driving it, which happens to be located on the same page due to > a libffi quirk. > > The libffi use case is a bit strange anyway: its trampolines are > type-generic, and the per-call adjustment is data-driven. This means > that once you have libffi in the process, you have a generic > data-to-function-call mechanism available that can be abused (it's even > fully CET compatible in recent versions). And then you need to look at > the processes that use libffi. A lot of them contain bytecode > interpreters, and those enable data-driven arbitrary code execution as > well. I know that there are efforts under way to harden Python, but > it's going to be tough to get to the point where things are still > difficult for an attacker once they have the ability to make mprotect > calls. > > It was pointed out to me that libffi is doing things wrong, and the > trampolines should not be type-generic, but generated so that they match > the function being called. That is, the marshal/unmarshal code would be > open-coded in the trampoline, rather than using some generic mechanism > plus run-time dispatch on data tables describing the function type. > That is a very different design (and typically used by compilers (JIT or > not JIT) to implement native calls). Mapping some code page with a > repeating pattern would no longer work to defeat anti-JIT measures > because it's closer to real JIT. I don't know if kernel support could > make sense in this context, but it would be a completely different > patch. > > Thanks, > Florian > Hi Florian, I am making myself familiar with anti-JIT measures before I can respond to this comment. Bear with me. I will also respond to the above libffi comment. Madhavan ```