Having a patched version that builds is one aspect,
another one is the risk it introduces.
Hence now assessing the risk, that we carefully need to consider.

Did a (machine assited) risk assessment of the openssl v4.0.1-1ubuntu6
package, with everything that was needed to backport "ML-DSA NTT
vectorization":

Scope:

14 patches, 209 files touched, +4,083 / -305 lines relative to 4.0.1. One
patch (s390x-Fix-montgomery_multiplication_vectorized) is our own addition,
fixing a bug caught in testing - see below.

  # | Patch                                              | Files | +/-       | 
Arch scope 
--|-----------------------------------------------------|-------|-----------|---------------------------------------------
  1 | Add AVX2 asm for ML-DSA NTT                         |    4  | +1858/-2  | 
x86_64-only (asm)
  2 | Refactor to function pointers (AVX2/scalar)         |    1  | +114/-52  | 
generic dispatch, all arches
  3 | Optimize vmovshdup                                  |    1  | +203/-187 | 
x86_64-only (asm)
  4 | Preserve XMM regs on Windows                        |    1  | +83/-0    | 
x86_64/Windows-only (asm)
  5 | Win64 SEH unwind support                            |    1  | +146/-16  | 
x86_64/Windows-only (asm)
  6 | ML-DSA/ML-KEM fromdata propq                        |   12  | +136/-33  | 
generic keymgmt, all arches
  7 | Valgrind CT support                                 |   11  | +456/-72  | 
generic, all arches (no-op unless built with
    |                                                      |       |           
| CT validation)
  8 | Drop value barrier from reduce_once                 |    1  | +24/-12   | 
generic scalar CT code, all arches
  9 | Add missing header guards                           |   54  | +270/-0   | 
~54 unrelated files, all arches
 10 | Make crypto includes self-contained                 |   29  | +91/-11   | 
~29 unrelated files, all arches
 11 | Move *_arch.h -> include/arch                       |  118  | +128/-128 | 
mechanical, touches every non-x86 arch's
    |                                                      |       |           
| capability files
 12 | Vectorize (inverse) NTT (target)                    |    9  | +791/-24  | 
s390x vec128 impl + generic dispatch/sign/
    |                                                      |       |           
| verify glue
 13 | s390x fix (ours)                                    |    1  | +37/-22   | 
s390x-only

Bottom line up front: this is unfortunately not a self-contained, 
s390x-specific feature anymore.
About 60% of the files touched (patches 6, 7, 8, 9, 10, 11, and parts of 12) 
are platform-agnostic or affect non-target architectures, and were pulled in 
only to satisfy prerequisite/context dependencies for a clean apply.
That materially widens the risk surface beyond "s390x performance feature."

What we already know was broken (proof this risk):

The 30-test_ml_dsa.t / 30-test_evp.t s390x failure we just fixed is a real
live of the exact risk class flagged below: brand-new vector/SIMD
arithmetic code (ml_dsa_ntt_vec128.c), unaudited by real hardware for ~2.5
months upstream, shipped a montgomery-reduction bug that produced
deterministically wrong ML-DSA-65/87 keys and signatures (not a flaky/rare
bug - fixed KAT vectors failed).
It was caught only because the Launchpad s390x buildd actually ran the test 
suite on real hardware.
Means that:
  - New arch-specific vector code in this area has a demonstrated,
    non-hypothetical defect rate.
  - Our own amd64-only validation during initial backport analysis
    (Configure + build + tests) was insufficient to catch an s390x-specific bug.
    - Similar blind spots exists for other architectures.

Platform-agnostic code that increases risk beyond s390x:

1. NTT dispatch/init mechanism (crypto/ml_dsa/ml_dsa_ntt.c) - runs on every
   architecture
2. Sign/verify buffer allocation rewrite (crypto/ml_dsa/ml_dsa_sign.c)
3. Constant-time helper rewrite (crypto/ml_dsa/ml_dsa_local.h)
4. fromdata property-query support (ML-DSA and ML-KEM keymgmt)
5. Header-guard / self-contained-include hygiene patches
6. Arch-header rename (Move *_arch.h -> include/arch)
(I can go into more details on the above if needed.)

Things that are not concerning:
  - Patches #1, #3, #4, #5 (AVX2 asm, vmovshdup optimization, Windows
    XMM/SEH fixes) are strictly gated to x86_64 (and further to Windows for
    #4/#5) via build.info/preprocessor guards - zero exposure for
    non-x86_64 targets.
  - Patch #7 (valgrind CT support) only activates under
    OPENSSL_CONSTANT_TIME_VALIDATION, which is off in normal builds - no
    runtime behavior change by default.
  - The s390x vec128 file itself (ml_dsa_ntt_vec128.c) is fully gated behind
    OPENSSL_ML_DSA_S390X / build.info's perlasm_scheme != '31' check -
    confirmed it does not compile into non-s390x builds.
  - Two of the originally-identified "prerequisite" commits turned out to be
    no-ops against 4.0.1 (already fixed by earlier unrelated CVE backports)
    and were correctly excluded - no risk from those.

Residual risk:
1. This cannot be considered as 100% safe for all architectures,
   even with the successful PPA buiulds for all platforms.
2. It impacts Valgrind-CT (constant-time) pass now that
   patch #7 is in the tree, specifically over reduce_once/abs_signed/
   abs_mod_prime/maximum - the "dropped value barrier" change (item 3 above)
   is a deliberate but real weakening of one specific side-channel
   mitigation, and its safety currently rests entirely on upstream's own
   review, not on anything this package build validates.
3. There is a cerstin regression risk for libcrypto as a whole,
   not a narrow s390x feature: a bug in the shared ml_dsa_sign.c
   allocation path or the CT helper rewrite would affect TLS/CMS/anything
   using ML-DSA on amd64/arm64 desktops and servers,
   that could have a larger impact.
4. Given upstream shipped a real correctness bug in this exact code for
   ~2.5 months before fixing it, and given we are backporting to a
   stable-branch package (not to master where more eyes/CI iterate
   quickly), consider whether it's worth waiting for one more upstream
   release cycle to see if further fixes land for this code before it's
   considered "battle-tested," or explicitly flagging it as new/
   experimental in release notes.

Considering all this, brings us to the following conclusion that the
risk might be too high, hence we are recommending to not incl. the patch
set (for now) into 4.0.1 of 26.10, but keep it in PPA instead.

26.10 is a non-LTS only, means supported for only 9 month, that gives us
the opportunity to start soon looking into again, based on the follow-on
release.

Meanwhile the PPA build could be maintained on a best effort based, used
for further testing and stabilization, and could also be expanded with
the further patches from LP#2138631 once they landed in main.

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

Title:
  [26.10 FEAT] [SEC2555] openSSL: optimize ML-DSA for the s390x
  architecture

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2138632/+subscriptions


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

Reply via email to