Commit Graph

3 Commits

Author SHA1 Message Date
Mike Reed
34c56a5c3d Migrate to drawImage w/ sampling
Bug: skia:7650
Change-Id: Icb99ee9f7142fe1ca22f9fa66b1467486ce576a6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/357598
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
2021-01-22 22:38:02 +00:00
Mike Reed
e02d7f844b More hiding of legacy drawImage calls
Also cleanup some of the duplicate code in SkRecords

Bug: skia:7650
Change-Id: I4d3167a892c126c19a54002beab25c9a6c96fa5d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/357000
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
2021-01-22 13:53:42 +00:00
Mike Klein
5c612ade3b create a sample to demonstrate a timing attack
This sample attempts to re-create an image's alpha channel by drawing it
one pixel at a time and timing how long each pixel takes to draw.

The "abc" text should appear twice normally, and the third and fourth
versions are reconstructed from timing, one by timing 1:1 pixel draws,
the other by timing 1x1:1024x1024 upscale into an offscreen.  It's not
meant to be an exact reconstruction, but you can easily see the shapes,
particularly at -O0, -O1, and -Os.  Auto-vectorization from -O2/-O3 do
a good amount to cover up the problem.

The legacy CPU backend is the main place to look.  I haven't been able
to reconstruct any images using SkRasterPipelineBlitter or SkVMBlitter,
and while on the GPU I do see non-random patterns in the timing, it
appears to be the same single pattern across devices, OSes, GPUs, GPU
APIs and content... I assume it's something like our resource caching
policy.

This can't really be a GM, given how it draws non-deterministically.

Bug: chromium:1088224
Change-Id: I2ec79c8dd407ecb104fd9bf0c8039cb6dd1fe436
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313466
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Mike Reed <reed@google.com>
2020-08-28 16:17:39 +00:00