On Thu, Sep 24, 2020 at 03:23:52PM -0500, Madhavan T. Venkataraman wrote: > > > > Which ISA does not support PIC objects? You mentioned i386 below, but > > i386 does support them, it just needs to copy the PC into a GPR first > > (see below). > > Position Independent Code needs PC-relative branches. I was referring > to PC-relative data references. Like RIP-relative data references in > X64. i386 ISA does not support this. I was talking about PC-relative data references too: they are a requirement for PIC code that wants to access any global data. They can be implemented easily on i386 even though it doesn't have an addressing mode that uses the PC. > Otherwise, using an ABI quirk or a calling convention side effect to load the > PC into a GPR is, IMO, non-standard or non-compliant or non-approved or > whatever you want to call it. I would be conservative and not use it. Who knows > what incompatibility there will be with some future software or hardware > features? > > For instance, in the i386 example, we do a call without a matching return. > Also, we use a pop to undo the call. Can anyone tell me if this kind of use > is an ABI approved one? This doesn't have anything to do with the ABI, since what happened here isn't visible to any caller or callee. Any machine instruction sequence that has the effect of copying the PC into a GPR is acceptable, but this is basically the only possible solution on i386. If you don't like the call/pop mismatch (though that's supported by the hardware, and is what clang likes to use), you can use the slightly different technique used in my example, which copies the top of stack into a GPR after a call. This is how all i386 PIC code has always worked. > Standard API for all userland for all architectures > --------------------------------------------------- > > The next advantage in using the kernel is standardization. > > If the kernel supplies this, then all applications and libraries can use > it for all architectures with one single, simple API. Without this, each > application/library has to roll its own solution for every architecture-ABI > combo it wants to support. But you can get even more standardization out of a userspace library, because that can work even on non-linux OS's, as well as versions of linux where the new syscall isn't available. > > Furthermore, if this work gets accepted, I plan to add a glibc wrapper for > the kernel API. The glibc API would look something like this: > > Allocate a trampoline > --------------------- > > tramp = alloc_tramp(); > > Set trampoline parameters > ------------------------- > > init_tramp(tramp, code, data); > > Free the trampoline > ------------------- > > free_tramp(tramp); > > glibc will allocate and manage the code and data tables, handle kernel API > details and manage the trampoline table. glibc could do this already if it wants, even without the syscall, because this can be done in userspace already. > > Secure vs Performant trampoline > ------------------------------- > > If you recall, in version 1, I presented a trampoline type that is > implemented in the kernel. When an application invokes the trampoline, > it traps into the kernel and the kernel performs the work of the trampoline. > > The disadvantage is that a trip to the kernel is needed. That can be > expensive. > > The advantage is that the kernel can add security checks before doing the > work. Mainly, I am looking at checks that might prevent the trampoline > from being used in an ROP/BOP chain. Some half-baked ideas: > > - Check that the invocation is at the starting point of the > trampoline > > - Check if the trampoline is jumping to an allowed PC > > - Check if the trampoline is being invoked from an allowed > calling PC or PC range > > Allowed PCs can be input using the trampfd API mentioned in version 1. > Basically, an array of PCs is written into trampfd. The source PC will generally not be available if the compiler decided to tail-call optimize the call to the trampoline into a jump. What's special about these trampolines anyway? Any indirect function call could have these same problems -- an attacker could have overwritten the pointer the same way, whether it's supposed to point to a normal function or it is the target of this trampoline. For making them a bit safer, userspace could just map the page holding the data pointers/destination address(es) as read-only after initialization. > > Suggestions for other checks are most welcome! > > I would like to implement an option in the trampfd API. The user can > choose a secure trampoline or a performant trampoline. For a performant > trampoline, the kernel will generate the code. For a secure trampoline, > the kernel will do the work itself. > > In order to address the FFI_REGISTER ABI in libffi, we could use the secure > trampoline. In FFI_REGISTER, the data is pushed on the stack and the code > is jumped to without using any registers. > > As outlined in version 1, the kernel can push the data address on the stack > and write the code address into the PC and return to userland. > > For doing all of this, we need trampfd. We don't need this for FFI_REGISTER. I presented a solution that works in userspace. Even if you want to use a trampoline created by the kernel, there's no reason it needs to trap into the kernel at trampoline execution time. libffi's trampolines already handle this case today. > > Permitting the use of trampfd > ----------------------------- > > An "exectramp" setting can be implemented in SELinux to selectively allow the > use of trampfd for applications. > > Madhavan Applications can use their own userspace trampolines regardless of this setting, so it doesn't provide any additional security benefit by preventing usage of trampfd.
