Hi, I'm trying to answer all the remaining questions in one Email. I'm going to give a high level description first because many of the questions are actually not related to what we're reviewing.
As the case title suggests, the _technology_ is from Intel. And it's implemented in the embedded OS inside the ME chip on the motherboard. 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. The ME implements some Web Services which are available through XML/SOAP over HTTP. Some of the services are designed for remote access, but some can be (or can only be) accessed from the Host OS. That's why we need a driver and a daemon in Solaris. The daemon listens on http://localhost:16992/, this is to provide the same interface for applications running either locally or on a network node, as the firmware's protocol is designed in this way. 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. 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. Authentication is done by the firmware using either HTTP Digest or Kerberos. See AMT SDK for the details. LMS/HECI only act as a proxy for the packets between the applications and the firmware. LMS/HECI do not interpret the packets which are governed by the WS-MAN protocol (http://www.dmtf.org/standards/wsman) Use cases: There're countless use cases, here're some of them: http://softwarecommunity.intel.com/articles/eng/1032.htm Now the questions: jdc-1 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. jdc-2 What does that kernel driver do? A: It talks to the PCI device and the lms daemon, passing XML/SOAP messages between them but does not interprets the messages. jdc-3 Would it be necessary for someone inside a non-global zone to access that driver? If not, why not? If so, then how is that secured? How about inside an xVM instance? A: No process accesses the driver directly besides the LMS daemon. We \ do not support non-global zones at present. As for xVM, only one driver instance is supported. At least in the current and the past versions (v3.0/v2.x/v1.0) of AMT, There can be only one driver instance. AMT can be used to poweron/off/reset the entire system, not a guest OS or a zone. However, AMT can potentially be combined with Intel's VT-x, to deliver a more secure system: A persistent hidden management Virtual Machine that continues to monitor the system even when the major VMs are compromised. This addresses the two biggest problems of software-only manageability approaches: a) users tend to disable agents placed on their PCs by the IT department and b) PCs that are not powered on or able to boot are not manageable. However, VT-x is outside the scope of this case. 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. 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! djc-6 That implies that there's a user name and password (or verifier) database stored somewhere. Where are these things stored and how are they protected? A: stored in the firmware. djc-7 What can the driver do to the system? Can it modify system memory? Can it reboot the system? Can it turn off power? Can it force the system to reload a different kernel? No. No. No. dg-1 What access control does LMS provide (IP ACLs, AAA, Kerberos) A: Access control is provided by the firmware, not LMS/HECI. AMT can be configured in either 'Small Business mode', which uses HTTP Digest authentication, or 'Enterprise' mode which uses Kerberos authentication. To make the Kerberos scheme work, the Key Distribution Center (KDC) and domain controller are required to be deployed in the enterprise Intranet, and AMT devices must be configured with Kerberos options. dg-2 Fault management is a purpose of AMT. Should AMT be considered for integration with Solaris's existing fault management framework, FMA? Do the two really need to be separate which necessitates distinct management methods/infrastructure? A: FMA and AMT address different problems. How do you integrate Solaris with the code in the firmware ? dg-3 Why /usr/lib/lms and not /usr/lib/amt/lmsd ? A: I'm OK with both. 'lms' originated from Intel. bs-1 what's the actual access control and IPC mechanism here? you can't assume all local users are trusted, either. A: IPC is done over http://localhost:16992/. See dg-1 for access control. bs-2 Can we get a high level description of the access control model in its entirety? who are the communicating parties and what do they demonstrate to each other to prove their identity, and what do they use to decide whether to allow an operation? What access controls are used on the host to prevent an unauthorized user from talking to the management processor at all? A: Communication parties: local applications and the embedded OS inside the ME on the motherboard. Authentication: see above.
