[GIT PULL] Crypto Update for 6.17

[GIT PULL] Crypto Update for 6.17

[Herbert Xu]

Hi Linus:

The following changes since commit 40a98e702b528c631094f2e524d309faf33dc774:

  crypto: hkdf - move to late_initcall (2025-06-11 10:59:45 +0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git tags/v6.17-p1

for you to fetch changes up to bf24d64268544379d9a9b5b8efc2bb03967703b3:

  crypto: keembay - Use min() to simplify ocs_create_linked_list_from_sg() (2025-07-27 22:41:45 +1000)

----------------------------------------------------------------
This update includes the following changes:

API:

- Allow hash drivers without fallbacks (e.g., hardware key).

Algorithms:

- Add hmac hardware key support (phmac) on s390.
- Re-enable sha384 in FIPS mode.
- Disable sha1 in FIPS mode.
- Convert zstd to acomp.

Drivers:

- Lower priority of qat skcipher and aead.
- Convert aspeed to partial block API.
- Add iMX8QXP support in caam.
- Add rate limiting support for GEN6 devices in qat.
- Enable telemetry for GEN6 devices in qat.
- Implement full backlog mode for hisilicon/sec2.
----------------------------------------------------------------

Ahsan Atta (1):
      crypto: qat - allow enabling VFs in the absence of IOMMU

Alexey Kardashevskiy (1):
      crypto: ccp - Fix locking on alloc failure handling

Amit Singh Tomar (2):
      crypto: octeontx2 - Rework how engine group number is obtained
      crypto: octeontx2 - get engine group number for asymmetric engine

Arnd Bergmann (2):
      crypto: arm/aes-neonbs - work around gcc-15 warning
      crypto: ccp - reduce stack usage in ccp_run_aes_gcm_cmd

Ashish Kalra (2):
      crypto: ccp - Fix dereferencing uninitialized error pointer
      crypto: ccp - Fix SNP panic notifier unregistration

Bairavi Alagappan (1):
      crypto: qat - disable ZUC-256 capability for QAT GEN5

Bharat Bhushan (4):
      crypto: octeontx2 - add timeout for load_fvc completion poll
      crypto: octeontx2 - Fix address alignment issue on ucode loading
      crypto: octeontx2 - Fix address alignment on CN10K A0/A1 and OcteonTX2
      crypto: octeontx2 - Fix address alignment on CN10KB and CN10KA-B0

ChengZhenghan (1):
      crypto: x86 - Fix build warnings about export.h

Dr. David Alan Gilbert (1):
      crypto: virtio - Remove unused virtcrypto functions

Eric Biggers (4):
      crypto: x86/aegis - Fix sleeping when disallowed on PREEMPT_RT
      crypto: x86/aegis - Add missing error checks
      crypto: acomp - Fix CFI failure due to type punning
      crypto: krb5 - Fix memory leak in krb5_test_one_prf()

George Abraham P (2):
      crypto: qat - relocate power management debugfs helper APIs
      crypto: qat - enable power management debugfs for GEN6 devices

Giovanni Cabiddu (6):
      crypto: qat - lower priority for skcipher and aead algorithms
      crypto: qat - flush misc workqueue during device shutdown
      crypto: qat - fix DMA direction for compression on GEN2 devices
      crypto: qat - fix seq_file position update in adf_ring_next()
      crypto: qat - refactor ring-related debug functions
      crypto: qat - make adf_dev_autoreset() static

Harald Freudenberger (5):
      crypto: ahash - make hash walk functions from ahash.c public
      crypto: s390 - New s390 specific protected key hash phmac
      crypto: ahash - Add crypto_ahash_tested() helper function
      crypto: s390 - Add selftest support for phmac
      crypto: testmgr - Enable phmac selftest

Herbert Xu (21):
      crypto: ahash - Add support for drivers with no fallback
      crypto: aspeed/hash - Remove purely software hmac implementation
      crypto: aspeed/hash - Reorganise struct aspeed_sham_reqctx
      crypto: aspeed/hash - Use init_tfm instead of cra_init
      crypto: aspeed/hash - Provide rctx->buffer as argument to fill padding
      crypto: aspeed/hash - Move sham_final call into sham_update
      crypto: aspeed/hash - Move final padding into dma_prepare
      crypto: aspeed/hash - Remove sha_iv
      crypto: aspeed/hash - Use API partial block handling
      crypto: aspeed/hash - Add fallback
      crypto: aspeed/hash - Iterate on large hashes in dma_prepare
      crypto: aspeed/hash - Fix potential overflow in dma_prepare_sg
      crypto: marvell/cesa - Remove unnecessary state setting on final
      crypto: marvell/cesa - Fix engine load inaccuracy
      crypto: s390/hmac - Fix counter in export state
      crypto: s390/sha3 - Use cpu byte-order when exporting
      padata: Fix pd UAF once and for all
      padata: Remove comment for reorder_work
      crypto: ahash - Stop legacy tfms from using the set_virt fallback path
      crypto: aspeed - Fix hash fallback path typo
      Merge tag 'local-lock-for-net' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip into head

Holger Dengler (1):
      s390/crypto: Add protected key hmac subfunctions for KMAC

Jeff Barnes (1):
      crypto: testmgr - Restore sha384 and hmac_sha384 drbgs in FIPS mode

John Ernberg (3):
      crypto: caam - Prevent crash on suspend with iMX8QM / iMX8ULP
      crypto: caam - Support iMX8QXP and variants thereof
      dt-bindings: crypto: fsl,sec-v4.0: Add power domains for iMX8QM and iMX8QXP

Lukas Bulwahn (1):
      crypto: caam - avoid option aliasing with the CONFIG_CAAM_QI build option

Mario Limonciello (1):
      crypto: ccp - Add missing bootloader info reg for pspv6

Markus Theil (1):
      crypto: jitter - fix intermediary handling

Małgorzata Mielnik (2):
      crypto: qat - relocate bank state helper functions
      crypto: qat - add live migration enablers for GEN6 devices

Mengbiao Xiong (1):
      crypto: ccp - Fix crash when rebind ccp device for ccp.ko

Ovidiu Panait (6):
      crypto: sun8i-ce - fix nents passed to dma_unmap_sg()
      crypto: sun8i-ce - remove ivlen field of sun8i_cipher_req_ctx
      crypto: sun8i-ce - use helpers to get hash block and digest sizes
      hwrng: mtk - handle devm_pm_runtime_enable errors
      crypto: engine - remove request batching support
      crypto: engine - remove {prepare,unprepare}_crypt_hardware callbacks

Rob Herring (Arm) (2):
      dt-bindings: crypto: Convert ti,omap2-aes to DT schema
      dt-bindings: crypto: Convert ti,omap4-des to DT schema

Ruben Wauters (1):
      crypto: jitter - replace ARRAY_SIZE definition with header include

Ryan Wanner (5):
      dt-bindings: crypto: add sama7d65 in Atmel AES
      dt-bindings: crypto: add sama7d65 in Atmel SHA
      dt-bindings: crypto: add sama7d65 in Atmel TDES
      dt-bindings: rng: atmel,at91-trng: add sama7d65 TRNG
      crypto: atmel - add support for AES and SHA IPs available on sama7d65 SoC

Sakari Ailus (2):
      hwrng: drivers - Remove redundant pm_runtime_mark_last_busy() calls
      crypto: drivers - Remove redundant pm_runtime_mark_last_busy() calls

Sebastian Andrzej Siewior (2):
      local_lock: Move this_cpu_ptr() notation from internal to main header
      crypto: cryptd - Use nested-BH locking for cryptd_cpu_queue

Suman Kumar Chakraborty (19):
      crypto: qat - use unmanaged allocation for dc_data
      crypto: qat - add support for decompression service to GEN6 devices
      Documentation: qat: update sysfs-driver-qat for GEN6 devices
      crypto: zstd - convert to acomp
      crypto: qat - remove duplicate masking for GEN6 devices
      crypto: qat - restore ASYM service support for GEN6 devices
      crypto: zstd - fix duplicate check warning
      crypto: qat - use pr_fmt() in adf_gen4_hw_data.c
      crypto: qat - replace CHECK_STAT macro with static inline function
      crypto: qat - relocate and rename bank state structure definition
      crypto: qat - fix virtual channel configuration for GEN6 devices
      crypto: qat - validate service in rate limiting sysfs api
      crypto: qat - add decompression service for rate limiting
      crypto: qat - consolidate service enums
      crypto: qat - relocate service related functions
      crypto: qat - add adf_rl_get_num_svc_aes() in rate limiting
      crypto: qat - add get_svc_slice_cnt() in device data structure
      crypto: qat - add compression slice count for rate limiting
      crypto: qat - enable rate limiting feature for GEN6 devices

Svyatoslav Pankratov (1):
      crypto: qat - fix state restore for banks with exceptions

Thomas Fourier (3):
      crypto: inside-secure - Fix `dma_unmap_sg()` nents value
      crypto: keembay - Fix dma_unmap_sg() nents value
      crypto: img-hash - Fix dma_unmap_sg() nents value

Thomas Weißschuh (1):
      crypto: ccree - Don't use %pK through printk

Thorsten Blum (2):
      crypto: zstd - replace zero-length array with flexible array member
      crypto: keembay - Use min() to simplify ocs_create_linked_list_from_sg()

Vegard Nossum (1):
      crypto: testmgr - desupport SHA-1 for FIPS 140

Vijay Sundar Selvamani (3):
      crypto: qat - add decompression service to telemetry
      crypto: qat - enable telemetry for GEN6 devices
      Documentation: qat: update debugfs-driver-qat_telemetry for GEN6 devices

Wenkai Lin (1):
      crypto: hisilicon/sec2 - implement full backlog mode for sec

Yury Norov (1):
      padata: use cpumask_nth()

Yury Norov [NVIDIA] (2):
      crypto: pcrypt - Optimize pcrypt_aead_init_tfm()
      crypto: caam - Fix opencoded cpumask_next_wrap() in caam_drv_ctx_init()

Zenghui Yu (1):
      crypto: hisilicon - Use fine grained DMA mapping direction

Zhiqi Song (1):
      crypto: hisilicon/hpre - fix dma unmap sequence

 Documentation/ABI/testing/debugfs-driver-qat       |    2 +-
 .../ABI/testing/debugfs-driver-qat_telemetry       |   10 +-
 Documentation/ABI/testing/sysfs-driver-qat         |   50 +-
 Documentation/ABI/testing/sysfs-driver-qat_rl      |   14 +-
 Documentation/crypto/crypto_engine.rst             |    6 -
 .../bindings/crypto/atmel,at91sam9g46-aes.yaml     |    4 +-
 .../bindings/crypto/atmel,at91sam9g46-sha.yaml     |    4 +-
 .../bindings/crypto/atmel,at91sam9g46-tdes.yaml    |    4 +-
 .../devicetree/bindings/crypto/fsl,sec-v4.0.yaml   |   41 +-
 .../devicetree/bindings/crypto/omap-aes.txt        |   31 -
 .../devicetree/bindings/crypto/omap-des.txt        |   30 -
 .../devicetree/bindings/crypto/ti,omap2-aes.yaml   |   58 ++
 .../devicetree/bindings/crypto/ti,omap4-des.yaml   |   65 ++
 .../devicetree/bindings/rng/atmel,at91-trng.yaml   |    1 +
 arch/arm/crypto/aes-neonbs-glue.c                  |    2 +-
 arch/s390/configs/debug_defconfig                  |    1 +
 arch/s390/configs/defconfig                        |    1 +
 arch/s390/crypto/Makefile                          |    1 +
 arch/s390/crypto/hmac_s390.c                       |   12 +-
 arch/s390/crypto/paes_s390.c                       |    2 +-
 arch/s390/crypto/phmac_s390.c                      | 1048 ++++++++++++++++++++
 arch/s390/crypto/sha.h                             |    3 +
 arch/s390/crypto/sha3_256_s390.c                   |   22 +-
 arch/s390/crypto/sha3_512_s390.c                   |   23 +-
 arch/s390/include/asm/cpacf.h                      |    4 +
 arch/x86/crypto/aegis128-aesni-glue.c              |   40 +-
 arch/x86/crypto/aria_aesni_avx2_glue.c             |    1 +
 arch/x86/crypto/aria_aesni_avx_glue.c              |    1 +
 arch/x86/crypto/camellia_aesni_avx_glue.c          |    1 +
 arch/x86/crypto/camellia_glue.c                    |    1 +
 arch/x86/crypto/curve25519-x86_64.c                |    1 +
 arch/x86/crypto/serpent_avx_glue.c                 |    1 +
 arch/x86/crypto/sm4_aesni_avx_glue.c               |    1 +
 arch/x86/crypto/twofish_glue.c                     |    1 +
 arch/x86/crypto/twofish_glue_3way.c                |    1 +
 crypto/ahash.c                                     |   39 +-
 crypto/cryptd.c                                    |    6 +
 crypto/crypto_engine.c                             |   55 +-
 crypto/deflate.c                                   |    7 +-
 crypto/jitterentropy-kcapi.c                       |    9 +-
 crypto/jitterentropy.c                             |    2 +-
 crypto/krb5/selftest.c                             |    1 +
 crypto/pcrypt.c                                    |    7 +-
 crypto/testmgr.c                                   |   39 +-
 crypto/zstd.c                                      |  390 +++++---
 drivers/char/hw_random/atmel-rng.c                 |    1 -
 drivers/char/hw_random/cctrng.c                    |    1 -
 drivers/char/hw_random/mtk-rng.c                   |    5 +-
 drivers/char/hw_random/npcm-rng.c                  |    1 -
 drivers/char/hw_random/omap3-rom-rng.c             |    1 -
 drivers/char/hw_random/rockchip-rng.c              |    3 -
 drivers/char/hw_random/stm32-rng.c                 |    1 -
 drivers/crypto/Kconfig                             |   13 +
 .../crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c    |   15 +-
 drivers/crypto/allwinner/sun8i-ce/sun8i-ce-hash.c  |    6 +-
 drivers/crypto/allwinner/sun8i-ce/sun8i-ce.h       |    2 -
 drivers/crypto/aspeed/aspeed-hace-hash.c           |  802 ++++-----------
 drivers/crypto/aspeed/aspeed-hace.h                |   28 +-
 drivers/crypto/atmel-aes.c                         |    1 +
 drivers/crypto/atmel-sha.c                         |    1 +
 drivers/crypto/caam/Makefile                       |    4 -
 drivers/crypto/caam/ctrl.c                         |   13 +-
 drivers/crypto/caam/debugfs.c                      |    2 +-
 drivers/crypto/caam/debugfs.h                      |    2 +-
 drivers/crypto/caam/intern.h                       |    5 +-
 drivers/crypto/caam/jr.c                           |    3 +-
 drivers/crypto/caam/qi.c                           |    5 +-
 drivers/crypto/ccp/ccp-debugfs.c                   |    3 +
 drivers/crypto/ccp/ccp-ops.c                       |  163 +--
 drivers/crypto/ccp/sev-dev.c                       |   26 +-
 drivers/crypto/ccp/sp-pci.c                        |    1 +
 drivers/crypto/ccree/cc_buffer_mgr.c               |   54 +-
 drivers/crypto/ccree/cc_cipher.c                   |    4 +-
 drivers/crypto/ccree/cc_hash.c                     |   30 +-
 drivers/crypto/ccree/cc_pm.c                       |    1 -
 drivers/crypto/hisilicon/hpre/hpre_crypto.c        |    8 +-
 drivers/crypto/hisilicon/qm.c                      |    1 -
 drivers/crypto/hisilicon/sec2/sec.h                |   63 +-
 drivers/crypto/hisilicon/sec2/sec_crypto.c         |  595 +++++++----
 drivers/crypto/hisilicon/sgl.c                     |   15 +-
 drivers/crypto/hisilicon/zip/zip_crypto.c          |   13 +-
 drivers/crypto/img-hash.c                          |    2 +-
 drivers/crypto/inside-secure/safexcel_hash.c       |    8 +-
 .../crypto/intel/keembay/keembay-ocs-hcu-core.c    |    8 +-
 drivers/crypto/intel/keembay/ocs-aes.c             |    4 +-
 .../crypto/intel/qat/qat_420xx/adf_420xx_hw_data.c |   18 +-
 .../crypto/intel/qat/qat_4xxx/adf_4xxx_hw_data.c   |   14 +-
 .../crypto/intel/qat/qat_6xxx/adf_6xxx_hw_data.c   |  129 ++-
 .../crypto/intel/qat/qat_6xxx/adf_6xxx_hw_data.h   |   22 +-
 drivers/crypto/intel/qat/qat_common/Makefile       |    4 +
 .../intel/qat/qat_common/adf_accel_devices.h       |   40 +-
 drivers/crypto/intel/qat/qat_common/adf_aer.c      |    2 +-
 .../crypto/intel/qat/qat_common/adf_bank_state.c   |  238 +++++
 .../crypto/intel/qat/qat_common/adf_bank_state.h   |   49 +
 .../crypto/intel/qat/qat_common/adf_cfg_common.h   |    1 +
 .../crypto/intel/qat/qat_common/adf_cfg_services.c |   45 +-
 .../crypto/intel/qat/qat_common/adf_cfg_services.h |   13 +-
 .../crypto/intel/qat/qat_common/adf_cfg_strings.h  |    1 +
 .../crypto/intel/qat/qat_common/adf_common_drv.h   |    2 +-
 .../crypto/intel/qat/qat_common/adf_gen4_hw_data.c |  229 +----
 .../crypto/intel/qat/qat_common/adf_gen4_hw_data.h |   10 +-
 .../intel/qat/qat_common/adf_gen4_pm_debugfs.c     |  105 +-
 .../crypto/intel/qat/qat_common/adf_gen4_vf_mig.c  |    7 +-
 drivers/crypto/intel/qat/qat_common/adf_gen6_pm.h  |   24 +
 .../intel/qat/qat_common/adf_gen6_pm_dbgfs.c       |  124 +++
 .../crypto/intel/qat/qat_common/adf_gen6_shared.c  |    7 +
 .../crypto/intel/qat/qat_common/adf_gen6_shared.h  |    2 +
 drivers/crypto/intel/qat/qat_common/adf_gen6_tl.c  |  146 +++
 drivers/crypto/intel/qat/qat_common/adf_gen6_tl.h  |  198 ++++
 drivers/crypto/intel/qat/qat_common/adf_init.c     |    1 +
 drivers/crypto/intel/qat/qat_common/adf_isr.c      |    5 +
 .../intel/qat/qat_common/adf_pm_dbgfs_utils.c      |   52 +
 .../intel/qat/qat_common/adf_pm_dbgfs_utils.h      |   36 +
 drivers/crypto/intel/qat/qat_common/adf_rl.c       |   86 +-
 drivers/crypto/intel/qat/qat_common/adf_rl.h       |   11 +-
 drivers/crypto/intel/qat/qat_common/adf_rl_admin.c |    1 +
 drivers/crypto/intel/qat/qat_common/adf_sriov.c    |    1 -
 drivers/crypto/intel/qat/qat_common/adf_sysfs.c    |    2 +
 drivers/crypto/intel/qat/qat_common/adf_sysfs_rl.c |   21 +-
 .../crypto/intel/qat/qat_common/adf_tl_debugfs.c   |    3 +
 .../intel/qat/qat_common/adf_transport_debug.c     |   21 +-
 drivers/crypto/intel/qat/qat_common/qat_algs.c     |   12 +-
 drivers/crypto/intel/qat/qat_common/qat_bl.c       |    6 +-
 .../crypto/intel/qat/qat_common/qat_compression.c  |    8 +-
 drivers/crypto/marvell/cesa/cipher.c               |    4 +-
 drivers/crypto/marvell/cesa/hash.c                 |   10 +-
 drivers/crypto/marvell/octeontx2/otx2_cpt_reqmgr.h |  128 ++-
 drivers/crypto/marvell/octeontx2/otx2_cptlf.h      |    3 +-
 .../crypto/marvell/octeontx2/otx2_cptpf_ucode.c    |   51 +-
 drivers/crypto/marvell/octeontx2/otx2_cptvf_algs.c |    6 +-
 drivers/crypto/marvell/octeontx2/otx2_cptvf_main.c |   28 +-
 drivers/crypto/marvell/octeontx2/otx2_cptvf_mbox.c |    7 +-
 .../crypto/marvell/octeontx2/otx2_cptvf_reqmgr.c   |   14 +-
 drivers/crypto/omap-aes-gcm.c                      |    1 -
 drivers/crypto/omap-aes.c                          |    1 -
 drivers/crypto/omap-des.c                          |    1 -
 drivers/crypto/omap-sham.c                         |    1 -
 drivers/crypto/stm32/stm32-cryp.c                  |    1 -
 drivers/crypto/stm32/stm32-hash.c                  |    1 -
 drivers/crypto/virtio/virtio_crypto_common.h       |    2 -
 drivers/crypto/virtio/virtio_crypto_core.c         |    2 +-
 drivers/crypto/virtio/virtio_crypto_mgr.c          |   36 -
 include/crypto/engine.h                            |    1 -
 include/crypto/internal/acompress.h                |    5 +-
 include/crypto/internal/engine.h                   |   15 -
 include/crypto/internal/hash.h                     |   36 +
 include/linux/crypto.h                             |    3 +
 include/linux/hisi_acc_qm.h                        |    4 +-
 include/linux/local_lock.h                         |   20 +-
 include/linux/local_lock_internal.h                |   30 +-
 include/linux/padata.h                             |    4 -
 kernel/padata.c                                    |  154 +--
 152 files changed, 4133 insertions(+), 2089 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/crypto/omap-aes.txt
 delete mode 100644 Documentation/devicetree/bindings/crypto/omap-des.txt
 create mode 100644 Documentation/devicetree/bindings/crypto/ti,omap2-aes.yaml
 create mode 100644 Documentation/devicetree/bindings/crypto/ti,omap4-des.yaml
 create mode 100644 arch/s390/crypto/phmac_s390.c
 create mode 100644 drivers/crypto/intel/qat/qat_common/adf_bank_state.c
 create mode 100644 drivers/crypto/intel/qat/qat_common/adf_bank_state.h
 create mode 100644 drivers/crypto/intel/qat/qat_common/adf_gen6_pm_dbgfs.c
 create mode 100644 drivers/crypto/intel/qat/qat_common/adf_gen6_tl.c
 create mode 100644 drivers/crypto/intel/qat/qat_common/adf_gen6_tl.h
 create mode 100644 drivers/crypto/intel/qat/qat_common/adf_pm_dbgfs_utils.c
 create mode 100644 drivers/crypto/intel/qat/qat_common/adf_pm_dbgfs_utils.h

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [GIT PULL] Crypto Update for 6.17

[pr-tracker-bot]

The pull request you sent on Tue, 29 Jul 2025 19:07:51 +0800:

> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git tags/v6.17-p1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/44a8c96edd0ee9320a1ad87afc7b10f38e55d5ec

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] Crypto Update for 6.17

