Announcement

Collapse
No announcement yet.

Linux 5.1 Getting A Minor Spectre V2 Retpolines Optimization For Select Instances

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

  • Linux 5.1 Getting A Minor Spectre V2 Retpolines Optimization For Select Instances

    Phoronix: Linux 5.1 Getting A Minor Spectre V2 Retpolines Optimization For Select Instances

    As the latest on the Spectre/Meltdown front for the Linux kernel, the in-development Linux 5.1 kernel is bringing an optimization for Retpolines "return trampolines" so GCC will generate more efficient code on x86/x86_64 in its mitigations against Spectre Variant Two...

    http://www.phoronix.com/scan.php?pag...poline-GCC-Opt

  • #2
    Originally posted by debianxfce View Post
    For non debug and non retpoline kernels those idiots can not flag the stupid error message out.
    https://git.kernel.org/pub/scm/linux.../bugs.c?h=v5.0


    Code:
    #ifdef CONFIG_DEBUG_KERNEL
    pr_err("Spectre mitigation: kernel not compiled with retpoline; no mitigation available!");
    #endif
    But you can though, so who cares?

    Comment


    • #3
      Stupid question (but I'm sure I'll get a kind response lol) but is there any benefit to compiling the kernel without mitigations rather than switching the mitigations off at boot time with the kernel options?

      Comment


      • #4
        Originally posted by Murple View Post
        Stupid question (but I'm sure I'll get a kind response lol) but is there any benefit to compiling the kernel without mitigations rather than switching the mitigations off at boot time with the kernel options?
        No.

        But if you need to compile your own kernel already for other reasons (which isn't as hard as it may seem), then you might as well set the additional things on compile time.

        Comment


        • #5
          Originally posted by starshipeleven View Post
          No.

          But if you need to compile your own kernel already for other reasons (which isn't as hard as it may seem), then you might as well set the additional things on compile time.
          Yeah, this. Not much dependency hell.

          Comment


          • #6
            Originally posted by Weasel View Post
            Yeah, this. Not much dependency hell.
            Why the fuck are you always dropping completely unrelated buzzwords lately?

            How in the name of Jeezus are you relating the current situation, which is just choosing compile-time options of Linux kernel, to dependency hell.

            Do you even know what is a Linux kernel, or what is dependency hell?

            Comment


            • #7
              Originally posted by starshipeleven View Post
              No.

              But if you need to compile your own kernel already for other reasons (which isn't as hard as it may seem), then you might as well set the additional things on compile time.
              Thanks. I don't mind compiling kernels but I wouldn't want to do it unnecessarily. I don't mind on a device where the kernel isn't updated often, but I try to run mainline as much as possible so it would be quite time consuming to maintain.

              Comment


              • #8
                Originally posted by starshipeleven View Post
                Why the fuck are you always dropping completely unrelated buzzwords lately?

                How in the name of Jeezus are you relating the current situation, which is just choosing compile-time options of Linux kernel, to dependency hell.

                Do you even know what is a Linux kernel, or what is dependency hell?
                WTF are you flipping for? Did you even see what I quoted? You said that compiling the kernel is not so difficult, and yes it's not because it doesn't have many dependencies, which is what I said and agreed with.

                Try compiling a package like ffmpeg without a package manager with ALL encoders/decoders/demuxers (let's say you want to compile all libs with -flto or custom options, w/e) and compile everything from source by grabbing them yourself, then go fucking talk to me about knowing what "dependency hell" is. I didn't mean the literal sense, it's still hell even if just for building.
                Last edited by Weasel; 03-08-2019, 05:44 PM.

                Comment


                • #9
                  Weasel

                  SDL and SDL related if not compiled with forethought can quickly turn into dependency hell. I don''t have time for source based or heavy compiling oriented distributions these days. Of course you don't need one of those to build your own custom kernel. The only dependency hell you can run into is module or driver built-ins and how they are related and what needs the other in the kernel configuration for a given module or built-in but still is not a true dependency hell, like building a bunch of libraries with restricted functionality compiling an app that requires libraries compiled with the latest well you get the idea, having to re-compile a ton of stuff with updated libraries so you can have the most latest stable version of a given app. Now that is dependency hell 100% true nightmare if you are are using slack want the newer version of a specific app. Either that or you can just settle with an older stable version or settle with older libraries and older software.

                  Sometimes staying with much older software pays off in the long run, especially if your not pick pick picky.

                  I am on Manjaro though so you can dis my disco if you wan't, stuff seems to be working astonishingly well for how up to date app versions are.

                  What was the original subject? Where was I oh yea subject kernel 5.1 never mind my bad.
                  Last edited by creative; 03-09-2019, 08:36 AM.

                  Comment


                  • #10
                    Originally posted by Weasel View Post
                    You said that compiling the kernel is not so difficult, and yes it's not because it doesn't have many dependencies, which is what I said and agreed with.
                    Dependency hell is not "having a lot of dependencies", it's "having conflicts within the dependencies". Only some applications have that issue, so you have it reversed.

                    Chrome could be like that if you try to build it all from source (and not rely on binary libs they ship or fetch from other places when building).

                    I didn't mean the literal sense, it's still hell even if just for building.
                    See, that's what I'm saying. Stop giving your own interpretation to things.

                    Comment

                    Working...
                    X