Git Product home page Git Product logo

silifuzz's Introduction

SiliFuzz - Fuzzing CPUs by proxy

What is SiliFuzz

SiliFuzz is a system that finds CPU defects by fuzzing software proxies, like CPU simulators or disassemblers, and then executing the accumulated test inputs (known as the corpus) on actual CPUs on a large scale. SiliFuzz is a work in progress, please refer to the paper for details.

Terminology

Software fuzzing and coverage

Fuzzing is a technique of testing a target (an application, or an API) with a large number of test inputs generated on the fly. The goal is to make these inputs as interesting and as diverse as possible in order to trigger corner cases. In other words, fuzzing aims to maximize the combined code coverage. Code coverage may have different meanings, e.g. which basic blocks are executed or which paths are taken in the program.

Proxy

For the purposes of SiliFuzz, a proxy is any software or hardware system that behaves similar to some aspects of the target CPU. For example, a CPU emulator or a disassembler. A proxy is needed when we cannot directly collect coverage information from the target.

By applying fuzzing techniques to a proxy, we can generate a series of test inputs (corpus) that produce interesting behavior in the proxy. Our underlying assumption is that this translates into similarly interesting behavior in the target.

Corpus / Corpus shard

A collection of inputs used for testing the target is known as corpus.

A reasonably large corpus contains millions of inputs and is usually split into multiple non-overlapping chunks called shards.

Snapshot

A SiliFuzz snapshot describes a short sequence of CPU instructions plus an initial state of CPU registers and memory to deterministically execute that sequence. A typical snapshot contains less than 100 bytes of code and runs in microseconds, but it can be arbitrarily large. Snapshots are stored as silifuzz.proto.Snapshot protocol buffers.

Snapshots are typically created from the inputs generated by a fuzzing engine. For CPU testing purposes these inputs are filtered to eliminate all non-deterministic snapshots.

Expected end state

An end state describes the contents of registers and memory expected to exist at the end of a Snapshot execution. If the snapshot executes differently on different CPU microarchitectures it will have multiple expected end states.

Snap

A Snap is an in-memory representation of a Snapshot that can be easily loaded and executed by the Runner. Snaps can be compiled in an executable program (also called baked-in runner) or loaded from disk by a reading runner. In the latter case the Snap on-disk format is essentially the same as the in-memory one except that native pointers are replaced with offsets. See this header for details. This format is often referred to as relocatable. Each Snap contains exactly one expected end state i.e. Snaps are microarchitecture-specific.

Runner

Runner is a binary for testing a single CPU core. A runner consumes a corpus shard, repeatedly executes random Snaps in it and checks that the expected end state is reached. Runner is a single-threaded process.

Orchestrator

The orchestrator is a process that drives multiple runners. In a typical setting the orchestrator will continuously execute one runner per logical CPU core, and accumulate and report any failures produced by the individual runner processes.

Supported platforms and microarchitectures

We have extensively tested SiliFuzz on the following x86_64 microarchitectures running recent Linux kernels:

  • intel-skylake / intel-cascadelake
  • intel-haswell / intel-broadwell
  • intel-ivybridge
  • amd-rome
  • amd-milan

Other x86_64 microarchitectures should work, too, as long as there is the compiler and OS support for them.

We are actively working on AArch64 support.

Trophies

A non-exhaustive list of bugs and defects SiliFuzz has found.

Bugs

A logic bug is an invalid CPU behavior inherent to a particular CPU microarchitecture or stepping. SiliFuzz has identified the following bugs:

Defects

An (electrical) defect is an invalid CPU behavior that happens only on one or several chips. SiliFuzz has found the following defects we described in the paper

  • F2XM1 Defect. Paper / Appendix A
  • Overshoot of an Illegal Instruction. Paper / Appendix B
  • FCOS Miscomputes. Paper / Appendix C
  • Missing x87 Data Pointer Update. Paper / Appendix D

Related projects

  • Centipede is a fuzzing engine developed at Google for fuzzing large and slow targets like CPU emulators.

Prework

Prework (for Bazel)

git clone https://github.com/google/silifuzz.git && cd silifuzz
SILIFUZZ_SRC_DIR=`pwd`
./install_build_dependencies.sh  # Currently, works for the latest Debian and Ubuntu only
bazel build -c opt @silifuzz//tools:{snap_corpus_tool,fuzz_filter_tool,snap_tool,silifuzz_platform_id,simple_fix_tool_main} \
     @silifuzz//runner:reading_runner_main_nolibc \
     @silifuzz//orchestrator:silifuzz_orchestrator_main