[Jiri Slaby]

On 29. 07. 25, 13:07, Herbert Xu wrote:
> Vegard Nossum (1):
>        crypto: testmgr - desupport SHA-1 for FIPS 140

Booting 6.17 with fips=1 crashes with this commit -- see below.

The crash is different being on 6.17 (below) and on the commit -- 
9d50a25eeb05c45fef46120f4527885a14c84fb2.

6.17 minus that one makes it work again.

Any ideas?

> [    1.186784][    T1] IPv6: Attempt to unregister permanent protocol 6
> [    1.188236][    T1] IPv6: Attempt to unregister permanent protocol 136
> [    1.189648][    T1] IPv6: Attempt to unregister permanent protocol 17
> [    2.351181][    T1] ------------[ cut here ]------------
> [    2.352257][    T1] WARNING: CPU: 10 PID: 1 at net/ipv6/ip6mr.c:409 ip6mr_free_table+0x28/0x60
> [    2.353536][    T1] Modules linked in:
> [    2.354113][    T1] CPU: 10 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-46-default #1 PREEMPT(voluntary) openSUSE Tumbleweed (unreleased)  b731e69de5611aa08621e4f613e2c88e3aba29e6
> [    2.356567][    T1] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022
> [    2.357843][    T1] RIP: 0010:ip6mr_free_table+0x28/0x60
> [    2.358654][    T1] Code: 90 90 0f 1f 44 00 00 53 48 89 fb e8 a2 11 0d 00 48 8b 43 10 8b 90 6c 01 00 00 85 d2 74 0e 48 8b 80 98 00 00 00 48 85 c0 74 02 <0f> 0b 48 8d 7b 38 e8 4d 65 33 ff 48 89 df be 0f 00 00 00 e8 80 fc
> [    2.361528][    T1] RSP: 0018:ffffcd1bc001fce8 EFLAGS: 00010286
> [    2.362458][    T1] RAX: ffffffff93f32e00 RBX: ffff8b6b05c9b000 RCX: ffff8b6b00898000
> [    2.363625][    T1] RDX: 0000000000000002 RSI: 00000000e843c2fc RDI: ffff8b6b05c9b000
> [    2.364785][    T1] RBP: ffffffff9566c2f0 R08: 0000000037609dba R09: 0000000000000075
> [    2.365982][    T1] R10: ffffcd1bc001fd30 R11: ffff8b6b00898fd8 R12: dead000000000122
> [    2.367157][    T1] R13: dead000000000100 R14: ffffffff9566b4c0 R15: ffffcd1bc001fdb8
> [    2.368332][    T1] FS:  0000000000000000(0000) GS:ffff8b6daf9a8000(0000) knlGS:0000000000000000
> [    2.369690][    T1] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    2.371077][    T1] CR2: 0000000000000000 CR3: 0000000047c54000 CR4: 0000000000750ef0
> [    2.372611][    T1] PKRU: 55555554
> [    2.373452][    T1] Call Trace:
> [    2.374252][    T1]  <TASK>
> [    2.375019][    T1]  ip6mr_rules_exit+0x80/0xe0
> [    2.376021][    T1]  ip6mr_net_exit_batch+0x2b/0x50
> [    2.377077][    T1]  ops_undo_list+0x10a/0x3b0
> [    2.378090][    T1]  ? __pfx_inet6_init+0x10/0x10
> [    2.379102][    T1]  unregister_pernet_operations+0xdd/0x170
> [    2.380279][    T1]  unregister_pernet_subsys+0x21/0x30
> [    2.381371][    T1]  ip6_mr_cleanup+0x43/0x50
> [    2.382321][    T1]  inet6_init+0x365/0x3d0
> [    2.383263][    T1]  do_one_initcall+0x58/0x390
> [    2.384256][    T1]  kernel_init_freeable+0x2a7/0x320
> [    2.385316][    T1]  ? __pfx_kernel_init+0x10/0x10
> [    2.386343][    T1]  kernel_init+0x1a/0x140
> [    2.387275][    T1]  ret_from_fork+0x28b/0x2c0
> [    2.388242][    T1]  ? __pfx_kernel_init+0x10/0x10
> [    2.389236][    T1]  ret_from_fork_asm+0x1a/0x30
> [    2.390213][    T1]  </TASK>
> [    2.390963][    T1] irq event stamp: 137165
> [    2.392123][    T1] hardirqs last  enabled at (137177): [<ffffffff91c079ee>] __up_console_sem+0x5e/0x70
> [    2.394179][    T1] hardirqs last disabled at (137188): [<ffffffff91c079d3>] __up_console_sem+0x43/0x70
> [    2.395868][    T1] softirqs last  enabled at (137088): [<ffffffff91b442e8>] __irq_exit_rcu+0xd8/0x100
> [    2.397531][    T1] softirqs last disabled at (137071): [<ffffffff91b442e8>] __irq_exit_rcu+0xd8/0x100
> [    2.399171][    T1] ---[ end trace 0000000000000000 ]---
> [    2.407972][    T1] NET: Unregistered PF_INET6 protocol family
> [    2.419868][    T1] =============================================================================
> [    2.420857][    T1] BUG RAWv6 (Tainted: G        W          ): Objects remaining on __kmem_cache_shutdown()
> [    2.420857][    T1] -----------------------------------------------------------------------------
> [    2.420857][    T1] 
> [    2.420857][    T1] Object 0x00000000394ddb07 @offset=0
> [    2.420857][    T1] Object 0x000000005b94be2d @offset=1856
> [    2.420857][    T1] Object 0x0000000067ad0f1b @offset=3712
> [    2.420857][    T1] Object 0x00000000c82c6c1d @offset=7424
> [    2.420857][    T1] Object 0x000000009feb574d @offset=9280
> [    2.420857][    T1] Object 0x00000000876e99c8 @offset=11136
> [    2.420857][    T1] Object 0x000000000aae5823 @offset=12992
> [    2.420857][    T1] Object 0x000000009a4d1547 @offset=14848
> [    2.420857][    T1] Object 0x000000003343b806 @offset=16704
> [    2.420857][    T1] Object 0x000000004cc8a8a9 @offset=18560
> [    2.420857][    T1] Object 0x00000000125f35fd @offset=20416
> [    2.420857][    T1] Object 0x000000007903e512 @offset=22272
> [    2.420857][    T1] Object 0x00000000705f6e50 @offset=24128
> [    2.420857][    T1] Object 0x00000000c222f065 @offset=25984
> [    2.420857][    T1] Object 0x0000000020b63684 @offset=27840
> [    2.420857][    T1] Object 0x00000000a2f1493f @offset=29696
> [    2.420857][    T1] Slab 0x0000000070ef76ad objects=17 used=16 fp=0x000000005ed43c1e flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)
> [    2.420857][    T1] Disabling lock debugging due to kernel taint
> [    2.420857][    T1] ------------[ cut here ]------------
> [    2.420857][    T1] WARNING: CPU: 2 PID: 1 at mm/slub.c:1176 __slab_err+0x19/0x20
> [    2.420857][    T1] Modules linked in:
> [    2.420857][    T1] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Tainted: G    B   W           6.17.0-46-default #1 PREEMPT(voluntary) openSUSE Tumbleweed (unreleased)  b731e69de5611aa08621e4f613e2c88e3aba29e6
> [    2.420857][    T1] Tainted: [B]=BAD_PAGE, [W]=WARN
> [    2.420857][    T1] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022
> [    2.420857][    T1] RIP: 0010:__slab_err+0x19/0x20
> [    2.420857][    T1] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 e8 76 ff ff ff be 01 00 00 00 bf 05 00 00 00 e8 87 6e 11 00 <0f> 0b e9 eb 0a ee ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
> [    2.420857][    T1] RSP: 0018:ffffcd1bc001fd40 EFLAGS: 00010082
> [    2.420857][    T1] RAX: 0000000000000000 RBX: ffff8b6b08968380 RCX: 0000000000000243
> [    2.420857][    T1] RDX: 0000000000000005 RSI: ffffcd1bc001fbe8 RDI: 0000000000000003
> [    2.420857][    T1] RBP: fffffb7904234e00 R08: 0000000000000000 R09: 00000000ffff7fff
> [    2.420857][    T1] R10: ffffffff95472540 R11: ffffcd1bc001fbe0 R12: dead000000000100
> [    2.420857][    T1] R13: ffffcd1bc001fd78 R14: fffffb7904234800 R15: ffff8b6b08d20000
> [    2.420857][    T1] FS:  0000000000000000(0000) GS:ffff8b6daf5a8000(0000) knlGS:0000000000000000
> [    2.420857][    T1] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    2.420857][    T1] CR2: 0000000000000000 CR3: 0000000047c54000 CR4: 0000000000750ef0
> [    2.420857][    T1] PKRU: 55555554
> [    2.420857][    T1] Call Trace:
> [    2.420857][    T1]  <TASK>
> [    2.420857][    T1]  __kmem_cache_shutdown.cold+0x13c/0x146
> [    2.420857][    T1]  ? __pfx_inet6_init+0x10/0x10
> [    2.420857][    T1]  kmem_cache_destroy+0x41/0x150
> [    2.420857][    T1]  proto_unregister+0x93/0x100
> [    2.420857][    T1]  inet6_init+0x3a2/0x3d0
> [    2.420857][    T1]  do_one_initcall+0x58/0x390
> [    2.420857][    T1]  kernel_init_freeable+0x2a7/0x320
> [    2.420857][    T1]  ? __pfx_kernel_init+0x10/0x10
> [    2.420857][    T1]  kernel_init+0x1a/0x140
> [    2.420857][    T1]  ret_from_fork+0x28b/0x2c0
> [    2.420857][    T1]  ? __pfx_kernel_init+0x10/0x10
> [    2.420857][    T1]  ret_from_fork_asm+0x1a/0x30
> [    2.420857][    T1]  </TASK>
> [    2.420857][    T1] irq event stamp: 137776
> [    2.420857][    T1] hardirqs last  enabled at (137775): [<ffffffff92a10b78>] _raw_spin_unlock_irq+0x28/0x50
> [    2.420857][    T1] hardirqs last disabled at (137776): [<ffffffff92a10893>] _raw_spin_lock_irq+0x53/0x60
> [    2.420857][    T1] softirqs last  enabled at (137566): [<ffffffff928b455e>] inet6_unregister_protosw+0x5e/0x70
> [    2.420857][    T1] softirqs last disabled at (137564): [<ffffffff928b4523>] inet6_unregister_protosw+0x23/0x70
> [    2.420857][    T1] ---[ end trace 0000000000000000 ]---
> [    2.507939][    T1] ------------[ cut here ]------------
> [    2.508959][    T1] kmem_cache_destroy RAWv6: Slab cache still has objects when called from proto_unregister+0x93/0x100
> [    2.508977][    T1] WARNING: CPU: 2 PID: 1 at mm/slab_common.c:525 kmem_cache_destroy+0x140/0x150
> [    2.512301][    T1] Modules linked in:
> [    2.513125][    T1] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Tainted: G    B   W           6.17.0-46-default #1 PREEMPT(voluntary) openSUSE Tumbleweed (unreleased)  b731e69de5611aa08621e4f613e2c88e3aba29e6
> [    2.516258][    T1] Tainted: [B]=BAD_PAGE, [W]=WARN
> [    2.517234][    T1] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022
> [    2.518767][    T1] RIP: 0010:kmem_cache_destroy+0x140/0x150
> [    2.519829][    T1] Code: 00 85 ed 74 92 eb b1 e8 7e 04 db ff eb 8f 48 8b 53 60 48 8b 4c 24 10 48 c7 c6 f0 af c9 92 48 c7 c7 08 ad 2c 93 e8 e0 62 cb ff <0f> 0b e9 04 ff ff ff e9 2f 03 a8 ff 0f 1f 40 00 90 90 90 90 90 90
> [    2.523085][    T1] RSP: 0018:ffffcd1bc001fdc8 EFLAGS: 00010246
> [    2.524197][    T1] RAX: 0000000000000000 RBX: ffff8b6b01e7f000 RCX: 000000000000026b
> [    2.525560][    T1] RDX: 0000000000000000 RSI: ffffcd1bc001fc78 RDI: 0000000000000003
> [    2.526955][    T1] RBP: 0000000000000001 R08: 0000000000000000 R09: 00000000ffff7fff
> [    2.528313][    T1] R10: ffffffff95472540 R11: ffffcd1bc001fc70 R12: ffffffff9456bac0
> [    2.529683][    T1] R13: ffffffff9478ace8 R14: 0000000000000000 R15: 0000000000000000
> [    2.531041][    T1] FS:  0000000000000000(0000) GS:ffff8b6daf5a8000(0000) knlGS:0000000000000000
> [    2.532563][    T1] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    2.535367][    T1] CR2: 0000000000000000 CR3: 0000000047c54000 CR4: 0000000000750ef0
> [    2.538374][    T1] PKRU: 55555554
> [    2.539338][    T1] Call Trace:
> [    2.540142][    T1]  <TASK>
> [    2.540897][    T1]  proto_unregister+0x93/0x100
> [    2.541851][    T1]  inet6_init+0x3a2/0x3d0
> [    2.542726][    T1]  do_one_initcall+0x58/0x390
> [    2.543618][    T1]  kernel_init_freeable+0x2a7/0x320
> [    2.544589][    T1]  ? __pfx_kernel_init+0x10/0x10
> [    2.545598][    T1]  kernel_init+0x1a/0x140
> [    2.546414][    T1]  ret_from_fork+0x28b/0x2c0
> [    2.547277][    T1]  ? __pfx_kernel_init+0x10/0x10
> [    2.548230][    T1]  ret_from_fork_asm+0x1a/0x30
> [    2.549174][    T1]  </TASK>
> [    2.549849][    T1] irq event stamp: 137776
> [    2.550694][    T1] hardirqs last  enabled at (137775): [<ffffffff92a10b78>] _raw_spin_unlock_irq+0x28/0x50
> [    2.552309][    T1] hardirqs last disabled at (137776): [<ffffffff92a10893>] _raw_spin_lock_irq+0x53/0x60
> [    2.553923][    T1] softirqs last  enabled at (137566): [<ffffffff928b455e>] inet6_unregister_protosw+0x5e/0x70
> [    2.555624][    T1] softirqs last disabled at (137564): [<ffffffff928b4523>] inet6_unregister_protosw+0x23/0x70
> [    2.557300][    T1] ---[ end trace 0000000000000000 ]---
> [    2.591591][    T1] IPI shorthand broadcast: enabled
thanks,
-- 
js
suse labs

