• @[email protected]
    link
    fedilink
    English
    31 year ago

    Caution disabling mitigations. Only enable on air-gap devices (devices without any connection, airplane mode).

    • @kadu
      link
      English
      21 year ago

      deleted by creator

      • @[email protected]
        link
        fedilink
        English
        11 year ago

        Hehe. Or they could send a 0 to your fan velocity. Or flash/lock (setting the flash bit to 0) your BIOS through ACPI calls. Even stolen your Steam token credential. I saw an example that runs commands as a Systemd volatile user service. There are a few POCs on GitHub about recovery passwords from the browser (sand-boxed environment) for generic environments. I think that everyone here is old enough to understand the consequences of our acts.

    • Mkengine
      link
      fedilink
      English
      11 year ago

      Do you mean I would have to execute the code for enabling and disabling every time I switch Wifi on and off? How severe is this, would it be okay to use it with wifi at home or does that not matter?

      • @[email protected]
        link
        fedilink
        English
        31 year ago

        Ideally yes, though it would probably also require a reboot to apply. Realistically disabling security mitigations should only expose you to risk when you execute untrusted code (e.g. load a website, run an untrusted program, or etc.), but there’s no way of telling if someone could connect to your system using an exploit and then abuse those hardware security flaws.

        Consider your own risk tolerance – is it worth it to you to get that extra few % of performance and risk someone gaining access to information on your Deck (and/or using that information to access other sensitive information)? It might also be worth mentioning that most games aren’t 100% trustworthy since we don’t exactly know what they’re running since game studios don’t share their source code.

  • AutoTL;DRB
    link
    fedilink
    English
    11 year ago

    This is the best summary I could come up with:


    A Phoronix reader recently published a guide that at its heart is a set of commands aimed at boosting the performance of SteamOS on the AMD APU powered Steam Deck.

    Here are some benchmarks showing the performance impact from these changes on the SteamOS 3.5 Preview release.

    The set of changes include setting the Steam Deck’s Van Gogh APU to the performance governor, adjusting the MGLRU settings, adjusting the memlock values, setting the I/O scheduler to Kyber, silencing the watchdog timer, and avoiding extra operations on file access times.

    See this blog post for all the details and instructions.

    Following my recent SteamOS 3.4 vs. SteamOS 3.5 Preview benchmarks, I repeated the SteamOS 3.5 Preview run while applying these optimizations as recommended.

    No other changes were made to the Steam Deck besides making the noted changes and then repeating the benchmarks.


    The original article contains 141 words, the summary contains 141 words. Saved 0%. I’m a bot and I’m open source!

    • @[email protected]
      link
      fedilink
      English
      31 year ago

      The original article contains 141 words, the summary contains 141 words. Saved 0%.

      Big miss from AutoTLDR this time around.