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. > > > You're supposed to review what the project team is doing. Not what Intel has been doing. If you don't agree with Intel's design, you cannot exclude it because it's already in the motherboard, and it functions with or without Solaris installed.
The complete Docs are in the AMT SDK, none of them are written by the project team. They provide background information but are not part of our work. Here: /net/furong.prc/export/home/wsbak/wr/AMT/Docs/ You may start with Overview.pdf. For security, you may want to read "Developers Guide to the Sample Setup and Configuration Application.pdf". >>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. > > > But the SOAP interface doesn't need to be approved by you. >>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. I meant packets received by the NIC from other network nodes. >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. > > > Simultaneous sessions are OK. Yes. >>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. > > > The driver's IOCTL interface is very volatile, not documented anywhere. And Intel is constantly upgrading the driver. But the XML/SOAP/HTTP interface has always been backward compatible through AMT 1.0 ~ 3.0. That's why we wanted to restrict the access to the driver only by LMS. Using HTTP is better and safer than allowing directly driver access. >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. > > > It's in SMF. Mark will answer the question. >>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. > > > NICs in this case do filter data by themselves. It's an onboard Intel NIC. OOB - out of band. >>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. > > The page says that if ME is configured with an IP address different from the IP address used by the Host OS, the Host OS never knows that packets destined to the ME's IP address should be routed locally through LMS to ME. >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. > > > Yes I believe there will be better questions after you spend enough time reading. Pointer provided above. Vincent.