Re: [GIT PULL] Crypto Update for 6.17

[Herbert Xu]

On Thu, Oct 02, 2025 at 10:10:41AM +0200, Jiri Slaby wrote:
> On 29. 07. 25, 13:07, Herbert Xu wrote:
> > Vegard Nossum (1):
> >        crypto: testmgr - desupport SHA-1 for FIPS 140
> 
> Booting 6.17 with fips=1 crashes with this commit -- see below.
> 
> The crash is different being on 6.17 (below) and on the commit --
> 9d50a25eeb05c45fef46120f4527885a14c84fb2.
> 
> 6.17 minus that one makes it work again.
> 
> Any ideas?

The purpose of the above commit is to remove the SHA1 algorithm
if you boot with fips=1.  As net/ipv6/seg6_hmac.c depends on the
sha1 algorithm, it will obviously fail if SHA1 isn't there.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [GIT PULL] Crypto Update for 6.17

[Jiri Slaby]

On 02. 10. 25, 11:30, Herbert Xu wrote:
> On Thu, Oct 02, 2025 at 10:10:41AM +0200, Jiri Slaby wrote:
>> On 29. 07. 25, 13:07, Herbert Xu wrote:
>>> Vegard Nossum (1):
>>>         crypto: testmgr - desupport SHA-1 for FIPS 140
>>
>> Booting 6.17 with fips=1 crashes with this commit -- see below.
>>
>> The crash is different being on 6.17 (below) and on the commit --
>> 9d50a25eeb05c45fef46120f4527885a14c84fb2.
>>
>> 6.17 minus that one makes it work again.
>>
>> Any ideas?
> 
> The purpose of the above commit is to remove the SHA1 algorithm
> if you boot with fips=1.  As net/ipv6/seg6_hmac.c depends on the
> sha1 algorithm, it will obviously fail if SHA1 isn't there.

