MDS Mitigation: any reason that's not enabled automatically?
-
You do understand pfsense is open source right - you could submit that wording if you wanted to..
https://docs.netgate.com/pfsense/en/latest/development/submitting-a-pull-request-via-github.htmlAn intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.11 | Lab VMs 2.8, 24.11 -
A system that has configuration options, should explain them, particularly if they are non-obvious.
There's the rub: what's 'obvious'?
Otherwise why even bother with a user friendly web interface?
To enable you to get the job done quickly. I don't know why some people have this "GUI means it's easy" mindset. GUI makes it convenient but not necessarily easy. You still have to know what you're doing. The GUI gives you common options grouped together in an easy to work with interface. It's not meant to be a replacement for the manual, or to supply general knowledge about networking, computing etc.
Just use the CLI, then you're not bothered by any "useless fluff".
I know what I'm doing from a networking perspective. I don't necessarily know how to achieve what I want on FreeBSD via CLI.
-
@KOM said in MDS Mitigation: any reason that's not enabled automatically?:
A system that has configuration options, should explain them, particularly if they are non-obvious.
There's the rub: what's 'obvious'?
A bug with a particular CPU architecture is non-obvious for anyone who's not steeped in computer security.
You can't compare that with knowing what a port, IP address, packet, netmask, etc. is. There are basics one must know to meaningfully use a particular tool, so basic networking knowledge has to be "assumed known" when dealing with a tool like pfSense.
What MDS is, and how it affects a firewall/routing/VPN software platform isn't standard knowledge, and thus can't be "assumed known".
The suggestion to google this information is almost as meaningful as certain ISPs suggesting you use their online ticketing system if you experience trouble with your internet connection... ;)
-
@johnpoz said in MDS Mitigation: any reason that's not enabled automatically?:
You do understand pfsense is open source right - you could submit that wording if you wanted to..
https://docs.netgate.com/pfsense/en/latest/development/submitting-a-pull-request-via-github.htmlThanks. I'll have to look into this. However, since for the most part I'm not doing sw development anymore, and even less so on FreeBSD or network programming, the number of contributions I'm likely to make to the code base is minimal, so to set it all up for two lines of text is a bit much.
I may set it all up in the future, when I'm less pressed for time by other matters, "just in case", but right now I can't. -
Well you could be the grammer, description police if you will ;) And just submit PRs for the gui description stuff ;)
-
-
hehehe - I did that on purpose ;)
-
Apologies for resurrecting this old thread but it seemed like the best place as it's the only thing to come up in Google for MDS Mitigation on pfSense.
@jimp while you state it doesn't really affect anyone with an appliance, would you recommend enabling MDS mitigation on those using pfSense in an ESXi VM for example?
Thanks. -
@Squuiid said in MDS Mitigation: any reason that's not enabled automatically?:
ESXi VM for example?
How do you think that would come into play... The mitigation where there would be a concern is the HOST, not a vm..
-
@johnpoz said in MDS Mitigation: any reason that's not enabled automatically?:
@Squuiid said in MDS Mitigation: any reason that's not enabled automatically?:
ESXi VM for example?
How do you think that would come into play... The mitigation where there would be a concern is the HOST, not a vm..
Is that you just speculating or is it based on something more concrete?
VMware state that not only a host should have MDS mitigations enabled but so too the guest vm it would seem.Have a read here and let me know what you think. To me it reads like the MDS mitigations should be enabled in a guest vm. Keen to hear your take on it however.
https://www.vmware.com/security/advisories/VMSA-2019-0008.html -
Where do you read that? Please point out the exact section of that HUGE ASS document that I have ZERO interest in reading ;) Because I am not running anything on esxi currently.
esxi has provided their own mitigation.. Also did you see the BIG POINT HERE which was the original point of this thread
"is mitigated through enablement of the ESXi Side-Channel-Aware Scheduler Version 1 or Version 2. These options may impose a non-trivial performance impact and are not enabled by default."
Do you host this esxi? Then yes you should look into mitigation to be done on the host for your clients running their OSes on your system.
Do you run your pfsense on some hosted VM? Then you should get with your host that they have mitigated so that their other clients can not gain info about your instance and stuff running on your instance.
Do you think this mitigation protects your instance from other instances that might be running on this VM host that is open to such attacks and not done any mitigation? That would be a slick trick for sure ;)
Do you think if you were running a VM on some host it would be ok for the HOST to tell you to turn on this specific mitigation in your VM? I would tell them to get bent, and if their mitigations they are doing are going to slow down my VMs and their performance - then there should be a discount in cost, or a bump in the resources assigned to make up for any loss of performance, etc..
If you run pfsense on your own esxi instance, and you have no other customers - then there is ZERO point in taking a performance hit.. Unless you plan on letting unknown users run code on your vms, or you run untrusted code yourself on your host or your vms... Which why would you be doing that on pfsense?
There really is almost no scenario where these mitigations would make sense to run on pfsense.. Since you should not be running untrusted code on pfsense, you should not be for sure allowing non trusted admins from accessing pfsense in the first place, let alone run code. etc. etc.
They have been provided, because if not users bitch.. But they sure and the hell should not be turned on by default if there would be any performance hit at all.. If you want to run it - have at it, its a clickity clickity thing to turn on.
-
@johnpoz said in MDS Mitigation: any reason that's not enabled automatically?:
If you run pfsense on your own esxi instance, and you have no other customers - then there is ZERO point in taking a performance hit.. Unless you plan on letting unknown users run code on your vms, or you run untrusted code yourself on your host or your vms... Which why would you be doing that on pfsense?
Firstly, thank you for the detailed response. You've essentially answered everything anyone could ever have wondered about this setting and this should hopefully be the last of the questions sent your way as a result!
I appreciate the time and effort you put into this.I do indeed host my own ESXi instance (homelab) and so won't be touching the setting.
I also have an SG-2440 which also works great and that one was addressed in your first post, again won't enable as a result.
Thanks. -
Yeah if your running your esxi in your own lab with your own vms - I wouldn't use any of the mitigation anything for this family of exploits.. If there is any possible performance hit.. Which most all of these mitigations are.. Some can be a pretty stiff hit..
Do you recall when meltdown first came out.. Lots of hoopla about that.. Even though most use cases of pfsense would have zero need for concern with such an attack vector..
Lots of traffic about it here and elsewhere, etc.. negate put out this blog back Jan of 2018
https://www.netgate.com/blog/an-update-on-meltdown-and-spectre.htmlThe important take away
Most of our users should not be concerned as long as they follow our basic guidelines for limiting access to the WebGUI, shell as well as physical access to the pfSense appliance.Same goes for all of these sorts of exploits..
