Report FIPS module failures through wolfssl_prov_is_running()

[yosuke-wolfssl]

Summary

Fixes finding 4540: in FIPS builds, wolfssl_prov_is_running() unconditionally
returned 1, so a wolfCrypt integrity/POST failure was invisible to callers polling
OSSL_PROV_PARAM_STATUS. This gates the provider's running/status report on the live
FIPS module status and adds a regression test for the new behavior.

Problem

• wolfssl_prov_is_running() had only one non-1 path — the WP_CHECK_FORCE_FAIL debug
  lever — and otherwise always returned 1.
• wolfprov_get_params() sets OSSL_PROV_PARAM_STATUS directly from
  wolfssl_prov_is_running(), so a status-polling caller always saw "running".
• The wp_fipsCb FIPS callback only logged and mutated no state, so a failure it
  received was dropped.

Net effect: a FIPS-aware caller enforcing a fail-stop policy via OSSL_PROV_PARAM_STATUS
could not observe an unhealthy FIPS module. (The wolfCrypt primitives themselves still
return errors in FIPS_MODE_FAILED, so this is a status-reporting / policy fail-open,
not silent fail-open crypto.)

Fix

Gate wolfssl_prov_is_running() on wolfCrypt_GetStatus_fips() under #ifdef HAVE_FIPS;
a non-zero status (integrity/POST or continuous-test failure) returns 0. Querying live
status is a single source of truth and does not depend on the callback having fired.
wp_fipsCb is left as a logger.

#ifdef HAVE_FIPS
    if (wolfCrypt_GetStatus_fips() != 0) {
        WOLFPROV_LEAVE(WP_LOG_COMP_PROVIDER, __FILE__ ":" WOLFPROV_STRINGIZE(__LINE__), 0);
        return 0;
    }
#endif

Regression test

New test/standalone/tests/fips_status/ standalone test. It loads libwolfprov, then:

• Healthy: asserts OSSL_PROV_PARAM_STATUS == 1 and that an AES-256-CBC init
  succeeds (proves the provider is actually operable, not just reporting healthy).
• After a forced FIPS failure: asserts status flips to 0 and the same operation
  is now rejected.

The failure is injected by a compile-time mechanism ladder chosen from what the build
provides:

1. HAVE_FIPS && HAVE_FORCE_FIPS_FAILURE → real wolfCrypt_SetStatus_fips(IN_CORE_FIPS_E).
2. HAVE_FIPS && __linux__ → ELF symbol interposition of wolfCrypt_GetStatus_fips(),
   guarded by a dlsym(RTLD_DEFAULT, ...) canary that fails loudly if interposition is
   not actually in effect (never misreports an ineffective inject as a provider regression).
3. otherwise → healthy path only, self-reported.

HAVE_FORCE_FIPS_FAILURE is enabled by an internal, test-only env knob
(WOLFPROV_FORCE_FIPS_FAILURE) — deliberately not a CLI flag, so it is not exposed to
customers. When set, -DHAVE_FORCE_FIPS_FAILURE reaches both the wolfSSL FIPS build and
the provider/test builds automatically via wolfSSL's generated options.h (no relay
variable or source-tree grep).

CI

fips-ready.yml (the source-FIPS job on ubuntu-22.04) builds with the knob, runs the
test, and greps for the forced-failure marker so the job fails if the negative branch
did not actually execute (guards against silent degradation).

Files

• src/wp_wolfprov.c — the fix; move the FIPS header include to the top.
• test/standalone/tests/fips_status/{test_fips_status.c,run.sh} — new test + driver.
• test/standalone/include.am, test/standalone/runners/run_standalone_tests.sh —
  register the test.
• scripts/utils-wolfssl.sh — internal WOLFPROV_FORCE_FIPS_FAILURE knob.
• .github/workflows/fips-ready.yml — build knob + test step + negative-path assertion.

Testing

• Both failure-injection branches (SetStatus and interposition) compile against the
  real FIPS headers.
• Master standalone runner: all pass.

[Copilot]

Pull request overview

This PR fixes FIPS-mode status reporting so that wolfssl_prov_is_running() (and therefore OSSL_PROV_PARAM_STATUS) reflects live wolfCrypt FIPS module failure state instead of always reporting “running”, and adds a standalone regression test plus CI wiring to ensure failures are observable to status-polling callers.

Changes:

• Gate wolfssl_prov_is_running() on wolfCrypt_GetStatus_fips() under HAVE_FIPS so non-zero FIPS status reports OSSL_PROV_PARAM_STATUS == 0.
• Add new standalone fips_status test (plus runner registration) that validates healthy behavior and forced-failure behavior.
• Add a test-only build knob (WOLFPROV_FORCE_FIPS_FAILURE) and CI step to ensure the negative-path assertion actually executes.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/wp_wolfprov.c	Make provider “running” status reflect live wolfCrypt FIPS status under HAVE_FIPS.
test/standalone/tests/fips_status/test_fips_status.c	New standalone regression test for provider status reporting before/after forced FIPS failure.
test/standalone/tests/fips_status/run.sh	Runner script for the new standalone test binary.
test/standalone/runners/run_standalone_tests.sh	Register/execute the new standalone test in the master standalone runner.
test/standalone/include.am	Add build rules for the new fips_status.test standalone program.
scripts/utils-wolfssl.sh	Add internal env knob to enable HAVE_FORCE_FIPS_FAILURE in wolfSSL FIPS builds for testing.
.github/workflows/fips-ready.yml	Enable the knob in CI and add a step that runs the new test and asserts the forced-failure branch executed.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #428

Scan targets checked: wolfprovider-bugs, wolfprovider-src

No new issues found in the changed files. ✅

[padelsbach]

Is there a more generic and thus more robust check than looking for this specific string? Maybe look for a pass/fail?

[padelsbach]

Can we call this WOLFPROV_FIPS_FORCE_FAIL for consistency with WOLFPROV_FORCE_FAIL?