Ok, but I don't immediately see what is one supposed to do to boot 6.17 
distro (openSUSE) kernel with fips=1 then?

-- 
js
suse labs

Re: [GIT PULL] Crypto Update for 6.17

[Jiri Slaby]

On 02. 10. 25, 12:05, Jiri Slaby wrote:
> On 02. 10. 25, 11:30, Herbert Xu wrote:
>> On Thu, Oct 02, 2025 at 10:10:41AM +0200, Jiri Slaby wrote:
>>> On 29. 07. 25, 13:07, Herbert Xu wrote:
>>>> Vegard Nossum (1):
>>>>         crypto: testmgr - desupport SHA-1 for FIPS 140
>>>
>>> Booting 6.17 with fips=1 crashes with this commit -- see below.
>>>
>>> The crash is different being on 6.17 (below) and on the commit --
>>> 9d50a25eeb05c45fef46120f4527885a14c84fb2.
>>>
>>> 6.17 minus that one makes it work again.
>>>
>>> Any ideas?
>>
>> The purpose of the above commit is to remove the SHA1 algorithm
>> if you boot with fips=1.  As net/ipv6/seg6_hmac.c depends on the
>> sha1 algorithm, it will obviously fail if SHA1 isn't there.
> 
> Ok, but I don't immediately see what is one supposed to do to boot 6.17 
> distro (openSUSE) kernel with fips=1 then?

