e.g. a test which calls explicit_bzero() in a way which would have it optimised out in a platform with a low-quality port.
A reasonably descriptive comment in the header (or failure text) of the test should guide a porter onto the path of wisdom.
(If there is a problem in that the test would need to inspect the output of explicit_bzero(), hence negating the optimisation, it can be implemented as multiple processes).
Testing that your entropy source is good sounds harder still.
reallocarray() should be pretty easy to test though.
But how many potential issues will your tests miss? If we had perfect test coverage for everything (and the tests were perfect, or we had test for them...), all software would be 100% bug-free.
Tests might not hurt, but I am not sure trying to cater for braindead porters is a good idea. They might get the idea they're doing it right once they get the tests to pass one way or another...
Reasonably descriptive commentary on the mentioned functions is there in the man pages. That is where porters should look.
There must be some side effect of the optimisation, otherwise there wouldn't be a problem. Detect that side effect (e.g. write a buffer of memory to disk, check timing of some code, ptrace-attach to the other process and inspect it, trigger a core dump and pick over the bones, code up an exploit which would work if the explicit_bzero() wasn't present)
> How do you know all the scenarios where some compiler would optimize things out?
You only really need to know one case where the compiler will, if the prevent-optimisation compiler magic isn't sprinkled on it.
> Tests might not hurt, but I am not sure trying to cater for braindead porters is a good idea. They might get the idea they're doing it right once they get the tests to pass one way or another...
At least they'd get an idea that something was up. I guess you might get away with:
#ifndef OPENBSD
#error "You can't just call bcopy() for explicit_bcopy() - see http://good-description-here why not"
#endifIf they are up for the job, they get that idea when they try to compile the thing and it doesn't because they are missing a function. They will read that function's documentation, and understand it; they may even take a peek at the implementation too, before porting it or implementing their own.
Call me smug but I think porting security sensitive software should be left to people who have a clue. If you have to litter the code with hints and education for people who don't know what they are doing, then you end up with a port that was done by someone who seemed like he might know what he's doing, when there's a good chance that he doesn't. I would rather be able to immediately recognize ports made by people who obviously don't have a clue. So I know what to avoid...
I am all for education, by the way. There are good secure coding guides out there, though having more wouldn't hurt. I just don't believe the approach you proposed is a good one.
If you do that, the best you can get is a test that works with one specific version of one specific compiler used with one specific set of compiler flags. It probably is easier to just inspect the resulting binary.
And you may not even get that, as the optimizer may use some fairly complex heuristics to choose whether to optimize away a call, such as register pressure (for example, in a three level deep for loop, it may not make sense to try and get extra stuff into registers)