Overriding kernel FIPS mode detection via env vars

[nozomi-gedimitr]

We are building an application using Microsoft go which gets launched in k8s linux FIPS / non-FIPS environments. Our non-FIPS environment has the following peculiarity though:

• The kernel reports that it is FIPS capable (i.e. /proc/sys/crypto/fips_enabled holds 1)
• The OpenSSL library is configured in non-FIPS mode (i.e. there is no FIPS provider)

In this non-FIPS environment now, the application panics by default at launch time

panic: opensslcrypto: FIPS mode requested (system FIPS mode) but not available in OpenSSL 3.0.18 30 Sep 2025

Until now, we were working around this issue by setting the env var GOFIPS to 0. However, with the recent changes (and specifically with #1708), this possibility is getting removed.

I would like to ask:

• Is there any other mechanism that we could use so that system detection of the FIPS mode is overridden?

Thank you!

[dagood]

Hi! Thanks for the details.

• The kernel reports that it is FIPS capable (i.e. /proc/sys/crypto/fips_enabled holds 1)

Hmm, I've never heard of this called FIPS capable before, I've always seen FIPS mode and exclusively used with the intent to build up a FIPS compliant system. Do you have any documentation/examples of it being used this way, for us to get an idea of how widespread this is?

In a general context, I would interpret "FIPS capable" when talking about a Linux distro/system to mean that it has a Linux kernel that is able to handle the fips=1 boot parameter and that the distro, if it includes OpenSSL, includes an OpenSSL installation that's capable of being FIPS compliant and the whole thing has a FIPS cert.

Until now, we were working around this issue by setting the env var GOFIPS to 0. However, with the recent changes (and specifically with #1708), this possibility is getting removed.

I would like to ask:

• Is there any other mechanism that we could use so that system detection of the FIPS mode is overridden?

There is not currently. Also: the GOFIPS=0 mechanism has already been removed: that change is in all supported versions of the Microsoft build of Go.

[dagood]

• The OpenSSL library is configured in non-FIPS mode (i.e. there is no FIPS provider)

Could you reconfigure OpenSSL to include a FIPS provider, if it's included in the distro and just not configured by default?

I'm not an expert in OpenSSL configuration, but https://github.com/microsoft/go/tree/microsoft/main/eng/doc/fips#linux-fips-mode-openssl has a few pointers to ways to configure OpenSSL in the 💡 Tip.

[nozomi-gedimitr]

Thank you for your response! We are well aware that our current deployment is internally inconsistent -- cannot really tell if there are other users that end up with such a peculiar setup.

The root cause is that in both FIPS / non-FIPS deployments, we are employing virtual machines with the FIPS mode set to on, the reason for that being mainly historical. We could obviously reconfigure so that the FIPS mode is correctly set to 0 in non-FIPS deployments, but we are hesitant due to possibly far-reaching impacts on other, unrelated services.

Regarding the current state, from what I understand here the GOFIPS env var is still being used to have the effect that we are interested in. Is this intentional, or a leftover from the recent rework? Would you consider keeping such a check in, even if our setup / request is based on above shaky legs?

[dagood]

Regarding the current state, from what I understand here the GOFIPS env var is still being used to have the effect that we are interested in.

Hmm. I agree with your reading of the code, and I don't think that's intentional.

I set up a FIPS VM to check it out: indeed, setting GOFIPS=0, GOFIPS=yesplease, or any other value causes a test app to end up without runtime FIPS mode (fips140.Enabled() is zero) because it skips the systemFIPSMode() check, which isn't what's documented. Even GOFIPS= does the same thing, a mistake that could easily be made in the wild because not everyone is aware of the difference between empty string and unset in Linux env.

I'd say this is a bug. I do think there's a case for keeping this behavior around, but it should probably be a more specific/intentional env var that doesn't have legacy strings attached. (Unless I'm mistaken, we recently had someone in a similar situation internally.)

@qmuntal, @gdams, thoughts?

For the record, here's my test: https://gist.github.com/dagood/ce283bf2635d2acfd56d1af363d1a6f4

[qmuntal]

I'd say this is a bug.

Yep, that is an oversight.

My intention is to end up removing GOFIPS once the GODEBUG=fips140 knob is more established, so I would lean towards fixing the bug. That is, making 1 the only meaningful GOFIPS value.

About this new (at least to me) use case, I wonder if we could cover it by skipping any system-wide FIPS check when GODEBUG=fips140=off. That wouldn't preclude OpenSSL to use a FIPS provider by default, but it would at least inform the "Go layer" that it shouldn't mess with FIPS at all. Note that GODEBUG=fips140 defaults to an empty value if the environment variable GOFIPS140 is set to off at build time. This means that GODEBUG=fips140=off can only happen if the user explicitly set it this way.

[dagood]

Note that GODEBUG=fips140 defaults to an empty value if the environment variable GOFIPS140 is set to off at build time.

Do you think this will end up being intuitive to people who interact with these? Or will it feel like a quirk (and need docs, etc.)? I don't have a great intuition for how these are used yet.

Another potential concern: is it possible that someone might set GODEBUG=fips140=off and actually want their program to panic if kernel FIPS is enabled, as a safety check?

FWIW, having our own MS_IGNORE_LINUX_KERNEL_FIPS=1 is what I had in mind as an extremely specific/intentional switch. (Also easy to doc.)

[dagood]

@qmuntal @gdams what would you say about applying this for the currently supported Go versions:

1. Change the code to make it so 0 is intentionally "ignore kernel FIPS mode". Change GOFIPS handling to treat any value that isn't 1 or 0 as being the same as unset, for safety.
   • This solves active customer asks by enshrining the existing behavior. We could leave it at that, but it seems reasonable to fix an obvious pitfall while here.
2. Update docs to explain the behavior, with a note about the unusual non-1 behavior in past patch versions.
3. Either change the meaning of GODEBUG=fips140=off or implement MS_IGNORE_LINUX_KERNEL_FIPS=1 in the next major release. Potentially remove GOFIPS=0 handling.

[qmuntal]

GODEBUG=fips140=off seems like a better fit than MS_IGNORE_LINUX_KERNEL_FIPS or than modify again GOFIPS for me. The user intent would be clear: FIPS-140 handling should be disabled. If someone then comes requesting a way to panic if kernel FIPS is enabled... then we can thing about adding a new value to GODEBUG=fips140, something like GODEBUG=fips140=off+ms_panicifkernelfips.

[dagood]

Our current plan is to fix the GOFIPS behavior to match the documentation, implement GODEBUG=fips140=off disabling kernel FIPS detection, and backport both of these changes to the active branches.