Now I do, in the context you write, I see inet6_init()'s fail path is 
broken. The two backtraces show:
[    2.381371][    T1]  ip6_mr_cleanup+0x43/0x50
[    2.382321][    T1]  inet6_init+0x365/0x3d0

and

[    2.420857][    T1]  proto_unregister+0x93/0x100
[    2.420857][    T1]  inet6_init+0x3a2/0x3d0

I am looking what exactly, but this is rather for netdev@

thanks,
-- 
js
suse labs

6.17 crashes in ipv6 code when booted fips=1 [was: [GIT PULL] Crypto Update for 6.17]

[Jiri Slaby]

On 02. 10. 25, 12:13, Jiri Slaby wrote:
> On 02. 10. 25, 12:05, Jiri Slaby wrote:
>> On 02. 10. 25, 11:30, Herbert Xu wrote:
>>> On Thu, Oct 02, 2025 at 10:10:41AM +0200, Jiri Slaby wrote:
>>>> On 29. 07. 25, 13:07, Herbert Xu wrote:
>>>>> Vegard Nossum (1):
>>>>>         crypto: testmgr - desupport SHA-1 for FIPS 140
>>>>
>>>> Booting 6.17 with fips=1 crashes with this commit -- see below.
>>>>
>>>> The crash is different being on 6.17 (below) and on the commit --
>>>> 9d50a25eeb05c45fef46120f4527885a14c84fb2.
>>>>
>>>> 6.17 minus that one makes it work again.
>>>>
>>>> Any ideas?
>>>
>>> The purpose of the above commit is to remove the SHA1 algorithm
>>> if you boot with fips=1.  As net/ipv6/seg6_hmac.c depends on the
>>> sha1 algorithm, it will obviously fail if SHA1 isn't there.
>>
>> Ok, but I don't immediately see what is one supposed to do to boot 
>> 6.17 distro (openSUSE) kernel with fips=1 then?
> 
> Now I do, in the context you write, I see inet6_init()'s fail path is 
> broken. The two backtraces show:
> [    2.381371][    T1]  ip6_mr_cleanup+0x43/0x50
> [    2.382321][    T1]  inet6_init+0x365/0x3d0
> 
> and
> 
> [    2.420857][    T1]  proto_unregister+0x93/0x100
> [    2.420857][    T1]  inet6_init+0x3a2/0x3d0
> 
> I am looking what exactly, but this is rather for netdev@

More functions from the fail path are not ready to unroll and resurrect 
from the failure.

Anyway, cherry-picking this -next commit onto 6.17 works as well (the 
code uses now crypto_lib's sha1, not crypto's):
commit 095928e7d80186c524013a5b5d54889fa2ec1eaa
Author: Eric Biggers <ebiggers@kernel.org>
Date:   Sat Aug 23 21:36:43 2025 -0400

     ipv6: sr: Use HMAC-SHA1 and HMAC-SHA256 library functions


I don't know what to do next -- should it be put into 6.17 stable later 
and we are done?

thanks,
-- 
js
suse labs

Re: 6.17 crashes in ipv6 code when booted fips=1 [was: [GIT PULL] Crypto Update for 6.17]

[Herbert Xu]

On Thu, Oct 02, 2025 at 12:57:11PM +0200, Jiri Slaby wrote:
>
> Anyway, cherry-picking this -next commit onto 6.17 works as well (the code
> uses now crypto_lib's sha1, not crypto's):
> commit 095928e7d80186c524013a5b5d54889fa2ec1eaa
> Author: Eric Biggers <ebiggers@kernel.org>
> Date:   Sat Aug 23 21:36:43 2025 -0400
> 
>     ipv6: sr: Use HMAC-SHA1 and HMAC-SHA256 library functions
> 
> 
> I don't know what to do next -- should it be put into 6.17 stable later and
> we are done?

Yes that works too.  But it's basically the same as reverting
the patch from Vegard since it makes the code use SHA1 again
even though we told it not too.

Perhaps we should just revert Vegard's change? Since it's kind
of pointless now that people are just using the underlying SHA1
algorithm directly through lib/crypto.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: 6.17 crashes in ipv6 code when booted fips=1 [was: [GIT PULL] Crypto Update for 6.17]

[Vegard Nossum]

On 02/10/2025 12:57, Jiri Slaby wrote:
> On 02. 10. 25, 12:13, Jiri Slaby wrote:
>> On 02. 10. 25, 12:05, Jiri Slaby wrote:
>>> On 02. 10. 25, 11:30, Herbert Xu wrote:
>>>> On Thu, Oct 02, 2025 at 10:10:41AM +0200, Jiri Slaby wrote:
>>>>> On 29. 07. 25, 13:07, Herbert Xu wrote:
>>>>>> Vegard Nossum (1):
>>>>>>         crypto: testmgr - desupport SHA-1 for FIPS 140
>>>>>
>>>>> Booting 6.17 with fips=1 crashes with this commit -- see below.
>>>>>
>>>>> The crash is different being on 6.17 (below) and on the commit --
>>>>> 9d50a25eeb05c45fef46120f4527885a14c84fb2.
>>>>>
>>>>> 6.17 minus that one makes it work again.
>>>>>
>>>>> Any ideas?
>>>>
>>>> The purpose of the above commit is to remove the SHA1 algorithm
>>>> if you boot with fips=1.  As net/ipv6/seg6_hmac.c depends on the
>>>> sha1 algorithm, it will obviously fail if SHA1 isn't there.
>>>
>>> Ok, but I don't immediately see what is one supposed to do to boot 
>>> 6.17 distro (openSUSE) kernel with fips=1 then?

First off, I just want to acknowledge that my commit to disable SHA-1
when booting with fips=1 is technically regressing userspace as well as
this specific ipv6 code.

However, fips=1 has a very specific use case, which is FIPS compliance.
Now, SHA-1 has been deprecated since 2011 but not yet fully retired
until 2030.

The purpose of the commit is to actually begin the transition as is
encouraged by NIST and prevent any new FIPS certifications from expiring
early, which would be the outcome for any FIPS certifications initiated
after December 31 this year. I think this is in line with the spirit of
using and supporting fips=1 to begin with, in the sense that if you
don't care about using SHA-1 then you probably don't care about fips=1
to start with either.

If you really want to continue using SHA-1 in FIPS mode with 6.17 then I
would suggest reverting my patch downstream as the straightforward fix.

