Performance Testing on CET Hardware

Measured overhead on systems with Intel CET (IBT) enabled, against an IBT baseline

The numbers below are the performance overhead of running protected builds on hardware with Intel CET's Indirect Branch Tracking (IBT) enabled. Both the baseline and the protected build were built with IBT active, isolating the cost of our protection on top of IBT, not the cost of IBT itself. Both builds were produced with the same compiler and flags and measured on the same machine in the same session. The OpenSSL and SQLite workloads are 20 interleaved runs; the FFmpeg workloads (30 seconds of 1080p video per encode or decode) are 7 interleaved runs, reported as a paired change. The bracketed interval is the 95% confidence interval on the change from the paired runs.

Bars left of the zero line are faster than the IBT baseline and bars right of it are slower. Every workload lands within a few percent either way.

Overhead by workload, IBT-enabled hardware Every workload plotted as percent overhead versus an IBT baseline. Most workloads land within a few percent either side of zero in either direction; FFmpeg AAC encode has the largest overhead and FFmpeg MJPEG encode the largest speedup on this sample. WORKLOAD % OVERHEAD VS IBT BASELINE −3% −2% −1% 0% +1% +2% +3% FFmpeg MPEG-4 encode −0.53% FFmpeg MPEG-4 decode −1.01% FFmpeg MJPEG encode −2.79% FFmpeg AAC encode +2.06% FFmpeg AAC decode −2.37% OpenSSL AES-128-CBC −0.04% OpenSSL AES-256-GCM −0.82% OpenSSL SHA-256 −0.47% OpenSSL RSA-2048 +0.61% OpenSSL ECDSA-P256 −0.22% SQLite speedtest1 +0.21%
% overhead is measured against an IBT baseline built with the same compiler and flags. The throughput rows (OpenSSL) are sign-inverted here so that every bar is directly comparable; the table below reports each result against its own raw metric, alongside the 95% confidence interval on the change.

Only three workloads have a confidence interval that clears zero, and all three are faster under protection than without it.

Workload Baseline median Protected median Change, 95% CI
FFmpeg MPEG-4 encode1.2049 s1.1945 s−0.53% [−1.03, −0.04]
FFmpeg MPEG-4 decode1.1530 s1.1223 s−1.01% [−4.79, +3.47]
FFmpeg MJPEG encode3.9381 s3.8899 s−2.79% [−6.20, −0.81]
FFmpeg AAC encode0.1322 s0.1361 s+2.06% [−0.79, +4.63]
FFmpeg AAC decode0.0151 s0.0149 s−2.37% [−5.99, +1.66]
OpenSSL AES-128-CBC1.9576 GB/s1.9562 GB/s+0.04% [−0.23, +0.30]
OpenSSL AES-256-GCM13.0025 GB/s13.1142 GB/s+0.82% [+0.12, +1.51]
OpenSSL SHA-2562.4393 GB/s2.4481 GB/s+0.47% [−0.27, +1.21]
OpenSSL RSA-20485,698 ops/s5,678 ops/s−0.61% [−2.79, +1.57]
OpenSSL ECDSA-P25623,612 ops/s23,640 ops/s+0.22% [−0.23, +0.67]
SQLite speedtest11.3241 s1.3332 s+0.21% [−0.61, +1.04]

Baseline and protected medians are both measured with IBT enabled. Change is reported against the raw metric: for the time-based rows (seconds) lower is better, so a positive change is slower; for the throughput rows (GB/s, ops/s) higher is better, so a negative change is slower. Confidence intervals that cross zero are not distinguishable from noise at this sample size.

Reading the numbers

Only three workloads have a confidence interval that stays entirely on one side of zero: MPEG-4 encode, MJPEG encode, and AES-256-GCM, all measurably faster under protection on top of the IBT baseline. Everything else, including the largest point movements among them (AAC decode and AAC encode), has an interval wide enough to cross zero, meaning the direction isn't distinguishable from run-to-run noise at this sample size. As with the shadow-stack numbers elsewhere on this site, the cryptographic rows are the noisiest to measure and move in both directions, which is expected for code that spends nearly all its time in tight, hand-tuned inner loops with little for the protection to act on.