Add SkRuntimeEffect Fuzzer
The major improvement is that now the fuzzer is able to execute
the sksl code (before it just compiled it). The fuzzer will
reserve 256 bytes for providing uniforms to the shader;
meanwhile, the fuzzer will read the remaining bytes as sksl code
to create SkRuntimeEffect. It then creates a shader and executes
it by painting the shader on a canvas.
The code was tested locally with afl-fuzz, and the execution
speed was around 700/sec.
An alternative implementation would have been using Fuzz.h to
read bytes; I decided to go with sk_sp<SkData> since it has a
comparable format to other binary fuzzer and meets all the
functionality in this fuzzer.
For future changes, there are 2 important improvements to the
implementation:
1) Current shader does not have children shaders; thus,
makeShader() will fail if the SkSL ever tries to use an 'in shader'.
As pointed out in patchset 11, after creating the runtime effect,
effect->children().count() will tell you how many children it's
expecting (how many 'in shader' variables were declared). When you
call makeShader(), the second and third arguments are a
(C-style) array of shader pointers, and
a count (which must match children().count()).
Some helpful examples can be SkRTShader::CreateProc in
SkRuntimeEffect.cpp, make_fuzz_shader in FuzzCanvas.cpp.
2)
In this fuzzer, after creating the paint from a shader, the paint
can be drawn on either GPU canvas or CPU, so a possible way is to
use SkSurface::MakeRenderTarget to create GPU canvas and use a byte
to determine which canvas it will be drawn on.
Change-Id: Ib0385edd0f5ec2f23744aa517135a6955c53ba38
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/300618
Commit-Queue: Zepeng Hu <zepenghu@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
2020-07-10 13:36:20 +00:00
|
|
|
/*
|
|
|
|
|
* Copyright 2020 Google, LLC
|
|
|
|
|
*
|
|
|
|
|
* Use of this source code is governed by a BSD-style license that can be
|
|
|
|
|
* found in the LICENSE file.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include "include/core/SkCanvas.h"
|
|
|
|
|
#include "include/core/SkPaint.h"
|
|
|
|
|
#include "include/core/SkSurface.h"
|
|
|
|
|
#include "include/effects/SkRuntimeEffect.h"
|
2020-08-12 14:25:31 +00:00
|
|
|
#include "src/core/SkRuntimeEffectPriv.h"
|
Add SkRuntimeEffect Fuzzer
The major improvement is that now the fuzzer is able to execute
the sksl code (before it just compiled it). The fuzzer will
reserve 256 bytes for providing uniforms to the shader;
meanwhile, the fuzzer will read the remaining bytes as sksl code
to create SkRuntimeEffect. It then creates a shader and executes
it by painting the shader on a canvas.
The code was tested locally with afl-fuzz, and the execution
speed was around 700/sec.
An alternative implementation would have been using Fuzz.h to
read bytes; I decided to go with sk_sp<SkData> since it has a
comparable format to other binary fuzzer and meets all the
functionality in this fuzzer.
For future changes, there are 2 important improvements to the
implementation:
1) Current shader does not have children shaders; thus,
makeShader() will fail if the SkSL ever tries to use an 'in shader'.
As pointed out in patchset 11, after creating the runtime effect,
effect->children().count() will tell you how many children it's
expecting (how many 'in shader' variables were declared). When you
call makeShader(), the second and third arguments are a
(C-style) array of shader pointers, and
a count (which must match children().count()).
Some helpful examples can be SkRTShader::CreateProc in
SkRuntimeEffect.cpp, make_fuzz_shader in FuzzCanvas.cpp.
2)
In this fuzzer, after creating the paint from a shader, the paint
can be drawn on either GPU canvas or CPU, so a possible way is to
use SkSurface::MakeRenderTarget to create GPU canvas and use a byte
to determine which canvas it will be drawn on.
Change-Id: Ib0385edd0f5ec2f23744aa517135a6955c53ba38
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/300618
Commit-Queue: Zepeng Hu <zepenghu@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
2020-07-10 13:36:20 +00:00
|
|
|
#include "src/gpu/GrShaderCaps.h"
|
|
|
|
|
|
|
|
|
|
#include "fuzz/Fuzz.h"
|
|
|
|
|
|
|
|
|
|
static constexpr size_t kReservedBytes = 256;
|
|
|
|
|
/**
|
|
|
|
|
* The fuzzer will take in the bytes and divide into two parts.
|
|
|
|
|
* original bytes : [... code bytes ... | 256 bytes]
|
|
|
|
|
* The first part is codeBytes, the original bytes minus 256 bytes, which will be treated
|
|
|
|
|
* as sksl code, intending to create SkRuntimeEffect.
|
|
|
|
|
* For the second part, it will first reserve 256 bytes and then allocate bytes with same size
|
|
|
|
|
* as effect->inputSize() to uniformBytes. The uniformBytes is intended to create makeShader().
|
|
|
|
|
* Note that if uniformBytes->size() != effect->inputSize() the shader won't be created.
|
2020-08-12 14:25:31 +00:00
|
|
|
*
|
|
|
|
|
* We fuzz twice, with two different settings for inlining in the SkSL compiler. By default, the
|
|
|
|
|
* compiler inlines most small to medium functions. This can hide bugs related to function-calling.
|
|
|
|
|
* So we run the fuzzer once with inlining disabled, and again with it enabled (aggressively).
|
|
|
|
|
* This gives us better coverage, and eases the burden on the fuzzer to inject useless noise into
|
|
|
|
|
* functions to suppress inlining.
|
Add SkRuntimeEffect Fuzzer
The major improvement is that now the fuzzer is able to execute
the sksl code (before it just compiled it). The fuzzer will
reserve 256 bytes for providing uniforms to the shader;
meanwhile, the fuzzer will read the remaining bytes as sksl code
to create SkRuntimeEffect. It then creates a shader and executes
it by painting the shader on a canvas.
The code was tested locally with afl-fuzz, and the execution
speed was around 700/sec.
An alternative implementation would have been using Fuzz.h to
read bytes; I decided to go with sk_sp<SkData> since it has a
comparable format to other binary fuzzer and meets all the
functionality in this fuzzer.
For future changes, there are 2 important improvements to the
implementation:
1) Current shader does not have children shaders; thus,
makeShader() will fail if the SkSL ever tries to use an 'in shader'.
As pointed out in patchset 11, after creating the runtime effect,
effect->children().count() will tell you how many children it's
expecting (how many 'in shader' variables were declared). When you
call makeShader(), the second and third arguments are a
(C-style) array of shader pointers, and
a count (which must match children().count()).
Some helpful examples can be SkRTShader::CreateProc in
SkRuntimeEffect.cpp, make_fuzz_shader in FuzzCanvas.cpp.
2)
In this fuzzer, after creating the paint from a shader, the paint
can be drawn on either GPU canvas or CPU, so a possible way is to
use SkSurface::MakeRenderTarget to create GPU canvas and use a byte
to determine which canvas it will be drawn on.
Change-Id: Ib0385edd0f5ec2f23744aa517135a6955c53ba38
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/300618
Commit-Queue: Zepeng Hu <zepenghu@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
2020-07-10 13:36:20 +00:00
|
|
|
*/
|
2020-08-12 14:25:31 +00:00
|
|
|
static bool FuzzSkRuntimeEffect_Once(sk_sp<SkData> bytes) {
|
Add SkRuntimeEffect Fuzzer
The major improvement is that now the fuzzer is able to execute
the sksl code (before it just compiled it). The fuzzer will
reserve 256 bytes for providing uniforms to the shader;
meanwhile, the fuzzer will read the remaining bytes as sksl code
to create SkRuntimeEffect. It then creates a shader and executes
it by painting the shader on a canvas.
The code was tested locally with afl-fuzz, and the execution
speed was around 700/sec.
An alternative implementation would have been using Fuzz.h to
read bytes; I decided to go with sk_sp<SkData> since it has a
comparable format to other binary fuzzer and meets all the
functionality in this fuzzer.
For future changes, there are 2 important improvements to the
implementation:
1) Current shader does not have children shaders; thus,
makeShader() will fail if the SkSL ever tries to use an 'in shader'.
As pointed out in patchset 11, after creating the runtime effect,
effect->children().count() will tell you how many children it's
expecting (how many 'in shader' variables were declared). When you
call makeShader(), the second and third arguments are a
(C-style) array of shader pointers, and
a count (which must match children().count()).
Some helpful examples can be SkRTShader::CreateProc in
SkRuntimeEffect.cpp, make_fuzz_shader in FuzzCanvas.cpp.
2)
In this fuzzer, after creating the paint from a shader, the paint
can be drawn on either GPU canvas or CPU, so a possible way is to
use SkSurface::MakeRenderTarget to create GPU canvas and use a byte
to determine which canvas it will be drawn on.
Change-Id: Ib0385edd0f5ec2f23744aa517135a6955c53ba38
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/300618
Commit-Queue: Zepeng Hu <zepenghu@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
2020-07-10 13:36:20 +00:00
|
|
|
if (bytes->size() < kReservedBytes) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
sk_sp<SkData> codeBytes = SkData::MakeSubset(bytes.get(), 0, bytes->size() - kReservedBytes);
|
|
|
|
|
|
|
|
|
|
SkRuntimeEffect::EffectResult tuple = SkRuntimeEffect::Make(
|
|
|
|
|
SkString((const char*) codeBytes->data(), codeBytes->size())
|
|
|
|
|
);
|
|
|
|
|
SkRuntimeEffect* effect = std::get<0>(tuple).get();
|
|
|
|
|
|
Remove 'in' variables from SkRuntimeEffect
Runtime effects previously allowed two kinds of global input variables:
'in' variables could be bool, int, or float. 'uniform' could be float,
vector, or matrix. Uniform variables worked like you'd expect, but 'in'
variables were baked into the program statically. There was a large
amount of machinery to make this work, and it meant that 'in' variables
needed to have values before we could make decisions about program
caching, and before we could catch some errors. It was also essentially
syntactic sugar over the client just inserting the value into their SkSL
as a string. Finally: No one was using the feature.
To simplify the mental model, and make the API much more predictable,
this CL removes 'in' variables entirely. We no longer need to
"specialize" runtime effect programs, which means we can catch more
errors up front (those not detected until optimization). All of the API
that referred to "inputs" (the previous term that unified 'in' and
'uniform') now just refers to "uniforms".
Bug: skia:10593
Change-Id: I971f620d868b259e652b3114f0b497c2620f4b0c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/309050
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
2020-08-10 18:26:16 +00:00
|
|
|
if (!effect || effect->uniformSize() > kReservedBytes) { // if there is not enough uniform bytes
|
Add SkRuntimeEffect Fuzzer
The major improvement is that now the fuzzer is able to execute
the sksl code (before it just compiled it). The fuzzer will
reserve 256 bytes for providing uniforms to the shader;
meanwhile, the fuzzer will read the remaining bytes as sksl code
to create SkRuntimeEffect. It then creates a shader and executes
it by painting the shader on a canvas.
The code was tested locally with afl-fuzz, and the execution
speed was around 700/sec.
An alternative implementation would have been using Fuzz.h to
read bytes; I decided to go with sk_sp<SkData> since it has a
comparable format to other binary fuzzer and meets all the
functionality in this fuzzer.
For future changes, there are 2 important improvements to the
implementation:
1) Current shader does not have children shaders; thus,
makeShader() will fail if the SkSL ever tries to use an 'in shader'.
As pointed out in patchset 11, after creating the runtime effect,
effect->children().count() will tell you how many children it's
expecting (how many 'in shader' variables were declared). When you
call makeShader(), the second and third arguments are a
(C-style) array of shader pointers, and
a count (which must match children().count()).
Some helpful examples can be SkRTShader::CreateProc in
SkRuntimeEffect.cpp, make_fuzz_shader in FuzzCanvas.cpp.
2)
In this fuzzer, after creating the paint from a shader, the paint
can be drawn on either GPU canvas or CPU, so a possible way is to
use SkSurface::MakeRenderTarget to create GPU canvas and use a byte
to determine which canvas it will be drawn on.
Change-Id: Ib0385edd0f5ec2f23744aa517135a6955c53ba38
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/300618
Commit-Queue: Zepeng Hu <zepenghu@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
2020-07-10 13:36:20 +00:00
|
|
|
return false;
|
|
|
|
|
}
|
Remove 'in' variables from SkRuntimeEffect
Runtime effects previously allowed two kinds of global input variables:
'in' variables could be bool, int, or float. 'uniform' could be float,
vector, or matrix. Uniform variables worked like you'd expect, but 'in'
variables were baked into the program statically. There was a large
amount of machinery to make this work, and it meant that 'in' variables
needed to have values before we could make decisions about program
caching, and before we could catch some errors. It was also essentially
syntactic sugar over the client just inserting the value into their SkSL
as a string. Finally: No one was using the feature.
To simplify the mental model, and make the API much more predictable,
this CL removes 'in' variables entirely. We no longer need to
"specialize" runtime effect programs, which means we can catch more
errors up front (those not detected until optimization). All of the API
that referred to "inputs" (the previous term that unified 'in' and
'uniform') now just refers to "uniforms".
Bug: skia:10593
Change-Id: I971f620d868b259e652b3114f0b497c2620f4b0c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/309050
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
2020-08-10 18:26:16 +00:00
|
|
|
sk_sp<SkData> uniformBytes =
|
|
|
|
|
SkData::MakeSubset(bytes.get(), bytes->size() - kReservedBytes, effect->uniformSize());
|
Add SkRuntimeEffect Fuzzer
The major improvement is that now the fuzzer is able to execute
the sksl code (before it just compiled it). The fuzzer will
reserve 256 bytes for providing uniforms to the shader;
meanwhile, the fuzzer will read the remaining bytes as sksl code
to create SkRuntimeEffect. It then creates a shader and executes
it by painting the shader on a canvas.
The code was tested locally with afl-fuzz, and the execution
speed was around 700/sec.
An alternative implementation would have been using Fuzz.h to
read bytes; I decided to go with sk_sp<SkData> since it has a
comparable format to other binary fuzzer and meets all the
functionality in this fuzzer.
For future changes, there are 2 important improvements to the
implementation:
1) Current shader does not have children shaders; thus,
makeShader() will fail if the SkSL ever tries to use an 'in shader'.
As pointed out in patchset 11, after creating the runtime effect,
effect->children().count() will tell you how many children it's
expecting (how many 'in shader' variables were declared). When you
call makeShader(), the second and third arguments are a
(C-style) array of shader pointers, and
a count (which must match children().count()).
Some helpful examples can be SkRTShader::CreateProc in
SkRuntimeEffect.cpp, make_fuzz_shader in FuzzCanvas.cpp.
2)
In this fuzzer, after creating the paint from a shader, the paint
can be drawn on either GPU canvas or CPU, so a possible way is to
use SkSurface::MakeRenderTarget to create GPU canvas and use a byte
to determine which canvas it will be drawn on.
Change-Id: Ib0385edd0f5ec2f23744aa517135a6955c53ba38
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/300618
Commit-Queue: Zepeng Hu <zepenghu@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
2020-07-10 13:36:20 +00:00
|
|
|
auto shader = effect->makeShader(uniformBytes, nullptr, 0, nullptr, false);
|
|
|
|
|
if (!shader) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
SkPaint paint;
|
|
|
|
|
paint.setShader(std::move(shader));
|
|
|
|
|
|
|
|
|
|
sk_sp<SkSurface> s = SkSurface::MakeRasterN32Premul(128, 128);
|
|
|
|
|
if (!s) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
s->getCanvas()->drawPaint(paint);
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-12 14:25:31 +00:00
|
|
|
bool FuzzSkRuntimeEffect(sk_sp<SkData> bytes) {
|
|
|
|
|
// Inline nothing
|
|
|
|
|
SkRuntimeEffect_SetInlineThreshold(0);
|
|
|
|
|
bool result = FuzzSkRuntimeEffect_Once(bytes);
|
|
|
|
|
|
|
|
|
|
// Inline everything
|
|
|
|
|
SkRuntimeEffect_SetInlineThreshold(std::numeric_limits<int>::max());
|
|
|
|
|
result = FuzzSkRuntimeEffect_Once(bytes) || result;
|
|
|
|
|
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-14 12:37:35 +00:00
|
|
|
#if defined(SK_BUILD_FOR_LIBFUZZER)
|
Add SkRuntimeEffect Fuzzer
The major improvement is that now the fuzzer is able to execute
the sksl code (before it just compiled it). The fuzzer will
reserve 256 bytes for providing uniforms to the shader;
meanwhile, the fuzzer will read the remaining bytes as sksl code
to create SkRuntimeEffect. It then creates a shader and executes
it by painting the shader on a canvas.
The code was tested locally with afl-fuzz, and the execution
speed was around 700/sec.
An alternative implementation would have been using Fuzz.h to
read bytes; I decided to go with sk_sp<SkData> since it has a
comparable format to other binary fuzzer and meets all the
functionality in this fuzzer.
For future changes, there are 2 important improvements to the
implementation:
1) Current shader does not have children shaders; thus,
makeShader() will fail if the SkSL ever tries to use an 'in shader'.
As pointed out in patchset 11, after creating the runtime effect,
effect->children().count() will tell you how many children it's
expecting (how many 'in shader' variables were declared). When you
call makeShader(), the second and third arguments are a
(C-style) array of shader pointers, and
a count (which must match children().count()).
Some helpful examples can be SkRTShader::CreateProc in
SkRuntimeEffect.cpp, make_fuzz_shader in FuzzCanvas.cpp.
2)
In this fuzzer, after creating the paint from a shader, the paint
can be drawn on either GPU canvas or CPU, so a possible way is to
use SkSurface::MakeRenderTarget to create GPU canvas and use a byte
to determine which canvas it will be drawn on.
Change-Id: Ib0385edd0f5ec2f23744aa517135a6955c53ba38
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/300618
Commit-Queue: Zepeng Hu <zepenghu@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
2020-07-10 13:36:20 +00:00
|
|
|
extern "C" int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
|
|
|
|
|
if (size > 3000) {
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
auto bytes = SkData::MakeWithoutCopy(data, size);
|
|
|
|
|
FuzzSkRuntimeEffect(bytes);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