SILIFUZZ_BIN_DIR=`pwd`/bazel-bin/
cd "${SILIFUZZ_BIN_DIR}"

NOTE: You can use a Docker container to avoid polluting the host system: docker run -it --tty --security-opt seccomp=unconfined --mount type=bind,source=${SILIFUZZ_SRC_DIR},target=/app debian:bookworm /bin/bash -c "cd /app && ./install_build_dependencies.sh && bazel build ... && bazel test ..."

Prework (fuzzing Unicorn target)

cd "${SILIFUZZ_SRC_DIR}"
COV_FLAGS_FILE="$(bazel info output_base)/external/com_google_fuzztest/centipede/clang-flags.txt"
bazel build -c opt --copt=-UNDEBUG --dynamic_mode=off \
  --per_file_copt=unicorn/.*@$(xargs < "${COV_FLAGS_FILE}" |sed -e 's/,/\\,/g' -e 's/ /,/g') @//proxies:unicorn_x86_64
bazel build -c opt @com_google_fuzztest//centipede:centipede
mkdir -p /tmp/wd

# Fuzz the Unicorn proxy under Centipede with parallelism of 30.
"${SILIFUZZ_BIN_DIR}/external/com_google_fuzztest/centipede/centipede" \
  --binary="${SILIFUZZ_BIN_DIR}/proxies/unicorn_x86_64" \
  --workdir=/tmp/wd \
  -j=30

NOTE: Please refer to Centipede documentation on how to efficiently run the fuzzing engine.

Using pre-generated corpus

You can download Centipede corpus files that have been generated using the instructions above here. The data can be processed by simple_fix_tool or used to seed future fuzzing runs.

Tools

silifuzz_platform_id

This helper tool is to check that the machine you're running on is supported.

$ ${SILIFUZZ_BIN_DIR}/tools/silifuzz_platform_id --short
intel-skylake

NOTE: SiliFuzz CPU detection logic does not account for certain desktop variants of otherwise supported CPUs. The tool will report "Unsupported platform" in such cases.

fuzz_filter_tool

The fuzz_filter_tool converts raw instructions into Snap-compatible Snapshots. It returns 0 when the conversion is possible and 1 otherwise. This interface is compatible with Centipede input_filter

fuzz_filter_tool raw_input_sequence

The raw_input_sequence file contains raw instructions which will be converted into the Snapshot format using InstructionsToSnapshot

Sample usage:

# INC EAX
echo -en '\xFF\xC0' > /tmp/inc_eax && ./tools/fuzz_filter_tool /tmp/inc_eax
echo $?
0

snap_tool

snap_tool examines and manipulates binary Snapshot protos. It can optionally load raw instructions and convert them to Snapshot.

echo -en '\xFF\xC0' > /tmp/inc_eax
./tools/snap_tool --raw print /tmp/inc_eax
Metadata:
  Id: inc_eax
  Architecture: x86_64 Linux
  Completeness: complete
Registers:
  gregs (non-0 only)
    rax = 0x20000000
    ....

simple_fix_tool

The simple fix tool takes fuzzing results from Centipede, converts raw instructions into a snapshots with no end states, adds end states to snapshots and finally packages snapshots into a sharded relocatable snap corpus.

Currently this runs as a non-restartable process on a single host and everything is put into memory so the size of corpus that can be handled is limited by available memory of the host. Since end states are generated on the host, the resulting corpus is single architecture.

Frequently asked questions

The rest of the document is organized in a How-to manner with each question describing a typical use case. The progression of the questions represents the increasing complexity of the task one is trying to accomplish. Each step typically requires either understanding or the artifacts (sometimes both) obtained at the previous step.

NOTE: The document assumes an x86_64 host/target CPU. The exact output may vary depending on the CPU vendor/stepping/etc and the environment (e.g. Docker/KVM).

WARNING: many of the instructions below execute arbitrary binary code with the privileges of the running user. The tool does its best to sandbox the code with seccomp(2). Use at your own risk.

How to create a simple snapshot

# INC EAX
$ echo -en '\xFF\xC0' > /tmp/inc_eax
$ ./tools/snap_tool --raw  --out=/tmp/inc_eax.pb make /tmp/inc_eax
# CPUID
$ echo -en '\x0F\xA2' > /tmp/cpuid
$ ./tools/snap_tool --raw --out=/tmp/cpuid.pb make /tmp/cpuid
<error log omitted>
Could not load snapshot: INTERNAL: Tracing failed: Non-deterministic insn CPUID

