Gavin Maltby wrote:
> On 08/04/06 18:00, Garrett D'Amore wrote:
>
>> I propose that /dev/openprom be changed to be mode 644, allowing any
>> user to access it. This would allow ordinary users to run prtconf -vp
>> (as well as a few other things like prtconf -F and prtconf -V) without
>> becoming root.
>
> Last I knew there was a dirty great big mutex around all entry to the
> OBP. And at least some drivers dive into the OBP repeatedly to
> retrieve properties again and again (dma properties for some HBA
> I think) which itself is bad if things are serialized, but
> userland access would allow a simple userland loop to affect
> all IO threads on the domain.
Well at least the openprom driver doesn't have big honking lock. (There
is only a singe mutex, which protects instance number counting and the
state machine. The lock is only held for short duration.)
And neither is there one in promif. There could be another one "lower"
in the stack (in the actual OBP firmware?) I suppose.
An alternate solution might be to try to cache the prom tree somewhere
in openprom, but this would require moving some of the logic in the
"flags" handling up from the promif/OBP firmware into the openprom
driver itself.
In any case, I don't think it is a huge risk.
Btw, I consider any driver which regularly dives into OBP (e.g. on every
read/write or ioctl) to be badly in need of redesign. The OBP tree
(including properties) is generally static, as far as I know. I'm not
aware of any way that OBP would ever update its tree after boot, even in
the event of PCI hotplug. But maybe I'm missing something here.
Far better would be to query those properties you need to know about at
attach() time, and then cache them in a soft state somewhere.
-- Garrett
>
> That may be stale information now; my point is that we need to be
> careful here.
>
> Cheers
>
> Gavin
--
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134 Fax: 951 325-2191
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
