Live data from Hacker News

Microsoft Engineer Proposes “Trampfd” for Improving Linux Security

phoronix.com

31–39 of 39 posts

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

#31

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

If he was an ex-Microsoft engineer, or a Microsoft engineer working on his own, I don’t think it would matter.

If Microsoft is using the hours of the engineer’s workday for this purpose, it provides insight that does matter.

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

#32

Earlier quoted context omitted.

I think it gives credability right off the bat.

Ideally, it wouldn't.

It is better than some random person giving idea on some project. If a Microsoft employee is proposing on behalf of the employer it has more chance of being proceeded forwarded/maintained/funded.

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

#33
post #26
post #16

Earlier quoted context omitted.

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.

JavaScriptCore had an amusing scheme where they'd make an (executable) memcpy gadget with the address hardcoded, then throw away read permissions to that memory. So the pointer's address is thus not readable without modifying memory permissions.

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

#35

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

Nested functions in c are totally awesome and perfectly safe as long as a) you don't pass them as function pointers and b) care about executable stacks. The nice thing is you avoid gross preprocessor crap.

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

#36
post #35

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

Nested functions in c are totally awesome and perfectly safe as long as a) you don't pass them as function pointers and b) care about executable stacks. The nice thing is you avoid gross preprocessor crap.

You probably want blocks, then: https://en.wikipedia.org/wiki/Blocks_(C_language_extension)

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

#37
post #35

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

Nested functions in c are totally awesome and perfectly safe as long as a) you don't pass them as function pointers and b) care about executable stacks. The nice thing is you avoid gross preprocessor crap.

When I was experimenting with threaded VM dispatch using computed gotos I discovered that GCC supports nested functions with __attribute__((constructor)). This hack allowed exporting computed goto addresses outside the execution loop function so that they'd be available when compiling bytecode.

This was useful because it meant your threaded jumps required fewer steps in the pipeline (compared to indexing a jump table), while also not needing any conditional for the threaded branch (e.g. not even checking for a NULL address before entering the loop, to initialize or substitute address placeholders).

The performance benefits of the constructor hack (low double digits, IIRC, maybe single digit, for a contrived test) were greater prior to Haswell (perhaps returning with Spectre mitigations?), but definitely not worth the headache of maintaining such non-portable, GCC-specific code. It did drive home, however, not only the usefulness of computed gotos (which are widely supported, excepting Visual Studio, and provide a far greater performance impact themselves), but the usefulness, in terms of design possibilities, of the ability to resolve computed goto addresses outside the function, which isn't supported anywhere except with that hack, AFAIK.

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

#38
post #35

Earlier quoted context omitted.

Nested functions in c are totally awesome and perfectly safe as long as a) you don't pass them as function pointers and b) care about executable stacks. The nice thing is you avoid gross preprocessor crap.

You probably want blocks, then: https://en.wikipedia.org/wiki/Blocks_(C_language_extension)

I'm very happy to see blocks show up, despite that they aren't yet supported by gcc. I keep hoping.

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

#39

Earlier quoted context omitted.

I think it gives credability right off the bat.

Ideally, it wouldn't.

But we don't live in that world. Someone that name drops their company name is more credible that some random blogger that works at a hardware store
Post reply on HN