Live data from Hacker News

Microsoft Engineer Proposes “Trampfd” for Improving Linux Security

phoronix.com

21–30 of 39 posts

Re: Microsoft Engineer Proposes “Trampfd” for Improving Linux Security

#22
Sounds a bit like how vsyscall works, except without kernel ABI reasons to back it up :/ Trying to have the kernel/application figure out if a trampoline is “legit” sounds like a bad idea, just like GCC’s nested functions in the first place (which people have been told to avoid for quite a while). Why not tell applications to migrate to iOS-style trampoline page remapping that’s used for imp_implementationWithBlock: https://landonf.org/code/objc/imp_implementationWithBlock.20...? libffi will likely be migrating away from its current technique to support Apple Silicon, anyhow.

Re: Microsoft Engineer Proposes “Trampfd” for Improving Linux Security

#23
post #21

Um, so a trampoline is some kind of redirect?

I think there are several slightly different variations, but generally a trampoline is something like this pseudo-code:

    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

#25

Does it really matter that he's a "Microsoft Engineer" or is that just thrown in there to ruffle old people's feathers?

I think it gives credability right off the bat.

Ideally, it wouldn't.

Re: Microsoft Engineer Proposes “Trampfd” for Improving Linux Security

#26
post #16
post #6

Earlier 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.

You still need to store the write pointers somewhere. So this very quickly becomes a game of cat and mouse.

Re: Microsoft Engineer Proposes “Trampfd” for Improving Linux Security

#27
post #6
post #2

Someone 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…

Yes, the edit is precisely what I was trying to get at. Do you happen to have context around this?

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

#28
post #2

Someone 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/ ).

Hmmm. So maybe this is a reasonable explanation.
Post reply on HN