Intel AMT [PSARC/2007/601 Self Review

[James Carlson]

Vincent Wang writes:
> This case is not to review the AMT technology - e.g. the XML/SOAP 
> interfaces of
> the firmware - but the platform support that Solaris needs to have.

We're responsible for the system as a whole, no matter where the parts
come from.

> This case does not propose any programming interface inside Solaris, but
> provice a proxy for the communicating parties who use a protocol defined
> in the firmware by Intel.

The SOAP interfaces exposed by that proxy are programming interfaces,
as is the kernel driver.

> Both the daemon (LMS) and the driver (HECI) are ported from Intel's code 
> for
> Linux, under BSD/GPL dual license. The ME can only receive packets from the
> physicall network, so a daemon is necessary to pass local requests to the
> firmware.

I'm not sure I understand "physicall network" in this context, but I
suspect that it's a reference to the PCI inteface you've described,
and not to another network interface.

My assumption (at this point) is that the daemon binds
127.0.0.1:16992, accepts connections (one or many? can there be
simultaneous sessions?), and then relays the messages to the kernel
driver which sends them over the PCI bus to this card.

> What privileges are required to talk with the kernel driver?
> 
> A: Privilege required: 'basic'. But the device file under /devices/...
> is root-owned. So it requires root or anyone with file_dac_read and
> file_dac_write to be able to open that device and talk with the driver.
> The device file is only used by the LMS daemon. Applications don't
> talk to the driver directly.

It sounds like ordinary users could open that node and talk to it.  In
that case, I don't think the daemon should run with elevated
privileges.  There's no need.  In fact, it should run with the minimum
privileges possible.

That brings up another question: what starts the daemon?  Is it an
inetd service or something in SMF?  Either way, please provide the
service name that users will see.

> jdc-4
> 
> If this documentation is correct, it seems to indicate that the daemon
> is in fact able to receive connection requests from outside of the
> box.  
> 
> A: No. Any packet destined to the 16992 port is filtered by the NIC as 
> OOB data to the AMT ME.

NICs don't filter data by themselves, there's no NIC related to
127.0.0.1, and I don't understand what "OOB" means in this context.

Please explain.

> jdc-5
> In fact, it incorrectly associates host names with the kernel's routing 
> mechanism, so it's quite
> unclear what (if anything) is meant here.
> 
> A: The web page is correct and it's owned by Intel. Intel and the 
> industry are correct. But it requires
> more reading before asking questions, especially as a PSARC member!

Then please explain exactly how the host name affects kernel routing
decisions (given that the kernel TCP/IP stack neither knows nor cares
about names) and how packets to 127.0.0.1 are ever routed.

I can't tell what this page is trying to say, so I can't tell what it
is we're being asked to review here.

Please at least provide a pointer to the additional reading that, in
your view, makes it possible for a PSARC member to ask questions about
this case.

Absent that, I think we may need to review this as a full case.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677