NOTE: To avoid non-deterministic results, various parts of SiliFuzz exclude certain classes of instructions, e.g. CPUID above.

How to inspect a snapshot

$ ./tools/snap_tool print /tmp/inc_eax.pb
Metadata:
  Id: inc_eax
  Architecture: x86_64 Linux
  Completeness: complete
Registers:
  gregs (non-0 only):
    rax = 0x20000000
    rip = 0xeb85c12b000
    <omitted>
End states (1):
  Endpoint:
    Instruction address: 0xeb85c12b002
  Platforms:
    intel-skylake
  Registers (diff vs snapshot's initial values):
    gregs (modified only):
      rax = 0x20000001
      rip = 0xeb85c12b002
      <omitted>

Notice how the end state value of the RAX register is 0x20000001 (0x20000000+1 which is exactly what INC EAX does). Also notice that the RIP value is the original +2 which is the size of the INC EAX instruction.

How to run a snapshot from a proto

$ ./tools/snap_tool play /tmp/inc_eax.pb
Snapshot played successfully.

How to convert a single snapshot into a (relocatable) corpus

Note: You will need to specify a target platform in order to generate a corpus. In this example, the resulting corpus targets the platform it was generated on.

$ cd "${SILIFUZZ_BIN_DIR}"
$ PLATFORM_ID=$(./tools/silifuzz_platform_id --short)

$ ./tools/snap_tool generate_corpus /tmp/inc_eax.pb \
--target_platform="${PLATFORM_ID}" > /tmp/inc_eax.corpus

# Will play the same "INC EAX" snapshot 1M times
$ ./runner/reading_runner_main_nolibc /tmp/inc_eax.corpus

You can inspect the process with gdb:

$ gdb ./runner/reading_runner_main_nolibc
(gdb) b RestoreUContextNoSyscalls
(gdb) run /tmp/inc_eax.corpus
Starting program: .../reading_runner_main_nolibc /tmp/inc_eax.corpus

Breakpoint 1, 0x0000456700010598 in RestoreUContextNoSyscalls ()
(gdb) x/i 0xeb85c12b000 # same as the rip value produced by snap_tool print above
   0xeb85c12b000:       inc    %eax

How to create a corpus from an emulator

NOTE: This step relies on the "fuzzing Unicorn target" step described earlier.

Convert fuzzing result corpus.* into a 10-shard runnable corpus for the current architecture.

cd "${SILIFUZZ_BIN_DIR}"

"${SILIFUZZ_BIN_DIR}/tools/simple_fix_tool_main" \
  --num_output_shards=10 \
  --output_path_prefix=/tmp/wd/runnable-corpus \
  /tmp/wd/corpus.*

The corpus shards will be at /tmp/wd/runnable-corpus.*

How to inspect a corpus file

$ ./tools/snap_corpus_tool list_snaps /tmp/inc_eax.corpus
...
I0000 00:00:1661887744.019079 4074672 snap_corpus_tool.cc:155] inc_eax

NOTE: This is a very basic tool at the moment offering just a few commands.

How to invoke the runner to scan a single core of a CPU

# Will play the same "INC EAX" snapshot on CPU#1 10k times.
$ ./runner/reading_runner_main_nolibc \
    --cpu=1 --num_iterations=10000 /tmp/inc_eax.corpus

How to scan all cores of a CPU

The orchestrator will cycle through all the shards listed in the file passed in --shard_list_file argument.

$ ls -1 /tmp/wd/runnable-corpus.* > /tmp/shard_list
# Will repeatedly run the corpus on all available CPU cores for 30s using
# /tmp/wd/runnable-corpus.* selected randomly.
$ ./orchestrator/silifuzz_orchestrator_main --duration=30s \
     --runner=./runner/reading_runner_main_nolibc \
     --shard_list_file=/tmp/shard_list

NOTE: The orchestrator can also load XZ-compressed corpus shards from files ending with .xz

silifuzz's People

Contributors

dougkwan avatar joanahalili avatar ksteuck avatar ncbray avatar qrczakmk avatar rickeylev avatar sarahjkim avatar ussuri avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

silifuzz's Issues

Questions on Silifuzz measurement results on CloudLab

Hi Silifuzz,

We used Silifuzz to run a large-scale measurement (10K hours in total) on 200 CloudLab machines, to understand more about SDC characteristics. The detailed setups are attached below.

Surprisingly, we didn’t observe any SDC besides a false positive (which I reported in October).

