Randy Fishel wrote: > >> > > >> > >> > ? 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 > >
I don't have any other ideas, these tools are designed for debugging only. Thanks, -Aubrey