>> Now I do, in the context you write, I see inet6_init()'s fail path is 
>> broken. The two backtraces show:
>> [    2.381371][    T1]  ip6_mr_cleanup+0x43/0x50
>> [    2.382321][    T1]  inet6_init+0x365/0x3d0
>>
>> and
>>
>> [    2.420857][    T1]  proto_unregister+0x93/0x100
>> [    2.420857][    T1]  inet6_init+0x3a2/0x3d0
>>
>> I am looking what exactly, but this is rather for netdev@
> 
> More functions from the fail path are not ready to unroll and resurrect 
> from the failure.
> 
> Anyway, cherry-picking this -next commit onto 6.17 works as well (the 
> code uses now crypto_lib's sha1, not crypto's):
> commit 095928e7d80186c524013a5b5d54889fa2ec1eaa
> Author: Eric Biggers <ebiggers@kernel.org>
> Date:   Sat Aug 23 21:36:43 2025 -0400
> 
>      ipv6: sr: Use HMAC-SHA1 and HMAC-SHA256 library functions
> 
> 
> I don't know what to do next -- should it be put into 6.17 stable later 
> and we are done?

I'd like to raise a general question about FIPS compliance here,
especially to Eric and the crypto folks: If SHA-1/SHA-256/HMAC is being
made available outside of the crypto API and code around the kernel is
making direct use of it, then this seems to completely subvert the
purpose of CONFIG_CRYPTO_FIPS/fips=1 since it essentially makes the
kernel non-compliant even when booting with fips=1.

Is this expected? Should it be documented?

FIPS also has a bunch of requirements around algorithm testing, for
example that every algorithm shall pass tests before it can be used.
lib/crypto/ has kunit tests, but there is no interaction with
CONFIG_CRYPTO_FIPS or fips=1 as far as I can tell, and no enforcement
mechanism. This seems like a bad thing for all the distros that are
currently certifying their kernels for FIPS.


Vegard

Re: 6.17 crashes in ipv6 code when booted fips=1 [was: [GIT PULL] Crypto Update for 6.17]

[Eric Biggers]

On Thu, Oct 02, 2025 at 01:30:43PM +0200, Vegard Nossum wrote:
> 
> On 02/10/2025 12:57, Jiri Slaby wrote:
> > On 02. 10. 25, 12:13, Jiri Slaby wrote:
> > > On 02. 10. 25, 12:05, Jiri Slaby wrote:
> > > > On 02. 10. 25, 11:30, Herbert Xu wrote:
> > > > > On Thu, Oct 02, 2025 at 10:10:41AM +0200, Jiri Slaby wrote:
> > > > > > On 29. 07. 25, 13:07, Herbert Xu wrote:
> > > > > > > Vegard Nossum (1):
> > > > > > >         crypto: testmgr - desupport SHA-1 for FIPS 140
> > > > > > 
> > > > > > Booting 6.17 with fips=1 crashes with this commit -- see below.
> > > > > > 
> > > > > > The crash is different being on 6.17 (below) and on the commit --
> > > > > > 9d50a25eeb05c45fef46120f4527885a14c84fb2.
> > > > > > 
> > > > > > 6.17 minus that one makes it work again.
> > > > > > 
> > > > > > Any ideas?
> > > > > 
> > > > > The purpose of the above commit is to remove the SHA1 algorithm
> > > > > if you boot with fips=1.  As net/ipv6/seg6_hmac.c depends on the
> > > > > sha1 algorithm, it will obviously fail if SHA1 isn't there.
> > > > 
> > > > Ok, but I don't immediately see what is one supposed to do to
> > > > boot 6.17 distro (openSUSE) kernel with fips=1 then?
> 
> First off, I just want to acknowledge that my commit to disable SHA-1
> when booting with fips=1 is technically regressing userspace as well as
> this specific ipv6 code.
> 
> However, fips=1 has a very specific use case, which is FIPS compliance.
> Now, SHA-1 has been deprecated since 2011 but not yet fully retired
> until 2030.
> 
> The purpose of the commit is to actually begin the transition as is
> encouraged by NIST and prevent any new FIPS certifications from expiring
> early, which would be the outcome for any FIPS certifications initiated
> after December 31 this year. I think this is in line with the spirit of
> using and supporting fips=1 to begin with, in the sense that if you
> don't care about using SHA-1 then you probably don't care about fips=1
> to start with either.
> 
> If you really want to continue using SHA-1 in FIPS mode with 6.17 then I
> would suggest reverting my patch downstream as the straightforward fix.
> 
> > > Now I do, in the context you write, I see inet6_init()'s fail path
> > > is broken. The two backtraces show:
> > > [    2.381371][    T1]  ip6_mr_cleanup+0x43/0x50
> > > [    2.382321][    T1]  inet6_init+0x365/0x3d0
> > > 
> > > and
> > > 
> > > [    2.420857][    T1]  proto_unregister+0x93/0x100
> > > [    2.420857][    T1]  inet6_init+0x3a2/0x3d0
> > > 
> > > I am looking what exactly, but this is rather for netdev@
> > 
> > More functions from the fail path are not ready to unroll and resurrect
> > from the failure.
> > 
> > Anyway, cherry-picking this -next commit onto 6.17 works as well (the
> > code uses now crypto_lib's sha1, not crypto's):
> > commit 095928e7d80186c524013a5b5d54889fa2ec1eaa
> > Author: Eric Biggers <ebiggers@kernel.org>
> > Date:   Sat Aug 23 21:36:43 2025 -0400
> > 
> >      ipv6: sr: Use HMAC-SHA1 and HMAC-SHA256 library functions
> > 
> > 
> > I don't know what to do next -- should it be put into 6.17 stable later
> > and we are done?
> 
> I'd like to raise a general question about FIPS compliance here,
> especially to Eric and the crypto folks: If SHA-1/SHA-256/HMAC is being
> made available outside of the crypto API and code around the kernel is
> making direct use of it

lib/ has had SHA-1 support since 2005.  The recent changes just made the
SHA-1 API more comprehensive and more widely used in the kernel.

> then this seems to completely subvert the
> purpose of CONFIG_CRYPTO_FIPS/fips=1 since it essentially makes the
> kernel non-compliant even when booting with fips=1.
> 
> Is this expected? Should it be documented?

If calling code would like to choose not to use or allow a particular
crypto algorithm when fips_enabled=1, it's free to do so.  

That's far more flexible than the crypto/ approach, which has
historically been problematic since it breaks things unnecessarily.  The
caller can actually do something that makes sense for it, including:

- Deciding whether FIPS requirements even apply to it in the first
  place.  (Considering that it may or may not be implementing something
  that would be considered a "security function" by FIPS.)

- Targeting the disablement to the correct, narrow area.  (Not something
  overly-broad like the entire IPv6 stack, or entire TPM support.)

So: if the people doing FIPS certifications of the whole kernel make a
determination that fips_enabled=1 kernels must not support IPv6 Segment
Routing with HMAC-SHA1 authentication, then they're welcome to send a
patch that makes seg6_genl_sethmac() reject SEG6_HMAC_ALGO_SHA1 if
fips_enabled.  And that would actually correctly disable the SHA-1
support only, rather than disabling the entire IPv6 stack...

Still, for many years lib/ has had APIs for SHA-1 and various
non-FIPS-approved crypto algorithms.  These are used even when
fips_enabled=1.  So, if this was actually important, one would think
these cases would have addressed already.  This is one of the reasons
why I haven't been worrying about adding these checks myself.

It's really up to someone who cares (if anyone does) to send patches.

> FIPS also has a bunch of requirements around algorithm testing, for
> example that every algorithm shall pass tests before it can be used.
> lib/crypto/ has kunit tests, but there is no interaction with
> CONFIG_CRYPTO_FIPS or fips=1 as far as I can tell, and no enforcement
> mechanism. This seems like a bad thing for all the distros that are
> currently certifying their kernels for FIPS.

As I've said in another thread
(https://lore.kernel.org/linux-crypto/20250917184856.GA2560@quark/,
https://lore.kernel.org/linux-crypto/20250918155327.GA1422@quark/),
small patches that add FIPS pre-operational self-tests would generally
be fine, if they are shown to actually be needed and are narrowly scoped
to what is actually needed.  These would be different from and much
simpler than the KUnit tests, which are the real tests.

But again, it's up to someone who cares to send patches.  And again,
lib/ has had SHA-1 since 2005, so this isn't actually new.

- Eric

Re: 6.17 crashes in ipv6 code when booted fips=1 [was: [GIT PULL] Crypto Update for 6.17]

[Vegard Nossum]

On 02/10/2025 19:23, Eric Biggers wrote:
> On Thu, Oct 02, 2025 at 01:30:43PM +0200, Vegard Nossum wrote:
>> I'd like to raise a general question about FIPS compliance here,
>> especially to Eric and the crypto folks: If SHA-1/SHA-256/HMAC is being
>> made available outside of the crypto API and code around the kernel is
>> making direct use of it
> 
> lib/ has had SHA-1 support since 2005.  The recent changes just made the
> SHA-1 API more comprehensive and more widely used in the kernel.

Sure, it was available under lib/ but what matters is that there were no
users outside of the crypto API. Adding direct users presumably breaks
the meaning of fips=1 -- which is why I'd like us to work out (and
explicitly document) what fips=1 actually means.

