| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
./tools/syz-env bin/golangci-lint run ./... --fix
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
MSR is an SPR (Special Purpose Register) which controls endianness,
32/64 bits, privilege state and other CPU state bits. Some bits can be
changed by the "mtmsr" instruction ("Move To MSR") but for the privilege
bits "rfid" ("Return From Interrrupt Doubleword") needs to be used and
SRR0/SRR1 SPRs need to be preloaded with the desired mode and an address
to jump.
This adds an "rfid" pseudo instruction.
Signed-off-by: Alexey Kardashevskiy <aik@linux.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
At the moment syzkaller only fuzzes the platform architecture defined
hypercalls. However there are custom defined hypercalls which KVM handles,
they make 2 groups - an extension of hypercalls and so-called ultracalls
which are handled by the secure VM firmware but in absense of the secure
VM facility, KVM gets to handle those as errors.
This enables the two extra groups of hypercalls in KVM. If not enabled,
KVM exits to let the userspace handle them (which syzkaller does not do).
Signed-off-by: Alexey Kardashevskiy <aik@linux.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RunTime Abstraction Services (RTAS) is an API used by the Linux
powerpc/pseries platform to talk to the hypervisor. Under KVM, this
is implemented as a custom hypercall (which we have support for) and
an in memory array of parameters. The hypercall is H_RTAS and its only
parameter is a pointer to the mentioned array. The vast majority of
RTAS calls are handled normally by QEMU and only a handful by KVM.
This adds fuzzing of 4 RTAS calls. This uses a chunk from main 256MB RAM
for parameters. The parameters are big endian hence "<<24" for the token.
To allow more targeted fuzzing, use iset.GenerateInt().
Signed-off-by: Alexey Kardashevskiy <aik@linux.ibm.com>
|
| |
|
|
|
|
|
|
|
| |
In order to keep all macro instruction helpers together, his moves
the "sc" helper to the instruction set next to ld64().
This should not cause any behavioral change.
Signed-off-by: Alexey Kardashevskiy <aik@linux.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GenerateInt() generates sort of random numbers for instruction fuzzer
with focus on corner cases, let's use it for POWERPC too.
Since we want memory access instruction to try these addresses, we preload
generated values in GPRs used by just generated instruction.
This in turn requires Insn::Encode() access for the instruction map to
encode load instructions so this moves ld64() from the generator to
insnSetMap and adds Insn::insnMap. This adds enc() to encode just
the instruction without any randomization.
This does not add additional instructions if cfg.MemRegions is empty so
the ifuzz_test.go test still passes.
Since EncodeParam() is not used by anything but Encode(), this open codes
it.
Signed-off-by: Alexey Kardashevskiy <aik@linux.ibm.com>
|
| |
|
|
|
|
|
| |
This is used in a few places already and more are coming, make it
a struct for better readability.
Signed-off-by: Alexey Kardashevskiy <aik@linux.ibm.com>
|
| |
|
|
|
|
|
|
|
| |
ifuzzimpl is too lenghty and too clumsy on my taste
(nm/vmimpl worked better b/c it's shorter and used less).
I've tried to come up with something shorter and nicer.
We could use "insn" as a common name for "instruction" in ifuzz,
but it's a commonly used name already so would cause lots of conflicts.
"iset" is somewhat descriptive, short and nice.
|
| |
|
|
| |
x86.InsnSetX86 is excessive. Everything in x86 package is x86-ish already.
|
| |
|
|
|
|
|
|
|
| |
ifuzzimpl imports the public interface package ifuzz
and prog package needs to import ifuzzimpl (implementation guts that
nobody outside of ifuzz should care about). This is not right.
Invert everything so that prog package only needs to import ifuzz
and ifuzz imports ifuzzimpl.
|
|
|
This adds KVM's syz_kvm_setup_cpu pseudo syscall. This adds placeholder
for options (none implemented yet).
This adds instruction generator for ifuzz; this also adds a few pseudo
instructions to simulate super/hyper/ultracalls
(a PPC64/pseries platform thing).
The insns.go is generated from PowerISA_public.v3.0B.pdf [1] by
a horrendous python3 script on top of pdftotext. The ISA covers POWER9
which is the latest available POWER CPU at the moment. The next ISA
for POWER10 is quite different and we will deal with it later.
The // comment after every instruction is a fixed opcode list for
verification purposes.
This does not define DecodeExt as there is no obvious replacement of
the Intel XED library for POWERPC (gapstone-capstone, later, may be).
[1] https://openpowerfoundation.org/?resource_lib=power-isa-version-3-0
Signed-off-by: Alexey Kardashevskiy <aik@linux.ibm.com>
|
