Messages in this thread | | | Subject | Re: [RFC] In-kernel fuzz testing for apps | From | Austin S Hemmelgarn <> | Date | Thu, 19 Nov 2015 10:37:15 -0500 |
| |
On 2015-11-18 18:39, Andrey Utkin wrote: > Me and my friend have once talked about careful application development, > which includes awareness about all possible error conditions. > So we have collected ideas about making kernel (or, in some cases, libc) > "hostile" to careless application, and we present it so that the idea > doesn't get lost, and maybe even gets real if somebody wants some > features from the list. This is an excellent idea for security testing, however, see below for more thoughts. > > - (libc) crash instantly if memcpy detects regions overlapping; I believe there are actually systems out there that do this, but they are ancient by now. > - return EINTR as much as possible; > - send/recv/etc. returns EAGAIN on non-blocking sockets as much as possible; > - send/recv tend to result in short writes/reads, e.g. 1 byte at a time, > to break assumption about sending/receiving some "not-so-big" thing at once; These three are tricky to do from userspace, but the first two could be done with ptrace with some effort (not sure about the third). > - let write return ENOSPC sometimes; Ironically, this can be done without much effort using BTRFS (although that will hopefully change in the future). > - scheduler behaves differently from common case (e.g. let it tend to > stop a thread at some syscalls); I don't see this one being very useful for any program that isn't running realtime or accessing hardware directly. > - return allocation failures; I'm pretty certain there is some library out there that you can preload to do this. > - make OOM killer manic! This isn't hard to do in a VM, either randomly adjust the memory balloon, or randomly enter the scan-code for Ctrl-Alt-SysRq-F on the console. > - make clocks which are not monotonic to go backward frequently; Same as above, but for different reasons. > - pretend the time is 2038 year or later; Same as above, also look up a program called 'datefudge'. > - (arguable) close syscall returns non-zero first time, or randomly; I'm actually genuinely curious about this one. What real-world circumstances could cause close() to fail? > - (arguable) special arch having NULL not all zero-bits. Actually I > don't believe it is feasible to make a lot of modern software to run in > such situation. This one is a functional guarantee for almost anything that uses virtual memory. In theory, it might be possible to get a lot of things working with NULL = 0xFFFFFFFF (or the equivalent on 64-bit arches), but I don't see that being particularly useful (anything that does anything with NULL other than check against it and use it as a dummy initializer is probably broken in other ways).
[unhandled content-type:application/pkcs7-signature] | |