Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755300AbbLDIAt (ORCPT ); Fri, 4 Dec 2015 03:00:49 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:45386 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755088AbbLDIAs (ORCPT ); Fri, 4 Dec 2015 03:00:48 -0500 Date: Fri, 4 Dec 2015 09:00:45 +0100 From: Pavel Machek To: Andrey Utkin Cc: linux-kernel@vger.kernel.org, Anton Subject: Re: [RFC] In-kernel fuzz testing for apps Message-ID: <20151204080044.GH14427@amd> References: <564D0C30.8010009@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <564D0C30.8010009@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1765 Lines: 38 Hi! > 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. > > - (libc) crash instantly if memcpy detects regions overlapping; > - 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; > - let write return ENOSPC sometimes; > - scheduler behaves differently from common case (e.g. let it tend to > stop a thread at some syscalls); > - return allocation failures; > - make OOM killer manic! > - make clocks which are not monotonic to go backward frequently; > - pretend the time is 2038 year or later; > - (arguable) close syscall returns non-zero first time, or randomly; > - (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. Most of these should be doable with ptrace. You could use for example subterfugue as a base. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/