> > >
> >
> > I believe that the primary reason for privilege is that it extracts the
> > tables via /dev/mem.
>
> Seriously ?
The lesswatts version does (which was the last version I used), but
there is an indication that the one we bring in will use /dev/xsvc.
>
> Is there no other way to get this ?
Not with this case (at least as far as I know).
>
> If that is the case then I have some very serious concerns that this case
> raises. Some of the security related but more about the stablity of the
> interfaces this case is using to get the data if it is reading memory
> directly. Surely we have a better way to get this data, and ideally given it
> is monitoring data we don't want such massive amount of privilege to read it.
Certainly, an acpi driver could be written to allow mapping,
accessing, or managing this space, but I don't see this occuring any
time soon.
>
> Then again maybe this is in the same category as iasl which (ab)uses /dev/xsvc
> for a similar purpose.
Pretty much. These tools will primarily be used for debugging, so I
see less of an issue. But the primary maintainer is on the interest
list, it is possible that he has some alternate ideas.
---- Randy
