"NAX" Linux Security Being Worked On For Helping Fend Off Fileless Malware Attacks

[phoronix]

Phoronix: "NAX" Linux Security Being Worked On For Helping Fend Off Fileless Malware Attacks

Due to the growing threat posed by file-less malware attacks where malware code is executed from anonymous executable memory pages that aren't backed by data on the file-system, the "NAX" Linux security module has been seeing work recently for helping to protect against such scenarios...

https://www.phoronix.com/scan.php?page=news_item&px=NAX-LSM-Module

[Developer12]

I haven't dug into the current work, but my first instinct is to require a JIT-capable program to very carefully declare what regions of memory it's putting JIT code into. I suspect that really only defends against malicious code injecting itself into an existing process though (ie. via buffer overflow and modification of a stack return pointer), so I probably don't understand the full scope of the issue.

[Ironmask]

Apple already doesn't allow JIT'ers to work on iOS, and .NET on UWP must be AOT compiled as well. If this trend continues, JIT compilers might become an endangered species. Which is really a shame, because the performance improvements a JIT compiler can provide are phenomenal, and you get tons of reflection and dynamic compilation capabilities. Maybe JIT compilers will simply be delegated to servers, and consumer platforms will use only AOT. Good thing .NET's AOT is already well-established and WASM is here to supplement performance-critical browser code since JavaScript can't be JIT'ed anymore. Still, this is kind of annoying and feels more like paranoia than security hardening. Where's the line between security and simply not being allowed to execute any code at all?

[NobodyXu]

Apple already doesn't allow JIT'ers to work on iOS, and .NET on UWP must be AOT compiled as well. If this trend continues, JIT compilers might become an endangered species. Which is really a shame, because the performance improvements a JIT compiler can provide are phenomenal, and you get tons of reflection and dynamic compilation capabilities. Maybe JIT compilers will simply be delegated to servers, and consumer platforms will use only AOT. Good thing .NET's AOT is already well-established and WASM is here to supplement performance-critical browser code since JavaScript can't be JIT'ed anymore. Still, this is kind of annoying and feels more like paranoia than security hardening. Where's the line between security and simply not being allowed to execute any code at all?

It is necessary to note that AOT actually provides better performance and uses less memory’s compared to JIT most of the time.
The only optimization that AOT is hard to do is profile based optimization, but even that is not undoable for AOT, just a bit hard to provides parameters/data close enough to real world.

Other than the portability and the profile based optimization, JIT is just a memory hog with slow start time and probably eats more CPU.
And most of the time JIT also comes with GC, another memory hog and CPU eater.

Regarding wasm, it’s totally different from JVM.
Compiler like llvm is able to optimize the code before generating wasm.
And, the wasm generator https://github.com/WebAssembly/binaryen can also performs some wasm-specific optimization.

In comparison, javac merely generates binary code without any optimization.
It is possible to use Graalvm, but then you will lose reflection.

And even reflection is not specific to Java, Rust, a compiled language also has compile-time “reflection”.
It is similar to Java reflection of which it provides token stream to the “reflection” code, but all done at compile-time and can be optimised just as normal code.

So for wasm, running in a wasm interpreter might lose some performance compared to JIT wasm, but I suppose with a well-optimized interpreter, the JIT wasm might not provide speedup as much as JIT for Java.

[pal666]

Apple already doesn't allow JIT'ers to work on iOS

don't worry, subj only disables jit 1) to anonymous pages and 2) for privileged processes. and they plan to add file attributes to allow to undisable it for some programs. and similar functionality is already available via other(more complex) security modules

the performance improvements a JIT compiler can provide are phenomenal

with phenomenal run time wasted on optimizations

[gigi]

so this is basically initial support...
doc rst provides info about what is possible with existing code..

[Ironmask]

with phenomenal run time wasted on optimizations

This is what tiered compilation is for.

[NobodyXu]

This is what tiered compilation is for.

TBF, tiered compilation merely speeds up the startup time.

JIT is still going to consume a lot of CPU time, being a memory hog and battery eater.