MDS Mitigation: any reason that's not enabled automatically?
-
@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..
