Randy Fishel wrote: > On Tue, 15 Jan 2008, Darren J Moffat wrote: > > >>David Chieu wrote: >> >>>Interface Type Comments >>>-------------------------------------------------------------------------- >>>can.suspend bool The ability to suspend as determined >>> by uadmin(2). >> >>>can.hibernate bool The ability to hibernate as determined >>> by uadmin(2). >> >>For Solaris on SPARC and x86 what are these likely to return ? >> >>I think that on (supported) x86 systems can.suspend could return true because >>that maps to ACPI S3, but currently can.hibernate will never be true. However >>on SPARC can.hibernate could be true but can.suspend would never be true. Is >>that correct ? > > > "Never" is a long time, but currently can.hibernate will return true > on x86 and can.suspend will return false on sparc. In this context, > 'suspend' equates to entering S3, and hibernate equates to entering > S4.
Actually, can.suspend (ACPI S3) could be true on x86 and can.hibernate (ACPI S4) could be true on sparc. Phi > > >>One of the reasons I think this is very important is because of my issue below >>about the authorisations. >> >> >>>The following RBAC authorizations and profiles will be added. >>> >>>Authorization Names: >>>solaris.system.power.:::System Power Management::help=SystemPowerMgmt.html >>>solaris.system.power.suspend::: Suspend the System::help=Suspend.html >>>solaris.system.power.suspend.ram::: Suspend to RAM::help=SuspendToRam.html >> >>Why does suspend to RAM need its own authorisation yet hibernate does not, ie >>what is the security difference between suspended to RAM versus any other type >>of suspend ? > > > The choice here centered around the the question: Is there a reason > to differentiate between auths for S3 and S4? > > Effectively, we believe that if a user has the privilege to do an > S4, then he also has the privilege to do an S3. Partially because the > state transition to S4 functionally goes to S3 first. But also > because we considered the possible security considerations. > > In S3, system state is entirely held in RAM, and will always be > contained in the running machine. If power is lost, state is lost. > > In S4, system state is first put to RAM (i.e. enter S3), and then > written to disk, and could be saved for a long time. This image > contains eveything this was contained in RAM (including the > possibility decrypted data that would othewise not be on the disk) and > *could* be: > > Viewed by someone who might get physical access to the image > Copied to another machine for viewing as above > Used to continue the system on a different hardware for > further viewing. > > What we concluded from this is that it might be desireable to allow > S3 and not S4, but not the opposite. This led us to the heirarcical > auth: > > solaris.system.power.suspend == allows both S3 and S4 > solaris.system.power.suspend.ram == only allows S3 > > > Going back to the 'can.*' comments above, for a user to currently > suspend a Sparc they must have solaris.system.power.suspend, and > adding 'ram' would prevent the user from suspending Sparc but not x86. > > > ---- Randy >
