PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory

David Chieu David.Chieu at sun.com
Thu Dec 6 14:54:44 PST 2007


Gary Winiger wrote:
> ...
> 	Team, thanks for the excellent update.  Still a few open questions:
>
> 	* Other than the IOCTL, I've missed seeing interface taxonomies.
> 	* I've also missed seeing the release binding.
> 	* What's the set of exported interface?
>   
The interface taxonomy for the IOCTLs is "project private", release 
binding: micro/patch.
Other than that there's no other exported interface. The users are 
directly talking
to the firmware which is AMT's real interface-provider. This project 
only provides
an HTTP(s) service on TCP port 16992/16993 to relay the messages to/from 
the firmware.
> 	* 5.6-5.8 seem incomplete to me.  What privileges?  What Rights
> 	  Profiles, and why?  Perhaps more explicitly, what's the
> 	  method_context of svc:/network/lms and how does this proposed
> 	  service comply to the SMF policy:
> 	  http://opensolaris.org/os/community/arc/policies/SMF-policy/
> 	  (which unfortunately is 2 revs behind the internal
> 	  http://sac.eng/cgi-bin/bp.cgi?NAME=SMF.bp)
> 	  Yes I'm sending John email once again ;-{
>   
The method_context section of LMS includes a limited set of privileges:
basic,sys_net_config,net_rawaccess
This is to grant LMS the rights to open /dev/heci and send IOCTLs.

A new authorization "solaris.smf.manage.lms" will be defined and listed 
under the
"Network Management" profile in /etc/security/prof_attr. Using RBAC, 
Only users with the
"solaris.smf.manage.lms" authorization can enable/disable the LMS service.
> 	* 6.15 " is there any way for other software in the system ...
> 	  that a given network interface is running AMT?"
> 	  Answer:  "It *should* be possible ..."
> 	  will this be done?
>   
Lacking hardware related information from Intel, this will not be done 
in phase I. However, it's added to the plan for Phase II. Good catch.
> 	* 7 "? Remotely Protect Computing Assets : Through Out of Band
> 	  communication, each system's software version numbers are checked
> 	  and, if necessary, system software and virus protection are
> 	  remotely updated with the most recent patches and virus definitions.
> 	  Viruses and worms can also be contained at their source, if needed,
> 	  by means of built-in circuit-breaker functionality.
>
> 	  "Intel AMT infrastructure supports the creation of setup and
> 	  configuration interfaces for management applications, as well
> 	  as network, security, and storage administration."
>
> 	  What does this mean relative to this project?  How are Solaris
> 	  veriion numbers (service tags ;-) being checked?  How is Solaris
> 	  system software and virus protection being remotely updated
> 	  with the most recent patches and virus definitions?
>
> Gary..
>   
This project currently does not deliver these features for phase I. But 
after the integration of
this project will work with ISVs (i.e. anti-virus vendors, etc.) to add 
the above mentioned feature.
The implementation detail is TDB. However, we realize/document the 
following AMT capabilities
e.g.
Remote software version checking/updating can be done by the using the 
EEPROM
named 3PDS (3rd Party Data Storage), and share it with remote management 
console.
See 6.18 about StorageRealm.

-- The Solaris AMT team



More information about the opensolaris-arc mailing list