>> then this seems to completely subvert the
>> purpose of CONFIG_CRYPTO_FIPS/fips=1 since it essentially makes the
>> kernel non-compliant even when booting with fips=1.
>>
>> Is this expected? Should it be documented?
> 
> If calling code would like to choose not to use or allow a particular
> crypto algorithm when fips_enabled=1, it's free to do so.
> 
> That's far more flexible than the crypto/ approach, which has
> historically been problematic since it breaks things unnecessarily.  The
> caller can actually do something that makes sense for it, including:
> 
> - Deciding whether FIPS requirements even apply to it in the first
>    place.  (Considering that it may or may not be implementing something
>    that would be considered a "security function" by FIPS.)
> 
> - Targeting the disablement to the correct, narrow area.  (Not something
>    overly-broad like the entire IPv6 stack, or entire TPM support.)
> 
> So: if the people doing FIPS certifications of the whole kernel make a
> determination that fips_enabled=1 kernels must not support IPv6 Segment
> Routing with HMAC-SHA1 authentication, then they're welcome to send a
> patch that makes seg6_genl_sethmac() reject SEG6_HMAC_ALGO_SHA1 if
> fips_enabled.  And that would actually correctly disable the SHA-1
> support only, rather than disabling the entire IPv6 stack...

I'm pretty sure the use of SHA-1/HMAC inside IPv6 segment routing counts
as a "security function" (as it is used for message authentication) and
thus should be subject to FIPS requirements when booting with fips=1.

> Still, for many years lib/ has had APIs for SHA-1 and various
> non-FIPS-approved crypto algorithms.  These are used even when
> fips_enabled=1.  So, if this was actually important, one would think
> these cases would have addressed already.  This is one of the reasons
> why I haven't been worrying about adding these checks myself.

I see some direct uses of lib/ algorithms outside the crypto API on
older kernels but at a glance they look mostly like specific drivers
that most distros probably don't even build, which might explain why it
hasn't been a problem in practice.

> It's really up to someone who cares (if anyone does) to send patches.

I'd assume most distributions that provide FIPS-certified kernels care.
As far as I can tell, they are all going to run into problems when they
start providing products based on v6.17. Maybe I'm wrong and it comes
down to an interpretation of FIPS requirements and what fips=1 is
intended to do -- again, why I'd like us to work this out and document
it so we have a clear and shared understanding and don't break mainline
FIPS support.

In the meantime, I think it would be good to stop converting more crypto
API users to lib/crypto/ users if it's not crystal clear that it's not a
"security function".

>> FIPS also has a bunch of requirements around algorithm testing, for
>> example that every algorithm shall pass tests before it can be used.
>> lib/crypto/ has kunit tests, but there is no interaction with
>> CONFIG_CRYPTO_FIPS or fips=1 as far as I can tell, and no enforcement
>> mechanism. This seems like a bad thing for all the distros that are
>> currently certifying their kernels for FIPS.
> 
> As I've said in another thread
> (https://lore.kernel.org/linux-crypto/20250917184856.GA2560@quark/,
> https://lore.kernel.org/linux-crypto/20250918155327.GA1422@quark/),
> small patches that add FIPS pre-operational self-tests would generally
> be fine, if they are shown to actually be needed and are narrowly scoped
> to what is actually needed.  These would be different from and much
> simpler than the KUnit tests, which are the real tests.
> 
> But again, it's up to someone who cares to send patches.  And again,
> lib/ has had SHA-1 since 2005, so this isn't actually new.

What's new is the direct user of lib/crypto/sha1.c outside the crypto
API since commit 095928e7d8018, which is very recent.

I don't think it's a good idea to duplicate all the logic around
FIPS and algorithm testing that already exists in the crypto API for
this exact purpose.


Vegard

Re: 6.17 crashes in ipv6 code when booted fips=1 [was: [GIT PULL] Crypto Update for 6.17]

[Eric Biggers]

On Mon, Oct 06, 2025 at 01:53:21PM +0200, Vegard Nossum wrote:
> On 02/10/2025 19:23, Eric Biggers wrote:
> > On Thu, Oct 02, 2025 at 01:30:43PM +0200, Vegard Nossum wrote:
> > > I'd like to raise a general question about FIPS compliance here,
> > > especially to Eric and the crypto folks: If SHA-1/SHA-256/HMAC is being
> > > made available outside of the crypto API and code around the kernel is
> > > making direct use of it
> > 
> > lib/ has had SHA-1 support since 2005.  The recent changes just made the
> > SHA-1 API more comprehensive and more widely used in the kernel.
> 
> Sure, it was available under lib/ but what matters is that there were no
> users outside of the crypto API.

That's incorrect.  The SHA-1 library was already used by
kernel/bpf/core.c and net/ipv6/addrconf.c.  And also
drivers/char/random.c prior to 5.17.

> Adding direct users presumably breaks the meaning of fips=1 -- which
> is why I'd like us to work out (and explicitly document) what fips=1
> actually means.

Well, fips=1 has never had any documentation.  If anyone cares they
should document it.

But also, as I said, if certain kernel subsystem(s) mustn't use certain
algorithms when fips=1, then the people who care about FIPS are welcome
to add that logic to those subsystems.  It's trivial:

    #include <linux/fips.h>

    if (fips_enabled)
            return -EOPNOTSUPP;

Sure, it's 3 lines per subsystem, but compare that to the 50-200 that
typically gets saved by switching to the library.  And the library
solves a number of other problems too.  So it's still well worth it.

I'll plan to add these checks to MD5 uses when doing MD5 conversions in
6.19.  Yes, I didn't add them to SHA-1 uses when doing SHA-1 conversions
in 6.18, but it's clear that disallowing SHA-1 is still a
work-in-progress anyway.  I'll assume that you or someone else are going
to finish the work for SHA-1 at some point.

> > Still, for many years lib/ has had APIs for SHA-1 and various
> > non-FIPS-approved crypto algorithms.  These are used even when
> > fips_enabled=1.  So, if this was actually important, one would think
> > these cases would have addressed already.  This is one of the reasons
> > why I haven't been worrying about adding these checks myself.
> 
> I see some direct uses of lib/ algorithms outside the crypto API on
> older kernels but at a glance they look mostly like specific drivers
> that most distros probably don't even build, which might explain why it
> hasn't been a problem in practice.

Again, incorrect.  Core kernel functionality uses, and continues to use,
non-FIPS-approved crypto algorithms.

Maybe the FIPS people assessed each of those use cases and determined
that they are not "security functions".  But I and other upstream kernel
developers have no visibility into that.

More likely IMO is that the FIPS people are just ignoring reality.

> I'd assume most distributions that provide FIPS-certified kernels care.
> As far as I can tell, they are all going to run into problems when they
> start providing products based on v6.17. Maybe I'm wrong and it comes
> down to an interpretation of FIPS requirements and what fips=1 is
> intended to do -- again, why I'd like us to work this out and document
> it so we have a clear and shared understanding and don't break mainline
> FIPS support.
> 
> In the meantime, I think it would be good to stop converting more crypto
> API users to lib/crypto/ users if it's not crystal clear that it's not a
> "security function".

You're welcome to be constructive instead of obstructive.

> > > FIPS also has a bunch of requirements around algorithm testing, for
> > > example that every algorithm shall pass tests before it can be used.
> > > lib/crypto/ has kunit tests, but there is no interaction with
> > > CONFIG_CRYPTO_FIPS or fips=1 as far as I can tell, and no enforcement
> > > mechanism. This seems like a bad thing for all the distros that are
> > > currently certifying their kernels for FIPS.
> > 
> > As I've said in another thread
> > (https://lore.kernel.org/linux-crypto/20250917184856.GA2560@quark/,
> > https://lore.kernel.org/linux-crypto/20250918155327.GA1422@quark/),
> > small patches that add FIPS pre-operational self-tests would generally
> > be fine, if they are shown to actually be needed and are narrowly scoped
> > to what is actually needed.  These would be different from and much
> > simpler than the KUnit tests, which are the real tests.
> > 
> > But again, it's up to someone who cares to send patches.  And again,
> > lib/ has had SHA-1 since 2005, so this isn't actually new.
> 
> What's new is the direct user of lib/crypto/sha1.c outside the crypto
> API since commit 095928e7d8018, which is very recent.

Again: while that particular user is new, the SHA-1 library was already
used by kernel/bpf/core.c and net/ipv6/addrconf.c.

> I don't think it's a good idea to duplicate all the logic around
> FIPS and algorithm testing that already exists in the crypto API for
> this exact purpose.

As I've said: if the pre-operational self-tests are actually needed in
lib/ after all, then lib/ can just implement the minimum that FIPS
requires, which is actually quite straightforward (typically just a
single check for algorithm).

I don't see it as duplicating the actual tests.  The way that
crypto/testmgr.c conflates the FIPS pre-operational self-tests and the
actual tests has always been really problematic.

- Eric

Re: 6.17 crashes in ipv6 code when booted fips=1 [was: [GIT PULL] Crypto Update for 6.17]

[Linus Torvalds]

On Mon, 6 Oct 2025 at 04:53, Vegard Nossum <vegard.nossum@oracle.com> wrote:
>
> I'm pretty sure the use of SHA-1/HMAC inside IPv6 segment routing counts
> as a "security function" (as it is used for message authentication) and
> thus should be subject to FIPS requirements when booting with fips=1.

I think the other way of writing that is "fips=1 is and will remain
irrelevant in the real world as long as it's that black-and-white".

             Linus

Re: 6.17 crashes in ipv6 code when booted fips=1 [was: [GIT PULL] Crypto Update for 6.17]

[Vegard Nossum]

On 06/10/2025 18:19, Linus Torvalds wrote:
> On Mon, 6 Oct 2025 at 04:53, Vegard Nossum <vegard.nossum@oracle.com> wrote:
>>
>> I'm pretty sure the use of SHA-1/HMAC inside IPv6 segment routing counts
>> as a "security function" (as it is used for message authentication) and
>> thus should be subject to FIPS requirements when booting with fips=1.
> 
> I think the other way of writing that is "fips=1 is and will remain
> irrelevant in the real world as long as it's that black-and-white".

Okay, so I get that we don't like fips=1 around here (I'm not a
particularly big fan myself), but what's with the snark? fips=1 exists
in mainline and obviously has users. I'm just trying to make sure it
remains useful and usable. Otherwise we're going back to the
jitterentropy situation where every distro has their own downstream
patches to pass FIPS certification. Is that what you want?

Confused,


Vegard

Re: 6.17 crashes in ipv6 code when booted fips=1 [was: [GIT PULL] Crypto Update for 6.17]

[Linus Torvalds]

On Mon, 6 Oct 2025 at 09:32, Vegard Nossum <vegard.nossum@oracle.com> wrote:
>
> Okay, so I get that we don't like fips=1 around here (I'm not a
> particularly big fan myself), but what's with the snark? fips=1 exists
> in mainline and obviously has users. I'm just trying to make sure it
> remains useful and usable.

