Thanks Vineetha.

To clarify for any observers, here's my understanding:

Ubuntu doesn't ship with a FIPS kernel by default.

If a user does use a FIPS enabled kernel, then libgcrypt20 detects this
and activates its own FIPS mode.

libgcrypt20 in Xenial's FIPS mode requires using /dev/random, which can
block when using full disk encryption during early boot up. This issue
is tracked in this bug. The Xenial version of libcrypt code is outdated
with respect to latest FIPS 140-2 specifications and parts of it uses
non-compliant algorithms.

Our fix is to disable libgcrypt20's FIPS mode, which is fine because it
isn't certified anyway.

This shouldn't regress existing users because Ubuntu's kernel does not
ship with FIPS enabled and so this mode in libgcrypt20 doesn't activate
in the usual case anyway.

For users who are using a FIPS-enabled kernel, Vineetha and her team
will perform SRU verification as normal to test the update once it is in
proposed.

We've tweaked the changelog entry for the SRU a little to make it clear
that users who aren't using a FIPS kernel shouldn't be affected by this
SRU.

** Changed in: libgcrypt20 (Ubuntu Xenial)
       Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-xenial

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1748310

Title:
  [SRU][xenial]boot stalls looking for entropy in FIPS mode

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libgcrypt20/+bug/1748310/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to