The Google and Meta papers report that “on the order of a few mercurial cores per several thousand machines” and a “SDC occurrence rate of one in thousand silicon devices”.

I’m writing to ask whether you have any insights on our observation? Are SDCs you observed specific to certain CPU families (like Intel CPUs)? Or, you suggest an even large-scale testbed than CloudLab?

Our measurement setups are:

  • Unique snapshots: 17,333
  • Total hours spent executing: 10,031
  • Machines: 200
  • CPU: Intel Xeon 4 core E5530 processors (50 machines) and Intel Xeon 8 core E5-2630v3 processors (150 machines)
  • Total execution per machine : ~50 hrs

We made a few changes (https://github.com/xlab-uiuc/SDCBench):

  • edited Silifuzz to collect and organize the generated snapshots before the feature was added to the repository (#1)
  • edited Silifuzz to run and report results at scale. The framework generates a snapshot to run on all machines and the machines report back their numbers to be stored into a database

Fatal error on Prework (for Bazel) step

Hello!
I would like to know if this is a real error or something I'm missing during the setup.
A few weeks ago I was able to installed in same config with no issues and now is showing the error shown in the image attached when trying to execute the bazel build command.

OS i'm using is:
Ubuntu 20.04

Silifuzz-error

Questions Size of Snapshot

Hi silifuzz,

I use Silifuzz as part of my research and after walking a while through the codebase I wanted to ask you some questions.

  1. Is there a way to define the number of instructions that the snapshot will contain (e.g after fuzzing unicorn the number of x86 instructions that a snapshot will contain ) ? Is it possible to create bigger snapshots (e.g containing 1000 instructions)? The paper mentions : "Our typical snapshot contains less than 100 bytes of code and runs in microseconds, but it can be arbitrarily large."
  2. Is there a way to check the size of a snapshot and more specifically get the number of instructions executed?
    Thank you in advance

Question on memory mapping in silifuzz

Hi Silifuzz author,

I am currently using Silifuzz as a part of my research, and during my experiments, there has some issue related with memory mapping.
Form silifuzz source: https://github.com/google/silifuzz/blob/main/runner/runner.cc

  1. It first creates memory mapping, here if we compared passed and failed log, seems failed log does not trigger memory mapping successfully:

     Passed memory mapping log:
     I<DATE> <PID> runner.cc:315] Creating memory mappings
     I<DATE> <PID> runner.cc:330] Mapping 0x10000
     I<DATE> <PID> runner.cc:330] Mapping 0x64548000
     ……
     I<DATE> <PID> runner.cc:330] Mapping 0x880f000
     I<DATE> <PID> runner.cc:330] Mapping 0x77919000
     I<DATE> <PID> runner.cc:347] Done creating memory mappings
    
     Failed memory mapping log:
     I<DATE> <PID> runner.cc:315] Creating memory mappings
     I<DATE> <PID> runner.cc:347] Done creating memory mappings
    
  2. Then start silifuzz iteration, here if we compared passed and failed log, seems failed log does not trigger iteration successfully since no memory mapping created.

    Passed iteration log: 
    I<DATE> <PID> runner.cc:624] iter #512 of 1000000
    I<DATE> <PID> runner.cc:627] #512 Running 10e61c7601de69b752e110d80f81a65bd0081f84
    
    Failed iteration log:
    I<DATE> <PID> runner.cc:624] iter #512 of 1000000
    
  3. Finally, failed system hit “Execution misbehaved” and record error info, here outcome = 6 means “Execution caused a signal.”

    E<DATE> <PID> runner.cc:439] Snapshot [05ade11fea669f234eb7606b4c62df40ebc27ee8] failed, outcome = 6
    I<DATE> <PID> runner.cc:473] Execution misbehaved
    I<DATE> <PID> snapshot_enums.cc:75] Signal: 11
    I<DATE> <PID> snapshot_enums.cc:76] sig_address: 0x0
    

So here the problem is why failed system cannot create memory mapping successfully?

Please check below full log from failed system, thanks.
runner_log_2023-10-12-21-53-45_cpu7.log

Support of SiliFuzz in Intel Skylake (Client) CPUs

Hi,

I used the command below to check SiliFuzz's support for my CPU:
PLATFORM_ID=$(./tools/silifuzz_platform_id)
The output indicates that my Intel Skylake (Client) CPU is unsupported:

