Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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?pa...NAX-LSM-Module

  • #2
    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.

    Comment


    • #3
      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?

      Comment


      • #4
        Originally posted by Ironmask View Post
        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.
        Last edited by NobodyXu; 21 August 2021, 10:13 PM.

        Comment


        • #5
          Originally posted by Ironmask View Post
          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
          Originally posted by Ironmask View Post
          the performance improvements a JIT compiler can provide are phenomenal
          with phenomenal run time wasted on optimizations
          Last edited by pal666; 22 August 2021, 10:28 AM.

          Comment


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

            Comment


            • #7
              Originally posted by pal666 View Post
              with phenomenal run time wasted on optimizations
              This is what tiered compilation is for.

              Comment


              • #8
                Originally posted by Ironmask View Post

                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.

                Comment

                Working...
                X