James Carlson wrote: > Paul Jakma writes: > >> On Wed, 17 Oct 2007, Nicolas Williams wrote: >> >> >>> My impression was that the AMT chip gets its own IPv4 address. >>> >> It can be configured to share an IP with the host. >> > > *boggle* > > If so, then I think we have a good reason to have a full review. I > see nothing in the provided materials that would place constraints on > the system configuration mechanisms or how addresses are assigned. > > At a minimum, such an approach means that we end up with the same > IPsec and IP Filter policy bypass as we saw with IB SDP, as well as > unclear TX interaction, and all of that requires additional > documentation and PAC advice. >
I'm not sure I understand here. The embedded environment is not equipped to participate in IPsec. If the customer *administratively* enables AMT (which is, IIRC, off-by-default), then they have decided that this system component should always be running. Assignment of addresses, and whether to share IP addresses or not (by default it does share!) is done using BIOS configuration screens typically. Basically, there are two possible configurations if this service is enabled. In the first, the combination of the NIC and AMT/ME acts as a "filter", which intercepts TCP traffic for these ports. Call this configuration "shared-IP". In the second, the NIC and the AMT act as a separate service processor, with their own IP stack, that does not really participate with the hosts (at least not in a way that the host could normally notice), with their own MAC and IP addresses. One thing that hasn't been discussed here, and which I *hope* the project team has undertaken, is that LMS must squat on the AMT ports in the shared IP configuration. Even if it just binds to them and then never services the traffic. This is required to prevent any other facility from attempting to bind to those ports handled by AMT/ME (since they are in the unreserved range.) On other operating systems, I understand that this is something that LMS normally does. It *may* be that it will also forward traffic on that port to the ME. That would be a simple proxy. As far as interfaces go, the HTTP/SOAP interfaces are "AMT project private" in normal ARC parlance, or, at worst, they could be called Volatile. Software on the host doesn't normally talk to them (unless the management software is ported to Solaris. Note that that would be the subject of another ARC case, and is not treated here.) So, IIUC, the bits that ARC needs to most be concerned about are: * management of the LMS service, in particular how does it get started, stopped, etc. (I'd like to see a full specification of the SMF facility, is it standalone or inetd started, etc.) * security implications. In this case, the embedded environment is configured completely apart from Solaris in the AMT/ME, and handles its own authentication on its own behalf. The LMS/HECI pair is just a transportation conduit, not providing any security of its own. * secure-by-default. LMS needs to be off-by-default, as AMT is also off-by-default. * interaction between the heci driver and LMS are project private ioctls. I think the project team needs to confirm this, and confirm that heci doesn't expose any knobs which are accessible to non-privileged users except via LMS. * implications for interoperability (there are several). - In the shared IP configuration, LMS needs to bind to the AMT ports, because other software running on the host cannot make use of those ports. (Attempts to do so will "appear" as lost traffic.) - AMT won't function in a shared IP configuration where the NIC is part of a layer 2 or layer 3 aggregate or failover configuration, at least not if other NICs that are not part of AMT are involved (I am not sure this an ARC matter. I wonder what advice Intel gives its customers here.) - AMT may not operate properly with NWAM, for the same reasons (project team please confirm/elaborate here) (I'm not sure this precisely is an ARC matter, either.) I think all these bits can be resolved, and done so satisfactorily in the context of a fasttrack. However, I don't think it will be the end of the world (or even particularly bad for any particular business needs) if this case were derailed into a full case. -- Garrett
