James Carlson wrote: > 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. >
No, basically the Intel ethernet chip has a "shunt" to deliver traffic to a specific TCP port to the embedded environment (ME) instead of the host computer. If I understand David properly, the HECI and LMS services are required to enable the computer to talk to the ME. Remote systems (management stations) can do so already by talking HTTP on the named port to the ME (using the same IP address as the host computer. Although there is a facility for using static IP addressing with different MAC addresses and IP addresses for the host and embedded environments, in the default configuration they share the MAC and IP addresses. Note that the configuration of this is done from the system BIOS, or over an already running AMT session, and really falls outside the scope of this case.) > 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. > The sessions are short-lived (stateless) HTTP transactions. So one/many doesn't make sense here. Only one HTTP transaction at a time is supported, because that's all the embedded environment is equipped to handle. > >> 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. > Agreed. > 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. > Uh yes, in this case they do. The NIC has special firmware/support, so that the NIC filters the data and hands it off to the embedded AMT environment (which is really another embedded computer running on the motherboard!) when it comes in on this port. The idea is to be able to enable system management, including resetting the system, remotely, even when the operating system is hosed or just not running, and to do so without adding another network interface to the machine. > 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. > I don't think this is a full case, but a more complete document describing AMT is required for the fasttrack, I think. -- Garrett
