[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] os: deprecate the -enable-fips option and QEMU's FIPS enforc

From: Paolo Bonzini
Subject: Re: [PATCH] os: deprecate the -enable-fips option and QEMU's FIPS enforcement
Date: Wed, 21 Oct 2020 11:51:10 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1

On 21/10/20 10:38, Daniel P. Berrangé wrote:
> On Tue, Oct 20, 2020 at 07:22:03PM +0200, Paolo Bonzini wrote:
>> On 20/10/20 18:22, Daniel P. Berrangé wrote:
>>> @@ -153,6 +153,9 @@ int os_parse_cmd_args(int index, const char *optarg)
>>>          break;
>>>  #if defined(CONFIG_LINUX)
>>>      case QEMU_OPTION_enablefips:
>>> +        warn_report("-enable-fips is deprecated, please build QEMU with "
>>> +                    "the `libgcrypt` library as the cryptography provider "
>>> +                    "to enable FIPS compliance");
>>>          fips_set_state(true);
>>>          break;
>>>  #endif
>> Should you also remove fips_set_state(true) and make fips_get_state()
>> return the contents of /proc/sys/crypto/fips_enabled, so that VNC
>> password authentication is disabled?
> I did think about doing that, but decided that since my intention is
> to delete all trace of fips_get_state / fips_set_state at the end of
> the deprecation period, that it'd be saner just to leave the semantics
> unchanged during the deprecation period.

But would it be correct?  In order to have the advertised behavior of
"enable FIPS compliance just with procfs, no need to do anything in
QEMU" you need to disable VNC password authentication; so while
fips_set_state is an abomination, fips_get_state should remain.

> Deprecation notices shouldn't really be associated with changes in
> functionality at time they are introduced.

I think you can consider it a bugfix since no one sets fips_enabled
without knowing what they're doing.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]