E0000 00:00:1696353932.029503  366275 [platform.cc:103](https://github.com/google/silifuzz/blob/346fe5f5eed2427142baa2ef405385f06d3ac89e/util/x86_64/platform.cc#L95)] Unknown Intel platform: family = 6 model = 94 stepping = 3
Unsupported platform

After checking the source code and the Wiki, I found that SiliFuzz supports Intel Skylake (Server) CPUs with model 85.

I wonder if it's possible for SiliFuzz to support Intel Skylake (Client) CPUs with model 94 as well?

Query on missing snapshot from runnable corpus generated from fuzzing unicorn(emulator)

Hi Silifuzz author,

I am currently using Silifuzz as a part of my research, and during my experiments, I encountered a particular scenario that I'd like to discuss.

I fuzzed the the provided unicorn with the centipede and generated the corpus. While converting result corpus to the runnable corpus, I noticed in the log there are lots of snapshot misbehaving with flags such as

  • Memory state mismatch
  • Unsupported signal-based endpoint
  • Execution misbehaved

The snapshot id was also listed on the logs. However, when I was trying to print the trace for those specific snapshot, they were absent from the runnable corpus.

I would greatly appreciate it if you could address the following queries, as your insights would not only benefit my research but also enhance my understanding of the Silifuzz workflow:

  1. Are the aforementioned snapshot present in the final runnable corpus with say different snapshot id?
  2. If these snapshots are not included in the runnable corpus, is there a way we can execute those snapshots using runner as I fell those could generate interesting scenario in the real hardware?

Thank you for your time and assistance.

Seeking guidance on Corpus Generation and Tool Output

I setup silifuzz successfully and was able to run the fuzzer with your custom seed and then scan the CPU. To explore further, I have been tinkering with creating my own input seeds and generating runnable corpus.

Q1: Input Seed and Corpus Creation
I have generated my custom input seed and subsequently created an input corpus. Upon executing the command:

./tools/snap_tool --raw print /tmp/seed/<input_instruction_file>

The output indicates modifications in the gregs section without displaying register values, unlike the original seed where I observed values such as rax = 0x1 during an inc eax operation. Does this absence of register values suggest an issue with the validity of the seed?

Q2: Snapshot Count in Corpus Generation

On my system, I have created a corpus using the following procedure:

echo -en '\xFF\xC0' > /tmp/inc_eax
./tools/snap_tool generate_corpus /tmp/inc_eax.pb --target_platform="${PLATFORM_ID}" > /tmp/inc_eax.corpus
./tools/snap_corpus_tool list_snaps /tmp/inc_eax.corpus

The output shows a single snapshot (04092d36e2ce88b4563db8b37d3ee5a498d5bcba). Is it expected to have only one snapshot per corpus, or should there be multiple snapshots? The output is not the same as what you have shown as an example.

Q3: Post-processing Guidance

I couldn't find documentation explaining how to interpret the tool output and perform post-processing on the results. Specifically, I am uncertain about the meaning of a "violation" in this context. Could you provide guidance on how to interpret the output and what actions (reproduction & root cause analysis) should be taken in the case of a violation?

Questions on Silifuzz

Hi,
We are testing silifuzz to detect defects/bugs on the CPU. I am writing to ask few questions, which I have listed down below:

  1. The Corpus provided https://github.com/google/silifuzz#using-pre-generated-corpus, what type of instructions are included in the corpus.
  2. Can you update the WIKI for the latest code change.
  3. In this commit d905605, supported platform included intel-sapphire-rapids, does unicorn also support saphire-rapids new instructions.

False positive eflags SDC on intel 12th gen CPUs

Hi, silifuzz authors

I recently found many false positives with dealing with eflags on the two 12900 CPUs I'm fuzzing on. I'm not sure if this would affect other 12th gen intel CPUs.

Example shown below:

Bytes: \xBC\xC4\x04\x8A\xD2\x66\x81\xDE\xF2\x00\x69\x9F\xC5\xAA\x18\x1D\x5D\x20\xE1\x00

Instructions:

0x85c2d36000:   mov     esp, 0xd28a04c4                                                              
0x85c2d36005:   sbb     si, 0xf2                                                                     
0x85c2d3600a:   imul    ebx, dword ptr [rdi + 0x1d18aac5], 0xe1205d     

Output from running corpus

./runner/reading_runner_main_nolibc extracted_snapshot.corpus --cpu=0                                                                    
E<DATE> <PID> runner.cc:439] Snapshot [stdin] failed, outcome = 3                                                                                                                                          
I<DATE> <PID> runner.cc:441] Registers (diff vs expected end_state 0):                                                                                                                                     
I<DATE> <PID> runner.cc:442]   gregs (modified only):
I<DATE> <PID> logging_util.cc:25]   eflags = 0x206 want 0x246
I<DATE> <PID> runner.cc:451]   fpregs (modified only): 

