DieHard FAQs

General questions

What does DieHard do?

DieHard prevents some nasty errors - ones that crash programs and lead to security vulnerabilities. These are memory errors, including double-frees & heap corruption (which DieHard eliminates), and dangling pointer errors (or stale pointers) and heap buffer overflows (which DieHard makes unlikely to have any effect).

Who should use DieHard?

DieHard is good for software developers, since it makes programmer errors unlikely to crash a program and reduces the risk of security vulnerabilities. It's also good for end users, who can take advantage of DieHard's protections now.

What versions of Windows (& Firefox) does DieHard support?

In addition to supporting nearly any application for Linux and Solaris, DieHard currently protects Firefox on Windows XP and 2003. DieHard works with Firefox versions and higher, as well as version

Can DieHard protect any other application than Mozilla?

On Windows, the DieHard protection system currently supports Mozilla only; we plan to add more applications soon. On Linux, DieHard can protect any application. In addition, programmers using DieHard (on Windows or Linux) can protect any application they are developing.

My security program claims that the DieHard zip file contains a virus - can that be true?

Absolutely not. Your security program (so far, I only know of one, by "astaro") noticed that the distribution contains an example HTML file that shows how DieHard works. And that HTML does not contain a virus, either! It just causes certain versions of Mozilla to crash if you aren't running DieHard.

Does running DieHard significantly slow down a system?

Unless your system had too little memory installed, DieHard has no perceptible performance impact on applications like Firefox.

How much more memory does DieHard require?

That depends on your application, but in general, memory consumption will increase by 50-75%.

Does DieHard protect only programs launched after it is activated?


I see that DieHard runs multiple copies of a program and "votes". How many copies of a program are running at the same time?

There is a version of DieHard for Linux that runs multiple replicas simultaneously, and then you can choose how many replicas you would like to run. However, the Windows version runs just one copy of your program.


Technical questions

Does DieHard prevent all crashes? If not, what does it prevent?

No, although that would be nice. DieHard completely prevents particular memory management errors from having any effect (these are "double frees" and "invalid frees"). It dramatically reduces the likelihood of another kind of error known as "dangling pointer" errors, and lowers the odds that moderate buffer overflows will have any effect. It prevents certain library-based heap overflows (e.g., through strcpy), and all but eliminates another problem known as "heap corruption."

How does DieHard differ from Vista's, OpenBSD's, and Linux's "address space randomization"?

Address space randomization places large chunks of memory (obtained via mmap / VirtualAlloc) at different places in memory, but leaves unchanged the relative position of heap objects. Linux adds some checks for particular memory management errors (and then aborts the program).

Long technical answer: OpenBSD (a variant of PHKmalloc) does some of what DieHard's allocator does, but DieHard does much more. On the security side, DieHard adds much more "entropy"; on the reliability side, it mathematically reduces the risk that a programmer bug will have any impact on program execution.

OpenBSD randomly locates pages of memory and allocates small objects from these pages. It improves security by avoiding the effect of certain errors. Like DieHard, it is resilient to double and invalid frees. It places guard pages around large chunks and frees such large chunks back to the OS (causing later references through dangling pointers to fail unless the chunk is reused). It attempts to block some buffer overflows by using page protection. Finally, it shuffles some allocated objects around on a page, randomizing their location within a page.

DieHard goes much further. First, it completely segregates heap metadata from the heap, making heap corruption (and hijack attacks) nearly impossible. On OpenBSD, a large-enough underflow on OpenBSD can overwrite the page directory or local page info struct (at the beginning of each page), hijacking the allocator. This presentation [ruxcon.org.au] describes several ways OpenBSD's allocator can be attacked. By contrast, none of DieHard's metadata is located in the allocated object space.

Second, DieHard randomizes the placement of objects across the entire heap. This has numerous advantages. On the security side, it makes brute-force attempts to locate adjacent objects nearly impossible -- in OpenBSD, knowing the allocation sequence determines which pages objects will land on (see the presentation pointed to above).

DieHard's complete randomization is key to provably avoiding a range of errors with high probability. It reduces the worst-case odds that a buffer overflow has any impact to 50%. The actual likelihood is even lower when the heap is not full. DieHard also avoids dangling pointer errors with very high probability (e.g., 99.999%), making it nearly impervious to such mistakes. You can read our PLDI paper for more details and formulae.