MDS Mitigation: any reason that's not enabled automatically?

KOM · May 28, 2019, 7:50 PM

There's Google for that. Explaining a CPU vulnerability, the mitigation and why you may or may not need it is a little more than a tooltip can handle. Personally, I don't want paragraphs of text wrapped around every option.

rcfa · May 28, 2019, 8:06 PM

@KOM said in MDS Mitigation: any reason that's not enabled automatically?:

There's Google for that. Explaining a CPU vulnerability, the mitigation and why you may or may not need it is a little more than a tooltip can handle. Personally, I don't want paragraphs of text wrapped around every option.

A system that has configuration options, should explain them, particularly if they are non-obvious. Otherwise why even bother with a user friendly web interface? Just use the CLI, then you're not bothered by any "useless fluff".

Right now, the description there is:

"Microarchitectural Data Sampling mitigation. If disabled the kernel memory can be accessed by unprivileged users on affected CPUs. This option controls which method of MDS mitigation is used, if any."

It doesn't take much to add:

"MDS will not impact system security in standard use scenarios, however mitigation will incur a 10-15% performance penalty. The option exists for non-standard system use, such as e.g. installing untrusted third party software packages. For this reason, mitigation is disabled by default."

johnpoz · May 28, 2019, 8:14 PM

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.html

KOM · May 28, 2019, 8:16 PM

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.

rcfa · May 28, 2019, 8:37 PM

@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... ;)

rcfa · May 28, 2019, 8:41 PM

@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.html

Thanks. 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.

johnpoz · May 28, 2019, 10:40 PM

Well you could be the grammer, description police if you will ;) And just submit PRs for the gui description stuff ;)

KOM · May 28, 2019, 11:54 PM

@johnpoz "grammar"

johnpoz · May 29, 2019, 12:38 AM

hehehe - I did that on purpose ;)

Squuiid · Jun 12, 2020, 9:51 AM

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.

johnpoz · Jun 12, 2020, 6:37 PM

@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..

Squuiid · Jun 12, 2020, 6:47 PM

@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

johnpoz · Jun 12, 2020, 7:00 PM

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.

Squuiid · Jun 12, 2020, 9:28 PM

@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.

johnpoz · Jun 12, 2020, 10:11 PM

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.html

The 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..