Me and my friend have once talked about careful application development,This is an excellent idea for security testing, however, see below for more thoughts.
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.
I believe there are actually systems out there that do this, but they are ancient by now.
- (libc) crash instantly if memcpy detects regions overlapping;
- return EINTR as much as possible;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).
- 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;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 toI don't see this one being very useful for any program that isn't running realtime or accessing hardware directly.
stop a thread at some syscalls);
- 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 IThis 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).
don't believe it is feasible to make a lot of modern software to run in
such situation.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature