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

[Mark Logan]

I'm not sure what you mean by "noaccess".  Do you want us to change the 
method_context for LMS from "root:root" to "noaccess:noaccess"?

Gary Winiger wrote:
> 	OOPS looks like an empty reply escaped my try to kill it.
> 	Sorry...
>
>   
>> 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.
>>     
>
> 	Nits, that could be edifying.
> 	It seems to me there might well be other interfaces other than
> 	just the IOCTLs lurking about.  Yes as I said, I read that the
> 	IOCTLs were project private.
> 	Other interfaces might be the device name, the service name
> 	and service properties.
> 	Presumably this is the case that exports the device (/dev/heci),
> 	either that or it has a case dependency that I missed.
> 	Presumably this is the case that exports the service
> 	(svc:/network/lms).
>
> 	Are there any service specific properties?
>
>   
>>> 	* 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.
>>     
>
> 	Hummm, this seems to be different than a later reply.  The point
> 	is to run with the least effective and permitted privileges
> 	an non-system (viz "noaccess" user/group) ids as possible.
> 	Anything above that needs some justification.
>
>   
>>> 	* 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.
>>     
>
> 	Hummm, not for phase I seem OK, but remotely nuking Solaris
> 	components without administrative requests seems overall bad.
> 	There's the whole "Connected Customer" group under Steve Wilson
> 	that needs to be brought into the picture for anything related
> 	to Software Updating.  I suspect there's a parallel group for
> 	Firmware Updating some place in John Fowler's orginization.
> 	I'd suggest contacting FWARC before proceeding along those
> 	lines.
>
> Gary..
>