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
