Open Stack

Archana,

>> * Was FIPS compliance discussed/considered in the context of confidential computing?
>
> I haven’t been part of the confidential computing discussions, but we discussed having minimal FIPS support in the past - not in the context of confidential computing. What we ended up doing was to atleast the least make sure the guest is started in FIPS mode on detecting that the host is running in FIPS mode.

And this works.  Snir had to do some workaround in order to use the
dracut-fips modules when generating the guest initrd (when the host is
running on FIPS mode) ...

> https://github.com/kata-containers/kata-containers/commit/0bd41b9dbe691ed70fa8769089a4a8795a5d54c9
> Kernel support for FIPS was also added in the upstream kata kernel config.

... but generally speaking the work done on kata-containers was solid. \o/


However, with this whole new world of vendored code I brought to
Snir's attention that we should be careful on what we're (maybe
blindly) vendoring, as if whatever we vendor ends up implementing
their own crypto algorithms we may violate FIPS on our side.

So, it's more a head's up that we should be paying attention to what
we'll use and a request for help on ensuring that whatever we use, we
check before whether it'd break FIPS compliance.

Not related to this email, but still related to this thread
(especially to Christophe's answer), ocicrypt and ocicrypt-rs should
be properly evaluated.  And I think we may encounter more cases as we
progress with the implementation of the confidential effort.

Best Regards,
-- 
Fabiano Fidêncio