Does it really matter that he's a "Microsoft Engineer" or is that just thrown in there to ruffle old people's feathers?
If Microsoft is using the hours of the engineer’s workday for this purpose, it provides insight that does matter.
31–39 of 39 posts
Does it really matter that he's a "Microsoft Engineer" or is that just thrown in there to ruffle old people's feathers?
If Microsoft is using the hours of the engineer’s workday for this purpose, it provides insight that does matter.
Earlier quoted context omitted.
I think it gives credability right off the bat.
Ideally, it wouldn't.
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.
Why can't they write the code to a writeable page then remove the write permissions when they need to execute it?
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:…
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.
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.
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.
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)