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

[Gary Winiger]

	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..