Add tests for issue #1542
The correct results are obtained with the following program:
struct foo {
unsigned char f0;
unsigned int f1:4;
unsigned short f2:4;
};
struct bar {
char f0;
struct foo foo;
};
int main() {
struct bar y;
memset(&y, 0, sizeof(y));
y.f0 = 0x12;
y.foo.f0 = 0x34;
y.foo.f1 = 0x56;
y.foo.f2 = 0x78;
int i;
for (i = 0; i < sizeof(y); i++)
printf("%02x", ((unsigned char*)&y)[i]);
printf("\n");
}
1. It always crashed in cover_reset when coverage is disabled.
2. Use NONFAILING when accessing image segments.
3. Give it additional 100 ms as it may be slow.
4. Add a test for syz_mount_image.
This commit adds a new attribute to syzkaller targets that tells
syzkaller how to invoke the syz-executor command.
Some systems, like Fuchsia, are now building syz-executor as part of the
build, and there is no need to copy it over, or to run it from `/tmp`.
In fact, that might stop working at some time in the future in Fuchsia.
All places that used to copy syz-executor into the target machine will
now check for the SyzExecutorCmd flag, and won't copy it if the flag is
set.
Syzkaller binaries are built in C mode even if they are c++ binaries.
Recent clang version (clang++-10) consider this an error/warning,
causing issues during build time.
Change-Id: Ia6d1ab46597efc42772c1c7a63188c3c04a729a7
Enable /dev/tty{1-6}. These seem to be special.
Few first connected to framebuffers. But the rest
seem to be different from e.g. tty20 anyway.
Also /dev/tty is different from the rest.
/dev/ttyS3 and /dev/ttyprintk are different.
Properly pair BSD pty terminals.
Add a second mode that extracts constant values from
ELF object, instead of running the executable.
This allows to not (1) link binaries, (2) use proper cross-compiler.
It finally fixes 386/arm extracts for my distro.
Hopefully not makes things worse for others,
should generally be safer/more reliable.
The current mode is left b/c I can't test all OSes,
windows binaries are not ELF, so we may need it anyway.
But later we may switch more OSes to this new mode
if they break (fuchsia?).
On my Debian gcc -m32 is hopelessly broken.
Using clang fixes at least arch 386.
Arch arm is still broken b/c clang does not like
some of kernel arm inline assemly constraints.
It's /dev/watch_queue not /dev/fd_watch_queue.
Don't know if it was renamed, or alwys wrong, but does not matter much,
now it's /dev/watch_queue.
Also attach v4l ioctls to /dev/swradio,radio,vbi,cec.
It seems that _some_ of them are applicable to these devices as well.
Linux v5.5 extends struct clone_args for clone3() by two additional
parameters:
@set_tid: Pointer to an array of type *pid_t. The size
of the array is defined using @set_tid_size.
This array is used to select PIDs/TIDs for
newly created processes. The first element in
this defines the PID in the most nested PID
namespace. Each additional element in the array
defines the PID in the parent PID namespace of
the original PID namespace. If the array has
less entries than the number of currently
nested PID namespaces only the PIDs in the
corresponding namespaces are set.
@set_tid_size: This defines the size of the array referenced
in @set_tid. This cannot be larger than the
kernel's limit of nested PID namespaces.
Cc: Adrian Reber <areber@redhat.com>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Add new crypto algorithms from linux-next (future v5.5):
- BLAKE2b and BLAKE2s
- "-arm" implementations of ChaCha and XChaCha
- "-arm" and "-neon" implementations of Poly1305
Regenerate consts on linux-next next-20191125.
DEVLINK_ATTR_NETNS_* consts were chifted by 1.
__BPF_FUNC_MAX_ID increased as usual.
CRYPTO_ALG_TYPE_BLKCIPHER, CRYPTO_ALG_TYPE_ABLKCIPHER were removed,
replace them with CRYPTO_ALG_TYPE_SKCIPHER.
Move HostFuzzer from vm/qemu.
It's needed in a number of other packages
and strictly saying is not specific to qemu
(it just happened that both fuchsia and akaros only support qemu).
The port-based exception APIs have been deprecated on Fuchsia and will
be removed shortly. Delete them from the syscall definitions and
modify the Fuchsia executor to use the new channel-based APIs instead.
