Announcement

Collapse
No announcement yet.

The Disappointing Direction Of Linux Performance From 4.16 To 5.4 Kernels

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

  • #91
    Wow after reading all the comments here, it has become clear that there are quite a few ignorant users here.

    This is coming from someone, who, as an ignorant teenager many years ago, was a black hatter.

    Point 1: If any of the CPU exploits are in use, you won't know it. Someone that figures out how to utilize any of the exploits isn't going to say anything.

    Point 2: It is POSSIBLE to write specially crafted javascript that can take advantage of a stealth exploit that does a complete stealth takeover of your machine. Depending on the exploit, it is then possible to do things like modify the bios to load exploited code, etc.

    I am not saying it has been done, but it is most certainly POSSIBLE. That fact alone should give you pause. You folks disabling mitigations and other security features are nuts.

    Hard to exploit vulnerabilities that have been exploited stay private. Quite often, only your data or access to your machine is sold or used fore nefarious purposes, not the vulnerability itself.

    Point 3: You can't detect the code doing the exploit because of the nature of the vulnerabilities. When they are exploited (if they haven't been already), the general public won't find out until someone makes a mistake.

    Comment


    • #92
      Originally posted by Paul Frederick View Post

      In case you are unaware Nvidia licenses technology from others. It is not theirs to just give away either. So a binary driver is the absolute best they can do. 70 years beyond the death of an author that may change? Until then Nvidia is bound by copyright law just as much as anyone else is.
      That's a poor excuse, if others GPU companies managed, especially smaller ones like AMD, nVidia could too if it wanted.
      I'd also guess most of these to-hide-technologies would no be in the kernel driver.
      Finding their drivers/hardware better sure, arguing about it all day ok, but I fail to see the point of trying to defend nVidia on the topic of not opening their driver.

      Comment


      • #93
        Originally posted by pgoetz View Post

        Don't rant: read and understand. The slowdown is largely due to hardware security mitigations, which you can turn off.
        I know. It's hardware flaws. So the question is if free-bugs Cpus are affected by mitigation as well.

        Comment


        • #94
          Originally posted by betam4x View Post
          I am not saying it has been done, but it is most certainly POSSIBLE. That fact alone should give you pause. You folks disabling mitigations and other security features are nuts.

          Hard to exploit vulnerabilities that have been exploited stay private. Quite often, only your data or access to your machine is sold or used fore nefarious purposes, not the vulnerability itself.
          A lot of my systems are
          1. Used for lengthy scientific computations
          2. Behind a firewall
          3. Are only accessible by trusted users, mostly scientists who both know nothing about hacking and don't care
          I can't think of any reason why I wouldn't disable mitigations on these systems.



          Comment


          • #95
            Originally posted by Azrael5 View Post
            I know. It's hardware flaws. So the question is if free-bugs Cpus are affected by mitigation as well.
            I'm not sure, but who has bug-free CPUs? AFAIK, the Intel vulnerabilities go back years and affect multiple generations of CPUs.

            Comment


            • #96
              Originally posted by pgoetz View Post

              I'm not sure, but who has bug-free CPUs? AFAIK, the Intel vulnerabilities go back years and affect multiple generations of CPUs.
              Cylons.

              Comment


              • #97
                FWIW, I wasn't able to replicate the performance delta using upstream kernels, running on a Google Compute Engine VM, machtype n1-highcpu-8, using a GCE Local SSD (SCSI-attached) for the first benchmark, which I believe was the pts/sqlite benchmark using a thread count of 1:

                SQLite 3.30.1
                Threads / Copies: 1
                Seconds < Lower Is Better
                5.4.0-rc3 ................. 224 |==========================================
                5.3.0 ..................... 225 |===========================================
                v5.4-rc3-80-gafb2442fa429 . 227 |===========================================
                5.4.0-rc7 ................. 223 |==========================================

                Processor: Intel Xeon (4 Cores / 8 Threads), Chipset: Intel 440FX 82441FX PMC, Memory: 1 x 7373 MB RAM, Disk: 11GB PersistentDisk + 403GB EphemeralDisk, Network: Red Hat Virtio device

                OS: Debian 10, Kernel: 5.4.0-rc3-xfstests (x86_64) 20191113, Compiler: GCC 8.3.0, File-System: ext4, System Layer: KVM

                Comment


                • #98
                  Originally posted by pgoetz View Post

                  I'm not sure, but who has bug-free CPUs? AFAIK, the Intel vulnerabilities go back years and affect multiple generations of CPUs.
                  Some kind of Arm Cpus are free from the known bugs.

                  Comment


                  • #99
                    Originally posted by Azrael5 View Post

                    I know. It's hardware flaws. So the question is if free-bugs Cpus are affected by mitigation as well.
                    No, mitigations are turned off for those CPUs.
                    For example Meltdown mitigation is turned off for AMD CPUs that are not affected.

                    Comment


                    • Originally posted by skeevy420 View Post

                      Cylons.
                      That's debatable. They wanted to kill everyone

                      Comment

                      Working...
                      X