FWIW, I'd recommend *against* stashing a node in /dev. Better to just
access the /devices node directly IMO. The /dev links are a convenience
that is appropriate for "quasi-public" interfaces... you're not going to
need the /dev link (won't this just live in some fixed location like
/devices/pseudo or somesuch?) and its one less thing you need to
publish. (Plus then no need for devfsadm changes to support the
/dev/heci interface.)
-- Garrett
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..
>
