Those are kernel parameters, it's the same idea as command-line parameters in a normal program.
They're usually passed in by the bootloader (excepting the case when the kernel itself is the bootloader, such as in a standalone efi build - in that case you pass them in the kernel config).
Oh...can't wait for this to start showing up in production. And, just like every other time 'advice' like this is taken uncritically, when something bad happens the devs will just point at us and say "security problem...all on you" and never face a single consequence. But, hey, they got rid of 'useless' security and some-guy-on-the-Internet said they will get 25% back.
Is it a security problem on a single user gaming computer or a laptop?
Generally not.
If your production system is managed competently, I'm certain that there are engineers that can assess risk vs. performance and whether spectre and similar issues warrant those mitigations in your specific environment and make the appropriate design decisions.
If on the other hand your system is managed by "best-practices", distro defaults, and what "some-guy-on-the-internet said", well then you have much bigger problems.
I'd be interested in some companion material to evaluate the cost/benefit tradeoff here.
My gut says that single user machines it doesn't matter so much, however these same machines probably run a lot of untrusted JavaScript that may be able to exploit things.
A crud rest service receiving requests from the open internet, probably a bad idea to disable mitigations on that machine.
On the other hand, a video transcoder or similar picking tasks off a queue and writing back to storage maybe it's fine? Though I'll admit I'm not sure that there wouldn't be ways to cause (sensitive) data to get into the output file, so would default to leaving everything enabled, especially since the input to transcode would be arbitrary
1) The canonical use case is "steal your login credentials/crypto keys". So yes you have to care about single users, if the single user has access to sensitive info.
2) No, most people (not just engineers) are bad at risk assessment. Like thinking "my single user system shouldn't care about this".
3) I was talking about prod environments, not your random laptop.
Observation: While there may very well be security implications of adding these kernel parameters to a Linux system that is running directly on bare-metal x86 hardware (as other posters have alluded to) -- some of these flags might have no negative effect on security IF the Linux in question is running in an emulated and/or code-transpiled and/or virtualized environment -- i.e., Bochs or QEMU or various x86 emulators written in JavaScript that run on a browser...
(Simple example: You probably wouldn't care much about Spectre mitigations if you're running Linux on a x86 emulator on an ARM CPU...)
In other words, some of these kernel parameters COULD give speed increases in virtualized environments WITHOUT sacrificing a corresponding loss of security, due to differences between a software-emulated x86 environment, and a hardware bare-metal actual x86 environment...
The trick then, can be boiled down to:
a) Know your Linux host environment...
b) Know what implications given kernel parameters will have in that environment...
a) The specific x86 chip manufacturer and architecture (i.e., Intel, AMD, VIA, IDT, Cyrix, Transmeta, Zhaoxin, MCST (Elbrus), ? -- see https://en.wikipedia.org/wiki/List_of_x86_manufacturers -- there's a huge difference in potential security issues between say, the earliest Intel 386, and the latest Intel or AMD (or compatible) 64-bit x86 multi-cored multi-threaded CPU...
b) What security issues are potentially present in that CPU;
c) What the Virtual Machine / Emulator and/or Virtualized Environment does or doesn't do.
(For example, if you use Bochs (https://bochs.sourceforge.io/) for the guest environment on an x86 host -- then there's absolutely nothing that the guest OS can do to mitigate host OS security issues -- that's because all instructions inside of the guest are emulated -- security must be handled at the level of the OS/Hardware that is running Bochs, that is, at the level of the host.)
Now, things get slightly more weird with Virtual Machines/Emulators/Virtual Environments that permit some/all of the x86 instructions to run directly on the host hardware.
Here we have to distinguish between user-mode and "protected mode" (OS and/or Hypervisor, Ring < 3, instructions)...
You see, a Virtual Machines/Emulator/Virtual Environments -- may permit patterns of the following sort:
1) Some/All of the user-mode x86 instructions in the guest environment to run directly in the host environment without translation/modification...
2) Some/All of the user-mode x86 instructions AND some/all of the "protected mode" (OS and/or Hypervisor, Ring < 3, instructions) to run directly in the host environment without translation/modification...
Now, I am not an expert on any of this.
I am not an expert on all of the Virtual Machines/Emulator/Virtual Environments out there, nor am I an expert on all x86 instructions, protected mode or user mode...
But what I can tell you is simply this:
What x86 instructions a Virtual Machine/Emulator/Virtual Environment permits to be run directly, that is, which x86 instructions, existing in the guest OS, ran directly on the host CPU (without modification or deletion or "hooking"/"intercepting" or what-have-you), could have a large impact on security...
Which is a double-edged sword!
The more power that is given to the guest OS to access the lower layers (the host or physical hardware) -- the more guest OS's can potentially mitigate security issues...
But on the other hand:
The more power that is given to a guest OS to access the lower layers (the host or physical hardware) -- the more that guest OS can potentially CAUSE security issues!
It's a double-edged sword!
Ultimately: The more you can know about the layers of your specific stack, the better the position you'll be in to control security, and security-related issues...
Anyway, great question!
I'm not the expert... take everything that I'm saying with the proverbial "grain of salt"... It's a good idea to do all of the research necessary to know your own specific stack...
Also, one thing that I do know -- that if you're running an x86 emulator on a non-x86 CPU, the option (from the Virtual Machine/Emulator/Virtual Environment's point-of-view) of simply passing on instructions to the lower-level CPU for direct execution -- no longer exists -- in other words, running on a non-x86 CPU (i.e. ARM, RISC-V, etc.) -- the Virtual Machine/Emulator/Virtual Environment now MUST translate or interpret x86 instructions in the guest -- it can no longer ask the underlying host to run them directly, without...
I appreciate the detailed response! You certainly got the gears turning in my brain. A couple points:
> What x86 instructions a Virtual Machine/Emulator/Virtual Environment permits to be run directly, that is, which x86 instructions, existing in the guest OS, ran directly on the host CPU (without modification or deletion or "hooking"/"intercepting" or what-have-you), could have a large impact on security...
How would I even begin to map out which instructions get passed directly to the host cpu? I mean even if we just look at KVM, there's many other pieces of software that go into a virtualization environment. Wouldn't qemu, virsh, or KVM versions/configuration impact which instructions go right to the hardware? We haven't even gotten to the guest config, or any host hardware details! My instinct says it's extremely difficult to answer our question without a team of engineers.
> if you're running an x86 emulator on a non-x86 CPU, the option (from the Virtual Machine/Emulator/Virtual Environment's point-of-view) of simply passing on instructions to the lower-level CPU for direct execution -- no longer exists -- in other words, running on a non-x86 CPU (i.e. ARM, RISC-V, etc.) -- the Virtual Machine/Emulator/Virtual Environment now MUST translate or interpret x86 instructions in the guest -- it can no longer ask the underlying host to run them directly, without modification...
Makes sense to me. My follow up is now, does paravirtualization effectively create the same translation requirement? If I have an x86 xen-based hypervisor running x86 guests, does the virtual interface provided by xen give us a similar security control that ARM->x86 provides? (Or at least "good enough")?
I appreciate the appreciation! But please remember I am not an expert in this area -- only a fellow interested party. A "student" (for lack of a better term) of sorts. I'll tell you everything I know -- but keep in mind that in this setting I am not unlike Hamlet's Horatio -- that is, "There are more things in Heaven and Earth -- that are dreamt of in my philosophy..." :-)
>Wouldn't qemu, virsh, or KVM versions/configuration impact which instructions go right to the hardware?
They would indeed!
>How would I even begin to map out which instructions get passed directly to the host cpu?
It's a great question!
If I recall correctly, Bochs has/had a compilation option whereby if a flag was set, Bochs would to (at the expense of a lot of speed!) proceed to create a log or report or tallying of some sort -- such that when you exited it, it would show a list of each x86 instruction type that was used during runtime -- in other words, if you ran an OS in Bochs -- you could then get a list of ALL of the x86 instructions it used! Very handy if you're trying to get a new/alien OS to work on an x86 emulator, if/when in early versions of the emulator there might be bugs in emulating specific x86 instructions...
QEMU might have (or have had!) the same facility. I am not a QEMU expert, so I don't know.
Also, there's at least 3 possible things that can happen to any given instruction:
1) It can go through unmodified;
2) It can go through modified (for example, jumps may have their target address modified; this is because if code portions are expanded because of other modification, jump target locations will change...)
3) It can be intercepted by the VM environment (and/or Hypervisor), where specific code in the VM environment or Hypervisor is executed to replace or emulate the functionality of the instruction...
QEMU might have a way to log/count instructions that it intercepts/modifies, albeit, if this exists, this would probably be a compilation-time switch that would need to be set, and performing this would probably slow down guest considerably...
>My instinct says it's extremely difficult to answer our question without a team of engineers.
My instinct says that your instinct is extremely correct!
>My follow up is now, does paravirtualization effectively create the same translation requirement?
Again, I'm not an expert. I would guess that it would not be off-limits for the paravirtualizer to engage in translation, but I would also guess that if the paravirtualizer could avoid it for the most part, it would... but those are only guesses...
If you really want to understand "how deep the rabbit hole goes" (AFAIK) -- then I would start by going here:
Now, what is this mess of code, you might ask? Well for this exercise, IGNORE MOST OF IT!. Do a word search for 'procedure interpret', of which part looks like this:
repeat i:= code[pc]; pc:= pc+1;
case i.op of
add : begin m[sp+1]:= m[sp+1]+m[sp]; sp:= sp+1 end;
neg : m[sp]:= -m[sp];
mul : begin m[sp+1]:= m[sp+1]*m[sp]; sp:= sp+1 end;
divd : begin m[sp+1]:= m[sp+1] div m[sp]; sp:= sp+1 end;
[...20 or so more lines deleted, for brevity...]
end
until h
end;
So what is that, and how is it relevant to this discussion you may ask! Ah! You see, that's a Turing-complete machine implemented 20 or so lines of Pascal Code! (in this case, inside of an early pascal compiler, the reason for which being that if yo...
I had the exact same kernel parameters in my NixOS configuration[0] and after some benchmarks (mostly Emacs-related) I observed a 10-15% speedup, pretty neat.
At home, I don't do threat models or risk assessments. I also don't care that much about 5 to 15% increase in benchmarks, I just hope that the OS vendor makes sensible decisions in regards to safety and performance.
At work, I do care about small increases but I would never just copy some random kernel options found on an otherwise empty web site. Cargo culting useless or harmful options is a very tangible threat.
The website actually started as a sort of joke by someone in the kernel community. Then it stuck around.
For example, I found it useful professionally. We're releasing a new hardware model. We're doing some in-depth performance tuning/evaluation. To understand our performance characteristics, I needed us to break down the performance change into improvement due to new hardware and reduction due to new mitigations.
Linking this page in the Jira issue was the fastest way to get the point across what we needed to look into.
It is not, at all, something I would ever recommend to lay people, or use in the actual shipping product.
If everybody have mitigations on, nobody spends time to develop exploits for unpatched systems, so eventually disabling mitigations from your gaming PC will not make it very insecure.
Of course this is possible if everybody else keeps their mitigations on.
If you have the spare cash and room, it's not a bad idea to keep gaming devices separate from work or personal devices.
Gaming may conflict with security in several aspects:
- Performance optimizations (eg. this website)
- Installing various closed-source drivers, peripheral utilities, or custom installers
- Granting privileged access to legitimate anti-cheat software
- Or even, perish the thought, installing pirated games and cracks
If you enable 2FA on your Steam account, backup your saved games to the cloud, and otherwise keep your gaming PC devoid of any remotely sensitive or valuable data, you can mostly have peace of mind as you blissfully install all kinds of untrusted software on what is essentially a glorified gaming console.
If you want to use your nice 38" curved monitor for non-gaming activities on a secure computer, a KVM switch is pretty cheap.
(Of course, if you're happy playing DRM-free games on Linux with a sufficiently powerful AMD card, you don't need to bother with any of that.)
mods are grate but many (not all) mods basically mean running programs with the same permissions as the game from not necessarily trusted sources
and while there are many trustable and reputable mods out there there have been multiple cases of high profile mods stealing user logins, e.g. in Minecraft.
Now that I think about it, don't most decent screens have multiple input ports nowadays?
For speakers you can just use a Y connector. Add a wireless mouse with multiple outputs built-in (eg Logitech MX Master), or a separate gaming mouse if you prefer, and that just leaves the keyboard to switch between the two devices.
Yeah, I've been doing exactly what you describe and it gets the job done. I just daydream of being able to press a button and all my peripherals are switched without significant lag.
Changing the input on my monitor requires three button presses, and comes with a noticeable lag. Then I've got to press a button on the bottom of my mouse, and another button for my keyboard. If I bought a fancy KVM, I'd be able to swap everything in a couple seconds! It'd be nice also to hook up a mic and webcam but I'll probably just think about it for another 6 months and never pull the trigger.
it's nearly never someone targeting you, it's most times dining targeting thousands of arbitrary people at once
if you are especially unlucky the atack comes with you opening a website or similar
and honestly firewalls often only help against atacks against services with open ports running on your system, once they are in your system they have a lot of ways to circumvent your firewall (assuming it's a desktop system or similar, mainly not a single service system)
Sure but how many scripts are scanning the internet for exploitable Spectre and Meltdown vulns? As I understand it they are quite difficult to implement and execute at scale.
You’re grossly underestimating how difficult it is to pull off these exploits in practice. Even before getting to post compromise activity the adversary has to have a JavaScript VM escape, and also escape the browser sandbox. That shit is worth serious cash and nobody is gonna be spamming the internet with their precious zero days.
Even then you have to perform privilege escalation and map out the network. By this point you’re already pwned. The adversary isn’t gonna be looking for or even capable of pulling off a low level cpu exploit.
Also it's not like a gaming PC is not a worthy target. Gaming has sizeable black and grey markets, and also could be held hostage, seeing how often progress is tied to an account, and how personally attached people become to their progress.
As long as the vulnerability protections are on by default then this sort of thing will only affect people looking to tinker. I like the minimalism of course but the blogpost breaking down the parameters is obviously way more useful.
I appreciate the brevity of the site but it leaves a little to be desired. They should have a footer section that explains each option and what major versions of kernel support them, or at least a text link to the latest kernel command line arguments. [1]
Note the kernel version in the URL as the options evolve with time. Some will be deprecated and some added but the kernel does not always complain if you utilize a deprecated option or an option that does not exist.
I have mitigations disabled on my laptop. I mainly work offline and only run trusted code. I also use noscript and only enable javascript on trusted sites. I also use auto tab suspend to stop javascript from running if I am not using the tab.
Realistically, there is very little threat to turning off the mitigations with enough precautions in place. Obviously not recommended on a vps or other shared servers etc.
I find this dubious -- I think the last parameter (`mitigations=off`) does the job they're after.
Regardless, I'd expect a small/difficult-to-discern improvement in practical use-cases. Caveat: on relatively recent chips. Many-generations old i3/i5 chips with none of these mitigations in hardware probably are suffering.
I'm sure synthetic `openssl` benchmarks are favorable, but I don't use my computer for that
If you're churning enterprise data, sure, it might be meaningfully quicker - but good luck convincing auditors that was a good idea.
58 comments
[ 2.8 ms ] story [ 101 ms ] threadThey're usually passed in by the bootloader (excepting the case when the kernel itself is the bootloader, such as in a standalone efi build - in that case you pass them in the kernel config).
Some previous appearances -- there were others:
https://news.ycombinator.com/item?id=22830330 (368 points by laurentdc on April 10, 2020)
https://news.ycombinator.com/item?id=19928110 (11 points by Tomte on May 16, 2019)
https://news.ycombinator.com/item?id=18497751 (4 points by jcelerier on Nov 20, 2018)
Source: https://github.com/jcelerier/jcelerier.github.io/blob/master...
Discussion: https://linuxreviews.org/HOWTO_make_Linux_run_blazing_fast_(...
Generally not.
If your production system is managed competently, I'm certain that there are engineers that can assess risk vs. performance and whether spectre and similar issues warrant those mitigations in your specific environment and make the appropriate design decisions.
If on the other hand your system is managed by "best-practices", distro defaults, and what "some-guy-on-the-internet said", well then you have much bigger problems.
Also, best website ever.
My gut says that single user machines it doesn't matter so much, however these same machines probably run a lot of untrusted JavaScript that may be able to exploit things.
A crud rest service receiving requests from the open internet, probably a bad idea to disable mitigations on that machine.
On the other hand, a video transcoder or similar picking tasks off a queue and writing back to storage maybe it's fine? Though I'll admit I'm not sure that there wouldn't be ways to cause (sensitive) data to get into the output file, so would default to leaving everything enabled, especially since the input to transcode would be arbitrary
2) No, most people (not just engineers) are bad at risk assessment. Like thinking "my single user system shouldn't care about this".
3) I was talking about prod environments, not your random laptop.
(Simple example: You probably wouldn't care much about Spectre mitigations if you're running Linux on a x86 emulator on an ARM CPU...)
In other words, some of these kernel parameters COULD give speed increases in virtualized environments WITHOUT sacrificing a corresponding loss of security, due to differences between a software-emulated x86 environment, and a hardware bare-metal actual x86 environment...
The trick then, can be boiled down to:
a) Know your Linux host environment...
b) Know what implications given kernel parameters will have in that environment...
c) Choose trade-offs accordingly...
a) The specific x86 chip manufacturer and architecture (i.e., Intel, AMD, VIA, IDT, Cyrix, Transmeta, Zhaoxin, MCST (Elbrus), ? -- see https://en.wikipedia.org/wiki/List_of_x86_manufacturers -- there's a huge difference in potential security issues between say, the earliest Intel 386, and the latest Intel or AMD (or compatible) 64-bit x86 multi-cored multi-threaded CPU...
b) What security issues are potentially present in that CPU;
c) What the Virtual Machine / Emulator and/or Virtualized Environment does or doesn't do.
(For example, if you use Bochs (https://bochs.sourceforge.io/) for the guest environment on an x86 host -- then there's absolutely nothing that the guest OS can do to mitigate host OS security issues -- that's because all instructions inside of the guest are emulated -- security must be handled at the level of the OS/Hardware that is running Bochs, that is, at the level of the host.)
Now, things get slightly more weird with Virtual Machines/Emulators/Virtual Environments that permit some/all of the x86 instructions to run directly on the host hardware.
Here we have to distinguish between user-mode and "protected mode" (OS and/or Hypervisor, Ring < 3, instructions)...
You see, a Virtual Machines/Emulator/Virtual Environments -- may permit patterns of the following sort:
1) Some/All of the user-mode x86 instructions in the guest environment to run directly in the host environment without translation/modification...
2) Some/All of the user-mode x86 instructions AND some/all of the "protected mode" (OS and/or Hypervisor, Ring < 3, instructions) to run directly in the host environment without translation/modification...
Now, I am not an expert on any of this.
I am not an expert on all of the Virtual Machines/Emulator/Virtual Environments out there, nor am I an expert on all x86 instructions, protected mode or user mode...
But what I can tell you is simply this:
What x86 instructions a Virtual Machine/Emulator/Virtual Environment permits to be run directly, that is, which x86 instructions, existing in the guest OS, ran directly on the host CPU (without modification or deletion or "hooking"/"intercepting" or what-have-you), could have a large impact on security...
Which is a double-edged sword!
The more power that is given to the guest OS to access the lower layers (the host or physical hardware) -- the more guest OS's can potentially mitigate security issues...
But on the other hand:
The more power that is given to a guest OS to access the lower layers (the host or physical hardware) -- the more that guest OS can potentially CAUSE security issues!
It's a double-edged sword!
Ultimately: The more you can know about the layers of your specific stack, the better the position you'll be in to control security, and security-related issues...
Anyway, great question!
I'm not the expert... take everything that I'm saying with the proverbial "grain of salt"... It's a good idea to do all of the research necessary to know your own specific stack...
Also, one thing that I do know -- that if you're running an x86 emulator on a non-x86 CPU, the option (from the Virtual Machine/Emulator/Virtual Environment's point-of-view) of simply passing on instructions to the lower-level CPU for direct execution -- no longer exists -- in other words, running on a non-x86 CPU (i.e. ARM, RISC-V, etc.) -- the Virtual Machine/Emulator/Virtual Environment now MUST translate or interpret x86 instructions in the guest -- it can no longer ask the underlying host to run them directly, without...
> What x86 instructions a Virtual Machine/Emulator/Virtual Environment permits to be run directly, that is, which x86 instructions, existing in the guest OS, ran directly on the host CPU (without modification or deletion or "hooking"/"intercepting" or what-have-you), could have a large impact on security...
How would I even begin to map out which instructions get passed directly to the host cpu? I mean even if we just look at KVM, there's many other pieces of software that go into a virtualization environment. Wouldn't qemu, virsh, or KVM versions/configuration impact which instructions go right to the hardware? We haven't even gotten to the guest config, or any host hardware details! My instinct says it's extremely difficult to answer our question without a team of engineers.
> if you're running an x86 emulator on a non-x86 CPU, the option (from the Virtual Machine/Emulator/Virtual Environment's point-of-view) of simply passing on instructions to the lower-level CPU for direct execution -- no longer exists -- in other words, running on a non-x86 CPU (i.e. ARM, RISC-V, etc.) -- the Virtual Machine/Emulator/Virtual Environment now MUST translate or interpret x86 instructions in the guest -- it can no longer ask the underlying host to run them directly, without modification...
Makes sense to me. My follow up is now, does paravirtualization effectively create the same translation requirement? If I have an x86 xen-based hypervisor running x86 guests, does the virtual interface provided by xen give us a similar security control that ARM->x86 provides? (Or at least "good enough")?
I appreciate the appreciation! But please remember I am not an expert in this area -- only a fellow interested party. A "student" (for lack of a better term) of sorts. I'll tell you everything I know -- but keep in mind that in this setting I am not unlike Hamlet's Horatio -- that is, "There are more things in Heaven and Earth -- that are dreamt of in my philosophy..." :-)
>Wouldn't qemu, virsh, or KVM versions/configuration impact which instructions go right to the hardware?
They would indeed!
>How would I even begin to map out which instructions get passed directly to the host cpu?
It's a great question!
If I recall correctly, Bochs has/had a compilation option whereby if a flag was set, Bochs would to (at the expense of a lot of speed!) proceed to create a log or report or tallying of some sort -- such that when you exited it, it would show a list of each x86 instruction type that was used during runtime -- in other words, if you ran an OS in Bochs -- you could then get a list of ALL of the x86 instructions it used! Very handy if you're trying to get a new/alien OS to work on an x86 emulator, if/when in early versions of the emulator there might be bugs in emulating specific x86 instructions...
QEMU might have (or have had!) the same facility. I am not a QEMU expert, so I don't know.
Also, there's at least 3 possible things that can happen to any given instruction:
1) It can go through unmodified;
2) It can go through modified (for example, jumps may have their target address modified; this is because if code portions are expanded because of other modification, jump target locations will change...)
3) It can be intercepted by the VM environment (and/or Hypervisor), where specific code in the VM environment or Hypervisor is executed to replace or emulate the functionality of the instruction...
QEMU might have a way to log/count instructions that it intercepts/modifies, albeit, if this exists, this would probably be a compilation-time switch that would need to be set, and performing this would probably slow down guest considerably...
>My instinct says it's extremely difficult to answer our question without a team of engineers.
My instinct says that your instinct is extremely correct!
>My follow up is now, does paravirtualization effectively create the same translation requirement?
Again, I'm not an expert. I would guess that it would not be off-limits for the paravirtualizer to engage in translation, but I would also guess that if the paravirtualizer could avoid it for the most part, it would... but those are only guesses...
If you really want to understand "how deep the rabbit hole goes" (AFAIK) -- then I would start by going here:
http://pascal.hansotten.com/uploads/pascals/pascal-s%20sneps...
Now, what is this mess of code, you might ask? Well for this exercise, IGNORE MOST OF IT!. Do a word search for 'procedure interpret', of which part looks like this:
procedure interpret;
begin pc:= 0; h:= false; end;So what is that, and how is it relevant to this discussion you may ask! Ah! You see, that's a Turing-complete machine implemented 20 or so lines of Pascal Code! (in this case, inside of an early pascal compiler, the reason for which being that if yo...
[0] https://github.com/siraben/dotfiles/commit/c0eb0b43083738cab...
Funny timing.
At home, I don't do threat models or risk assessments. I also don't care that much about 5 to 15% increase in benchmarks, I just hope that the OS vendor makes sensible decisions in regards to safety and performance.
At work, I do care about small increases but I would never just copy some random kernel options found on an otherwise empty web site. Cargo culting useless or harmful options is a very tangible threat.
For example, I found it useful professionally. We're releasing a new hardware model. We're doing some in-depth performance tuning/evaluation. To understand our performance characteristics, I needed us to break down the performance change into improvement due to new hardware and reduction due to new mitigations.
Linking this page in the Jira issue was the fastest way to get the point across what we needed to look into.
It is not, at all, something I would ever recommend to lay people, or use in the actual shipping product.
Of course this is possible if everybody else keeps their mitigations on.
If you have the spare cash and room, it's not a bad idea to keep gaming devices separate from work or personal devices.
Gaming may conflict with security in several aspects:
- Performance optimizations (eg. this website)
- Installing various closed-source drivers, peripheral utilities, or custom installers
- Granting privileged access to legitimate anti-cheat software
- Or even, perish the thought, installing pirated games and cracks
If you enable 2FA on your Steam account, backup your saved games to the cloud, and otherwise keep your gaming PC devoid of any remotely sensitive or valuable data, you can mostly have peace of mind as you blissfully install all kinds of untrusted software on what is essentially a glorified gaming console.
If you want to use your nice 38" curved monitor for non-gaming activities on a secure computer, a KVM switch is pretty cheap.
(Of course, if you're happy playing DRM-free games on Linux with a sufficiently powerful AMD card, you don't need to bother with any of that.)
mods are grate but many (not all) mods basically mean running programs with the same permissions as the game from not necessarily trusted sources
and while there are many trustable and reputable mods out there there have been multiple cases of high profile mods stealing user logins, e.g. in Minecraft.
For speakers you can just use a Y connector. Add a wireless mouse with multiple outputs built-in (eg Logitech MX Master), or a separate gaming mouse if you prefer, and that just leaves the keyboard to switch between the two devices.
Changing the input on my monitor requires three button presses, and comes with a noticeable lag. Then I've got to press a button on the bottom of my mouse, and another button for my keyboard. If I bought a fancy KVM, I'd be able to swap everything in a couple seconds! It'd be nice also to hook up a mic and webcam but I'll probably just think about it for another 6 months and never pull the trigger.
Also the website is for everyone that does not know about kernel flags completely useless.
And turn on eBPF for full insecurity.
if you are especially unlucky the atack comes with you opening a website or similar
and honestly firewalls often only help against atacks against services with open ports running on your system, once they are in your system they have a lot of ways to circumvent your firewall (assuming it's a desktop system or similar, mainly not a single service system)
Even then you have to perform privilege escalation and map out the network. By this point you’re already pwned. The adversary isn’t gonna be looking for or even capable of pulling off a low level cpu exploit.
also known as
forgot how fundamental broken the security model of many cpus is
also know as
who cares if it's my gaming PC and I'm not a hight profile target
or
omg, don't do online banking on that system
Well... if you keep it just for online banking it's perfectly safe and fast.
https://www.kernel.org/doc/html/latest/admin-guide/kernel-pa...
When you do know how computers work and how your threat models looks like, absolutely do run this. 10-15% more performance is no joke.
[0] https://linuxreviews.org/HOWTO_make_Linux_run_blazing_fast_(...
Note the kernel version in the URL as the options evolve with time. Some will be deprecated and some added but the kernel does not always complain if you utilize a deprecated option or an option that does not exist.
[1] - https://www.kernel.org/doc/html/v5.15/admin-guide/kernel-par...
Realistically, there is very little threat to turning off the mitigations with enough precautions in place. Obviously not recommended on a vps or other shared servers etc.
Regardless, I'd expect a small/difficult-to-discern improvement in practical use-cases. Caveat: on relatively recent chips. Many-generations old i3/i5 chips with none of these mitigations in hardware probably are suffering.
I'm sure synthetic `openssl` benchmarks are favorable, but I don't use my computer for that
If you're churning enterprise data, sure, it might be meaningfully quicker - but good luck convincing auditors that was a good idea.