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.
These horrific modes should be enabled per-process or per-executable-file.
Thanks for your time and for any kind comment.
--
OpenPGP usage is appreciated (it also helps your letter to bypass spam
filters). To email me with encryption easily, go
https://encrypt.to/0xC6FCDB11
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).
On 11/18/2015 03:39 PM, 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.
>
> - (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.
>
> These horrific modes should be enabled per-process or per-executable-file.
>
> Thanks for your time and for any kind comment.
>
Check out CONFIG_FAULT_INJECTION, lib/fault_inject.c . There are a few things
there already. You could expand on that for other functionality.
Thanks,
Laura
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