In this case, the corpus expects eflags to have ZF (Zero flag) set, but the flag is set depending on which core the set of instructions runs on. On a 12900 cores 0-15 are p cores while cores 16-23 are e-cores

The instruction that influences the zero flag in this scenario is the imul ebx, dword ptr [rdi + 0x1d18aac5], 0xe1205d instruction.

The GDB dump below represents state of the program after the execution of the instructions.

Running on an e-core produces the expected result, the zero flag is set. (Running this on cores 16-23)

> 0x00000085c2d36014:  ff 15 00 00 00 00       call   QWORD PTR [rip+0x0]        # 0x85c2d3601a
rax            0x20000000          536870912
rbx            0x0                 0
rcx            0x100               256
rdx            0x20000000          536870912
rsi            0x2000ff0e          536936206
rdi            0x20000000          536870912
rbp            0x20000000          0x20000000
rsp            0xd28a04c4          0xd28a04c4
r8             0x20000000          536870912
r9             0x20000000          536870912
r10            0x20000000          536870912
r11            0x20000000          536870912
r12            0x20000000          536870912
r13            0x20000000          536870912
r14            0x20000000          536870912
r15            0x20000000          536870912
rip            0x85c2d36014        0x85c2d36014
eflags         0x246               [ PF ZF IF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0

However, running on an p-core produces the incorrect result, the zero flag is not set. (Running this on cores 0-15)

=> 0x00000085c2d36014:  ff 15 00 00 00 00       call   QWORD PTR [rip+0x0]        # 0x85c2d3601a
rax            0x20000000          536870912
rbx            0x0                 0
rcx            0x100               256
rdx            0x20000000          536870912
rsi            0x2000ff0e          536936206
rdi            0x20000000          536870912
rbp            0x20000000          0x20000000
rsp            0xd28a04c4          0xd28a04c4
r8             0x20000000          536870912
r9             0x20000000          536870912
r10            0x20000000          536870912
r11            0x20000000          536870912
r12            0x20000000          536870912
r13            0x20000000          536870912
r14            0x20000000          536870912
r15            0x20000000          536870912
rip            0x85c2d36014        0x85c2d36014
eflags         0x206               [ PF IF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0

According to the intel manual Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 2 Page 3-490, it states that for the imul instruction "The SF, ZF, AF, and PF flags are undefined."

Thus, I believe that this is a false positive because the ZF should not matter in this scenario (whether it is set or not) for the expected output.

Is there a way to filter out this false positive case that silifuzz produces?

Docker run not successful

I keep running into below issues while running the docker as mentioned in https://github.com/google/silifuzz#prework-for-bazel

command: docker run -it --tty --security-opt seccomp=unconfined --mount type=bind,source=${SILIFUZZ_SRC_DIR},target=/app debian /bin/bash -c "cd /app && ./install_build_dependencies.sh && bazel build ... && bazel test ..."

Dir: SILIFUZZ_SRC_DIR

Error:

> INFO: Found 336 targets...
> ERROR: /app/util/BUILD:492:8: Executing genrule //util:builtins_ar failed: (Exit 1): bash failed: error executing command (from target //util:builtins_ar) /bin/bash -c 'source external/bazel_tools/tools/genrule/genrule-setup.sh; cp "$(/usr/lib/llvm-14/bin/clang  --rtlib=compiler-rt -print-libgcc-file-name)" "bazel-out/k8-fastbuild/bin/util/libbuiltins.a"'
> 
> Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
> cp: cannot stat '/usr/lib/llvm-14/lib/clang/14.0.6/lib/linux/libclang_rt.builtins-x86_64.a': No such file or directory
> ERROR: /app/util/BUILD:492:8: Executing genrule //util:builtins_ar failed: (Exit 1): bash failed: error executing command (from target //util:builtins_ar) /bin/bash -c ... (remaining 1 argument skipped)
> 
> Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
> cp: cannot stat '/usr/lib/llvm-14/lib/clang/14.0.6/lib/linux/libclang_rt.builtins-x86_64.a': No such file or directory
> INFO: Elapsed time: 30.186s, Critical Path: 1.67s
> INFO: 1164 processes: 1149 internal, 15 processwrapper-sandbox.
> FAILED: Build did NOT complete successfully
> 

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.