Microsoft Engineer Proposes “Trampfd” for Improving Linux Security
21–30 of 39 posts
Re: Microsoft Engineer Proposes “Trampfd” for Improving Linux Security
#22Re: Microsoft Engineer Proposes “Trampfd” for Improving Linux Security
#23Um, so a trampoline is some kind of redirect?
while (next_fn_to_call != nullptr) {
next_fn_to_call = next_fn_to_call()
}
So each function potentially wants to call a new function once it's done, but you don't want to blow the stack (or maybe use a stack at all) so it returns that function (pointer) rather than calling it. Then you need a little loop to call the return value: that's your trampoline.The article is potentially a bit lower level given it's talking about things down at the CPU level, but I imagine its a vaguely connected idea.
Re: Microsoft Engineer Proposes “Trampfd” for Improving Linux Security
#24Does it really matter that he's a "Microsoft Engineer" or is that just thrown in there to ruffle old people's feathers?
Re: Microsoft Engineer Proposes “Trampfd” for Improving Linux Security
#25Re: Microsoft Engineer Proposes “Trampfd” for Improving Linux Security
#26Earlier quoted context omitted.
Currently the page must be writeable at some point in order to create the trampoline. A page fault is used as a way of executing the trampoline without the page having to be made executable/writable---the page fault handler recognises the page as a special trampoline page and handles the jump to the trampolines target address (which was previously registered using the new syscall). Note that AFAICS this is unrelated…
Double map it, like a JIT does. Once writable, and once executable. Put the pointers into different shared objects so that ASLR puts a randomized offset between them and you can't discover the write pointers from the execute pointer, and vice versa.
Re: Microsoft Engineer Proposes “Trampfd” for Improving Linux Security
#27Someone in the Phoronix comments wondered why not just map it (the kernel-assisted trampoline memory page) executable and not writeable, to avoid the attack surface but be significantly faster. I also wonder exactly why, admittedly I haven’t read the mailing list thread entirely but purely working on theory I wonder what the advantages of working on page fault is. Less abusable gadgets in memory? More flexibility? Pe…
Currently the page must be writeable at some point in order to create the trampoline. A page fault is used as a way of executing the trampoline without the page having to be made executable/writable---the page fault handler recognises the page as a special trampoline page and handles the jump to the trampolines target address (which was previously registered using the new syscall). Note that AFAICS this is unrelated…
edit: also, “spectre mitigations” was just a shot in the dark. It does feel like this mode of jmping (modifying saved registers and restoring them) would be more prone to interfering with speculative execution.
Re: Microsoft Engineer Proposes “Trampfd” for Improving Linux Security
#28Someone in the Phoronix comments wondered why not just map it (the kernel-assisted trampoline memory page) executable and not writeable, to avoid the attack surface but be significantly faster. I also wonder exactly why, admittedly I haven’t read the mailing list thread entirely but purely working on theory I wonder what the advantages of working on page fault is. Less abusable gadgets in memory? More flexibility? Pe…
Interestingly on ARM64 such mappings are prohibited, since this breaks PAN (the spec requires it: https://siguza.github.io/PAN/ ).