)]}'
{
  "commit": "745a3c7bf8a435ab80829024a671ddd65c31463b",
  "tree": "d5c5c117b021645042ef8873ee40ab6dbfe72a6a",
  "parents": [
    "f259e982fc16afb87f3263ddd71203f29727aab5"
  ],
  "author": {
    "name": "William Dauchy",
    "email": "wdauchy@gmail.com",
    "time": "Fri Oct 02 21:03:38 2026 +0200"
  },
  "committer": {
    "name": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "time": "Wed Oct 07 14:28:37 2026 -0700"
  },
  "message": "Speed up copy_from_prebuf by accumulating in registers\n\ncopy_from_prebuf is the constant-time table lookup in\nBN_mod_exp_mont_consttime. It ORs each masked table entry into the\noutput with b-\u003ed[j] |\u003d table[j] \u0026 mask. Because b-\u003ed may alias table,\nthe compiler cannot keep the output in registers across table entries,\nso each of the 2^window passes reloads and stores every output limb\nand depends on the previous pass through a store-to-load round trip.\n\nInstead, compute the 2^window masks up front, still behind\nvalue_barrier_w, and build the output four limbs at a time in local\naccumulators, walking all table entries before storing each limb once.\nAs before, the memory access pattern does not depend on idx: every\nlimb of every table entry is read, and selection is done only with\nmasks. The window size macros move above the function so that\nBN_MAX_MOD_EXP_CTIME_WINDOW can size the mask array.\n\nOn x86_64, RSA uses the mont5 assembly and does not reach this code.\nOn aarch64 it is on the RSA private key path for 2048- to 4096-bit\nkeys. In an Envoy TLS-terminating proxy on AWS Graviton4, it was 18%\nof CPU time under an RSA-2048 handshake load. (AWS-LC replaced this\nfunction with an s2n-bignum assembly lookup on aarch64; this change\nstays in portable C.)\n\nbssl_bench BM_SpeedRSASign, single thread, signs/s:\n\nCPU                          RSA-2048                RSA-3072  RSA-4096\nNeoverse V2 (Graviton4) [1]  1061 -\u003e 1268  (+19.5%)  +15%      +12%\nNeoverse N1 (Graviton2)       282 -\u003e  304  (+7.8%)   +5.5%     +5.0%\nApple M4 Max                 2645 -\u003e 3045  (+15.1%)  +12.9%    +9.7%\nXeon 8375C, NO_ASM [2]        740 -\u003e  794  (+7.2%)   +3.9%     +7.0%\n\n[1] Measured on BoringSSL 0.20260413.0 with this change applied. In\n    Envoy with one TLS 1.3 handshake per request on an RSA-2048\n    certificate, throughput went from 806 to 895 requests per\n    CPU-second (+11%) and p99 latency from 4.6 to 3.5 ms.\n[2] OPENSSL_NO_ASM to exercise the C path on x86_64; median of 8 runs\n    on a shared machine, so noisy. With assembly enabled, x86_64 RSA\n    does not use this function and is unchanged within noise (Zen 5,\n    ~2510 RSA-2048 signs/s either way).\n\nWith CONSTANT_TIME_VALIDATION, the BN and RSA tests in crypto_test\nreport no new valgrind errors on aarch64 (Neoverse N1) or on x86_64\nwith OPENSSL_NO_ASM. (On aarch64, valgrind flags the same two reads of\nan empty std::optional in the ErrorEquals test helper with and without\nthis change; nothing in the library.)\n\nChange-Id: Idabb8c6d515e9e577a58118da8ec2f964ee5d334\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/103567\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\nReviewed-by: David Benjamin \u003cdavidben@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "dfdb9074c70d07fb82570f0ef9af84224bbe5f11",
      "old_mode": 33188,
      "old_path": "crypto/fipsmodule/bn/exponentiation.cc.inc",
      "new_id": "81b638593f2d2af40f17a0aec5f438912487546c",
      "new_mode": 33188,
      "new_path": "crypto/fipsmodule/bn/exponentiation.cc.inc"
    }
  ]
}