Re: [Call for Testing] Syzkaller (kernel fuzzing)
BTW, the executables are for amd64. Sorry for sharing it on tech-kern. Regards, Utkarsh Anand On 26 October 2017 at 12:20, Utkarsh Anand wrote: > You can now access the binaries from: http://ftp.netbsd.org/pub/ > NetBSD/misc/utkarsh009/syzkaller/syzkaller-binaries.tar.gz > I'll keep updating them from time to time. > > Regards, > Utkarsh Anand > > On 26 October 2017 at 08:03, Utkarsh Anand wrote: > >> Hello, >> I have been working on adding support for NetBSD in syzkaller: >> github.com/google/syzkaller >> I would like to ask interested volunteers to test the binaries (check >> attachments). >> Command to run the binaries: ./syz-stress -executor ./syz-executor >> Let it run on the machine. It might take quite long to finish, so you >> could probably let it running overnight and then share the last few >> lines of the output (basically, the conclusive part). Even if you're >> not running the latest build, the results are of great help. I'll >> resend the updated binaries, in case there is a change in the code. >> >> Regards, >> Utkarsh Anand >> Sent from my iPad >> > >
Re: [Call for Testing] Syzkaller (kernel fuzzing)
You can now access the binaries from: http://ftp.netbsd.org/pub/NetBSD/misc/utkarsh009/syzkaller/syzkaller-binaries.tar.gz I'll keep updating them from time to time. Regards, Utkarsh Anand On 26 October 2017 at 08:03, Utkarsh Anand wrote: > Hello, > I have been working on adding support for NetBSD in syzkaller: > github.com/google/syzkaller > I would like to ask interested volunteers to test the binaries (check > attachments). > Command to run the binaries: ./syz-stress -executor ./syz-executor > Let it run on the machine. It might take quite long to finish, so you > could probably let it running overnight and then share the last few > lines of the output (basically, the conclusive part). Even if you're > not running the latest build, the results are of great help. I'll > resend the updated binaries, in case there is a change in the code. > > Regards, > Utkarsh Anand > Sent from my iPad >
Proposed changes for PR kern/52639 - kernhist(9)
The attached diffs implement the following changes in the KERNHIST feature, and is the proposed fix for PR kern/52639. (The diffs are compressed to allow them to be attached to this Email; they would otherwise exceed message-size limitations.) I would appreciate your review and (constructive) comments. Since this PR is interfering with other developers' efforts, I would like to get this committed within the next few days. Changes: * All history arguments are stored as uintmax_t values, both in the kernel and in the structures used for exporting the history data to userland. This avoids problems on some architectures where passing a 64-bit (or larger) value to printf() can result in printf() processing the value as multiple arguments. (This is particularly problematic when printf()'s format string is not a literal, since in that case the compiler cannot know how large each argument should be.) * All [1] existing users of KERNHIST have had their format strings updated. Each format specifier now includes an explicit length modifier 'j' to refer to numeric values of the size of unitmax_t. * All [1] existing users of KERNHIST have had their format strings updated to replace uses of "%p" with "%#jx", and the pointer arguments are now cast to (uintptr_t) before being subsequently cast to (uintmax_t). This is needed to avoid compiler warnings about casting "pointer to integer of a different size." * vmstat(1) has been modified to handle the new size of arguments in the history data as exported by sysctl(). * The kernhist(9) man-page has been updated to note the additional requirements imposed on the format strings, along with several other minor changes. Note that it would have been possible to use an explicit length for the history arguments, for example uint64_t, rather than uintmax_t. But that would require another "rototill" of all the users in the future when we find an architecture that supports a larger size. Also, the printf() format specifiers for explicitly-sized values, such as "%"PRIu64", is much more verbose (and less aesthetically appealing, IMHO) than simply using "%ju". [1] Further note that I've tried very hard to find all "the existing users of KERNHIST" but it is possible that I've missed a couple. I would be glad to update any stragglers that anyone identifies. +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++ diffs.text.gz Description: Binary data
Re: Deadlock on fragmented memory?
On Wed, Oct 25, 2017 at 11:49:01AM +0700, Robert Elz wrote: > Most applications would never bother, but the ones that do a lot of > running of other processes (say, sh, and probably make) could make use > of this and cut down on a lot of both data copying and page contention. For sh and make it would also be nice to use posix_spawn for at least the simple cases. That saves a lot of pmap manipulations... Joerg
Re: hand over arg/env pages on exec (was: Deadlock on fragmented memory?)
Date:Wed, 25 Oct 2017 11:29:34 +0200 From:Edgar =?iso-8859-1?B?RnXf?= Message-ID: <20171025092934.gv73...@trav.math.uni-bonn.de> | vfork childs aside, the kernel could just zero out what it wouldn't copy; | no new interface needed. Yes, it could, but it should not need to. | However, how do you deal with the case that the strings are scattered | around the dying process' address space? The old way. | Or is it intentional to have a new exec interface only to be used when the | caller knows the arguments are contigous? Yes, intentional - processes using it would have to know what they're doing, and deliberately plan to set things up correctly. (Maybe there could be a library function to help, but it might not.) There are all kinds of issues, like the arg pointers, which can be just as much an issue as the args themselves - I would have the calling process make those be page relative offsets (from the start of the arg list (or env list) and then have the exec code create a new list of pointers by (validating and then) adding the base addr of the arg pages in the new process's addr space (a separate copy, so the originals remain - which isn't important for the args, but allows the env to simply be passed along unchanged, and the kernel could detect that). Perhaps. kre
hand over arg/env pages on exec (was: Deadlock on fragmented memory?)
vfork childs aside, the kernel could just zero out what it wouldn't copy; no new interface needed. However, how do you deal with the case that the strings are scattered around the dying process' address space? Or is it intentional to have a new exec interface only to be used when the caller knows the arguments are contigous?
