intN value ranges

[Dmitry Vyukov]

Marco Vanotti wrote:
> Hey Dmitry, I have a qq about syzkaller... If I declare a system call to use
> int8 or int16, will it try to use values outside of that range?

Hi Marco,

Where/how did you observe this?

[Marco Vanotti]

Hey Dmitry!

This is not something I observed, it is something I wanted to know. If I specify int8, will syzkaller take it as a hint or will it always use values inside that range?

[Dmitry Vyukov]

On Fri, Jun 12, 2020 at 8:00 AM Marco Vanotti <mvan...@google.com> wrote:
>
> Hey Dmitry!
>
> This is not something I observed, it is something I wanted to know. If I specify int8, will syzkaller take it as a hint or will it always use values inside that range?

But the memory storage is 1 byte in this case, so whatever syzkaller
uses/generates, there is no way to fit larger values into 1 byte of
memory. So why does it matter? Even if it's a hint, it should be good
enough. Or you mean something else?

[Marco Vanotti]

If I define a value to be an int8 in the syscall description by mistake, but the syscall in reality takes a uintptr, will syzkaller ever generate values outside the int8 range?

[Dmitry Vyukov]

On Fri, Jun 12, 2020 at 9:04 AM Marco Vanotti <mvan...@google.com> wrote:
>
> If I define a value to be an int8 in the syscall description by mistake, but the syscall in reality takes a uintptr, will syzkaller ever generate values outside the int8 range?

I think we _used_ to generate larger values before, but lately become
more careful and try to truncate values to their physical size, in
particular:

syzkaller$ grep truncateToBitSize prog/*.go
prog/hints.go: v = truncateToBitSize(v, bitsize)
prog/hints.go: replacer = truncateToBitSize(replacer, bitsize)
prog/mutation.go: a.Val = truncateToBitSize(a.Val, t.TypeBitSize())
prog/rand.go: return truncateToBitSize(v, bits)

The reasons were:
- improved fuzzing efficiency (we rely on descriptions being correct
whole lot, and can't do good job with wrong descriptions anyway)
- nicer reproducers (previously produces nonsense like int8 arg with
value 0x4327582752345)
- mutation not producing effectively the same program (changing only
high unused part)
- fewer candidates when using comparison operand interception

Your concern is valid, but I still think what we are doing is right.
Like all other bugs in descriptions, it looks like a good candidate
for static descriptions checking, what we now do in tools/syz-check.
Checking that syscall has an int32 type, but we have int8 should be
easy enough. Or we could, say, enforce that all top-level syscall
arguments are long-sized for an OS.