Several customers have noticed that certain Java Studio tools don't
work properly in a zone.  Specifically, "cc -fast", fpversion(1), and
the Sun Performance Library (libsunperf.so) all perform sub-optimally
in a zone, at least on SPARC systems.  This turns out to be because
each depends on the output of "prtconf -vp" to gather information
about the architecture of the machine on which they are running (cache
sizes, processor speeds, etc.).  Since /dev/openprom isn't available
within a zone, the prtconf command fails and the tools use the
"generic" setting, which doesn't work well on modern CPUs.  More
details are available in bug 5013129.

While this is clearly far from an ideal interface for gathering this
sort of information, the fact is that there is currently no other
mechanism available to unprivileged processes (with the exception of
processor_info(2) for processor speeds), and in any case this is the
behavior of the existing tools.  Rather than have applications behave
poorly within a zone (raising concerns about the performance overhead
of zones), or requiring customers to upgrade their tools, we'd like
to seamlessly support the existing tools.

This can be readily done by adding /dev/openprom to the list of
devices available by default in a zone.  In addition, I propose
requiring that a process wishing to open /dev/openprom for writing
must possess all privileges (similar to the restrictions on
/dev/kmem).  This not only keeps processes within a zone from
modifying prom settings, but also closes a privilege escalation path
currently available to processes that are euid 0 but have restricted
privileges (they can modify security-password, boot-file, and other
sensitive prom settings in order to get control of the system on the
next reboot).

Note that /dev/openprom was initially excluded from use in non-global
zones due to concerns over the safety of allowing even read-only
access; in previous Solaris releases, misuse of the OPROMGETPROP
interface could cause a system panic.  On further investigation,
though, this problem appears to be fixed (as confirmed by bug and
code examination as well as testing).

Since the known dependencies are only for SPARC systems,
and the value of /dev/openprom on x86 is somewhat dubious, the
proposed changes will only apply to SPARC systems.