OpenSolaris

The fix for:

6726575 ipfilter needs to be able to do randomised port mapping

essentially copied the libc code:
        usr/src/lib/libc/port/gen/drand48.c
into the kernel:
        usr/src/uts/common/inet/ipf/drand48.c
without regard to the requirement that there be no floating-point
code in the kernel.

This went unnoticed until I compiled my child of /ws/onnv-gate
with gcc via a nightly build with:
        __GNUC=; export __GNUC

I bfu'd a sparc test machine with the resulting archives
and it came up showing:

/usr/kernel/drv/sparcv9/ipf: undefined symbol '__adddf3'
/usr/kernel/drv/sparcv9/ipf: undefined symbol '__floatsidf'
/usr/kernel/drv/sparcv9/ipf: undefined symbol '__muldf3'
WARNING: mod_load: cannot load module 'ipf'

The fix requires at least deleting the floating-point
code from uts/common/inet/ipf/drand48.c, if not all the
other unused code as well:

< static double
< ipf_r_drand48_u(void)
< {
<       static double two16m = 1.0 / ((int32_t)1 << N);
< 
<       next();
<       return (two16m * (two16m * (two16m * x[0] + x[1]) + x[2]));
< }
< 
< NEST(double, ipf_r_erand48_u, ipf_r_drand48_u)
< 
191,193d179
< EXPORT0(double, ipf_r_drand48, ipf_r_drand48_u)
< EXPORT1(double, ipf_r_erand48, ipf_r_erand48_u)

N/A

The rather light editing of this file that was copied from
        usr/src/lib/libc/port/gen/drand48.c
was deliberate - the idea being to change the code as little as possible to
make maintenance of it easier. The downside here being that it was felt
necessary to make the name space of this file private to ipf so that it
didn't conflict with other code that is or wants to be in the kernel.
Copying the code is not a maintainable solution -- minimal changes or
otherwise.  This approach should be revisited.
The choice of which code to use (and how) was a result of lengthy discussion with experts on the subject - the decision wasn't quite as easy as many would like to believe.

For those that believe developing good PRNGs is something they can do during a coffee break, I'm sure there are many possibilities for publication that would benefit the world at large.

The worst mistake that fixing 6726575 could have resulted in would have been to assume that it was possible to develop a new PRNG, that was at least as good as any other in the source tree - in less than a day.
No one is proposing creating a new PRNG.  Please explain why the code cannot
be refactored (e.g., so that floating point won't be accidentally introduced)
and shared through traditional mechanisms like usr/src/common.  Note that
namespace issues can be solved through a variety of mechanisms; sharing the
implementation is what's important.
Moving the code was discussed but such a change demands more effort, than there was time available to fix the bug, to do it properly.

In the fullness of time, providing better exposure to random number functions in the kernel is desirable but needs to be properly considered and part of a project (or RFE) in its own right.

At the time of the bug fix, everything that has been mentioned in this chain of comments was discussed and understood with members of the open/solaris security team . Further discussion about this should happen in the appropriate forum (security- xxxxx@xxxxx.org), not in this bug's "Public Comments".