KHB: Failure-oblivious computing [LWN.net]

KHB: Failure-oblivious computing

Posted Jun 29, 2006 17:19 UTC (Thu) by JoeBuck (subscriber, #2330)
In reply to: KHB: Failure-oblivious computing by walterh
Parent article: KHB: Failure-oblivious computing

But the current way that these things are being handled by hardening mechanisms is that the application is terminated (or a thread is terminated) on a bad memory access. That leaves sites vulnerable to denial-of-service attacks.

Certainly it's possible to augment the approach by adding logging, so the fact that an error occurred can be recorded.

(Log in to post comments)

KHB: Failure-oblivious computing

Posted Jun 29, 2006 17:48 UTC (Thu) by cventers (subscriber, #31465) [Link]

Are you responding to someone who is talking about the risk of
unauthorized access and suggesting that the current situation is worse
because it would be a denial of service attack?

This article is very interesting, but I can't say that the technique
described would be something I'd be at all comfortable using. One of the
biggest sources for bugs in software is unpredictable code paths and
input. This method takes the results of a broken assumption and breaks
more assumptions. While this may work OK in certain scenarios, I propose
something fundamentally better (and less expensive?)

What if an invalid memory access simply resulted in an /exception/ versus
a signal? Then I wrap my "parse this RFC2833 junk" function around a try
{} / catch block. If I got an invalid memory access trying to parse the
RFC2833, I write a detailed log entry (hell, if I were uber-clever, I
could use a special 'snapshot my memory' syscall to tell the kernel to
immediately mark my whole state as COW, so it can be dumped to disk. Now
you can do run-time core dumps and continue.). Then I simply deny service
to that operation. The bug is contained. If someone was trying to exploit
it, I've got their IP, and if I'm a programmer I've got a core. If I'm an
administrator, no users complained at all, or perhaps only one if it was
triggered accidentally.

The details, of course, lie in the implementation....

KHB: Failure-oblivious computing

Posted Jun 29, 2006 17:51 UTC (Thu) by cventers (subscriber, #31465) [Link]

To expand on this a bit, the author alluded to the better performance of
the failure-oblivious Apache due to its workers not dying. The fact that
Apache breaks itself down into workers in this way is an important
reliability feature of Apache -- one that is capable of somewhat avoiding
denial of service attacks.

KHB: Failure-oblivious computing

Posted Jun 29, 2006 17:53 UTC (Thu) by cventers (subscriber, #31465) [Link]

Silly me, this special syscall even already exists! How about stuffing
this in a SIGSEGV signal handler.

/* Dump some core. */
if (fork() == 0) raise(SIGABRT);

/* Magic to initiate an exception from whatever context we were running
in before our signal handler got called */

KHB: Failure-oblivious computing

Posted Jun 29, 2006 18:09 UTC (Thu) by cventers (subscriber, #31465) [Link]

I apologize to the readers and editors about the volume of my comments replying to myself, but I think we need a longjmp() that is safe to use as an exit from a signal handler. Then my above code could be:

int handle (int sig)
{
  struct jmp_buf buf;

  if (sig == SIGSEGV) {
     if (fork() == 0) raise(SIGABRT);
     pop_jmp_buf_from_tls_stack(&buf);
     longjmp_after_sig(&buf, sig);
  }
}

...then strategically place:

// Prepare an exception context
if (save_context_in_tls_stack() == SIGSEGV) {
   // operation failed
}

do_something_possibly_unsafe();

// Forget about that context
pop_jmp_buf_from_tls_stack(NULL);

Comments?

KHB: Failure-oblivious computing

Posted Jun 29, 2006 21:34 UTC (Thu) by nix (subscriber, #2304) [Link]

Throwing from certain signal handlers is safe in the presence of -fasynchronous-unwind-tables, but I sort of doubt that SIGSEGV is necessarily one of them (what if, e.g., the unwinder segfaults, something which is not unknown?)

Joe Buck would know for sure, I'd guess. :)