It literally caused non-bootable machines because of that allegedly
"remains useful and usable" because it changed something that never
failed to failing. That's how this thread started.

So that's why the snark. I think you are deluding yourself and others
if you call that "useful and usable".

           Linus

Re: 6.17 crashes in ipv6 code when booted fips=1 [was: [GIT PULL] Crypto Update for 6.17]

[Vegard Nossum]

On 06/10/2025 18:19, Linus Torvalds wrote:
> I think the other way of writing that is "fips=1 is and will remain 
> irrelevant in the real world as long as it's that black-and-white".

On 06/10/2025 19:11, Linus Torvalds wrote:
> On Mon, 6 Oct 2025 at 09:32, Vegard Nossum <vegard.nossum@oracle.com> wrote:
>>
>> Okay, so I get that we don't like fips=1 around here (I'm not a
>> particularly big fan myself), but what's with the snark? fips=1 exists
>> in mainline and obviously has users. I'm just trying to make sure it
>> remains useful and usable.
> 
> It literally caused non-bootable machines because of that allegedly
> "remains useful and usable" because it changed something that never
> failed to failing. That's how this thread started.
> 
> So that's why the snark. I think you are deluding yourself and others
> if you call that "useful and usable".

Yes, thank you, I've already acknowledged that my patch caused boot
failures and I apologize for that unintentional breakage. Why does this
mean we should throw fips=1 in the bin, though? That's a total non sequitur.

The fact is that fips=1 is not useful if it doesn't actually result
something that complies with the standard; the only purpose of fips=1 is
to allow the kernel to be used and certified as a FIPS module. But as
SHA-1 is still allowed for now, please go ahead and revert my patch,
it's commit 9d50a25eeb05c.


Vegard

Re: 6.17 crashes in ipv6 code when booted fips=1 [was: [GIT PULL] Crypto Update for 6.17]

[Eric Biggers]

On Mon, Oct 06, 2025 at 09:11:41PM +0200, Vegard Nossum wrote:
> The fact is that fips=1 is not useful if it doesn't actually result
> something that complies with the standard; the only purpose of fips=1 is
> to allow the kernel to be used and certified as a FIPS module.

Don't all the distros doing this actually carry out-of-tree patches to
fix up some things required for certification that upstream has never
done?  So that puts the upstream fips=1 support in an awkward place,
where it's always been an unfinished (and undocumented) feature.

- Eric

Re: 6.17 crashes in ipv6 code when booted fips=1 [was: [GIT PULL] Crypto Update for 6.17]

[Linus Torvalds]

On Mon, 6 Oct 2025 at 12:12, Vegard Nossum <vegard.nossum@oracle.com> wrote:
>
> Yes, thank you, I've already acknowledged that my patch caused boot
> failures and I apologize for that unintentional breakage. Why does this
> mean we should throw fips=1 in the bin, though?

That's not what I actually ever said.

I said "as long as it's that black-and-white". You entirely ignored that part.

THAT was my point. I don't think it makes much sense to treat this as
some kind of absolute on/off switch.

So I would suggest that "fips=1" mean that we'd *WARN* about use of
things like this that FIPS says should be off the table in 2031.

The whole "disable it entirely" was a mistake. That's obvious in
hindsight. So let's *learn* from that mistake and stop doing that.

If somebody is in a situation where they really need to disable SHA1,
I think they should hard-disable it and just make sure it doesn't get
compiled in at all.

But for the foreseeable immediate future, the reasonable thing to do
is AT MOST to warn about fips rules, not break things.

Because the black-and-white thing is obviously broken. One boot
failure was enough - we're *NOT* doubling down on that mistake.

                Linus

Re: 6.17 crashes in ipv6 code when booted fips=1 [was: [GIT PULL] Crypto Update for 6.17]

[Simo Sorce]

On Mon, 2025-10-06 at 19:26 +0000, Eric Biggers wrote:
> On Mon, Oct 06, 2025 at 09:11:41PM +0200, Vegard Nossum wrote:
> > The fact is that fips=1 is not useful if it doesn't actually result
> > something that complies with the standard; the only purpose of fips=1 is
> > to allow the kernel to be used and certified as a FIPS module.
> 
> Don't all the distros doing this actually carry out-of-tree patches to
> fix up some things required for certification that upstream has never
> done?  So that puts the upstream fips=1 support in an awkward place,
> where it's always been an unfinished (and undocumented) feature.

FWIW downstream patching, at least until recently, has been minimal.
The upstream behavior has been good enough to be representative of the
behavior you would expect from a certified binary.

Note: this may change going forward, but I am confident that as issues
arise people will propose upstream patches to keep it as close as
possible within acceptable parameters for upstream behavior.

-- 
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc

Re: 6.17 crashes in ipv6 code when booted fips=1 [was: [GIT PULL] Crypto Update for 6.17]

[Vegard Nossum]

On 06/10/2025 21:26, Eric Biggers wrote:
> On Mon, Oct 06, 2025 at 09:11:41PM +0200, Vegard Nossum wrote:
>> The fact is that fips=1 is not useful if it doesn't actually result
>> something that complies with the standard; the only purpose of fips=1 is
>> to allow the kernel to be used and certified as a FIPS module.
> 
> Don't all the distros doing this actually carry out-of-tree patches to
> fix up some things required for certification that upstream has never
> done?  So that puts the upstream fips=1 support in an awkward place,
> where it's always been an unfinished (and undocumented) feature.

I can't speak for all distros, but we have a handful of patches, around
6 or 7 I believe, most are fairly small. (We are, however, looking to
move to the standalone module I sent the RFC for, which has a lot more
patches...)

But yes, mainline fips=1 support is in a slightly awkward place. I see
no real reason for anybody to ever use it in production unless it's
actually a NIST certified build either.

That doesn't mean we shouldn't try to minimize the amount of downstream
patches, though. (IMHO, anyway.)

I would like to try to document what fips=1 is currently and how to use
it and how to program for it (if nobody -- however unlikely -- beats me
to it). I came across this thread from over 10 years ago where people
are asking about the kernel FIPS docs and we still don't have any:

https://mta.openssl.org/pipermail/openssl-users/2015-March/000904.html


Vegard

Re: 6.17 crashes in ipv6 code when booted fips=1 [was: [GIT PULL] Crypto Update for 6.17]

[Theodore Ts'o]

On Mon, Oct 06, 2025 at 03:45:46PM -0400, Simo Sorce wrote:
> Note: this may change going forward, but I am confident that as issues
> arise people will propose upstream patches to keep it as close as
> possible within acceptable parameters for upstream behavior.

What I'm curious about is what falls within the acceptable parameters
of *distro* behavior.  If NIST-certified labs really insist that
certifying requires making the kernel completely unsupportable from a
commercial perspective, at what point will *distros* decide to give it
up as a bad idea, or to have a completely different binary kernel
package that only crazy customers would be willing to use?

If there is something beyond hard-disabling CONFIG_CRYPTO_SHA1 which
all distributions could agree with --- what would that set of patches
look like, and would it be evenly vaguely upstream acceptable.  It
could even hidden behind CONFIG_BROKEN.  :-)

						- Ted
						

Re: 6.17 crashes in ipv6 code when booted fips=1 [was: [GIT PULL] Crypto Update for 6.17]

[Linus Torvalds]

On Wed, 8 Oct 2025 at 05:13, Theodore Ts'o <tytso@mit.edu> wrote:
>
> If there is something beyond hard-disabling CONFIG_CRYPTO_SHA1 which
> all distributions could agree with --- what would that set of patches
> look like, and would it be evenly vaguely upstream acceptable.  It
> could even hidden behind CONFIG_BROKEN.  :-)

Maybe just

 (a) make it a runtime flag - so that it can't mess up the boot, at least

 (b) make it ternary so that you get a "warn vs turn off"

 (c) and allow people to clear it too - so that you can sanely *test*
it without forcing a possibly unusable machine

and then

 (d) make the clearing be dependent on that 'lockdown' set that nobody
remotely normal uses anyway

would make this thing a whole lot more testable, and a whole lot less abrupt.

Christ, if even FIPS went "we know this is a big thing, we'll give you
a decade to sort things out", then the kernel damn well shouldn't make
it some black-and-white sudden flag.

So we should *NOT* say "FIPS says turn it off eventually, so we should
turn it off". No. That was very very wrong.

We should say "FIPS says turn it off eventually, so we should give
users simple tools to find problem spots".

And that "simple tools" very much is about not making it some kind of
"Oh, what happens is that the machine is unusable". It should be that
"Oh, look, now it gives a warning that I would have a problem in XYZ
if it wasn't available".

                   Linus