)]}'
{
  "commit": "4188c3f49552bfea3b740b3007fdcb096d21cae1",
  "tree": "e63222410c1b11a4248ab8500090480fd0ee64a6",
  "parents": [
    "5963bff2378e55aa32dabf0cd0ef00ce3b71d849"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Sun Nov 18 14:24:52 2018 -0600"
  },
  "committer": {
    "name": "CQ bot account: commit-bot@chromium.org",
    "email": "commit-bot@chromium.org",
    "time": "Mon Nov 19 19:10:09 2018 +0000"
  },
  "message": "Remove cacheline striping in copy_from_prebuf.\n\nThe standard computation model for constant-time code is that memory\naccess patterns must be independent of secret data.\nBN_mod_exp_mont_consttime was previously written to a slightly weaker\nmodel: only cacheline access patterns must be independent of secret\ndata. It assumed accesses within a cacheline were indistinguishable.\n\nThe CacheBleed attack (https://eprint.iacr.org/2016/224.pdf) showed this\nassumption was false. Cache lines may be divided into cache banks, and\nthe researchers were able to measure cache bank contention pre-Haswell.\nFor Haswell, the researchers note \"But, as Haswell does show timing\nvariations that depend on low address bits [19], it may be vulnerable to\nsimilar attacks.\"\n\nOpenSSL\u0027s fix to CacheBleed was not to adopt the standard constant-time\ncomputation model. Rather, it now assumes accesses within a 16-byte\ncache bank are indistinguishable, at least in the C copy_from_prebuf\npath. These weaker models failed before with CacheBleed, so avoiding\nsuch assumptions seems prudent. (The [19] citation above notes a false\ndependence between memory addresses with a distance of 4k, which may be\nwhat the paper was referring to.) Moreover, the C path is largely unused\non x86_64 (which uses mont5 asm), so it is especially questionable for\nthe generic C code to make assumptions based on x86_64.\n\nJust walk the entire table in the C implementation. Doing so as-is comes\nwith a performance hit, but the striped memory layout is, at that point,\nuseless. We regain the performance loss (and then some) by using a more\nnatural layout. Benchmarks below.\n\nThis CL does not touch the mont5 assembly; I haven\u0027t figured out what\nit\u0027s doing yet.\n\nPixel 3, aarch64:\nBefore:\nDid 3146 RSA 2048 signing operations in 10009070us (314.3 ops/sec)\nDid 447 RSA 4096 signing operations in 10026666us (44.6 ops/sec)\nAfter:\nDid 3210 RSA 2048 signing operations in 10010712us (320.7 ops/sec)\nDid 456 RSA 4096 signing operations in 10063543us (45.3 ops/sec)\n\nPixel 3, armv7:\nBefore:\nDid 2688 RSA 2048 signing operations in 10002266us (268.7 ops/sec)\nDid 459 RSA 4096 signing operations in 10004785us (45.9 ops/sec)\nAfter:\nDid 2709 RSA 2048 signing operations in 10001299us (270.9 ops/sec)\nDid 459 RSA 4096 signing operations in 10063737us (45.6 ops/sec)\n\nx86_64 Broadwell, mont5 assembly disabled:\n(This configuration is not actually shipped anywhere, but seemed a\nuseful data point.)\nBefore:\nDid 14274 RSA 2048 signing operations in 10009130us (1426.1 ops/sec)\nDid 2448 RSA 4096 signing operations in 10046921us (243.7 ops/sec)\nAfter:\nDid 14706 RSA 2048 signing operations in 10037908us (1465.0 ops/sec)\nDid 2538 RSA 4096 signing operations in 10059986us (252.3 ops/sec)\n\nChange-Id: If41da911d4281433856a86c6c8eadf99cd33e2d8\nReviewed-on: https://boringssl-review.googlesource.com/c/33268\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "fa326a7fe0212d7b92abc0b3bbb39bc8405b87f7",
      "old_mode": 33188,
      "old_path": "crypto/fipsmodule/bn/exponentiation.c",
      "new_id": "1b9680fb9a028b570270ec05dc36427ca86946c7",
      "new_mode": 33188,
      "new_path": "crypto/fipsmodule/bn/exponentiation.c"
    }
  ]
}