From dchieu@sac.sfbay.sun.com Tue Oct 16 13:44:47 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9GKilOR015806 for ; Tue, 16 Oct 2007 13:44:47 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9GKfOuA058829; Tue, 16 Oct 2007 14:41:26 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ000G0LUT1CW00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 16 Oct 2007 13:41:25 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ000DVQUT0WV30@nwk-avmta-1.sfbay.Sun.COM>; Tue, 16 Oct 2007 13:41:24 -0700 (PDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l9GKfNWr035893; Tue, 16 Oct 2007 13:41:23 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9GKifMv015801; Tue, 16 Oct 2007 13:44:41 -0700 (PDT) Received: (from dchieu@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l9GKiffU015797; Tue, 16 Oct 2007 13:44:41 -0700 (PDT) Date: Tue, 16 Oct 2007 13:44:41 -0700 (PDT) From: David Chieu Subject: Intel AMT [PSARC/2007/601 Self Review] To: PSARC-ext@sun.com Cc: Mark.Logan@sun.com, Vincent.Wang@sun.com Message-id: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 4173 I'm sending this on behalf of Mark Logan and Vincent Wang. They are working on Solaris integration of Intel's Active Management Technology (AMT), which is a hardware-based system management technology - proprietary to Intel. The Solaris work consists of a user-land proxy and a kernel device driver. See Sun Open Source Review #6613 & 6583 (review status approved). We believe this work is a self-review candidate for the following reasons, as architecture + interface are defined by Intel, a priori, to work with other OSes. - The user-land proxy is called Local Manageability Service (LMS) that communicates with web standard SOAP/HTTP messages. This proxy acts as a pass through. The LMS interface is defined by Intel's AMT SDK. See http://softwarecommunity.intel.com/articles/eng/1023.htm. - The kernel device driver is called Host Embedded Controller Interface (HECI) which talks to Intel's Management Engine (ME), a separate small ARC-architecture processor built into the North Bridge of the PC motherboard. Intel's ME hardware defines the interface. See http://openamt.org If anyone disagrees, please speak up. We'll promote this case to a FastTrack. Project proposed PSARC case Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Intel AMT 1.2. Name of Document Author/Supplier: Author: David Chieu 1.3 Date of This Document: 16 October, 2007 4. Technical Description 4.1 Introduction The project delivers a Solaris device driver for Intel Active Management Technology(1), AMT-enabled hardware, and a user-level daemon to access and route system management information from the device driver. 4.2 Background and scope Intel Active Management Technology(AMT) is a silicon-resident management mechanism for remote discovery, healing, and protection of computing systems. Intel announced AMT in 2005 to gain system management support for Intel's vPro processor family(2). AMT is a powerful new tool for remote and out-of-band management of Intel PCs. Many major third party software management vendors such as Cisco, CA, Microsoft, Dell, and HP have already integrated support for AMT. However, we like to note that AMT is Intel-centric and is not available on any AMD or SPARC-based machines. 4.3 Proposal This proposal addresses only two specific AMT components to put forth the basic building blocks for developing support of Intel AMT. The two components are: 1) Solaris HECI device driver - Host Embedded Controller Interface to communicate with Intel AMT chips 2) Solaris LMS user daemon - Local Manageability Service daemon to route messages from HECI driver and host operating system services This project implements: ------------------- | LMS daemon | a Solaris user-mode daemon (/usr/lib/lms) ------------------- || ------------------------------------ || ------------------- | HECI driver | a Solaris kernel-mode driver (/kernel/drv/heci) ------------------- 4.4 Use Cases System management applications communicate to AMT via high-level SOAP/HTTP protocol. The intended uses are watchdog, software licensing, user notification service, group computer shutdown, network administration, etc. 4.5 Interfaces interface | stability | description ----------------+--------------------------------------------------------- heci driver(7D) | Volatile | Intel AMT SDK lms(1M) | Volatile | see intel_amt_sdk3.0.zip ----------------+-------------------------------------------------------- Binding: patch/micro 4.6 References: 1. http://www.intel.com/technology/platform-technology/intel-amt/index.htm 2. http://www.intel.com/business/vpro/ 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: self-review 6.6. ARC Exposure: open 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: onnv 6.5. ARC review type: Automatic 6.6. ARC Exposure: open From gdamore@Sun.COM Tue Oct 16 14:16:03 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9GLG2wV016831 for ; Tue, 16 Oct 2007 14:16:03 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9GLCXqU014691 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Oct 2007 05:12:41 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ000J0LW91J000@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 16 Oct 2007 14:12:37 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ000DKHW90WZ80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 16 Oct 2007 14:12:36 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9GLCZXE023411 for ; Tue, 16 Oct 2007 14:12:36 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ000301ULEJF00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 16 Oct 2007 14:12:35 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ000GC9W8BYA90@fe-sfbay-10.sun.com>; Tue, 16 Oct 2007 14:12:11 -0700 (PDT) Date: Tue, 16 Oct 2007 14:09:30 -0700 From: "Garrett D'Amore" Subject: Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> Sender: Garrett.Damore@Sun.COM To: David Chieu Cc: PSARC-ext@Sun.COM, Mark.Logan@Sun.COM, Vincent.Wang@Sun.COM Message-id: <4715288A.9050005@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 5004 I think this may warrant promotion to a fast track. In particular, the interface that the LMS exports to the rest of the system (perhaps just acting as an HTTP proxy) warrants some basic review. The questions I'd like to see answered in a fasttrack are: 1) does LMS export any interface over the network? (If its a web proxy....) 2) what is the administrative interface to manage the LMS service? (SMF? properties for managing what port it binds to, etc?) 3) how does this fit within secure-by-default? Does the service listen only to IN_ADDR_ANY, or does it open up a port accessible to the entire network? Thanks. -- Garrett David Chieu wrote: > I'm sending this on behalf of Mark Logan and Vincent Wang. They are working on Solaris integration of Intel's Active Management Technology (AMT), which is a hardware-based system management technology - proprietary to Intel. The Solaris work consists of a user-land proxy and a kernel device driver. See Sun Open Source Review #6613 & 6583 (review status approved). We believe this work is a self-review candidate for the following reasons, as architecture + interface are defined by Intel, a priori, to work with other OSes. > > - The user-land proxy is called Local Manageability Service (LMS) that communicates with web standard SOAP/HTTP messages. This proxy acts as a pass through. The LMS interface is defined by Intel's AMT SDK. See http://softwarecommunity.intel.com/articles/eng/1023.htm. > - The kernel device driver is called Host Embedded Controller Interface (HECI) which talks to Intel's Management Engine (ME), a separate small ARC-architecture processor built into the North Bridge of the PC motherboard. Intel's ME hardware defines the interface. See http://openamt.org > > If anyone disagrees, please speak up. We'll promote this case to a FastTrack. > > Project proposed PSARC case > > Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI > This information is Copyright 2007 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Intel AMT > 1.2. Name of Document Author/Supplier: > Author: David Chieu > 1.3 Date of This Document: > 16 October, 2007 > 4. Technical Description > > 4.1 Introduction > > The project delivers a Solaris device driver for Intel Active Management Technology(1), AMT-enabled > hardware, and a user-level daemon to access and route system management information from the device driver. > > 4.2 Background and scope > > Intel Active Management Technology(AMT) is a silicon-resident management mechanism for remote discovery, healing, and protection of computing systems. Intel announced AMT in 2005 to gain system management support for Intel's vPro processor family(2). AMT is a powerful new tool for remote and out-of-band management of Intel PCs. Many major third party software management vendors such as Cisco, CA, Microsoft, Dell, and HP have already integrated support for AMT. However, we like to note that AMT is Intel-centric and is not available on any AMD or SPARC-based machines. > > 4.3 Proposal > > This proposal addresses only two specific AMT components to put forth the basic building blocks for developing > support of Intel AMT. The two components are: > > 1) Solaris HECI device driver - Host Embedded Controller Interface to communicate with Intel AMT chips > > 2) Solaris LMS user daemon - Local Manageability Service daemon to route messages from HECI driver and host operating system services > > > This project implements: > > ------------------- > | LMS daemon | a Solaris user-mode daemon (/usr/lib/lms) > ------------------- > || > ------------------------------------ > || > ------------------- > | HECI driver | a Solaris kernel-mode driver (/kernel/drv/heci) > ------------------- > > 4.4 Use Cases > > System management applications communicate to AMT via high-level SOAP/HTTP protocol. The intended uses are > watchdog, software licensing, user notification service, group computer shutdown, network administration, etc. > > 4.5 Interfaces > > interface | stability | description > ----------------+--------------------------------------------------------- > heci driver(7D) | Volatile | Intel AMT SDK > lms(1M) | Volatile | see intel_amt_sdk3.0.zip > ----------------+-------------------------------------------------------- > > Binding: patch/micro > > 4.6 References: > > 1. http://www.intel.com/technology/platform-technology/intel-amt/index.htm > > 2. http://www.intel.com/business/vpro/ > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: self-review > 6.6. ARC Exposure: open > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > onnv > 6.5. ARC review type: Automatic > 6.6. ARC Exposure: open > > From carlsonj@phorcys.east.sun.com Tue Oct 16 14:31:53 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9GLVqHL017314 for ; Tue, 16 Oct 2007 14:31:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9GLSNt8024438; Tue, 16 Oct 2007 14:28:29 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ00020XWZHBU00@brm-avmta-1.central.sun.com>; Tue, 16 Oct 2007 15:28:29 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ000IL5WZFHDA0@brm-avmta-1.central.sun.com>; Tue, 16 Oct 2007 15:28:28 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9GLS6Zi023330; Tue, 16 Oct 2007 17:28:06 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9GLS6Bw023327; Tue, 16 Oct 2007 17:28:06 -0400 (EDT) Date: Tue, 16 Oct 2007 17:28:06 -0400 From: James Carlson Subject: Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <4715288A.9050005@sun.com> To: "Garrett D'Amore" Cc: David Chieu , PSARC-ext@Sun.COM, Mark.Logan@Sun.COM, Vincent.Wang@Sun.COM Message-id: <18197.11494.326860.154398@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <4715288A.9050005@sun.com> Status: RO Content-Length: 1576 Garrett D'Amore writes: > I think this may warrant promotion to a fast track. Definitely. > In particular, the interface that the LMS exports to the rest of the > system (perhaps just acting as an HTTP proxy) warrants some basic review. > > The questions I'd like to see answered in a fasttrack are: > > 1) does LMS export any interface over the network? (If its a web > proxy....) > > 2) what is the administrative interface to manage the LMS service? > (SMF? properties for managing what port it binds to, etc?) > > 3) how does this fit within secure-by-default? Does the service > listen only to IN_ADDR_ANY, or does it open up a port accessible to the > entire network? More generally: have you looked at the security questionnaires? How do you comply with them? http://www.opensolaris.org/os/community/arc/policies/ITS/ http://www.opensolaris.org/os/community/arc/policies/NITS-policy/ http://www.opensolaris.org/os/community/arc/bestpractices/security-questions/ Are the port numbers involved registered with IANA? What security is provided? What privileges are required to talk with the kernel driver? What does that kernel driver do? 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? -- James Carlson, Solaris Networking 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 From David.Chieu@Sun.COM Tue Oct 16 14:53:44 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9GLriOH018394 for ; Tue, 16 Oct 2007 14:53:44 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9GLoM2O016393 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 16 Oct 2007 14:50:23 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ00000JXZYFP00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 16 Oct 2007 14:50:22 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ000DVTXZVWZE0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 16 Oct 2007 14:50:19 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9GLoJrY026857 for ; Tue, 16 Oct 2007 14:50:19 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ000D01W675P00@fe-sfbay-09.sun.com> (original mail from David.Chieu@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 16 Oct 2007 14:50:19 -0700 (PDT) Received: from [10.1.48.110] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ000ESPXZHT330@fe-sfbay-09.sun.com>; Tue, 16 Oct 2007 14:50:05 -0700 (PDT) Date: Tue, 16 Oct 2007 14:50:15 -0700 From: David Chieu Subject: Re: Intel AMT [PSARC/2007/601 FastTrack] In-reply-to: <18197.11494.326860.154398@gargle.gargle.HOWL> Sender: David.Chieu@Sun.COM To: James Carlson Cc: "Garrett D'Amore" , David Chieu , psarc-ext@Sun.COM, Mark.Logan@Sun.COM, Vincent.Wang@Sun.COM Message-id: <47153217.4030108@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <4715288A.9050005@sun.com> <18197.11494.326860.154398@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 342 James Carlson wrote: > Garrett D'Amore writes: > >> I think this may warrant promotion to a fast track. >> > > Definitely. > > Ok, James & Garrett, I've changed the case to fast-track as requested. The timeout set to 10/24/2007 I'll let the project team to do some research & answer both sets of your questions. -- David Chieu From Mark.Logan@Sun.COM Tue Oct 16 15:05:44 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9GM5he5019254 for ; Tue, 16 Oct 2007 15:05:44 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9GM2M98028814 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 16 Oct 2007 23:02:22 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ00040DYJWM400@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 16 Oct 2007 16:02:20 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ000IAIYJUHJE0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 16 Oct 2007 16:02:18 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9GM2Iro000971 for ; Tue, 16 Oct 2007 15:02:18 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ000001XZCCB00@fe-sfbay-09.sun.com> (original mail from Mark.Logan@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 16 Oct 2007 15:02:17 -0700 (PDT) Received: from [10.1.48.235] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ000E6VYJLT3B0@fe-sfbay-09.sun.com>; Tue, 16 Oct 2007 15:02:09 -0700 (PDT) Date: Tue, 16 Oct 2007 15:00:40 -0700 From: Mark Logan Subject: Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <4715288A.9050005@sun.com> Sender: Mark.Logan@Sun.COM To: "Garrett D'Amore" Cc: David Chieu , PSARC-ext@Sun.COM, Vincent.Wang@Sun.COM Message-id: <47153488.1090101@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <4715288A.9050005@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 5649 Hi Garrett, I see that you know about AMT! Garrett D'Amore wrote: > I think this may warrant promotion to a fast track. > > In particular, the interface that the LMS exports to the rest of the > system (perhaps just acting as an HTTP proxy) warrants some basic review. > > The questions I'd like to see answered in a fasttrack are: > > 1) does LMS export any interface over the network? (If its a web > proxy....) LMS is a web proxy, but only for clients running on the same machine. It only accepts connections from the local machine. > > 2) what is the administrative interface to manage the LMS service? > (SMF? properties for managing what port it binds to, etc?) I used SMF. But the port it binds to is fixed and defined by Intel. > > 3) how does this fit within secure-by-default? Does the service > listen only to IN_ADDR_ANY, or does it open up a port accessible to > the entire network? I don't think it affects secure-by-default because it will only accept connections from the local machine. Mark > > Thanks. > > -- Garrett > > David Chieu wrote: >> I'm sending this on behalf of Mark Logan and Vincent Wang. They are >> working on Solaris integration of Intel's Active Management >> Technology (AMT), which is a hardware-based system management >> technology - proprietary to Intel. The Solaris work consists of a >> user-land proxy and a kernel device driver. See Sun Open Source >> Review #6613 & 6583 (review status approved). We believe this work is >> a self-review candidate for the following reasons, as architecture + >> interface are defined by Intel, a priori, to work with other OSes. >> >> - The user-land proxy is called Local Manageability Service (LMS) >> that communicates with web standard SOAP/HTTP messages. This proxy >> acts as a pass through. The LMS interface is defined by Intel's AMT >> SDK. See http://softwarecommunity.intel.com/articles/eng/1023.htm. >> - The kernel device driver is called Host Embedded Controller >> Interface (HECI) which talks to Intel's Management Engine (ME), a >> separate small ARC-architecture processor built into the North Bridge >> of the PC motherboard. Intel's ME hardware defines the interface. See >> http://openamt.org >> >> If anyone disagrees, please speak up. We'll promote this case to a >> FastTrack. >> >> Project proposed PSARC case >> >> Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI >> This information is Copyright 2007 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> Intel AMT >> 1.2. Name of Document Author/Supplier: >> Author: David Chieu >> 1.3 Date of This Document: >> 16 October, 2007 >> 4. Technical Description >> >> 4.1 Introduction >> >> The project delivers a Solaris device driver for Intel Active >> Management Technology(1), AMT-enabled >> hardware, and a user-level daemon to access and route system >> management information from the device driver. >> >> 4.2 Background and scope >> >> Intel Active Management Technology(AMT) is a silicon-resident >> management mechanism for remote discovery, healing, and protection of >> computing systems. Intel announced AMT in 2005 to gain system >> management support for Intel's vPro processor family(2). AMT is a >> powerful new tool for remote and out-of-band management of Intel PCs. >> Many major third party software management vendors such as Cisco, CA, >> Microsoft, Dell, and HP have already integrated support for AMT. >> However, we like to note that AMT is Intel-centric and is not >> available on any AMD or SPARC-based machines. >> >> 4.3 Proposal >> >> This proposal addresses only two specific AMT components to put forth >> the basic building blocks for developing >> support of Intel AMT. The two components are: >> >> 1) Solaris HECI device driver - Host Embedded Controller Interface to >> communicate with Intel AMT chips >> >> 2) Solaris LMS user daemon - Local Manageability Service daemon to >> route messages from HECI driver and host operating system services >> >> >> This project implements: >> >> ------------------- >> | LMS daemon | a Solaris user-mode daemon (/usr/lib/lms) >> ------------------- >> || >> ------------------------------------ >> || >> ------------------- >> | HECI driver | a Solaris kernel-mode driver (/kernel/drv/heci) >> ------------------- >> >> 4.4 Use Cases >> >> System management applications communicate to AMT via high-level >> SOAP/HTTP protocol. The intended uses are >> watchdog, software licensing, user notification service, group >> computer shutdown, network administration, etc. >> >> 4.5 Interfaces >> >> interface | stability | description >> ----------------+--------------------------------------------------------- >> >> heci driver(7D) | Volatile | Intel AMT SDK >> lms(1M) | Volatile | see intel_amt_sdk3.0.zip >> ----------------+-------------------------------------------------------- >> >> >> Binding: patch/micro >> >> 4.6 References: >> >> 1. >> http://www.intel.com/technology/platform-technology/intel-amt/index.htm >> >> 2. http://www.intel.com/business/vpro/ >> >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> ON >> 6.5. ARC review type: self-review >> 6.6. ARC Exposure: open >> >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> onnv >> 6.5. ARC review type: Automatic >> 6.6. ARC Exposure: open >> >> > From daleg@elemental.org Tue Oct 16 15:08:58 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9GM8vC2019427 for ; Tue, 16 Oct 2007 15:08:58 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9GM5UQL020191; Tue, 16 Oct 2007 16:05:33 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ000B0PYP9NF00@nwk-avmta-2.sfbay.sun.com>; Tue, 16 Oct 2007 15:05:33 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ0001HMYP85WD0@nwk-avmta-2.sfbay.sun.com>; Tue, 16 Oct 2007 15:05:32 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9GLwR9v018467; Tue, 16 Oct 2007 22:05:32 +0000 (GMT) Received: from mmp11es.sun.com ([160.41.209.21] [160.41.209.21]) by relay14i.sun.com with ESMTP id BT-MMP-372711; Tue, 16 Oct 2007 22:05:32 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp11es.sun.com with ESMTP id BT-MMP-36362; Tue, 16 Oct 2007 22:05:31 +0000 (Z) Received: from lithium.elemental.org ([130.85.5.200] [130.85.5.200]) by relay1i.sun.com with ESMTP id BT-MMP-1931595; Tue, 16 Oct 2007 22:05:31 +0000 (Z) Received: from [130.85.70.33] (deuterium.ucs.umbc.edu [130.85.70.33]) (authenticated bits=0) by lithium.elemental.org (8.13.8/8.13.8/ELEMENTAL-3.1) with ESMTP id l9GM5Vbm010123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Oct 2007 18:05:31 -0400 (EDT) Date: Tue, 16 Oct 2007 18:05:29 -0400 From: Dale Ghent Subject: Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <4715288A.9050005@sun.com> To: "Garrett D'Amore" Cc: David Chieu , PSARC-ext@sun.com, Mark.Logan@sun.com, Vincent.Wang@sun.com Message-id: <742CE572-193F-41E0-BF96-3D5C0E50ED64@elemental.org> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <4715288A.9050005@sun.com> Status: RO Content-Length: 1116 On Oct 16, 2007, at 5:09 PM, Garrett D'Amore wrote: > I think this may warrant promotion to a fast track. > > In particular, the interface that the LMS exports to the rest of the > system (perhaps just acting as an HTTP proxy) warrants some basic > review. > > The questions I'd like to see answered in a fasttrack are: > > 1) does LMS export any interface over the network? (If its a web > proxy....) > > 2) what is the administrative interface to manage the LMS service? > (SMF? properties for managing what port it binds to, etc?) > > 3) how does this fit within secure-by-default? Does the service > listen only to IN_ADDR_ANY, or does it open up a port accessible to > the > entire network? Furthermore... 4) What access control does LMS provide (IP ACLs, AAA, Kerberos) 5) 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? 6) Why /usr/lib/lms and not /usr/lib/amt/lmsd ? /dale From daleg@elemental.org Tue Oct 16 15:12:11 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9GMCATd019603 for ; Tue, 16 Oct 2007 15:12:10 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9GM8eRG002325; Tue, 16 Oct 2007 23:08:44 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ000201YUIAK00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 16 Oct 2007 15:08:42 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ0000FYYUIJC10@nwk-avmta-1.sfbay.Sun.COM>; Tue, 16 Oct 2007 15:08:42 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9GM5ckb017905; Tue, 16 Oct 2007 22:08:41 +0000 (GMT) Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231]) by relay43i.sun.com with ESMTP id BT-MMP-1690856; Tue, 16 Oct 2007 22:08:41 +0000 (Z) Received: from relay42i.sun.com ([192.5.209.72] [192.5.209.72]) by mms48es.sun.com with ESMTP id BT-MMP-2703109; Tue, 16 Oct 2007 22:08:41 +0000 (Z) Received: from lithium.elemental.org ([130.85.5.200] [130.85.5.200]) by relay4i.sun.com with ESMTP id BT-MMP-6463458; Tue, 16 Oct 2007 22:08:41 +0000 (Z) Received: from [130.85.70.33] (deuterium.ucs.umbc.edu [130.85.70.33]) (authenticated bits=0) by lithium.elemental.org (8.13.8/8.13.8/ELEMENTAL-3.1) with ESMTP id l9GM8KtR010305 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Oct 2007 18:08:20 -0400 (EDT) Date: Tue, 16 Oct 2007 18:08:18 -0400 From: Dale Ghent Subject: Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <47153488.1090101@sun.com> To: Mark Logan Cc: "Garrett D'Amore" , PSARC-ext@sun.com, David Chieu , Vincent.Wang@sun.com Message-id: <087ED362-A78A-471A-B088-6EF6779C8574@elemental.org> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <4715288A.9050005@sun.com> <47153488.1090101@sun.com> Status: RO Content-Length: 415 On Oct 16, 2007, at 6:00 PM, Mark Logan wrote: > I don't think it affects secure-by-default because it will only accept > connections from the local machine. That's reassuring, but it still doesn't make it secure. Access by a local user is still possible, be they a curious but valid user, or a unknown person who has access a compromised account. LMS will still require reliable AAA in that regard. /dale From sommerfeld@sun.com Tue Oct 16 15:13:02 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9GMD1ZW019811 for ; Tue, 16 Oct 2007 15:13:01 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9GM9SrR008269; Wed, 17 Oct 2007 06:09:38 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ000B05YW0TG00@nwk-avmta-2.sfbay.sun.com>; Tue, 16 Oct 2007 15:09:36 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ000127YVZ63E0@nwk-avmta-2.sfbay.sun.com>; Tue, 16 Oct 2007 15:09:36 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l9GM9WJY021642; Tue, 16 Oct 2007 18:09:32 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9GM9VUr004992; Tue, 16 Oct 2007 18:09:31 -0400 (EDT) Date: Tue, 16 Oct 2007 18:09:31 -0400 From: Bill Sommerfeld Subject: Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <47153488.1090101@sun.com> To: Mark Logan Cc: "Garrett D'Amore" , PSARC-ext@sun.com, David Chieu , Vincent.Wang@sun.com Message-id: <1192572571.1887.12.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.12.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <4715288A.9050005@sun.com> <47153488.1090101@sun.com> Status: RO Content-Length: 463 On Tue, 2007-10-16 at 15:00 -0700, Mark Logan wrote: > > 3) how does this fit within secure-by-default? Does the service > > listen only to IN_ADDR_ANY, or does it open up a port accessible to > > the entire network? > I don't think it affects secure-by-default because it will only accept > connections from the local machine. what's the actual access control and IPC mechanism here? you can't assume all local users are trusted, either. - Bill From Nicolas.Williams@sun.com Tue Oct 16 15:43:28 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9GMhSl6021658 for ; Tue, 16 Oct 2007 15:43:28 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9GMe4fx016655; Tue, 16 Oct 2007 15:40:06 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ10070L0ATCZ00@brm-avmta-1.central.sun.com>; Tue, 16 Oct 2007 16:40:05 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ1006UR0AQ8200@brm-avmta-1.central.sun.com>; Tue, 16 Oct 2007 16:40:03 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9GMe2rA001721; Tue, 16 Oct 2007 17:40:02 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9GMe2Ds001720; Tue, 16 Oct 2007 17:40:02 -0500 (CDT) Date: Tue, 16 Oct 2007 17:40:02 -0500 From: Nicolas Williams Subject: Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <4715288A.9050005@sun.com> To: "Garrett D'Amore" Cc: David Chieu , PSARC-ext@sun.com, Mark.Logan@sun.com, Vincent.Wang@sun.com Message-id: <20071016224001.GV29257@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <4715288A.9050005@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 877 On Tue, Oct 16, 2007 at 02:09:30PM -0700, Garrett D'Amore wrote: > I think this may warrant promotion to a fast track. > > In particular, the interface that the LMS exports to the rest of the > system (perhaps just acting as an HTTP proxy) warrants some basic review. > > The questions I'd like to see answered in a fasttrack are: > > 1) does LMS export any interface over the network? (If its a web > proxy....) Looking at the Intel AMT pages... The AMT chip itself does, independently of the host OS. It's like an Intel-specific SP with Service Tags, sort of, except it appears to be off-by-default. The LMS is nebulous at first look, but "[t]he LMS driver provides an interface enabling local management software agents to communicate with the Intel Management Engine using the same high-level protocols as those used for remote management (e.g. XML, SOAP)." From Nicolas.Williams@sun.com Tue Oct 16 15:48:34 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9GMmXGO021938 for ; Tue, 16 Oct 2007 15:48:34 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9GMingN015987; Tue, 16 Oct 2007 23:45:09 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ1006050J6HX00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 16 Oct 2007 15:45:06 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ10001J0J5JC40@nwk-avmta-1.sfbay.Sun.COM>; Tue, 16 Oct 2007 15:45:06 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9GMj5g1001732; Tue, 16 Oct 2007 17:45:05 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9GMj5jI001731; Tue, 16 Oct 2007 17:45:05 -0500 (CDT) Date: Tue, 16 Oct 2007 17:45:05 -0500 From: Nicolas Williams Subject: Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> To: David Chieu Cc: PSARC-ext@sun.com, Mark.Logan@sun.com, Vincent.Wang@sun.com Message-id: <20071016224504.GW29257@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 560 On Tue, Oct 16, 2007 at 01:44:41PM -0700, David Chieu wrote: > 4.4 Use Cases > > System management applications communicate to AMT via high-level > SOAP/HTTP protocol. The intended uses are watchdog, software > licensing, user notification service, group computer shutdown, > network administration, etc. "...group computer shutdown..." I think that's a quote that applies to the chip itself, rather than the driver and daemon. It seems that one has to turn this on in the BIOS, that it's off by default. One can set a password via the BIOS as well. From Mark.Logan@sun.com Tue Oct 16 16:16:54 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9GNGsFF023080 for ; Tue, 16 Oct 2007 16:16:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9GNDX8b026371 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 16 Oct 2007 16:13:33 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ100G0R1UK1F00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 16 Oct 2007 16:13:32 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ100EB41UJEV20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 16 Oct 2007 16:13:31 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9GNDVsv005916 for ; Tue, 16 Oct 2007 16:13:31 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ100I011KF7A00@fe-sfbay-10.sun.com> (original mail from Mark.Logan@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 16 Oct 2007 16:13:31 -0700 (PDT) Received: from [10.1.48.235] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ1005RC1UIX4E0@fe-sfbay-10.sun.com>; Tue, 16 Oct 2007 16:13:31 -0700 (PDT) Date: Tue, 16 Oct 2007 16:12:01 -0700 From: Mark Logan Subject: Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <18197.11494.326860.154398@gargle.gargle.HOWL> Sender: Mark.Logan@sun.com To: James Carlson Cc: "Garrett D'Amore" , David Chieu , PSARC-ext@sun.com, Vincent.Wang@sun.com Message-id: <47154541.5060400@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <4715288A.9050005@sun.com> <18197.11494.326860.154398@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 1912 Hi James, James Carlson wrote: > Garrett D'Amore writes: > >> I think this may warrant promotion to a fast track. >> > > Definitely. > > >> In particular, the interface that the LMS exports to the rest of the >> system (perhaps just acting as an HTTP proxy) warrants some basic review. >> >> The questions I'd like to see answered in a fasttrack are: >> >> 1) does LMS export any interface over the network? (If its a web >> proxy....) >> >> 2) what is the administrative interface to manage the LMS service? >> (SMF? properties for managing what port it binds to, etc?) >> >> 3) how does this fit within secure-by-default? Does the service >> listen only to IN_ADDR_ANY, or does it open up a port accessible to the >> entire network? >> > > More generally: have you looked at the security questionnaires? How > do you comply with them? > > http://www.opensolaris.org/os/community/arc/policies/ITS/ > http://www.opensolaris.org/os/community/arc/policies/NITS-policy/ > http://www.opensolaris.org/os/community/arc/bestpractices/security-questions/ > I think we are OK, since LMS only accepts connections from the local machine. See: http://openamt.org/wiki/LocalManageabilityService > Are the port numbers involved registered with IANA? What security is > provided? > The ports are registered with IANA: 16992 and 16993. HTTP digest access authentication is required. > What privileges are required to talk with the kernel driver? What > does that kernel driver do? > The kernel driver requires root privileges. The driver just passes the HTTP requests down to the AMT firmware and passes the HTTP responses back up. > 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? > > I'm going to let David answer to these questions. > From Mark.Logan@sun.com Tue Oct 16 16:18:31 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9GNIVpX023126 for ; Tue, 16 Oct 2007 16:18:31 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9GNF99U040426 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 16 Oct 2007 17:15:10 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ10091R1X9UD00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 16 Oct 2007 16:15:09 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ10005D1WZJC60@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 16 Oct 2007 16:15:09 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9GNEwKT008402 for ; Tue, 16 Oct 2007 16:14:59 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ100K011233O00@fe-sfbay-09.sun.com> (original mail from Mark.Logan@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 16 Oct 2007 16:14:58 -0700 (PDT) Received: from [10.1.48.235] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ100CCV1WYK4C0@fe-sfbay-09.sun.com>; Tue, 16 Oct 2007 16:14:58 -0700 (PDT) Date: Tue, 16 Oct 2007 16:13:28 -0700 From: Mark Logan Subject: Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <087ED362-A78A-471A-B088-6EF6779C8574@elemental.org> Sender: Mark.Logan@sun.com To: Dale Ghent Cc: "Garrett D'Amore" , PSARC-ext@sun.com, David Chieu , Vincent.Wang@sun.com Message-id: <47154598.8030201@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <4715288A.9050005@sun.com> <47153488.1090101@sun.com> <087ED362-A78A-471A-B088-6EF6779C8574@elemental.org> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 518 You are right. LMS requires HTTP digest access authentication. Mark Dale Ghent wrote: > On Oct 16, 2007, at 6:00 PM, Mark Logan wrote: > >> I don't think it affects secure-by-default because it will only accept >> connections from the local machine. > > That's reassuring, but it still doesn't make it secure. Access by a > local user is still possible, be they a curious but valid user, or a > unknown person who has access a compromised account. LMS will still > require reliable AAA in that regard. > > /dale From sommerfeld@sun.com Tue Oct 16 16:47:39 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9GNlcFp023507 for ; Tue, 16 Oct 2007 16:47:39 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9GNi4ks017930; Wed, 17 Oct 2007 07:44:15 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ100B0F39PZX00@brm-avmta-1.central.sun.com>; Tue, 16 Oct 2007 17:44:13 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ1006AD39O8F30@brm-avmta-1.central.sun.com>; Tue, 16 Oct 2007 17:44:12 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l9GNi8fw019308; Tue, 16 Oct 2007 19:44:08 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9GNi7rU005293; Tue, 16 Oct 2007 19:44:07 -0400 (EDT) Date: Tue, 16 Oct 2007 19:44:06 -0400 From: Bill Sommerfeld Subject: Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <47154598.8030201@sun.com> To: Mark Logan Cc: Dale Ghent , PSARC-ext@sun.com, Vincent.Wang@sun.com, "Garrett D'Amore" , David Chieu Message-id: <1192578246.1887.28.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.12.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <4715288A.9050005@sun.com> <47153488.1090101@sun.com> <087ED362-A78A-471A-B088-6EF6779C8574@elemental.org> <47154598.8030201@sun.com> Status: RO Content-Length: 583 On Tue, 2007-10-16 at 16:13 -0700, Mark Logan wrote: > You are right. LMS requires HTTP digest access authentication. Mark, 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? Getting fragments of the spec, one line per message isn't working. - Bill From Nicolas.Williams@Sun.COM Tue Oct 16 17:00:03 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9H003I3023967 for ; Tue, 16 Oct 2007 17:00:03 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9GNueJd009303; Tue, 16 Oct 2007 16:56:41 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ100D0L3UH0Z00@brm-avmta-1.central.sun.com>; Tue, 16 Oct 2007 17:56:41 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ10065R3UF8030@brm-avmta-1.central.sun.com>; Tue, 16 Oct 2007 17:56:40 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9GNud5T001900; Tue, 16 Oct 2007 18:56:39 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9GNuclH001899; Tue, 16 Oct 2007 18:56:38 -0500 (CDT) Date: Tue, 16 Oct 2007 18:56:38 -0500 From: Nicolas Williams Subject: Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <20071016224504.GW29257@Sun.COM> To: David Chieu Cc: PSARC-ext@Sun.COM, Mark.Logan@Sun.COM, Vincent.Wang@Sun.COM Message-id: <20071016235638.GX29257@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <20071016224504.GW29257@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 817 On Tue, Oct 16, 2007 at 05:45:05PM -0500, Nicolas Williams wrote: > On Tue, Oct 16, 2007 at 01:44:41PM -0700, David Chieu wrote: > > 4.4 Use Cases > > > > System management applications communicate to AMT via high-level > > SOAP/HTTP protocol. The intended uses are watchdog, software > > licensing, user notification service, group computer shutdown, > > network administration, etc. > > "...group computer shutdown..." > > I think that's a quote that applies to the chip itself, rather than the > driver and daemon. It seems that one has to turn this on in the BIOS, > that it's off by default. One can set a password via the BIOS as well. Of course, the driver and daemon allow the chip's facilities to be accessed locally, so "group computer shutdown" applies as a use case for the driver and daemon. From David.Chieu@sun.com Tue Oct 16 17:34:21 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9H0YL0l024304 for ; Tue, 16 Oct 2007 17:34:21 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9H0Urh7027159 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Oct 2007 01:30:59 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ100F0R5FMGR00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 16 Oct 2007 18:30:58 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ1006NV5FL8C50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 16 Oct 2007 18:30:57 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9H0Uvvu016762 for ; Tue, 16 Oct 2007 17:30:57 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ1006015EHXW00@fe-sfbay-10.sun.com> (original mail from David.Chieu@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 16 Oct 2007 17:30:57 -0700 (PDT) Received: from [10.1.48.110] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ1005UE5FKW190@fe-sfbay-10.sun.com>; Tue, 16 Oct 2007 17:30:56 -0700 (PDT) Date: Tue, 16 Oct 2007 17:31:06 -0700 From: David Chieu Subject: Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <47154541.5060400@sun.com> Sender: David.Chieu@sun.com To: Mark Logan , James Carlson Cc: "Garrett D'Amore" , David Chieu , PSARC-ext@sun.com, Vincent.Wang@sun.com Message-id: <471557CA.9000902@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <4715288A.9050005@sun.com> <18197.11494.326860.154398@gargle.gargle.HOWL> <47154541.5060400@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 610 Mark Logan wrote: > James Carlson wrote: > >> 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? >> >> > I'm going to let David answer to these questions. This project phase I is only concerned about global zone and dom0. Phase II targets non-global and domUs. Currently, we're *not* aware of any customer requirements to access heci driver from a non-global zone. I'm not familiar with virtualization - please advise if there are areas that we need to take notes. -- David Chieu From Mark.Logan@sun.com Tue Oct 16 17:51:02 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9H0p1iO024758 for ; Tue, 16 Oct 2007 17:51:01 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9H0lcdp003787; Wed, 17 Oct 2007 01:47:39 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ100K0567E6800@nwk-avmta-1.sfbay.Sun.COM>; Tue, 16 Oct 2007 17:47:38 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ1000DO67EJ7A0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 16 Oct 2007 17:47:38 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9H0lbEj018086; Tue, 16 Oct 2007 17:47:37 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ10040166UDP00@fe-sfbay-09.sun.com> (original mail from Mark.Logan@Sun.COM); Tue, 16 Oct 2007 17:47:37 -0700 (PDT) Received: from [10.1.48.235] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ100HXG67DKOC0@fe-sfbay-09.sun.com>; Tue, 16 Oct 2007 17:47:37 -0700 (PDT) Date: Tue, 16 Oct 2007 17:46:08 -0700 From: Mark Logan Subject: Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <1192578246.1887.28.camel@thunk> Sender: Mark.Logan@sun.com To: Bill Sommerfeld Cc: Dale Ghent , PSARC-ext@sun.com, Vincent.Wang@sun.com, "Garrett D'Amore" , David Chieu Message-id: <47155B50.6000405@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <4715288A.9050005@sun.com> <47153488.1090101@sun.com> <087ED362-A78A-471A-B088-6EF6779C8574@elemental.org> <47154598.8030201@sun.com> <1192578246.1887.28.camel@thunk> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 776 I understand. I didn't realize there would be concerns about this. I will work on it and send it to you tomorrow. Mark Bill Sommerfeld wrote: > On Tue, 2007-10-16 at 16:13 -0700, Mark Logan wrote: > >> You are right. LMS requires HTTP digest access authentication. >> > > Mark, > > 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? > > Getting fragments of the spec, one line per message isn't working. > > - Bill > > > > > From carlsonj@phorcys.east.sun.com Wed Oct 17 05:08:58 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HC8vx5005922 for ; Wed, 17 Oct 2007 05:08:57 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HC5R6o020648; Wed, 17 Oct 2007 20:05:31 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ2003051L4PV00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Oct 2007 05:05:28 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2001901L3QX60@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Oct 2007 05:05:28 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9HBvZGY025278; Wed, 17 Oct 2007 07:57:35 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9HBvZua025275; Wed, 17 Oct 2007 07:57:35 -0400 (EDT) Date: Wed, 17 Oct 2007 07:57:35 -0400 From: James Carlson Subject: Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <742CE572-193F-41E0-BF96-3D5C0E50ED64@elemental.org> To: Dale Ghent , Mark Logan , David Chieu Cc: "Garrett D'Amore" , PSARC-ext@sun.com, Vincent.Wang@sun.com Message-id: <18197.63663.245036.835518@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <4715288A.9050005@sun.com> <18197.11494.326860.154398@gargle.gargle.HOWL> <47154541.5060400@sun.com> <471557CA.9000902@sun.com> <742CE572-193F-41E0-BF96-3D5C0E50ED64@elemental.org> Status: RO Content-Length: 3684 Dale Ghent writes: > 6) Why /usr/lib/lms and not /usr/lib/amt/lmsd ? Unless there are multiple private objects associated with amt, and enough of them that littering /usr/lib with them would be seen as annoying, there's no reason to create a subdirectory in /usr/lib. Mark Logan writes: > > http://www.opensolaris.org/os/community/arc/policies/ITS/ > > http://www.opensolaris.org/os/community/arc/policies/NITS-policy/ > > http://www.opensolaris.org/os/community/arc/bestpractices/security-questions/ > > > I think we are OK, since LMS only accepts connections from the local > machine. > See: http://openamt.org/wiki/LocalManageabilityService It's unclear exactly how the daemon does this. The web page you've provided seems to suggest that both 127.0.0.1 (which is strictly internal) *and* the local host name will work. The local host name typically resolves to one of the local interface IP addresses. However, the documentation is imprecise. It doesn't discuss what assumptions it makes about the host name to address mappings. In fact, it incorrectly associates host names with the kernel's routing mechanism, so it's quite unclear what (if anything) is meant here. 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. That would place it under the "secure by default" and access control rules. (I can't tell if this web page is a normative or an informative reference. If it's meant to be normative, it's not complete. Please provide complete documentation with the case materials.) > > Are the port numbers involved registered with IANA? What security is > > provided? > > > The ports are registered with IANA: 16992 and 16993. OK. Those appear to be AMT SOAP/HTTP and AMT SOAP/HTTPS. > HTTP digest access authentication is required. 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? > > What privileges are required to talk with the kernel driver? What > > does that kernel driver do? > > > The kernel driver requires root privileges. Meaning "all privileges," I assume, and not magic UID 0. > The driver just passes the HTTP requests down to the AMT firmware and > passes the HTTP responses back up. That's not what I was asking. 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? I'm trying to get an idea of whether this device node is just a monitoring interface or if it has more serious security issues to be concerned about. David Chieu writes: > Mark Logan wrote: > > James Carlson wrote: > > > >> 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? > >> > >> > > I'm going to let David answer to these questions. > This project phase I is only concerned about global zone and dom0. Phase > II targets non-global and domUs. Currently, we're *not* aware of any > customer requirements to access heci driver from a non-global zone. I'm > not familiar with virtualization - please advise if there are areas that > we need to take notes. That's fine. As long as you know of no customer requirement to do this, and you're not supporting it, I'm happy. -- James Carlson, Solaris Networking 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 From Vincent.Wang@sun.com Wed Oct 17 06:34:09 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HDY9tc007238 for ; Wed, 17 Oct 2007 06:34:09 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HDUloE015944 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Oct 2007 06:30:47 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200C055JBF600@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 06:30:47 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2004BF5IZBO40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 06:30:45 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9HDUZWH018683 for ; Wed, 17 Oct 2007 13:30:35 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JQ200I015HLMY00@mail-apac.sun.com> (original mail from Vincent.Wang@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 21:30:35 +0800 (SGT) Received: from [61.51.83.61] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JQ2009135INO213@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 21:30:34 +0800 (SGT) Date: Wed, 17 Oct 2007 21:34:05 +0800 From: Vincent Wang Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <4715F129.2010704@sun.com> Sender: Vincent.Wang@sun.com To: Vincent R Wang , David Chieu , Mark Logan , James.D.Carlson@sun.com, daleg@elemental.org, gdamore@sun.com Cc: PSARC-ext@sun.com Message-id: <47160F4D.9040704@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 Status: RO Content-Length: 5989 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. From Vincent.Wang@Sun.COM Wed Oct 17 07:27:23 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HERMwA007910 for ; Wed, 17 Oct 2007 07:27:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HENpaV020162 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Oct 2007 22:24:00 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ20050N7ZY0H00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 08:23:58 -0600 (MDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2001GF7ZVVY50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 08:23:56 -0600 (MDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9HENtlu019759 for ; Wed, 17 Oct 2007 14:23:55 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JQ200E017WFG000@mail-apac.sun.com> (original mail from Vincent.Wang@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 22:23:55 +0800 (SGT) Received: from [61.51.83.61] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JQ2009597ZPO263@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 22:23:54 +0800 (SGT) Date: Wed, 17 Oct 2007 22:27:35 +0800 From: Vincent Wang Subject: PSARC doesn't work!! Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <18197.63663.245036.835518@gargle.gargle.HOWL> Sender: Vincent.Wang@Sun.COM To: James Carlson Cc: Dale Ghent , Mark Logan , David Chieu , "Garrett D'Amore" , PSARC-ext@Sun.COM Message-id: <47161BD7.3050206@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <4715288A.9050005@sun.com> <18197.11494.326860.154398@gargle.gargle.HOWL> <47154541.5060400@sun.com> <471557CA.9000902@sun.com> <742CE572-193F-41E0-BF96-3D5C0E50ED64@elemental.org> <18197.63663.245036.835518@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 Status: RO Content-Length: 701 PSARC doesn't work! I'm deeply worried because none of the people who raised questions spent more than an hour even googling the text about the technology. Do you guys respect the hard work of the excellent engineers in other companies who invented AMT, and the billions of dollars spent developing the technology? I'm especially worried because these people include _James D Carlson_ who has been in Sun for such a long time! Do you know that this conversation can be easily searched on google? Whatever you say, you represent the image of Sun's engineers! People may ask, why is he asking these guys to review this stuff for an approval? What? Tell me why. And be responsible. Vincent. From carlsonj@phorcys.east.sun.com Wed Oct 17 07:32:26 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HEWPuh007980 for ; Wed, 17 Oct 2007 07:32:25 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HEStwB008990; Wed, 17 Oct 2007 15:28:58 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ20050P888AV00@brm-avmta-1.central.sun.com>; Wed, 17 Oct 2007 08:28:56 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2001GL887W270@brm-avmta-1.central.sun.com>; Wed, 17 Oct 2007 08:28:55 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9HEL3co025798; Wed, 17 Oct 2007 10:21:03 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9HEL39J025795; Wed, 17 Oct 2007 10:21:03 -0400 (EDT) Date: Wed, 17 Oct 2007 10:21:03 -0400 From: James Carlson Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <47160F4D.9040704@sun.com> To: Vincent Wang Cc: David Chieu , Mark Logan , daleg@elemental.org, gdamore@sun.com, PSARC-ext@sun.com Message-id: <18198.6735.800976.111283@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> Status: RO Content-Length: 3481 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 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 From carlsonj@phorcys.east.sun.com Wed Oct 17 07:42:33 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HEgWnU008017 for ; Wed, 17 Oct 2007 07:42:32 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HEd1el026347; Wed, 17 Oct 2007 22:39:05 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ20020N8P4NJ00@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 07:39:04 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ200ENU8P2TAC0@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 07:39:02 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9HEVBwY025861; Wed, 17 Oct 2007 10:31:11 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9HEVBrW025858; Wed, 17 Oct 2007 10:31:11 -0400 (EDT) Date: Wed, 17 Oct 2007 10:31:11 -0400 From: James Carlson Subject: Re: PSARC doesn't work!! Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <47161BD7.3050206@sun.com> To: Vincent Wang Cc: Dale Ghent , Mark Logan , David Chieu , "Garrett D'Amore" , PSARC-ext@Sun.COM Message-id: <18198.7343.33264.793552@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <4715288A.9050005@sun.com> <18197.11494.326860.154398@gargle.gargle.HOWL> <47154541.5060400@sun.com> <471557CA.9000902@sun.com> <742CE572-193F-41E0-BF96-3D5C0E50ED64@elemental.org> <18197.63663.245036.835518@gargle.gargle.HOWL> <47161BD7.3050206@sun.com> Status: RO Content-Length: 1818 Vincent Wang writes: > PSARC doesn't work! > > I'm deeply worried because none of the people who raised questions spent > more than an hour even googling the text about the technology. > > Do you guys respect the hard work of the excellent engineers in other > companies who invented AMT, and the billions of dollars spent developing > the technology? > > I'm especially worried because these people include _James D Carlson_ > who has been in Sun for such a long time! It's the project team's responsibility to submit complete materials for review. It's not the ARC member's responsibility to go off and figure out what (if anything) a project team might be trying to do. > Do you know that this conversation can be easily searched on google? Of course. > Whatever you say, you represent the image of Sun's engineers! I'm well aware. > People may ask, why is he asking these guys to review this stuff for an > approval? What? > > Tell me why. And be responsible. As with any review -- design, code, or otherwise -- the point of an architectural review is to make sure that what's being done by the project team is consistent with good practices. In this case, that means that the project conforms to expected norms (secure by default, least privilege, and SMF, among others) and is something that can potentially be used by future projects as a building block. Your case sponsor is supposed to help you with this. He's supposed to make sure that your materials are complete and that he understands what the project is doing. I don't think that happened in this instance. -- James Carlson, Solaris Networking 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 From Paul.Jakma@sun.com Wed Oct 17 08:11:34 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HFBXh1008534 for ; Wed, 17 Oct 2007 08:11:33 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HF87tS008390 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Oct 2007 23:08:10 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200409A1L7E00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 08:08:09 -0700 (PDT) Received: from gmp-eb-mail-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ200ECZA1KTBD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 08:08:09 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HF86YX000636 for ; Wed, 17 Oct 2007 15:08:08 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200G017BSA200@fe-emea-09.sun.com> (original mail from Paul.Jakma@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 16:08:07 +0100 (BST) Received: from [81.168.24.40] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ2005L4A197P20@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 16:07:58 +0100 (BST) Date: Wed, 17 Oct 2007 16:07:50 +0100 (BST) From: Paul Jakma Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <18198.6735.800976.111283@gargle.gargle.HOWL> Sender: Paul.Jakma@sun.com To: James Carlson Cc: Vincent Wang , David Chieu , Mark Logan , daleg@elemental.org, gdamore@sun.com, PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> Status: RO Content-Length: 1439 On Wed, 17 Oct 2007, James Carlson wrote: > 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. >> 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. Firmware 'near' the NIC (I've never seen an explanation of the exact mechanism) interposes itself between hardware and OS and 'hijacks' traffic to that port. It never makes it to the OS. Essentially, LOMish firmware and host are sharing a NIC, presumably to save money - on hardware in the first instance, and possibly even on IP administration of a LOM in the second. IMLU. (The clean answer of course would have been to just add dual-MAC capability to the NIC, and let the LOMish/OoB-management firmware have it's own MAC address and IP). regards, -- Paul Jakma, Solaris Networking Sun Microsystems, Scotland http://opensolaris.org/os/project/quagga tel: EMEA x73150 / +44 15066 73150 From sommerfeld@sun.com Wed Oct 17 08:15:56 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HFFt5k008573 for ; Wed, 17 Oct 2007 08:15:55 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HFCOBM029936; Wed, 17 Oct 2007 16:12:27 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200401A8PJX00@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 08:12:25 -0700 (PDT) Received: from localhost.east.sun.com ([129.148.19.3]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ200ERWA8NTCE0@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 08:12:24 -0700 (PDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9HFCIBj004282; Wed, 17 Oct 2007 11:12:18 -0400 (EDT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9HFCI1m004281; Wed, 17 Oct 2007 11:12:18 -0400 (EDT) Date: Wed, 17 Oct 2007 11:12:18 -0400 From: Bill Sommerfeld Subject: Re: PSARC doesn't work!! Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <47161BD7.3050206@sun.com> To: Vincent Wang Cc: James Carlson , David Chieu , Mark Logan , "Garrett D'Amore" , PSARC-ext@sun.com Message-id: <1192633938.3938.53.camel@localhost> MIME-version: 1.0 X-Mailer: Evolution 2.12.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <4715288A.9050005@sun.com> <18197.11494.326860.154398@gargle.gargle.HOWL> <47154541.5060400@sun.com> <471557CA.9000902@sun.com> <742CE572-193F-41E0-BF96-3D5C0E50ED64@elemental.org> <18197.63663.245036.835518@gargle.gargle.HOWL> <47161BD7.3050206@sun.com> X-Authentication-warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Status: RO Content-Length: 624 On Wed, 2007-10-17 at 22:27 +0800, Vincent Wang wrote: > I'm deeply worried because none of the people who raised questions spent > more than an hour even googling the text about the technology. I think you don't understand how psarc works. If you want all of us to spend an hour or so each on the case, file as full case and schedule an inception review. Otherwise spend the time necessary to write a concise summary of the technology so that an experienced generalist can walk away after reading it and maybe one or two of the references saying "yes, this obviously is ready to go into (open)solaris". - Bill From sommerfeld@sun.com Wed Oct 17 08:27:58 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HFRwvv008659 for ; Wed, 17 Oct 2007 08:27:58 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HFOUH5024953; Wed, 17 Oct 2007 08:24:32 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ20050DASW2E00@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 08:24:32 -0700 (PDT) Received: from localhost.east.sun.com ([129.148.19.3]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2004FZASVVI00@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 08:24:32 -0700 (PDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9HFOQh5004288; Wed, 17 Oct 2007 11:24:26 -0400 (EDT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9HFOQp3004287; Wed, 17 Oct 2007 11:24:26 -0400 (EDT) Date: Wed, 17 Oct 2007 11:24:26 -0400 From: Bill Sommerfeld Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: To: Paul Jakma Cc: James Carlson , gdamore@sun.com, PSARC-ext@sun.com, David Chieu , Vincent Wang , Mark Logan Message-id: <1192634666.3938.66.camel@localhost> MIME-version: 1.0 X-Mailer: Evolution 2.12.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> X-Authentication-warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Status: RO Content-Length: 667 On Wed, 2007-10-17 at 16:07 +0100, Paul Jakma wrote: > Firmware 'near' the NIC (I've never seen an explanation of the exact > mechanism) interposes itself between hardware and OS and 'hijacks' > traffic to that port. It never makes it to the OS. one implication of this is that, when this is in use, the NIC cannot be part of a L2 aggregation (because the upstream switch will load-spread some of the management traffic flows to other ports in the aggregation). And using it with other L2/L3 redundancy technologies (such as IPMP and OSPF-MP) is going to be tricky (the shared management IP address must not be seen as reachable via other NICs). - Bill From gdamore@sun.com Wed Oct 17 08:29:35 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HFTZ4k008679 for ; Wed, 17 Oct 2007 08:29:35 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HFQ8cK006664 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Oct 2007 16:26:12 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200503AVN6600@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 08:26:11 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2004H6AVMVK00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 08:26:11 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HFQAin023432 for ; Wed, 17 Oct 2007 08:26:10 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200G01AHRK200@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 08:26:10 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ2001O0AV7UJ60@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 08:25:56 -0700 (PDT) Date: Wed, 17 Oct 2007 08:23:11 -0700 From: "Garrett D'Amore" Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <18198.6735.800976.111283@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: James Carlson Cc: Vincent Wang , David Chieu , Mark Logan , daleg@elemental.org, PSARC-ext@sun.com Message-id: <471628DF.8080801@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 5132 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 From Paul.Jakma@sun.com Wed Oct 17 08:36:45 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HFajvM008794 for ; Wed, 17 Oct 2007 08:36:45 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HFXN4f027956 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Oct 2007 08:33:23 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200507B7NIR00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 08:33:23 -0700 (PDT) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ20042RB7LVB10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 08:33:22 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HFXLEQ007800 for ; Wed, 17 Oct 2007 15:33:21 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200F01AKDST00@fe-emea-10.sun.com> (original mail from Paul.Jakma@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 16:33:20 +0100 (BST) Received: from [81.168.24.40] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ200MIPB76QG20@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 16:33:15 +0100 (BST) Date: Wed, 17 Oct 2007 16:33:04 +0100 (BST) From: Paul Jakma Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: Sender: Paul.Jakma@sun.com To: Vincent Wang Cc: David Chieu , James Carlson , Mark Logan , daleg@elemental.org, gdamore@sun.com, PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> Status: RO Content-Length: 1003 On Wed, 17 Oct 2007, Paul Jakma wrote: > Firmware 'near' the NIC (I've never seen an explanation of the exact > mechanism) interposes itself between hardware and OS and 'hijacks' > traffic to that port. It never makes it to the OS. Ah, googling suggests that when this "Not quite a NIC" has this management-port-hijack feature enabled, that it would limit the NIC to 100Mb/s mode (due to firmware implementation not supporting GigE somehow). Is this performance limitation still present? Another question I would have: If the management-hijack is active and the OS requests promiscious receive, does the OS get the management-port traffic? I.e. I suspect this feature *must* either break AMT or else network-observability through promiscious-mode operation, is this the case? If not, I'd be curious as to how it's done. regards, -- Paul Jakma, Solaris Networking Sun Microsystems, Scotland http://opensolaris.org/os/project/quagga tel: EMEA x73150 / +44 15066 73150 From Vincent.Wang@sun.com Wed Oct 17 08:43:47 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HFhl0j008834 for ; Wed, 17 Oct 2007 08:43:47 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HFeNiu018471 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Oct 2007 08:40:25 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200103BJDEH00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 08:40:25 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2004CKBJBBRD0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 08:40:24 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9HFeNuO018702 for ; Wed, 17 Oct 2007 15:40:23 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JQ200H01BIVRY00@mail-apac.sun.com> (original mail from Vincent.Wang@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 23:40:23 +0800 (SGT) Received: from [61.51.83.61] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JQ2009CJBIYO2B3@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 23:40:23 +0800 (SGT) Date: Wed, 17 Oct 2007 23:43:57 +0800 From: Vincent Wang Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <18198.6735.800976.111283@gargle.gargle.HOWL> Sender: Vincent.Wang@sun.com To: James Carlson Cc: David Chieu , Mark Logan , daleg@elemental.org, gdamore@sun.com, PSARC-ext@sun.com Message-id: <47162DBD.9050007@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 Status: RO Content-Length: 4973 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. From Nicolas.Williams@sun.com Wed Oct 17 08:48:01 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HFm0in008897 for ; Wed, 17 Oct 2007 08:48:01 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HFiSZM022496; Wed, 17 Oct 2007 23:44:30 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200616BQ50A00@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 08:44:29 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ20040BBQ3VC20@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 08:44:28 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9HFiRjF002461; Wed, 17 Oct 2007 10:44:27 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9HFiR6O002460; Wed, 17 Oct 2007 10:44:27 -0500 (CDT) Date: Wed, 17 Oct 2007 10:44:27 -0500 From: Nicolas Williams Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <1192634666.3938.66.camel@localhost> To: Bill Sommerfeld Cc: Paul Jakma , James Carlson , gdamore@sun.com, PSARC-ext@sun.com, David Chieu , Vincent Wang , Mark Logan Message-id: <20071017154427.GD29257@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 805 On Wed, Oct 17, 2007 at 11:24:26AM -0400, Bill Sommerfeld wrote: > On Wed, 2007-10-17 at 16:07 +0100, Paul Jakma wrote: > > Firmware 'near' the NIC (I've never seen an explanation of the exact > > mechanism) interposes itself between hardware and OS and 'hijacks' > > traffic to that port. It never makes it to the OS. > > one implication of this is that, when this is in use, the NIC cannot be > part of a L2 aggregation (because the upstream switch will load-spread > some of the management traffic flows to other ports in the aggregation). > > And using it with other L2/L3 redundancy technologies (such as IPMP and > OSPF-MP) is going to be tricky (the shared management IP address must > not be seen as reachable via other NICs). My impression was that the AMT chip gets its own IPv4 address. From Paul.Jakma@sun.com Wed Oct 17 08:54:59 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HFsxOJ009268 for ; Wed, 17 Oct 2007 08:54:59 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HFpbPr005407; Wed, 17 Oct 2007 08:51:37 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ20021PC20LD00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Oct 2007 08:51:36 -0700 (PDT) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ20044KC1YBWE0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Oct 2007 08:51:35 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HFpY2r009766; Wed, 17 Oct 2007 15:51:34 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200101BJY7000@fe-emea-10.sun.com> (original mail from Paul.Jakma@Sun.COM); Wed, 17 Oct 2007 16:51:34 +0100 (BST) Received: from [81.168.24.40] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ200MLSC1LQG20@fe-emea-10.sun.com>; Wed, 17 Oct 2007 16:51:27 +0100 (BST) Date: Wed, 17 Oct 2007 16:51:20 +0100 (BST) From: Paul Jakma Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <20071017154427.GD29257@Sun.COM> Sender: Paul.Jakma@sun.com To: Nicolas Williams Cc: Bill Sommerfeld , James Carlson , gdamore@sun.com, PSARC-ext@sun.com, David Chieu , Vincent Wang , Mark Logan Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <20071017154427.GD29257@Sun.COM> Status: RO Content-Length: 333 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. regards, -- Paul Jakma, Solaris Networking Sun Microsystems, Scotland http://opensolaris.org/os/project/quagga tel: EMEA x73150 / +44 15066 73150 From Paul.Jakma@sun.com Wed Oct 17 08:57:46 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HFvjo7009508 for ; Wed, 17 Oct 2007 08:57:46 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HFsFwQ026744; Wed, 17 Oct 2007 23:54:23 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200A0DC6KY500@brm-avmta-1.central.sun.com>; Wed, 17 Oct 2007 09:54:20 -0600 (MDT) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ200960C6IQ010@brm-avmta-1.central.sun.com>; Wed, 17 Oct 2007 09:54:19 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HFsIwF010043; Wed, 17 Oct 2007 15:54:18 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200101BJY7000@fe-emea-10.sun.com> (original mail from Paul.Jakma@Sun.COM); Wed, 17 Oct 2007 16:54:18 +0100 (BST) Received: from [81.168.24.40] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ200MM8C66QG20@fe-emea-10.sun.com>; Wed, 17 Oct 2007 16:54:07 +0100 (BST) Date: Wed, 17 Oct 2007 16:53:59 +0100 (BST) From: Paul Jakma Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <20071017154427.GD29257@Sun.COM> Sender: Paul.Jakma@sun.com To: Nicolas Williams Cc: Bill Sommerfeld , James Carlson , gdamore@sun.com, PSARC-ext@sun.com, David Chieu , Vincent Wang , Mark Logan Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <20071017154427.GD29257@Sun.COM> Status: RO Content-Length: 362 On Wed, 17 Oct 2007, Nicolas Williams wrote: > My impression was that the AMT chip gets its own IPv4 address. I'd be curious if the MAC address is still shared for this case or not though. regards, -- Paul Jakma, Solaris Networking Sun Microsystems, Scotland http://opensolaris.org/os/project/quagga tel: EMEA x73150 / +44 15066 73150 From gdamore@sun.com Wed Oct 17 09:01:29 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HG1TJH009806 for ; Wed, 17 Oct 2007 09:01:29 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HFw2p0045462; Wed, 17 Oct 2007 09:58:07 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ20060DCCUPK00@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 08:58:06 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2004QLCCTVI20@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 08:58:05 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HFw5AU017736; Wed, 17 Oct 2007 08:58:05 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200K01C6LJO00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Wed, 17 Oct 2007 08:58:05 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ200GXBCCN2I80@fe-sfbay-09.sun.com>; Wed, 17 Oct 2007 08:57:59 -0700 (PDT) Date: Wed, 17 Oct 2007 08:55:14 -0700 From: "Garrett D'Amore" Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <1192634666.3938.66.camel@localhost> Sender: Garrett.Damore@sun.com To: Bill Sommerfeld Cc: Paul Jakma , James Carlson , PSARC-ext@sun.com, David Chieu , Vincent Wang , Mark Logan Message-id: <47163062.3030304@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 958 Bill Sommerfeld wrote: > On Wed, 2007-10-17 at 16:07 +0100, Paul Jakma wrote: > >> Firmware 'near' the NIC (I've never seen an explanation of the exact >> mechanism) interposes itself between hardware and OS and 'hijacks' >> traffic to that port. It never makes it to the OS. >> > > one implication of this is that, when this is in use, the NIC cannot be > part of a L2 aggregation (because the upstream switch will load-spread > some of the management traffic flows to other ports in the aggregation). > > And using it with other L2/L3 redundancy technologies (such as IPMP and > OSPF-MP) is going to be tricky (the shared management IP address must > not be seen as reachable via other NICs). > Not if both ports are managed by the same technology. For Intel motherboards that have multiple NICs, this *may* be the case. (I'm not sure.) It would preclude mixing and matching add-in NICs though. -- Garrett > - Bill > > > From Nicolas.Williams@sun.com Wed Oct 17 09:01:36 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HG1adV009822 for ; Wed, 17 Oct 2007 09:01:36 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HFw2pb045462; Wed, 17 Oct 2007 09:58:10 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200609CCXPR00@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 08:58:09 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2004QRCCXVI20@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 08:58:09 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9HFw5BB002470; Wed, 17 Oct 2007 10:58:05 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9HFw4O6002469; Wed, 17 Oct 2007 10:58:04 -0500 (CDT) Date: Wed, 17 Oct 2007 10:58:04 -0500 From: Nicolas Williams Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <47162DBD.9050007@sun.com> To: Vincent Wang Cc: James Carlson , David Chieu , Mark Logan , daleg@elemental.org, gdamore@sun.com, PSARC-ext@sun.com Message-id: <20071017155804.GE29257@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <47162DBD.9050007@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 971 On Wed, Oct 17, 2007 at 11:43:57PM +0800, Vincent Wang wrote: > James Carlson wrote: > >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. Intel's design might be relevant to whether or not the service must be off by default, therefore it's relevant, though only in a tangential way (since there is nothing the ARC could do about the protocol if it didn't like it). > >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. I think that's correct. But the port number and SOAP interfaces still need to be listed as a Volatile interface. (Not an ARC member.) Nico -- From Paul.Jakma@sun.com Wed Oct 17 09:02:43 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HG2hgD009984 for ; Wed, 17 Oct 2007 09:02:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HFxL89023484; Wed, 17 Oct 2007 08:59:21 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ20060ZCEXR000@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 08:59:21 -0700 (PDT) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2004TZCEUVI20@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 08:59:19 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HFxIGE010544; Wed, 17 Oct 2007 15:59:18 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200101BJY7000@fe-emea-10.sun.com> (original mail from Paul.Jakma@Sun.COM); Wed, 17 Oct 2007 16:59:18 +0100 (BST) Received: from [81.168.24.40] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ200MN2CEIQG20@fe-emea-10.sun.com>; Wed, 17 Oct 2007 16:59:08 +0100 (BST) Date: Wed, 17 Oct 2007 16:59:05 +0100 (BST) From: Paul Jakma Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <1192634666.3938.66.camel@localhost> Sender: Paul.Jakma@sun.com To: Bill Sommerfeld Cc: James Carlson , gdamore@sun.com, PSARC-ext@sun.com, David Chieu , Vincent Wang , Mark Logan Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> Status: RO Content-Length: 924 On Wed, 17 Oct 2007, Bill Sommerfeld wrote: > one implication of this is that, when this is in use, the NIC cannot be > part of a L2 aggregation (because the upstream switch will load-spread > some of the management traffic flows to other ports in the aggregation). > > And using it with other L2/L3 redundancy technologies (such as IPMP and > OSPF-MP) is going to be tricky (the shared management IP address must > not be seen as reachable via other NICs). IMLU: These don't preclude use of AMT in normal operation - the OS can always redirect packets to AMT that didn't get hijacked. Does obviously preclude reliable Out-of-Band use of AMT. Indeed, I really wonder how the LOM firmware can know whether or not it needs to do ARP for a shared IP. regards, -- Paul Jakma, Solaris Networking Sun Microsystems, Scotland http://opensolaris.org/os/project/quagga tel: EMEA x73150 / +44 15066 73150 From gdamore@sun.com Wed Oct 17 09:03:43 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HG3gAw010002 for ; Wed, 17 Oct 2007 09:03:43 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HG027n029034 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Oct 2007 00:00:19 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ20033KCGJF600@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 09:00:19 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ20041VCGIBYE0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 09:00:18 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HG0ILd017979 for ; Wed, 17 Oct 2007 09:00:18 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200F01CCKJH00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 09:00:18 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ200807CFZ7Q40@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 08:59:59 -0700 (PDT) Date: Wed, 17 Oct 2007 08:57:15 -0700 From: "Garrett D'Amore" Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: Sender: Garrett.Damore@sun.com To: Paul Jakma Cc: Vincent Wang , David Chieu , James Carlson , Mark Logan , daleg@elemental.org, PSARC-ext@sun.com Message-id: <471630DB.6020604@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 1267 Paul Jakma wrote: > On Wed, 17 Oct 2007, Paul Jakma wrote: > >> Firmware 'near' the NIC (I've never seen an explanation of the exact >> mechanism) interposes itself between hardware and OS and 'hijacks' >> traffic to that port. It never makes it to the OS. > > Ah, googling suggests that when this "Not quite a NIC" has this > management-port-hijack feature enabled, that it would limit the NIC to > 100Mb/s mode (due to firmware implementation not supporting GigE > somehow). I think this is only true when the host operating system is not running. If the host OS is running, then gigabit should be fine. > > Is this performance limitation still present? See above. > > Another question I would have: If the management-hijack is active and > the OS requests promiscious receive, does the OS get the > management-port traffic? I.e. I suspect this feature *must* either > break AMT or else network-observability through promiscious-mode > operation, is this the case? If not, I'd be curious as to how it's done. I'm not sure (not on the project team), but as this was asked from Intel at their AMT presentation at the Intel Developer Forum, I believe the answer is that the host doesn't receive these packets, even in promiscuous mode. - -Garrett From carlsonj@phorcys.east.sun.com Wed Oct 17 09:04:36 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HG4axx010020 for ; Wed, 17 Oct 2007 09:04:36 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HG17in009264; Wed, 17 Oct 2007 09:01:09 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ20031FCHWHK00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Oct 2007 09:01:08 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2004LUCHUBRE0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Oct 2007 09:01:06 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9HG0i0P026535; Wed, 17 Oct 2007 12:00:44 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9HG0ic5026532; Wed, 17 Oct 2007 12:00:44 -0400 (EDT) Date: Wed, 17 Oct 2007 12:00:44 -0400 From: James Carlson Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: To: Paul Jakma Cc: Nicolas Williams , Bill Sommerfeld , gdamore@sun.com, PSARC-ext@sun.com, Mark Logan , David Chieu , Vincent Wang Message-id: <18198.12716.591499.622266@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <20071017154427.GD29257@Sun.COM> Status: RO Content-Length: 1037 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. The issue here isn't with what Intel does or doesn't do. It's with how the project integrates into Solaris, which is something that's entirely under this project team's control. -- James Carlson, Solaris Networking 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 From Mark.Logan@sun.com Wed Oct 17 09:07:51 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HG7oJO010064 for ; Wed, 17 Oct 2007 09:07:51 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HG4RfB024445; Wed, 17 Oct 2007 17:04:28 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ20070LCNF2000@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 09:04:27 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2004N8CNEVC30@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 09:04:26 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HG4QDW018613; Wed, 17 Oct 2007 09:04:26 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200K01C6LJO00@fe-sfbay-09.sun.com> (original mail from Mark.Logan@Sun.COM); Wed, 17 Oct 2007 09:04:26 -0700 (PDT) Received: from [192.168.1.45] ([71.118.30.33]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ2001Y1CN6UJG0@fe-sfbay-09.sun.com>; Wed, 17 Oct 2007 09:04:18 -0700 (PDT) Date: Wed, 17 Oct 2007 09:04:17 -0700 From: Mark Logan Subject: Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <1192578246.1887.28.camel@thunk> Sender: Mark.Logan@sun.com To: Bill Sommerfeld Cc: Dale Ghent , PSARC-ext@sun.com, Vincent.Wang@sun.com, "Garrett D'Amore" , David Chieu Message-id: <47163281.60905@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_gyb84vy/qpzeM5usKk0P4w)" X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <4715288A.9050005@sun.com> <47153488.1090101@sun.com> <087ED362-A78A-471A-B088-6EF6779C8574@elemental.org> <47154598.8030201@sun.com> <1192578246.1887.28.camel@thunk> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) Status: RO Content-Length: 4794 This is a multi-part message in MIME format. --Boundary_(ID_gyb84vy/qpzeM5usKk0P4w) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi Bill, I wrote this before I saw all the discussions that went on this morning. I read a few and I am afraid to read any more right now. I hope this is still relevant because I believe that it will help clear up any confusion. First I want to make it clear that the entity to which you are authenticating is the AMT firmware, not LMS. The AMT firmware is also called the Management Engine and it is like a low-cost, mini service processor that shares the machine's single network interface. The AMT firmware contains all the authentication code and the web server. If you were to breach the AMT firmware's security, you would be gaining access to the AMT firmware, not to Solaris. The LMS daemon and the HECI driver do no interpetation of the data, they just pass the requests down to the firmware and the responses back up. The purpose of LMS and HECI is to provide a pathway for applications running on the local machine to talk to the AMT firmware. Applications running on other machines on the network can also talk to the AMT firmware, but they do not go through LMS and HECI. A complete description of the AMT firmware's access control models can be found in the last section of this page: http://softwarecommunity.intel.com/articles/eng/1004.htm Mark Bill Sommerfeld wrote: > On Tue, 2007-10-16 at 16:13 -0700, Mark Logan wrote: > >> You are right. LMS requires HTTP digest access authentication. >> > > Mark, > > 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? > > Getting fragments of the spec, one line per message isn't working. > > - Bill > > > > > --Boundary_(ID_gyb84vy/qpzeM5usKk0P4w) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi Bill,

I wrote this before I saw all the discussions that went on this morning.  I read a few and I am afraid to read any more right now.  I hope this is still relevant because I believe that it will help clear up any confusion.

First I want to make it clear that the entity to which you are authenticating is the AMT firmware, not LMS.  The AMT firmware is also called the Management Engine and it is like a low-cost, mini service processor that shares the machine's single network interface.  The AMT firmware contains all the authentication code and the web server.

If you were to breach the AMT firmware's security, you would be gaining access to the AMT firmware, not to Solaris.

The LMS daemon and the HECI driver do no interpetation of the data, they just pass the requests down to the firmware and the responses back up.  The purpose of LMS and HECI is to provide a pathway for applications running on the local machine to talk to the AMT firmware.  Applications running on other machines on the network can also talk to the AMT firmware, but they do not go through LMS and HECI.

A complete description of the AMT firmware's access control models can be found in the last section of this page: http://softwarecommunity.intel.com/articles/eng/1004.htm

Mark


Bill Sommerfeld wrote: 
On Tue, 2007-10-16 at 16:13 -0700, Mark Logan wrote:
  
You are right.  LMS requires HTTP digest access authentication.
    

Mark,

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?

Getting fragments of the spec, one line per message isn't working.

					- Bill

--Boundary_(ID_gyb84vy/qpzeM5usKk0P4w)-- From gdamore@sun.com Wed Oct 17 09:10:16 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HGAGIa010203 for ; Wed, 17 Oct 2007 09:10:16 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HG6sws025836; Wed, 17 Oct 2007 09:06:54 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200701CRH7C00@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 09:06:53 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2004DTCRGVL30@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 09:06:52 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HG6qiq018929; Wed, 17 Oct 2007 09:06:52 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200F01CCKJH00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) ; Wed, 17 Oct 2007 09:06:52 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ2008SPCRA7Q70@fe-sfbay-10.sun.com>; Wed, 17 Oct 2007 09:06:52 -0700 (PDT) Date: Wed, 17 Oct 2007 09:04:02 -0700 From: "Garrett D'Amore" Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <20071017154427.GD29257@Sun.COM> Sender: Garrett.Damore@sun.com To: Nicolas Williams Cc: Bill Sommerfeld , Paul Jakma , James Carlson , PSARC-ext@sun.com, David Chieu , Vincent Wang , Mark Logan Message-id: <47163272.5060609@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <20071017154427.GD29257@Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 1678 Nicolas Williams wrote: > On Wed, Oct 17, 2007 at 11:24:26AM -0400, Bill Sommerfeld wrote: > >> On Wed, 2007-10-17 at 16:07 +0100, Paul Jakma wrote: >> >>> Firmware 'near' the NIC (I've never seen an explanation of the exact >>> mechanism) interposes itself between hardware and OS and 'hijacks' >>> traffic to that port. It never makes it to the OS. >>> >> one implication of this is that, when this is in use, the NIC cannot be >> part of a L2 aggregation (because the upstream switch will load-spread >> some of the management traffic flows to other ports in the aggregation). >> >> And using it with other L2/L3 redundancy technologies (such as IPMP and >> OSPF-MP) is going to be tricky (the shared management IP address must >> not be seen as reachable via other NICs). >> > > My impression was that the AMT chip gets its own IPv4 address. > That is an option. But it is not the default configuration. In the default configuration, both the host and the embedded environment use the same MAC address, using DHCP, and thus share an IP address. If static IP addressing is used, then the embedded environment can be assigned its own MAC address, and its own IP address. This is only true if the NIC is the onboard wired NIC. For WiFi, I believe that only a shared MAC address configuration is possible. (And only a small number of configurations have the WiFi support using only Intel WiFi cards, of course.) And yes, I do realize that it should have been possible to assign two MAC addresses and let each do DHCP on its own behalf. However, for reasons I don't understand, this is not the design choice that Intel took. -- Garrett From gdamore@sun.com Wed Oct 17 09:11:01 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HGB0DT010221 for ; Wed, 17 Oct 2007 09:11:01 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HG7Qkg002501; Thu, 18 Oct 2007 00:07:38 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200B0HCSOSO00@brm-avmta-1.central.sun.com>; Wed, 17 Oct 2007 10:07:36 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2009SYCSNPV10@brm-avmta-1.central.sun.com>; Wed, 17 Oct 2007 10:07:35 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HG7Zd0019056; Wed, 17 Oct 2007 09:07:35 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200F01CQYP600@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Wed, 17 Oct 2007 09:07:35 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ200GVJCSH2IB0@fe-sfbay-09.sun.com>; Wed, 17 Oct 2007 09:07:34 -0700 (PDT) Date: Wed, 17 Oct 2007 09:04:45 -0700 From: "Garrett D'Amore" Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: Sender: Garrett.Damore@sun.com To: Paul Jakma Cc: Nicolas Williams , Bill Sommerfeld , James Carlson , PSARC-ext@sun.com, David Chieu , Vincent Wang , Mark Logan Message-id: <4716329D.8060501@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <20071017154427.GD29257@Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 364 Paul Jakma wrote: > On Wed, 17 Oct 2007, Nicolas Williams wrote: > >> My impression was that the AMT chip gets its own IPv4 address. > > I'd be curious if the MAC address is still shared for this case or not > though. > > regards, No, in that config they have separate MAC addresses. And this option is only available with wired ethernet, not wifi. -- Garrett From gdamore@sun.com Wed Oct 17 09:12:44 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HGCgpF010258 for ; Wed, 17 Oct 2007 09:12:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HG9Aad002956; Thu, 18 Oct 2007 00:09:20 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200703CVIAH00@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 09:09:18 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2004MFCVIVI30@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 09:09:18 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HG9IxU029110; Wed, 17 Oct 2007 09:09:18 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200601CT46900@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) ; Wed, 17 Oct 2007 09:09:18 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ2008YMCVC7Q80@fe-sfbay-10.sun.com>; Wed, 17 Oct 2007 09:09:15 -0700 (PDT) Date: Wed, 17 Oct 2007 09:06:28 -0700 From: "Garrett D'Amore" Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: Sender: Garrett.Damore@sun.com To: Paul Jakma Cc: Bill Sommerfeld , James Carlson , PSARC-ext@sun.com, David Chieu , Vincent Wang , Mark Logan Message-id: <47163304.3010403@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 996 Paul Jakma wrote: > On Wed, 17 Oct 2007, Bill Sommerfeld wrote: > >> one implication of this is that, when this is in use, the NIC cannot be >> part of a L2 aggregation (because the upstream switch will load-spread >> some of the management traffic flows to other ports in the aggregation). >> >> And using it with other L2/L3 redundancy technologies (such as IPMP and >> OSPF-MP) is going to be tricky (the shared management IP address must >> not be seen as reachable via other NICs). > > IMLU: These don't preclude use of AMT in normal operation - the OS can > always redirect packets to AMT that didn't get hijacked. > > Does obviously preclude reliable Out-of-Band use of AMT. Indeed, I > really wonder how the LOM firmware can know whether or not it needs to > do ARP for a shared IP. There is a private method by which the firmware decides whether the host OS is alive and healthy. If so, then the host does this work. If not, then the firmware takes over. -- Garrett > > regards, From Vincent.Wang@Sun.COM Wed Oct 17 09:22:25 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HGMP9R010422 for ; Wed, 17 Oct 2007 09:22:25 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HGJ3sR052867 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Oct 2007 10:19:03 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200C01DBQM100@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 10:19:02 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2009JDDBNPV20@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 10:19:00 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9HGIwVv019402 for ; Wed, 17 Oct 2007 16:18:58 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JQ200C01D3UVV00@mail-apac.sun.com> (original mail from Vincent.Wang@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Oct 2007 00:18:58 +0800 (SGT) Received: from [61.51.83.61] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JQ2002DBDBHS60Z@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 18 Oct 2007 00:18:58 +0800 (SGT) Date: Thu, 18 Oct 2007 00:22:41 +0800 From: Vincent Wang Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: Sender: Vincent.Wang@Sun.COM To: Paul Jakma Cc: David Chieu , James Carlson , Mark Logan , daleg@elemental.org, gdamore@Sun.COM, PSARC-ext@Sun.COM Message-id: <471636D1.7080109@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 Status: RO Content-Length: 1049 Paul Jakma wrote: > On Wed, 17 Oct 2007, Paul Jakma wrote: > >> Firmware 'near' the NIC (I've never seen an explanation of the exact >> mechanism) interposes itself between hardware and OS and 'hijacks' >> traffic to that port. It never makes it to the OS. > > > Ah, googling suggests that when this "Not quite a NIC" has this > management-port-hijack feature enabled, that it would limit the NIC to > 100Mb/s mode (due to firmware implementation not supporting GigE > somehow). > > Is this performance limitation still present? > Not known to me on the latest Weybridge beta platform. > Another question I would have: If the management-hijack is active and > the OS requests promiscious receive, does the OS get the > management-port traffic? I.e. I suspect this feature *must* either > break AMT or else network-observability through promiscious-mode > operation, is this the case? If not, I'd be curious as to how it's done. > No. Even in promiscuous mode the host OS does not receive AMT packets. Don't know how it's done. Vincent. From Paul.Jakma@sun.com Wed Oct 17 09:27:12 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HGRBXf010819 for ; Wed, 17 Oct 2007 09:27:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HGNYdE003552 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Oct 2007 17:23:49 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200C0TDJNVY00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 10:23:47 -0600 (MDT) Received: from gmp-eb-mail-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2009O7DJMQ720@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 10:23:46 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HGNjX0009244 for ; Wed, 17 Oct 2007 16:23:45 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200B01D70DR00@fe-emea-10.sun.com> (original mail from Paul.Jakma@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 17:23:45 +0100 (BST) Received: from [81.168.24.40] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ200MQEDJKQG20@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 17:23:45 +0100 (BST) Date: Wed, 17 Oct 2007 17:23:42 +0100 (BST) From: Paul Jakma Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <471630DB.6020604@sun.com> Sender: Paul.Jakma@sun.com To: "Garrett D'Amore" Cc: Vincent Wang , David Chieu , James Carlson , Mark Logan , daleg@elemental.org, PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <471630DB.6020604@sun.com> Status: RO Content-Length: 641 On Wed, 17 Oct 2007, Garrett D'Amore wrote: > I think this is only true when the host operating system is not running. If > the host OS is running, then gigabit should be fine. So what happens when the host OS stops running suddenly (crash or hardware fault)? Further, it seems the host OS needs to re-enable the ARP intercept in the NIC hardware on shutdown. I'm very curious if that means a sudden host stop will render the AMT LOM inaccessible in short order.. regards, -- Paul Jakma, Solaris Networking Sun Microsystems, Scotland http://opensolaris.org/os/project/quagga tel: EMEA x73150 / +44 15066 73150 From gdamore@sun.com Wed Oct 17 09:38:51 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HGco0h010990 for ; Wed, 17 Oct 2007 09:38:50 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HGYgxk014012; Thu, 18 Oct 2007 00:35:27 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ20060JE2ZMM00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Oct 2007 09:35:23 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2004TDE2Q20D0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Oct 2007 09:35:14 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HGZElj002547; Wed, 17 Oct 2007 09:35:14 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200501DXS0C00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Wed, 17 Oct 2007 09:35:14 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ2006QXE2FRH70@fe-sfbay-09.sun.com>; Wed, 17 Oct 2007 09:35:14 -0700 (PDT) Date: Wed, 17 Oct 2007 09:32:19 -0700 From: "Garrett D'Amore" Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <18198.12716.591499.622266@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: James Carlson Cc: Paul Jakma , Nicolas Williams , Bill Sommerfeld , psarc-ext@sun.com, Mark Logan , David Chieu , Vincent Wang Message-id: <47163913.3050400@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <20071017154427.GD29257@Sun.COM> <18198.12716.591499.622266@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 4355 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 From gdamore@sun.com Wed Oct 17 09:43:22 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HGhM7Q011236 for ; Wed, 17 Oct 2007 09:43:22 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HGe0K6059648 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Oct 2007 10:40:00 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200D05EANTZ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 17 Oct 2007 10:39:59 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2009V2EALQ630@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 17 Oct 2007 10:39:57 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HGdvbO023201 for ; Wed, 17 Oct 2007 09:39:57 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200301E7UA000@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 17 Oct 2007 09:39:57 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ200JXIEAH8R60@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 17 Oct 2007 09:39:54 -0700 (PDT) Date: Wed, 17 Oct 2007 09:37:09 -0700 From: "Garrett D'Amore" Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: Sender: Garrett.Damore@sun.com To: Paul Jakma Cc: Vincent Wang , David Chieu , James Carlson , Mark Logan , daleg@elemental.org, psarc-ext@sun.com Message-id: <47163A35.20701@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <471630DB.6020604@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 1224 Paul Jakma wrote: > On Wed, 17 Oct 2007, Garrett D'Amore wrote: > >> I think this is only true when the host operating system is not >> running. If the host OS is running, then gigabit should be fine. > > So what happens when the host OS stops running suddenly (crash or > hardware fault)? The AMT firmware is supposed to figure this out. I think the NIC drops down to 100Mbps mode. I'm not sure exactly how this monitoring is done. I imagine there is a watchdog register that is tickled or somesuch. > > Further, it seems the host OS needs to re-enable the ARP intercept in > the NIC hardware on shutdown. I'm very curious if that means a sudden > host stop will render the AMT LOM inaccessible in short order.. No, AMT is precisely designed the way it is to deal with this case. If you crash your operating system, within a second or two (or thereabouts) AMT figures out that the host is out to lunch, and the ME takes over. In case anyone is curious, the ME/AMT environment is really like an embedded service processor, and as such, traffic to it is probably not terribly common. It has a serial port/console shunt, and also provides some other features like remote host reset capability, etc. -- Garrett From Paul.Jakma@sun.com Wed Oct 17 09:50:26 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HGoQ39011541 for ; Wed, 17 Oct 2007 09:50:26 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HGl33n010383 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Oct 2007 09:47:04 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ20092LEMF8300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 09:47:03 -0700 (PDT) Received: from gmp-eb-mail-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2004OWEMFVB50@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 09:47:03 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HGl20U010965 for ; Wed, 17 Oct 2007 16:47:02 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200601EGDRS00@fe-emea-09.sun.com> (original mail from Paul.Jakma@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 17:47:02 +0100 (BST) Received: from [81.168.24.40] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ2005ZGEMC7P20@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 17:47:01 +0100 (BST) Date: Wed, 17 Oct 2007 17:46:55 +0100 (BST) From: Paul Jakma Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <47163A35.20701@sun.com> Sender: Paul.Jakma@sun.com To: "Garrett D'Amore" Cc: Vincent Wang , David Chieu , James Carlson , Mark Logan , daleg@elemental.org, PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <471630DB.6020604@sun.com> <47163A35.20701@sun.com> Status: RO Content-Length: 600 On Wed, 17 Oct 2007, Garrett D'Amore wrote: > The AMT firmware is supposed to figure this out. I think the NIC drops > down to 100Mbps mode. So dont lock the switch port to 1Gb/s. > No, AMT is precisely designed the way it is to deal with this case. If you > crash your operating system, within a second or two (or thereabouts) AMT > figures out that the host is out to lunch, and the ME takes over. Ok, that's reassuring. regards, -- Paul Jakma, Solaris Networking Sun Microsystems, Scotland http://opensolaris.org/os/project/quagga tel: EMEA x73150 / +44 15066 73150 From Mark.Carlson@sun.com Wed Oct 17 09:50:38 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HGoaiN011557 for ; Wed, 17 Oct 2007 09:50:37 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HGl97X019903; Thu, 18 Oct 2007 00:47:14 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ20090XEMO8C00@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 09:47:12 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2004BPEMOVL60@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 09:47:12 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9HGlBMI024571; Wed, 17 Oct 2007 16:47:11 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200I01DC3PC00@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM); Wed, 17 Oct 2007 10:47:11 -0600 (MDT) Received: from MACsMAC.local ([12.96.171.10]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ200E1NEMGUE40@mail-amer.sun.com>; Wed, 17 Oct 2007 10:47:07 -0600 (MDT) Date: Wed, 17 Oct 2007 10:47:02 -0600 From: "Mark A. Carlson" Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <47163913.3050400@sun.com> Sender: Mark.Carlson@sun.com To: "Garrett D'Amore" Cc: James Carlson , Bill Sommerfeld , psarc-ext@sun.com, Mark Logan , David Chieu , Paul Jakma , Vincent Wang Message-id: <47163C86.7030903@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <20071017154427.GD29257@Sun.COM> <18198.12716.591499.622266@gargle.gargle.HOWL> <47163913.3050400@sun.com> User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) Status: RO Content-Length: 531 Garrett D'Amore wrote: > > ... > > 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.) Is this case exporting the WS-Management capability? Wouldn't we want external third party management application to be able to use that? -- mark From carlsonj@phorcys.east.sun.com Wed Oct 17 09:53:39 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HGrcax011596 for ; Wed, 17 Oct 2007 09:53:38 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HGns2Q016388; Wed, 17 Oct 2007 17:50:09 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ20090LERLED00@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 09:50:09 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2004YOERJVB50@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 09:50:08 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9HGnkl7026821; Wed, 17 Oct 2007 12:49:46 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9HGnkHt026818; Wed, 17 Oct 2007 12:49:46 -0400 (EDT) Date: Wed, 17 Oct 2007 12:49:46 -0400 From: James Carlson Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <47163913.3050400@sun.com> To: "Garrett D'Amore" Cc: Paul Jakma , Nicolas Williams , Bill Sommerfeld , PSARC-ext@sun.com, Mark Logan , David Chieu , Vincent Wang Message-id: <18198.15658.549413.862427@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <20071017154427.GD29257@Sun.COM> <18198.12716.591499.622266@gargle.gargle.HOWL> <47163913.3050400@sun.com> Status: RO Content-Length: 3648 Garrett D'Amore writes: > James Carlson wrote: > > 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), OK; "off by default" was one of the missing bits. > Assignment of addresses, and whether to share IP addresses or not (by > default it does share!) is done using BIOS configuration screens typically. I'd like to understand that better. Solaris can have multiple IP addresses on a single interface, and can use VLANs and other virtualization techniques, as well as IP address configuration that comes by way of DHCP and other mechanisms. How does this device know which address to use? As for my comment above, the fact that this device pulls packets out of band means that configured Solaris IP Filter policies are bypassed: if you set the system up to filter out particular hosts, that policy will _NOT_ work for the AMT. That's a surprising result, at least to me. The system will just ignore those filters. All of this also begs a question about what the loopback proxy is for ... > 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. Sure. I figured they were actually "Committed Private" for Intel -- as they'd have to be in some format that can deal with upgrade issues. I wasn't so concerned with that. I was more concerned with the security mechanism. > * 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.) Agreed. > - 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.) Projects that don't interoperate correctly or that are incompatible with each other _are_ important architectural details and are also things that we (as a system vendor) have to document for users. I doubt this will work right with TX labeled packets, so that's probably off the table. I see no mention of IPv6, so perhaps that's off as well. IP Filter and IPsec policies are ignored for the AMT traffic because there's no way for the host to implement them. The same goes for NAT and port redirection. Solaris port aggregation and can't work for similar reasons. IPMP _might_ not work right. If the address used by the AMT is marked "nofailover" rather than being a normal data address we might be able to get away with it. It's unclear. I have no idea if Solaris VLAN support is affected. Nor do I know what happens to a project that introduces an 802.1X authenticator -- likely, the port security switch is ineffective because that'd also be in Solaris software. > 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. All I'm interested in are the details. -- James Carlson, Solaris Networking 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 From gdamore@sun.com Wed Oct 17 09:53:56 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HGrudQ011612 for ; Wed, 17 Oct 2007 09:53:56 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HGoYHX026560; Wed, 17 Oct 2007 09:50:34 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ20080DES86B00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Oct 2007 09:50:32 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ20069RES8WF10@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Oct 2007 09:50:32 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HGoWai004811; Wed, 17 Oct 2007 09:50:32 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200301E7UA000@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) ; Wed, 17 Oct 2007 09:50:32 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ200JPPES48RC0@fe-sfbay-10.sun.com>; Wed, 17 Oct 2007 09:50:29 -0700 (PDT) Date: Wed, 17 Oct 2007 09:47:44 -0700 From: "Garrett D'Amore" Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <47163C86.7030903@sun.com> Sender: Garrett.Damore@sun.com To: "Mark A. Carlson" Cc: James Carlson , Bill Sommerfeld , psarc-ext@sun.com, Mark Logan , David Chieu , Paul Jakma , Vincent Wang Message-id: <47163CB0.6030001@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <20071017154427.GD29257@Sun.COM> <18198.12716.591499.622266@gargle.gargle.HOWL> <47163913.3050400@sun.com> <47163C86.7030903@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 650 Mark A. Carlson wrote: > > > Garrett D'Amore wrote: >> >> ... >> >> 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.) > Is this case exporting the WS-Management capability? > > Wouldn't we want external third party management application to be > able to use that? This case is not doing that, but the AMT firmware does. -- Garrett > > -- mark From Nicolas.Williams@sun.com Wed Oct 17 09:56:15 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HGuFrb011965 for ; Wed, 17 Oct 2007 09:56:15 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HGqm9G012371; Wed, 17 Oct 2007 09:52:48 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200E07EW0OB00@brm-avmta-1.central.sun.com>; Wed, 17 Oct 2007 10:52:48 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2009BSEVXQ740@brm-avmta-1.central.sun.com>; Wed, 17 Oct 2007 10:52:46 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9HGqjk5002506; Wed, 17 Oct 2007 11:52:45 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9HGqjSm002505; Wed, 17 Oct 2007 11:52:45 -0500 (CDT) Date: Wed, 17 Oct 2007 11:52:45 -0500 From: Nicolas Williams Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <20071017154427.GD29257@Sun.COM> To: Bill Sommerfeld Cc: Paul Jakma , James Carlson , gdamore@sun.com, PSARC-ext@sun.com, David Chieu , Vincent Wang , Mark Logan Message-id: <20071017165244.GG29257@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <20071017154427.GD29257@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2596 On Wed, Oct 17, 2007 at 10:44:27AM -0500, Nicolas Williams wrote: > On Wed, Oct 17, 2007 at 11:24:26AM -0400, Bill Sommerfeld wrote: > > On Wed, 2007-10-17 at 16:07 +0100, Paul Jakma wrote: > > > Firmware 'near' the NIC (I've never seen an explanation of the exact > > > mechanism) interposes itself between hardware and OS and 'hijacks' > > > traffic to that port. It never makes it to the OS. > > > > one implication of this is that, when this is in use, the NIC cannot be > > part of a L2 aggregation (because the upstream switch will load-spread > > some of the management traffic flows to other ports in the aggregation). > > > > And using it with other L2/L3 redundancy technologies (such as IPMP and > > OSPF-MP) is going to be tricky (the shared management IP address must > > not be seen as reachable via other NICs). > > My impression was that the AMT chip gets its own IPv4 address. OK, looking at the deployment guide[0], pg. 7-8, there are two options: - static addressing The AMT gets its own IP address (it's implied that this is IPv4 only) and hostname, and the host OS must have a separate one. It's unclear from the deployment docs whether the host OS can use DHCP while the AMT address is statically configured. - dynamic addressing The AMT shares an addressed obtained via DHCP with the host OS. It's unclear from the deployment docs whether the host OS can virtualize the NIC. It is clear, however, that there's at least one configuration where the AMT and the host OS share an IP address, and another where they do not. Perhaps one of the white papers will answer some of the things that are not clear in the deployment guide. Features available through the AMT (deployment guide[0] pg. 9-10): - Asset information - Wake-up - Remote control operations (?) - apparently including firmware updates - and other things (including TLS trust anchors, server cert mgmt, etc...) - Serial over LAN and IDE redirection[1] (yes, as in disk I/O) - AMT user accounts and ACL management Authentication options apparently include DIGEST-MD5, Kerberos V, and TLS client certificates (that is, the management console can have a private key and a certificate that it uses to authenticate to the AMTs). I did not find details of how Kerberos V is used (it can be used badly). TLS PSK is apparently supported using a one-time key burned into the AMT. [0] http://download.intel.com/business/vpro/pdfs/deployment_guide.pdf [1] http://softwareblogs.intel.com/2007/03/06/experimenting-with-ide-redirect-over-the-internet/ Nico -- From gdamore@sun.com Wed Oct 17 09:57:04 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HGv4Qw011983 for ; Wed, 17 Oct 2007 09:57:04 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HGrg3N012481 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Oct 2007 09:53:42 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200E0LEXHQO00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 10:53:41 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2009OFEXFQ040@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 10:53:39 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HGrdVJ005254 for ; Wed, 17 Oct 2007 09:53:39 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200B01EUZ8600@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 09:53:38 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ2006GYEX7RHH0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 09:53:31 -0700 (PDT) Date: Wed, 17 Oct 2007 09:50:46 -0700 From: "Garrett D'Amore" Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: Sender: Garrett.Damore@sun.com To: Paul Jakma Cc: Vincent Wang , David Chieu , James Carlson , Mark Logan , daleg@elemental.org, PSARC-ext@sun.com Message-id: <47163D66.8010306@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <471630DB.6020604@sun.com> <47163A35.20701@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 648 Paul Jakma wrote: > On Wed, 17 Oct 2007, Garrett D'Amore wrote: > >> The AMT firmware is supposed to figure this out. I think the NIC >> drops down to 100Mbps mode. > > So dont lock the switch port to 1Gb/s. That's right. And I *think* the rationale for this is that the ME is *even* running when your system is mostly powered down. Think "hibernate" or "sleep". AMT allows an administrator to wake the system up remotely so that it can be patched, whatever. (Sort of like Wake-on-LAN, but different.) The idea is that 100Mbps requires far, far less power to keep alive and running than 1Gbps. So the ME only supports 100Mbps. -- Garrett From David.Chieu@sun.com Wed Oct 17 09:58:50 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HGwodv012003 for ; Wed, 17 Oct 2007 09:58:50 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HGtR8w028169 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Oct 2007 09:55:28 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200E0VF0EVB00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 10:55:26 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2009VPF0DQ240@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 10:55:25 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HGtP8r025291 for ; Wed, 17 Oct 2007 09:55:25 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200001ETDAG00@fe-sfbay-10.sun.com> (original mail from David.Chieu@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 09:55:25 -0700 (PDT) Received: from [192.168.1.102] ([76.170.66.246]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ200JHDF008RF0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 09:55:13 -0700 (PDT) Date: Wed, 17 Oct 2007 09:55:11 -0700 From: David Chieu Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <47163A35.20701@sun.com> Sender: David.Chieu@sun.com To: "Garrett D'Amore" Cc: Paul Jakma , Vincent Wang , James Carlson , Mark Logan , daleg@elemental.org, psarc-ext@sun.com Message-id: <47163E6F.6090501@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <471630DB.6020604@sun.com> <47163A35.20701@sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 Status: RO Content-Length: 1606 Garrett D'Amore wrote: > Paul Jakma wrote: > >> On Wed, 17 Oct 2007, Garrett D'Amore wrote: >> >>> I think this is only true when the host operating system is not >>> running. If the host OS is running, then gigabit should be fine. >> >> >> So what happens when the host OS stops running suddenly (crash or >> hardware fault)? > > > The AMT firmware is supposed to figure this out. I think the NIC drops > down to 100Mbps mode. I'm not sure exactly how this monitoring is > done. I imagine there is a watchdog register that is tickled or somesuch. There is a separate ARC processor at the North Bridge of the PC motherboard. This processor runs AMT which can act like a watchdog to monitor the host OS. >> >> Further, it seems the host OS needs to re-enable the ARP intercept in >> the NIC hardware on shutdown. I'm very curious if that means a sudden >> host stop will render the AMT LOM inaccessible in short order.. > > > No, AMT is precisely designed the way it is to deal with this case. If > you crash your operating system, within a second or two (or > thereabouts) AMT figures out that the host is out to lunch, and the ME > takes over. > > In case anyone is curious, the ME/AMT environment is really like an > embedded service processor, and as such, traffic to it is probably not > terribly common. It has a serial port/console shunt, and also provides > some other features like remote host reset capability, etc. > In addition, there is a non-volatile memory area, in case of host OS crash, "the last words" can be saved there for postmortem. -- David Chieu > -- Garrett > From Nicolas.Williams@sun.com Wed Oct 17 09:59:34 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HGxXoe012021 for ; Wed, 17 Oct 2007 09:59:33 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HGtkX1023964; Thu, 18 Oct 2007 00:56:03 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200E0NF1CWF00@brm-avmta-1.central.sun.com>; Wed, 17 Oct 2007 10:56:00 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2009B6F1AQ440@brm-avmta-1.central.sun.com>; Wed, 17 Oct 2007 10:55:58 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9HGtwpU002515; Wed, 17 Oct 2007 11:55:58 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9HGtwxY002514; Wed, 17 Oct 2007 11:55:58 -0500 (CDT) Date: Wed, 17 Oct 2007 11:55:58 -0500 From: Nicolas Williams Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <47163913.3050400@sun.com> To: "Garrett D'Amore" Cc: James Carlson , Paul Jakma , Bill Sommerfeld , PSARC-ext@sun.com, Mark Logan , David Chieu , Vincent Wang Message-id: <20071017165557.GH29257@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <20071017154427.GD29257@Sun.COM> <18198.12716.591499.622266@gargle.gargle.HOWL> <47163913.3050400@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 331 On Wed, Oct 17, 2007 at 09:32:19AM -0700, Garrett D'Amore wrote: > * secure-by-default. LMS needs to be off-by-default, as AMT is also > off-by-default. It could be on-by-default, and temporarily disable itself if the AMT if off. (If you want remote AMT access why not local access?) But off-by-default ought to be acceptable. From Paul.Jakma@sun.com Wed Oct 17 10:13:51 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HHDpWO012738 for ; Wed, 17 Oct 2007 10:13:51 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HHAStV005048; Wed, 17 Oct 2007 11:10:28 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200A0JFPF0X00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Oct 2007 10:10:27 -0700 (PDT) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2006T8FPEWH30@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Oct 2007 10:10:27 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HHAQRU015707; Wed, 17 Oct 2007 17:10:26 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200I01FGIKR00@fe-emea-10.sun.com> (original mail from Paul.Jakma@Sun.COM); Wed, 17 Oct 2007 18:10:26 +0100 (BST) Received: from [81.168.24.40] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ200MVOFPBQG20@fe-emea-10.sun.com>; Wed, 17 Oct 2007 18:10:25 +0100 (BST) Date: Wed, 17 Oct 2007 18:10:22 +0100 (BST) From: Paul Jakma Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <18198.15658.549413.862427@gargle.gargle.HOWL> Sender: Paul.Jakma@sun.com To: James Carlson Cc: "Garrett D'Amore" , Nicolas Williams , Bill Sommerfeld , PSARC-ext@sun.com, Mark Logan , David Chieu , Vincent Wang Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <20071017154427.GD29257@Sun.COM> <18198.12716.591499.622266@gargle.gargle.HOWL> <47163913.3050400@sun.com> <18198.15658.549413.862427@gargle.gargle.HOWL> Status: RO Content-Length: 495 On Wed, 17 Oct 2007, James Carlson wrote: > I doubt this will work right with TX labeled packets, so that's > probably off the table. I see no mention of IPv6, so perhaps that's > off as well. A skim of the docs for the hardware suggest it at least supports having an IPv6 address configured for the management redirect. regards, -- Paul Jakma, Solaris Networking Sun Microsystems, Scotland http://opensolaris.org/os/project/quagga tel: EMEA x73150 / +44 15066 73150 From randy.fishel@sun.com Wed Oct 17 10:19:29 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HHJSMw012806 for ; Wed, 17 Oct 2007 10:19:28 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HHG5sB007009; Wed, 17 Oct 2007 11:16:06 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200A3FFYSJL00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Oct 2007 10:16:04 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2006IRFYRWD30@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Oct 2007 10:16:04 -0700 (PDT) Received: from grimmy.eng.sun.com (grimmy.SFBay.Sun.COM [129.146.108.114]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l9HHG0ec025811; Wed, 17 Oct 2007 10:16:00 -0700 (PDT) Received: from grimmy.eng.sun.com (localhost [127.0.0.1]) by grimmy.eng.sun.com (8.12.10+Sun/8.12.10) with ESMTP id l9HHFgQt013808; Wed, 17 Oct 2007 10:15:42 -0700 (PDT) Received: from localhost (randyf@localhost) by grimmy.eng.sun.com (8.12.10+Sun/8.12.10/Submit) with ESMTP id l9HHFglL013804; Wed, 17 Oct 2007 10:15:42 -0700 (PDT) Date: Wed, 17 Oct 2007 10:15:42 -0700 (PDT) From: Randy Fishel Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <47163304.3010403@sun.com> X-X-Sender: randyf@grimmy To: "Garrett D'Amore" Cc: Paul Jakma , Bill Sommerfeld , James Carlson , PSARC-ext@sun.com, David Chieu , Vincent Wang , Mark Logan Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <47163304.3010403@sun.com> X-Authentication-warning: grimmy.eng.sun.com: randyf owned process doing -bs Status: RO Content-Length: 1547 On Wed, 17 Oct 2007, Garrett D'Amore wrote: > Paul Jakma wrote: > > On Wed, 17 Oct 2007, Bill Sommerfeld wrote: > > > > > one implication of this is that, when this is in use, the NIC cannot be > > > part of a L2 aggregation (because the upstream switch will load-spread > > > some of the management traffic flows to other ports in the aggregation). > > > > > > And using it with other L2/L3 redundancy technologies (such as IPMP and > > > OSPF-MP) is going to be tricky (the shared management IP address must > > > not be seen as reachable via other NICs). > > > > IMLU: These don't preclude use of AMT in normal operation - the OS can > > always redirect packets to AMT that didn't get hijacked. > > > > Does obviously preclude reliable Out-of-Band use of AMT. Indeed, I really > > wonder how the LOM firmware can know whether or not it needs to do ARP for a > > shared IP. > > There is a private method by which the firmware decides whether the host OS is > alive and healthy. If so, then the host does this work. If not, then the > firmware takes over. > I have been looking for a place to ask this quesiton, and this might be it: What occurs if the machine is suspended and the NIC is still hot (maybe WOL enabled). Will the ME also be running? If so, the OS is not, will it still know that OS is alive and healthy, or decide it is bad and try and reboot? Will it be able to generate a PME and resume? (and maybe a host of other questions surrounding suspended machines). ---- Randy > -- Garrett > > > > regards, > From David.Chieu@sun.com Wed Oct 17 10:22:09 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HHM8Te012864 for ; Wed, 17 Oct 2007 10:22:08 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HHIij4003692; Thu, 18 Oct 2007 01:18:45 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200B01G396M00@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 10:18:45 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2004ZRG38VC80@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 10:18:44 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HHIivF009092; Wed, 17 Oct 2007 10:18:44 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200K01C6LJO00@fe-sfbay-09.sun.com> (original mail from David.Chieu@Sun.COM); Wed, 17 Oct 2007 10:18:44 -0700 (PDT) Received: from [192.168.1.102] ([76.170.66.246]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ200C0MG35QWE0@fe-sfbay-09.sun.com>; Wed, 17 Oct 2007 10:18:42 -0700 (PDT) Date: Wed, 17 Oct 2007 10:18:41 -0700 From: David Chieu Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <20071017165557.GH29257@Sun.COM> Sender: David.Chieu@sun.com To: Nicolas Williams Cc: "Garrett D'Amore" , James Carlson , Paul Jakma , Bill Sommerfeld , PSARC-ext@sun.com, Mark Logan , Vincent Wang Message-id: <471643F1.4040602@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <20071017154427.GD29257@Sun.COM> <18198.12716.591499.622266@gargle.gargle.HOWL> <47163913.3050400@sun.com> <20071017165557.GH29257@Sun.COM> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 Status: RO Content-Length: 587 Nicolas Williams wrote: >On Wed, Oct 17, 2007 at 09:32:19AM -0700, Garrett D'Amore wrote: > > >>* secure-by-default. LMS needs to be off-by-default, as AMT is also >>off-by-default. >> >> > >It could be on-by-default, and temporarily disable itself if the AMT if >off. (If you want remote AMT access why not local access?) But >off-by-default ought to be acceptable. > > Most PCs that we've in the lab has AMT on-by-default from the BIOS setting. Some has only AMT2.0 / AMT3.0 options, so off-by-default may not always work from the hardware point of view. -- David Chieu From scott.rotondo@sun.com Wed Oct 17 10:34:30 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HHYTCs014054 for ; Wed, 17 Oct 2007 10:34:29 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HHUx2e009435 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 18 Oct 2007 01:31:06 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200C0JGNT8C00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 17 Oct 2007 10:31:05 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ20065NGNSWD50@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 17 Oct 2007 10:31:04 -0700 (PDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l9HHV2tS022424; Wed, 17 Oct 2007 10:31:02 -0700 (PDT) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id l9HHUxs19426; Wed, 17 Oct 2007 10:31:00 -0700 (PDT) Date: Wed, 17 Oct 2007 10:30:59 -0700 From: Scott Rotondo Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: To: psarc-ext@sun.com Cc: Vincent Wang , Mark Logan Message-id: <471646D3.5080308@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <47163304.3010403@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070814) Status: RO Content-Length: 240 The sheer volume of email and variety of questions suggests to me that this case long ago passed the "obviousness" threshold for a fast-track. I'm not a PSARC member, but if I were, I'd be asking for a full review at this point. Scott From gdamore@Sun.COM Wed Oct 17 10:34:55 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HHYsWR014072 for ; Wed, 17 Oct 2007 10:34:54 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HHVLQO004381; Wed, 17 Oct 2007 18:31:30 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200H3BGOHL300@brm-avmta-1.central.sun.com>; Wed, 17 Oct 2007 11:31:29 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2009Z9GODQ760@brm-avmta-1.central.sun.com>; Wed, 17 Oct 2007 11:31:25 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HHVPdZ010984; Wed, 17 Oct 2007 10:31:25 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ20030199KDD00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) ; Wed, 17 Oct 2007 10:31:25 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ2007MEGO85N10@fe-sfbay-10.sun.com>; Wed, 17 Oct 2007 10:31:20 -0700 (PDT) Date: Wed, 17 Oct 2007 10:28:36 -0700 From: "Garrett D'Amore" Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: Sender: Garrett.Damore@Sun.COM To: Randy Fishel Cc: Paul Jakma , Bill Sommerfeld , James Carlson , PSARC-ext@Sun.COM, David Chieu , Vincent Wang , Mark Logan Message-id: <47164644.4060309@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <47163304.3010403@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 1788 Randy Fishel wrote: > On Wed, 17 Oct 2007, Garrett D'Amore wrote: > > >> Paul Jakma wrote: >> >>> On Wed, 17 Oct 2007, Bill Sommerfeld wrote: >>> >>> >>>> one implication of this is that, when this is in use, the NIC cannot be >>>> part of a L2 aggregation (because the upstream switch will load-spread >>>> some of the management traffic flows to other ports in the aggregation). >>>> >>>> And using it with other L2/L3 redundancy technologies (such as IPMP and >>>> OSPF-MP) is going to be tricky (the shared management IP address must >>>> not be seen as reachable via other NICs). >>>> >>> IMLU: These don't preclude use of AMT in normal operation - the OS can >>> always redirect packets to AMT that didn't get hijacked. >>> >>> Does obviously preclude reliable Out-of-Band use of AMT. Indeed, I really >>> wonder how the LOM firmware can know whether or not it needs to do ARP for a >>> shared IP. >>> >> There is a private method by which the firmware decides whether the host OS is >> alive and healthy. If so, then the host does this work. If not, then the >> firmware takes over. >> >> > > I have been looking for a place to ask this quesiton, and this might > be it: What occurs if the machine is suspended and the NIC is still > hot (maybe WOL enabled). Will the ME also be running? Yes! > If so, the OS > is not, will it still know that OS is alive and healthy, or decide it > is bad and try and reboot? Neither. The firmware is running and one can remotely reboot it using a management tool, but on its own, the ME takes no action. > Will it be able to generate a PME and > resume? (and maybe a host of other questions surrounding suspended > machines). > No. This is not a general watchdog facility. -- Garrett From gdamore@sun.com Wed Oct 17 10:36:35 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HHaZeS014236 for ; Wed, 17 Oct 2007 10:36:35 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HHXCRN013065; Wed, 17 Oct 2007 11:33:13 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200C07GRDCQ00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Oct 2007 10:33:13 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ20067TGRCWA60@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Oct 2007 10:33:12 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HHXCHD000649; Wed, 17 Oct 2007 10:33:12 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200301G36TV00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Wed, 17 Oct 2007 10:33:12 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ200EIUGRAV940@fe-sfbay-09.sun.com>; Wed, 17 Oct 2007 10:33:11 -0700 (PDT) Date: Wed, 17 Oct 2007 10:30:26 -0700 From: "Garrett D'Amore" Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <471643F1.4040602@sun.com> Sender: Garrett.Damore@sun.com To: David Chieu Cc: Nicolas Williams , James Carlson , Paul Jakma , Bill Sommerfeld , psarc-ext@sun.com, Mark Logan , Vincent Wang Message-id: <471646B2.1090802@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <20071017154427.GD29257@Sun.COM> <18198.12716.591499.622266@gargle.gargle.HOWL> <47163913.3050400@sun.com> <20071017165557.GH29257@Sun.COM> <471643F1.4040602@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 978 David Chieu wrote: > Nicolas Williams wrote: > >> On Wed, Oct 17, 2007 at 09:32:19AM -0700, Garrett D'Amore wrote: >> >> >>> * secure-by-default. LMS needs to be off-by-default, as AMT is also >>> off-by-default. >>> >> >> It could be on-by-default, and temporarily disable itself if the AMT if >> off. (If you want remote AMT access why not local access?) But >> off-by-default ought to be acceptable. >> >> > Most PCs that we've in the lab has AMT on-by-default from the BIOS > setting. Some has only AMT2.0 / AMT3.0 options, so off-by-default may > not always work from the hardware point of view. That's surprising. I thought, from the preso at IDF, that AMT was off-by-default. I'm not thrilled with the on-by-default behavior, but if that is the case, then there is nothing we can do about it for non-Sun branded systems. For *Sun branded* systems, we should configure this off by default, either in the factory or as part of our default BIOS image. -- Garrett From gdamore@sun.com Wed Oct 17 10:39:33 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HHdWAq014442 for ; Wed, 17 Oct 2007 10:39:32 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HHa4BS011671 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Oct 2007 01:36:09 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200H05GW9V400@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 11:36:09 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ20097HGW7PU60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 11:36:08 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HHa7VP011751 for ; Wed, 17 Oct 2007 10:36:07 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200801GLKY800@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 10:36:07 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ200757GVO5N40@fe-sfbay-10.sun.com>; Wed, 17 Oct 2007 10:35:48 -0700 (PDT) Date: Wed, 17 Oct 2007 10:33:04 -0700 From: "Garrett D'Amore" Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <471646D3.5080308@sun.com> Sender: Garrett.Damore@sun.com To: Scott Rotondo Cc: PSARC-ext@sun.com, Vincent Wang , Mark Logan Message-id: <47164750.8040308@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <47163304.3010403@sun.com> <471646D3.5080308@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 733 Scott Rotondo wrote: > The sheer volume of email and variety of questions suggests to me that > this case long ago passed the "obviousness" threshold for a fast-track. > > I'm not a PSARC member, but if I were, I'd be asking for a full review > at this point. > > Scott Fair enough. Though to be completely honest, I think at least *part* of the problem stems from an incomplete understanding of the boundaries of what is being reviewed. Hopefully at least *that* part is clear now. A full review probably isn't a terrible idea, but I'll leave it to a PSARC member to derail on Wednesday, if that is appropriate. (It is completely clear that this was not of scope for a self-review, though, I think.) -- Garrett From sommerfeld@sun.com Wed Oct 17 10:41:01 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HHf0rj014605 for ; Wed, 17 Oct 2007 10:41:00 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HHbYcV007723; Wed, 17 Oct 2007 18:37:36 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200C03GYO6L00@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 10:37:36 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2004LNGYNVA90@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 10:37:35 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l9HHbUHg035185; Wed, 17 Oct 2007 13:37:30 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9HHbUas009230; Wed, 17 Oct 2007 13:37:30 -0400 (EDT) Date: Wed, 17 Oct 2007 13:37:29 -0400 From: Bill Sommerfeld Subject: Re: Intel AMT [PSARC/2007/601] In-reply-to: <47163304.3010403@sun.com> To: "Garrett D'Amore" Cc: Paul Jakma , James Carlson , PSARC-ext@sun.com, David Chieu , Vincent Wang , Mark Logan Message-id: <1192642649.9141.18.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.12.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <47163304.3010403@sun.com> Status: RO Content-Length: 1754 On Wed, 2007-10-17 at 09:06 -0700, Garrett D'Amore wrote: > There is a private method by which the firmware decides whether the host > OS is alive and healthy. If so, then the host does this work. If not, > then the firmware takes over. That doesn't help if the rest of the network thinks that the way to get to the shared IP is via a NIC that AMT isn't aware of (for instance, you could be running OSPF multipathing and may have inadvertantly injected a host route for the management interface into the OSPF cloud). Taking this up a level, the boundaries of "what works" and "what doesn't work" with shared ip seem to be fuzzy. we can make the boundaries simple (don't share unless you're only using one ethernet port), or we can add hacks (having the host stack forward stuff to the AMT) which increase the complexity of the boundary between "what works" and "what doesn't work". IMHO, both we and our customers will be happier if we strongly recommend that customers run this feature in lower-complexity configurations. Just because you *can* in some cases share an ethernet port and/or IP address with this management processor doesn't mean you *should*. BTW, there's another gotcha to watch out for that I haven't seen mentioned yet: If the management processor is picking off traffic for a particular port, what happens when the host picks the same port for its own use (for instance as the local port of an outgoing connection)? if we're going to recommend using the shared ip mode we need some way to persistently fence off that port from local use. I've seen stray ipsec port-level policy rules cause some very hard-to-diagnose problems when an application other than the expected one latches on to the port.. - Bill From gdamore@sun.com Wed Oct 17 10:52:22 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HHqLIP015271 for ; Wed, 17 Oct 2007 10:52:21 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HHmihW017147; Thu, 18 Oct 2007 01:48:58 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200D0LHHLYT00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Oct 2007 10:48:57 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ20061SHHJWA80@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Oct 2007 10:48:55 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HHmt7T002818; Wed, 17 Oct 2007 10:48:55 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200401G47E300@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Wed, 17 Oct 2007 10:48:55 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ200ERSHHBV980@fe-sfbay-09.sun.com>; Wed, 17 Oct 2007 10:48:48 -0700 (PDT) Date: Wed, 17 Oct 2007 10:46:03 -0700 From: "Garrett D'Amore" Subject: Re: Intel AMT [PSARC/2007/601] In-reply-to: <1192642649.9141.18.camel@thunk> Sender: Garrett.Damore@sun.com To: Bill Sommerfeld Cc: Paul Jakma , James Carlson , PSARC-ext@sun.com, David Chieu , Vincent Wang , Mark Logan Message-id: <47164A5B.4070701@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <47163304.3010403@sun.com> <1192642649.9141.18.camel@thunk> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 3342 Bill Sommerfeld wrote: > On Wed, 2007-10-17 at 09:06 -0700, Garrett D'Amore wrote: > >> There is a private method by which the firmware decides whether the host >> OS is alive and healthy. If so, then the host does this work. If not, >> then the firmware takes over. >> > > That doesn't help if the rest of the network thinks that the way to get > to the shared IP is via a NIC that AMT isn't aware of (for instance, you > could be running OSPF multipathing and may have inadvertantly injected a > host route for the management interface into the OSPF cloud). > Then you deserve what you get. :-/ > Taking this up a level, the boundaries of "what works" and "what doesn't > work" with shared ip seem to be fuzzy. we can make the boundaries > simple (don't share unless you're only using one ethernet port), or we > can add hacks (having the host stack forward stuff to the AMT) which > increase the complexity of the boundary between "what works" and "what > doesn't work". > We don't "control" this fully... customers can configure BIOS on systems they bought from vendors like Dell, however they please. What we can say is, configuration in modes other than a simple set are unsupported on Solaris. > IMHO, both we and our customers will be happier if we strongly recommend > that customers run this feature in lower-complexity configurations. > Strongly agree. I think that the cases where customers are most likely to want to have higher complexity configurations are also the cases where the system has a separate service processor. AMT is Intel's "low-end" solution, for simpler systems with only one or two NICs in a very simple configuration. I do want to point out that the failure mode for most of these interoperability issues is loss of access to AMT facilities. This will not cause the system to panic, corrupt data, or do other bad things. What it will do is make it harder to use the remote console facility, remote disk support (I had forgotten about that!), etc. > Just because you *can* in some cases share an ethernet port and/or IP > address with this management processor doesn't mean you *should*. > > BTW, there's another gotcha to watch out for that I haven't seen > mentioned yet: > > If the management processor is picking off traffic for a particular > port, what happens when the host picks the same port for its own use > (for instance as the local port of an outgoing connection)? if we're > going to recommend using the shared ip mode we need some way to > persistently fence off that port from local use. > I think that I addressed that by noting that LMS needs to bind to those ports to hold them from accidental allocation to other host software. > I've seen stray ipsec port-level policy rules cause some very > hard-to-diagnose problems when an application other than the expected > one latches on to the port.. > Yes. This is why LMS *must* bind to those ports. A failure to bind to those ports indicates something else is bound, and that should be syslog'ed with a big warning. LMS should start early... early enough to preclude other software from getting in and binding to the port by accident. An alternative, but less desirable (IMO) approach is to do the filtering/rule in the kernel. I don't like that at all, though. -- Garrett From carlsonj@phorcys.east.sun.com Wed Oct 17 10:56:19 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HHuIEG015691 for ; Wed, 17 Oct 2007 10:56:18 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HHqkih014412; Wed, 17 Oct 2007 18:52:51 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200C07HO1XL00@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 10:52:49 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ20045OHO0VJC0@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 10:52:49 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9HHqRtQ027332; Wed, 17 Oct 2007 13:52:27 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9HHqRuI027329; Wed, 17 Oct 2007 13:52:27 -0400 (EDT) Date: Wed, 17 Oct 2007 13:52:27 -0400 From: James Carlson Subject: Re: Intel AMT [PSARC/2007/601] In-reply-to: <1192642649.9141.18.camel@thunk> To: Bill Sommerfeld Cc: "Garrett D'Amore" , PSARC-ext@sun.com, Mark Logan , David Chieu , Paul Jakma , Vincent Wang Message-id: <18198.19419.681053.584076@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <47163304.3010403@sun.com> <1192642649.9141.18.camel@thunk> Status: RO Content-Length: 956 Bill Sommerfeld writes: > If the management processor is picking off traffic for a particular > port, what happens when the host picks the same port for its own use > (for instance as the local port of an outgoing connection)? if we're > going to recommend using the shared ip mode we need some way to > persistently fence off that port from local use. This was discussed just a short bit ago on this thread. The answer is that the daemon has to bind that special port so that nobody else can use it. How or if it does so is unclear. Binding ports exclusively (and properly) on Solaris is unnecessarily hard. (The snoop visibility issue seems like a pretty serious problem to me, but I guess I'll just give up on that front.) -- James Carlson, Solaris Networking 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 From carlsonj@phorcys.east.sun.com Wed Oct 17 11:01:37 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HI1bjr015816 for ; Wed, 17 Oct 2007 11:01:37 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HHwAO4019785; Wed, 17 Oct 2007 10:58:11 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200D19HWY6Q00@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 10:58:10 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2004XZHWYVLB0@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 10:58:10 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9HHvlZP027391; Wed, 17 Oct 2007 13:57:47 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9HHvk1D027388; Wed, 17 Oct 2007 13:57:46 -0400 (EDT) Date: Wed, 17 Oct 2007 13:57:46 -0400 From: James Carlson Subject: Re: Intel AMT [PSARC/2007/601] In-reply-to: <47164A5B.4070701@sun.com> To: "Garrett D'Amore" Cc: Bill Sommerfeld , Paul Jakma , PSARC-ext@sun.com, David Chieu , Vincent Wang , Mark Logan Message-id: <18198.19738.921571.177230@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <47163304.3010403@sun.com> <1192642649.9141.18.camel@thunk> <47164A5B.4070701@sun.com> Status: RO Content-Length: 1302 Garrett D'Amore writes: > We don't "control" this fully... customers can configure BIOS on systems > they bought from vendors like Dell, however they please. > > What we can say is, configuration in modes other than a simple set are > unsupported on Solaris. Exactly. We control our documentation, and we have to tell customers what we support and expect. They should _not_ just be left to wander into these dark corners by themselves. > I do want to point out that the failure mode for most of these > interoperability issues is loss of access to AMT facilities. This will Actually, the failure mode that perhaps concerns us most is "AMT doesn't work with Solaris, but works fine with Linux and Windows on the same system; need escalation to management for a fix." > Yes. This is why LMS *must* bind to those ports. A failure to bind to > those ports indicates something else is bound, and that should be > syslog'ed with a big warning. And using the undocumented TCP_EXCLBIND ... ? Otherwise, we allow applications to bind underneath open wildcard sockets. -- James Carlson, Solaris Networking 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 From Mark.Carlson@sun.com Wed Oct 17 11:05:28 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HI5RdE016028 for ; Wed, 17 Oct 2007 11:05:28 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HI1u4T023505; Thu, 18 Oct 2007 02:02:05 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200F0LI3F8K00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Oct 2007 11:02:03 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2006DTI3EWA90@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Oct 2007 11:02:02 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9HI22Zd001100; Wed, 17 Oct 2007 18:02:02 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200H01G2T3100@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM); Wed, 17 Oct 2007 12:02:02 -0600 (MDT) Received: from MACsMAC.local ([12.96.171.30]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ2003NAI2YGZE0@mail-amer.sun.com>; Wed, 17 Oct 2007 12:01:54 -0600 (MDT) Date: Wed, 17 Oct 2007 12:01:29 -0600 From: "Mark A. Carlson" Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <47163CB0.6030001@sun.com> Sender: Mark.Carlson@sun.com To: "Garrett D'Amore" Cc: Bill Sommerfeld , James Carlson , PSARC-ext@sun.com, Mark Logan , David Chieu , Paul Jakma , Vincent Wang Message-id: <47164DF9.7070807@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_wQ6dBeCeFmfLOl17YkE9Sw)" X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <20071017154427.GD29257@Sun.COM> <18198.12716.591499.622266@gargle.gargle.HOWL> <47163913.3050400@sun.com> <47163C86.7030903@sun.com> <47163CB0.6030001@sun.com> User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) Status: RO Content-Length: 2768 This is a multi-part message in MIME format. --Boundary_(ID_wQ6dBeCeFmfLOl17YkE9Sw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Which case is the AMT firmware part of? -- mark Garrett D'Amore wrote: > Mark A. Carlson wrote: > >> Garrett D'Amore wrote: >> >>> ... >>> >>> 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.) >>> >> Is this case exporting the WS-Management capability? >> >> Wouldn't we want external third party management application to be >> able to use that? >> > > This case is not doing that, but the AMT firmware does. > > -- Garrett > >> -- mark >> > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > --Boundary_(ID_wQ6dBeCeFmfLOl17YkE9Sw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Which case is the AMT firmware part of?

-- mark

Garrett D'Amore wrote: 
Mark A. Carlson wrote:
  
Garrett D'Amore wrote:
    
...

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.)
      
Is this case exporting the WS-Management capability?

Wouldn't we want external third party management application to be 
able to use that?
    

This case is not doing that, but the AMT firmware does.

    -- Garrett
  
-- mark
    

_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
--Boundary_(ID_wQ6dBeCeFmfLOl17YkE9Sw)-- From gdamore@sun.com Wed Oct 17 11:09:52 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HI9pRf016089 for ; Wed, 17 Oct 2007 11:09:51 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HI6MpP025957; Thu, 18 Oct 2007 02:06:28 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200D01IAQMB00@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 11:06:26 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2004V1IAPVCC0@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 11:06:25 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HI6P6i016143; Wed, 17 Oct 2007 11:06:25 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200801HKPB400@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Wed, 17 Oct 2007 11:06:25 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ200EUGIACV9D0@fe-sfbay-09.sun.com>; Wed, 17 Oct 2007 11:06:13 -0700 (PDT) Date: Wed, 17 Oct 2007 11:03:28 -0700 From: "Garrett D'Amore" Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <47164DF9.7070807@sun.com> Sender: Garrett.Damore@sun.com To: "Mark A. Carlson" Cc: Bill Sommerfeld , James Carlson , PSARC-ext@sun.com, Mark Logan , David Chieu , Paul Jakma , Vincent Wang Message-id: <47164E70.9050605@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <20071017154427.GD29257@Sun.COM> <18198.12716.591499.622266@gargle.gargle.HOWL> <47163913.3050400@sun.com> <47163C86.7030903@sun.com> <47163CB0.6030001@sun.com> <47164DF9.7070807@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 1119 Mark A. Carlson wrote: > Which case is the AMT firmware part of? None. AMT is delivered by Intel as part of their chipset. It falls outside the scope of things that PSARC really has any influence over. -- Garrett > > -- mark > > Garrett D'Amore wrote: >> Mark A. Carlson wrote: >> >>> Garrett D'Amore wrote: >>> >>>> ... >>>> >>>> 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.) >>>> >>> Is this case exporting the WS-Management capability? >>> >>> Wouldn't we want external third party management application to be >>> able to use that? >>> >> >> This case is not doing that, but the AMT firmware does. >> >> -- Garrett >> >>> -- mark >>> >> >> _______________________________________________ >> opensolaris-arc mailing list >> opensolaris-arc@opensolaris.org >> From randy.fishel@sun.com Wed Oct 17 11:25:57 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HIPvf9016764 for ; Wed, 17 Oct 2007 11:25:57 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HIMYrg028580; Wed, 17 Oct 2007 11:22:34 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200K07J1MWU00@brm-avmta-1.central.sun.com>; Wed, 17 Oct 2007 12:22:34 -0600 (MDT) Received: from engmail4sca.SFBay.Sun.COM ([129.145.155.74]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2009NGJ1LQ490@brm-avmta-1.central.sun.com>; Wed, 17 Oct 2007 12:22:33 -0600 (MDT) Received: from grimmy.eng.sun.com (grimmy.SFBay.Sun.COM [129.146.108.114]) by engmail4sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l9HIMUGA010393; Wed, 17 Oct 2007 11:22:30 -0700 (PDT) Received: from grimmy.eng.sun.com (localhost [127.0.0.1]) by grimmy.eng.sun.com (8.12.10+Sun/8.12.10) with ESMTP id l9HIMBQt014017; Wed, 17 Oct 2007 11:22:11 -0700 (PDT) Received: from localhost (randyf@localhost) by grimmy.eng.sun.com (8.12.10+Sun/8.12.10/Submit) with ESMTP id l9HIMBdR014013; Wed, 17 Oct 2007 11:22:11 -0700 (PDT) Date: Wed, 17 Oct 2007 11:22:11 -0700 (PDT) From: Randy Fishel Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <47164644.4060309@sun.com> X-X-Sender: randyf@grimmy To: "Garrett D'Amore" Cc: Randy Fishel , Paul Jakma , Bill Sommerfeld , James Carlson , PSARC-ext@sun.com, David Chieu , Vincent Wang , Mark Logan Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <47163304.3010403@sun.com> <47164644.4060309@sun.com> X-Authentication-warning: grimmy.eng.sun.com: randyf owned process doing -bs Status: RO Content-Length: 1632 > > > > > > > There is a private method by which the firmware decides whether the host > > > OS is > > > alive and healthy. If so, then the host does this work. If not, then the > > > firmware takes over. > > > > > > > > > > I have been looking for a place to ask this quesiton, and this might be > > it: What occurs if the machine is suspended and the NIC is still hot (maybe > > WOL enabled). Will the ME also be running? > > Yes! > > > If so, the OS is not, will it still know that OS is alive and healthy, or > > decide it is bad and try and reboot? > > Neither. The firmware is running and one can remotely reboot it using a > management tool, but on its own, the ME takes no action. I havn't fully read the materials, and I guess what the ME actually does is beyond the scope of this discussion. However, I suspect that there is a mechanism in the "private method" described above that at least lets the ME know the host is going into an S3 state, and that the Solaris components *will* use this API, so if the host is in this state, the ME can properly report the condition. > > > Will it be able to generate a PME and resume? (and maybe a host of other > > questions surrounding suspended machines). > > > > No. This is not a general watchdog facility. PME is not a watchdog facility, but the hardware wake mechanism. And though again I guess what the ME actually does is beyond our control, I am interested that it has desired capabilities (it can wake a sleeping system), or else it needs to be documented to discourage this combination. ---- Randy > > -- Garrett > From gdamore@sun.com Wed Oct 17 11:28:35 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HISY5B016828 for ; Wed, 17 Oct 2007 11:28:35 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HIP5vi004894; Thu, 18 Oct 2007 02:25:10 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200E07J5VNL00@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 11:25:07 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2004D0J5VVLE0@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 11:25:07 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HIP7Lp008166; Wed, 17 Oct 2007 11:25:07 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200601ITKMR00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) ; Wed, 17 Oct 2007 11:25:07 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ200K4NJ5UULE0@fe-sfbay-10.sun.com>; Wed, 17 Oct 2007 11:25:07 -0700 (PDT) Date: Wed, 17 Oct 2007 11:22:22 -0700 From: "Garrett D'Amore" Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: Sender: Garrett.Damore@sun.com To: Randy Fishel Cc: Paul Jakma , Bill Sommerfeld , James Carlson , PSARC-ext@sun.com, David Chieu , Vincent Wang , Mark Logan Message-id: <471652DE.9010209@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <47163304.3010403@sun.com> <47164644.4060309@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 1934 Randy Fishel wrote: >>>>> >>>>> >>>> There is a private method by which the firmware decides whether the host >>>> OS is >>>> alive and healthy. If so, then the host does this work. If not, then the >>>> firmware takes over. >>>> >>>> >>>> >>> I have been looking for a place to ask this quesiton, and this might be >>> it: What occurs if the machine is suspended and the NIC is still hot (maybe >>> WOL enabled). Will the ME also be running? >>> >> Yes! >> >> >>> If so, the OS is not, will it still know that OS is alive and healthy, or >>> decide it is bad and try and reboot? >>> >> Neither. The firmware is running and one can remotely reboot it using a >> management tool, but on its own, the ME takes no action. >> > > I havn't fully read the materials, and I guess what the ME > actually does is beyond the scope of this discussion. However, I > suspect that there is a mechanism in the "private method" described > above that at least lets the ME know the host is going into an S3 > state, and that the Solaris components *will* use this API, so if the > host is in this state, the ME can properly report the condition. > Yes. > >>> Will it be able to generate a PME and resume? (and maybe a host of other >>> questions surrounding suspended machines). >>> >>> >> No. This is not a general watchdog facility. >> > > PME is not a watchdog facility, but the hardware wake mechanism. > And though again I guess what the ME actually does is beyond our > control, I am interested that it has desired capabilities (it can wake > a sleeping system), or else it needs to be documented to discourage > this combination. > It can wake the system. This is precisely one of the cases it was designed to support. It can either do an S3 resume, or a full system reset. -- Garrett > > ---- Randy > > >> -- Garrett >> >> From jek3@sun.com Wed Oct 17 11:41:38 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HIfbZA017253 for ; Wed, 17 Oct 2007 11:41:38 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HIc5e8010762; Thu, 18 Oct 2007 02:38:09 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200F05JRKC600@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 11:38:08 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2004EMJRJVCF0@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 11:38:07 -0700 (PDT) Received: from [129.150.12.137] (vpn-129-150-12-137.SFBay.Sun.COM [129.150.12.137]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9HIbuOT737863; Wed, 17 Oct 2007 11:37:56 -0700 (PDT) Date: Wed, 17 Oct 2007 08:37:54 -1000 From: Joseph Kowalski Subject: Re: PSARC doesn't work!! Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <47161BD7.3050206@sun.com> To: Vincent Wang Cc: James Carlson , Dale Ghent , Mark Logan , David Chieu , "Garrett D'Amore" , PSARC-ext@sun.com Message-id: <47165682.7030307@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <4715288A.9050005@sun.com> <18197.11494.326860.154398@gargle.gargle.HOWL> <47154541.5060400@sun.com> <471557CA.9000902@sun.com> <742CE572-193F-41E0-BF96-3D5C0E50ED64@elemental.org> <18197.63663.245036.835518@gargle.gargle.HOWL> <47161BD7.3050206@sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 1039 Vincent Wang wrote: > PSARC doesn't work! > > I'm deeply worried because none of the people who raised questions > spent more than an hour even googling the text about the technology. > > Do you guys respect the hard work of the excellent engineers in other > companies who invented AMT, and the billions of dollars spent > developing the technology? > > I'm especially worried because these people include _James D Carlson_ > who has been in Sun for such a long time! > > Do you know that this conversation can be easily searched on google? > Whatever you say, you represent the image of Sun's engineers! > > People may ask, why is he asking these guys to review this stuff for > an approval? What? > > Tell me why. And be responsible. > > Vincent. I'll tell you my opinion. **YOU** should be providing enough information such that a senior engineer can understand the proposal. James (et.al.) should not be "googling" for the information. This case has almost no substance. Look in the mirror. Yes, be responsible. - jek3 From Neal.Pollack@sun.com Wed Oct 17 12:24:55 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HJOs1x018863 for ; Wed, 17 Oct 2007 12:24:55 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HJKqGh025551; Wed, 17 Oct 2007 20:21:32 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200105LRRQK00@brm-avmta-1.central.sun.com>; Wed, 17 Oct 2007 13:21:27 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2009DSLRPQ7D0@brm-avmta-1.central.sun.com>; Wed, 17 Oct 2007 13:21:26 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HJLPB2015191; Wed, 17 Oct 2007 12:21:25 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200I01LOI8100@fe-sfbay-09.sun.com> (original mail from Neal.Pollack@Sun.COM); Wed, 17 Oct 2007 12:21:25 -0700 (PDT) Received: from [10.1.48.130] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ2007Y9LRCNGA0@fe-sfbay-09.sun.com>; Wed, 17 Oct 2007 12:21:12 -0700 (PDT) Date: Wed, 17 Oct 2007 12:21:12 -0700 From: Neal Pollack Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <1192634666.3938.66.camel@localhost> Sender: Neal.Pollack@sun.com To: Bill Sommerfeld Cc: Paul Jakma , James Carlson , gdamore@sun.com, PSARC-ext@sun.com, David Chieu , Vincent Wang , Mark Logan Message-id: <471660A8.5030101@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> User-Agent: Thunderbird 2.0.0.6 (X11/20070924) Status: RO Content-Length: 1356 Bill Sommerfeld wrote: > On Wed, 2007-10-17 at 16:07 +0100, Paul Jakma wrote: > >> Firmware 'near' the NIC (I've never seen an explanation of the exact >> mechanism) interposes itself between hardware and OS and 'hijacks' >> traffic to that port. It never makes it to the OS. >> > > one implication of this is that, when this is in use, the NIC cannot be > part of a L2 aggregation (because the upstream switch will load-spread > some of the management traffic flows to other ports in the aggregation). > > And using it with other L2/L3 redundancy technologies (such as IPMP and > OSPF-MP) is going to be tricky (the shared management IP address must > not be seen as reachable via other NICs). > The above should not be an issue, but should be noted. AMT, and the low cost southbridge core that substitutes for a more formal "rack server BMC or ILOM module", is only really showing up on low cost desktops and laptops at this time. So far, the industry chooses to use more functional full blown service processors on rack servers, much like Sun does on all the Sun systems built by Systems Group under Fowler. Most laptops and desktops do not utilize IPMP and link aggregation, but I'd agree it should be noted in the man pages for both AMT components, and the NIC manpage, in cases where AMT is in use. Neal > - Bill > > > From gww@eng.sun.com Wed Oct 17 12:42:33 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HJgVoo019172 for ; Wed, 17 Oct 2007 12:42:32 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HJd1XA010193; Thu, 18 Oct 2007 03:39:07 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ20022LML6TA00@brm-avmta-1.central.sun.com>; Wed, 17 Oct 2007 13:39:06 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2009FBML5PXD0@brm-avmta-1.central.sun.com>; Wed, 17 Oct 2007 13:39:05 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l9HJd1eW022661; Wed, 17 Oct 2007 12:39:01 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l9HJf9bT021385; Wed, 17 Oct 2007 12:41:09 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l9HJf80k021384; Wed, 17 Oct 2007 12:41:08 -0700 (PDT) Date: Wed, 17 Oct 2007 12:41:08 -0700 (PDT) From: Gary Winiger Subject: Re: Intel AMT [PSARC/2007/601 Self Review To: Mark.Carlson@sun.com, gdamore@sun.com Cc: David.Chieu@sun.com, Mark.Logan@sun.com, PSARC-ext@sun.com, Paul.Jakma@sun.com, Vincent.Wang@sun.com, james.d.carlson@sun.com, sommerfeld@sun.com Message-id: <200710171941.l9HJf80k021384@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 309 > Mark A. Carlson wrote: > > Which case is the AMT firmware part of? > > None. AMT is delivered by Intel as part of their chipset. It falls > outside the scope of things that PSARC really has any influence over. Hummm, so there's no longer any FWARC (or is FWARC not Sun wide- but just SPARC)? Gary.. From gww@eng.sun.com Wed Oct 17 12:48:19 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HJmI0A019311 for ; Wed, 17 Oct 2007 12:48:19 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HJihnA012754; Thu, 18 Oct 2007 03:44:54 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200307MUQ4C00@brm-avmta-1.central.sun.com>; Wed, 17 Oct 2007 13:44:50 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2009WSMUPQ2E0@brm-avmta-1.central.sun.com>; Wed, 17 Oct 2007 13:44:50 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l9HJilUI023565; Wed, 17 Oct 2007 12:44:47 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l9HJktJ4021423; Wed, 17 Oct 2007 12:46:55 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l9HJkthU021422; Wed, 17 Oct 2007 12:46:55 -0700 (PDT) Date: Wed, 17 Oct 2007 12:46:55 -0700 (PDT) From: Gary Winiger Subject: Re: Intel AMT [PSARC/2007/601 Self Review] To: gdamore@sun.com, james.d.carlson@sun.com Cc: Mark.Logan@sun.com, PSARC-ext@sun.com, Vincent.Wang@sun.com, dchieu@sac.sfbay.sun.com Message-id: <200710171946.l9HJkthU021422@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 754 > More generally: have you looked at the security questionnaires? How > do you comply with them? > > http://www.opensolaris.org/os/community/arc/policies/ITS/ > http://www.opensolaris.org/os/community/arc/policies/NITS-policy/ > http://www.opensolaris.org/os/community/arc/bestpractices/security-questions/ Given the lack of materials in a consumable fashion, I can't tell how this project complies with: http://opensolaris.org/os/community/arc/policies/audit-policy/;jsessionid=D4252346BD6A9F91C181BCD4338BFDE1 which is unfortuately out of date with respect to: http://sac.eng/cgi-bin/bp.cgi?NAME=audit.bp The approved as of 07/01/31 policy. Gary.. P.S. Sac staff seems to be behind in pushing out a number of policy updates. Nag Nag Nag From gdamore@sun.com Wed Oct 17 13:07:39 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HK7cjX020148 for ; Wed, 17 Oct 2007 13:07:39 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HK47dx015482; Wed, 17 Oct 2007 21:04:15 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200K0LNR1A000@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 13:04:13 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ200HD1NR1WE20@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Oct 2007 13:04:13 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HK4CZ8019863; Wed, 17 Oct 2007 13:04:12 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200301NM1E700@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Wed, 17 Oct 2007 13:04:11 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ200EJQNQY7DF0@fe-sfbay-09.sun.com>; Wed, 17 Oct 2007 13:04:11 -0700 (PDT) Date: Wed, 17 Oct 2007 13:01:26 -0700 From: "Garrett D'Amore" Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <200710171941.l9HJf80k021384@marduk.eng.sun.com> Sender: Garrett.Damore@sun.com To: Gary Winiger Cc: Mark.Carlson@sun.com, David.Chieu@sun.com, Mark.Logan@sun.com, PSARC-ext@sun.com, Paul.Jakma@sun.com, Vincent.Wang@sun.com, James.D.Carlson@sun.com, sommerfeld@sun.com Message-id: <47166A16.9000007@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710171941.l9HJf80k021384@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 1098 Gary Winiger wrote: >> Mark A. Carlson wrote: >> >>> Which case is the AMT firmware part of? >>> >> None. AMT is delivered by Intel as part of their chipset. It falls >> outside the scope of things that PSARC really has any influence over. >> > > Hummm, so there's no longer any FWARC (or is FWARC not Sun wide- > but just SPARC)? > I'm not sure that even FWARC has any control. This is on firmware on systems that Sun didn't originally ship.... in other words, consider the project team for AMT to be Intel. Good luck getting them to come back to ARC (FWARC or otherwise) for review! An AMT case might be required for any system that Sun ships with AMT on the BIOS. (Think an Intel-based upgrade to the Ultra 20.) In that case, FWARC review would be appropriate, but I'm not sure how happy the folks on FWARC would be to review a technology that they basically have little control over. (Even on Sun's potential Intel x86 systems, the implementation of AMT is provided by Intel firmware which nobody but Intel has the ability to update.) -- Garrett From David.Chieu@sun.com Wed Oct 17 13:12:54 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HKCrOl020233 for ; Wed, 17 Oct 2007 13:12:53 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HK9KGo023063; Thu, 18 Oct 2007 04:09:28 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ200419NZRUV00@brm-avmta-1.central.sun.com>; Wed, 17 Oct 2007 14:09:27 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2009EANZQPVF0@brm-avmta-1.central.sun.com>; Wed, 17 Oct 2007 14:09:26 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HK9QQe002389; Wed, 17 Oct 2007 13:09:26 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200101NSSUT00@fe-sfbay-10.sun.com> (original mail from David.Chieu@Sun.COM); Wed, 17 Oct 2007 13:09:26 -0700 (PDT) Received: from [10.1.48.110] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ200HG4NZPU2E0@fe-sfbay-10.sun.com>; Wed, 17 Oct 2007 13:09:25 -0700 (PDT) Date: Wed, 17 Oct 2007 13:09:36 -0700 From: David Chieu Subject: Re: Intel AMT [PSARC/2007/601 FastTrack - wait for spec] In-reply-to: <471660A8.5030101@Sun.Com> Sender: David.Chieu@sun.com To: James Carlson , PSARC-ext@sun.com Cc: Vincent Wang , Mark Logan , Amiram.Hayardeny@sun.com, Neal Pollack , Andy Roach , "Garrett D'Amore" Message-id: <47166C00.20400@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <471660A8.5030101@Sun.Com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 512 Please note, this PSARC case has been changed status to "waiting need spec" due to a barrage of interested questions. We don't have all the ducks lined up in a row yet. We'll re-open this case until the requested spec is produced. The spec will address all the questions asked. In the meanwhile, please send your questions / comments to the project alias: intel-amt-iteam@sun.com. You're welcome to join the alias to work with us. The project team appreciates all your help. -- The Solaris Intel AMT team From Mark.Carlson@Sun.COM Wed Oct 17 13:58:44 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HKwigx021932 for ; Wed, 17 Oct 2007 13:58:44 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9HKtMuO017026; Wed, 17 Oct 2007 13:55:22 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ20090XQ4AMB00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Oct 2007 13:55:22 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ200L84Q49WBA0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Oct 2007 13:55:21 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9HKtLSW027590; Wed, 17 Oct 2007 20:55:21 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200C01NA5A800@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM); Wed, 17 Oct 2007 14:55:21 -0600 (MDT) Received: from MACsMAC.local ([12.96.171.10]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ2001FJQ3RQ620@mail-amer.sun.com>; Wed, 17 Oct 2007 14:55:06 -0600 (MDT) Date: Wed, 17 Oct 2007 14:55:00 -0600 From: "Mark A. Carlson" Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <47166A16.9000007@sun.com> Sender: Mark.Carlson@Sun.COM To: "Garrett D'Amore" Cc: Gary Winiger , sommerfeld@Sun.COM, James.D.Carlson@Sun.COM, PSARC-ext@Sun.COM, Mark.Logan@Sun.COM, David.Chieu@Sun.COM, Paul.Jakma@Sun.COM, Vincent.Wang@Sun.COM Message-id: <471676A4.40105@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_2aRbYVMvnh+6QT2kVssURQ)" X-PMX-Version: 5.2.0.264296 References: <200710171941.l9HJf80k021384@marduk.eng.sun.com> <47166A16.9000007@sun.com> User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) Status: RO Content-Length: 3801 This is a multi-part message in MIME format. --Boundary_(ID_2aRbYVMvnh+6QT2kVssURQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT In storage we regularly had contracts put in place for interfaces provided by our suppliers. -- mark Garrett D'Amore wrote: > Gary Winiger wrote: > >>> Mark A. Carlson wrote: >>> >>> >>>> Which case is the AMT firmware part of? >>>> >>>> >>> None. AMT is delivered by Intel as part of their chipset. It falls >>> outside the scope of things that PSARC really has any influence over. >>> >>> >> Hummm, so there's no longer any FWARC (or is FWARC not Sun wide- >> but just SPARC)? >> >> > > I'm not sure that even FWARC has any control. This is on firmware on > systems that Sun didn't originally ship.... in other words, consider > the project team for AMT to be Intel. Good luck getting them to come > back to ARC (FWARC or otherwise) for review! > > An AMT case might be required for any system that Sun ships with AMT on > the BIOS. (Think an Intel-based upgrade to the Ultra 20.) In that > case, FWARC review would be appropriate, but I'm not sure how happy the > folks on FWARC would be to review a technology that they basically have > little control over. (Even on Sun's potential Intel x86 systems, the > implementation of AMT is provided by Intel firmware which nobody but > Intel has the ability to update.) > > -- Garrett > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > --Boundary_(ID_2aRbYVMvnh+6QT2kVssURQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT In storage we regularly had contracts put in place for interfaces
provided by our suppliers.

-- mark

Garrett D'Amore wrote: 
Gary Winiger wrote:
  
Mark A. Carlson wrote:
    
      
Which case is the AMT firmware part of?
      
        
None.  AMT is delivered by Intel as part of their chipset.  It falls 
outside the scope of things that PSARC really has any influence over.
    
      
	Hummm, so there's no longer any FWARC (or is FWARC not Sun wide-
	but just SPARC)?
  
    

I'm not sure that even FWARC has any control.  This is on firmware on 
systems that Sun didn't originally ship.... in other  words, consider 
the project team for AMT to be Intel.  Good luck getting them to come 
back to ARC (FWARC or otherwise) for review!

An AMT case might be required for any system that Sun ships with AMT on 
the BIOS.  (Think an Intel-based upgrade to the Ultra 20.)  In that 
case, FWARC review would be appropriate, but I'm not sure how happy the 
folks on FWARC would be to review a technology that they basically have 
little control over.  (Even on Sun's potential Intel x86 systems, the 
implementation of AMT is provided by Intel firmware which nobody but 
Intel has the ability to update.)

    -- Garrett

_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
--Boundary_(ID_2aRbYVMvnh+6QT2kVssURQ)-- From John.Plocher@Sun.COM Wed Oct 17 14:10:55 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9HLAsfm022460 for ; Wed, 17 Oct 2007 14:10:54 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9HL7T6C016200; Thu, 18 Oct 2007 05:07:29 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ20080NQOGQG00@brm-avmta-1.central.sun.com>; Wed, 17 Oct 2007 15:07:28 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ2004BGQOEV740@brm-avmta-1.central.sun.com>; Wed, 17 Oct 2007 15:07:26 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9HL7Qbf009818; Wed, 17 Oct 2007 14:07:26 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ200J01QA2AI00@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM); Wed, 17 Oct 2007 14:07:26 -0700 (PDT) Received: from wp668.sfbay.sun.com ([129.146.58.87]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ2008YQQOEEH80@fe-sfbay-10.sun.com>; Wed, 17 Oct 2007 14:07:26 -0700 (PDT) Date: Wed, 17 Oct 2007 14:07:23 -0700 From: John Plocher Subject: Re: Intel AMT [PSARC/2007/601 FastTrack - wait for spec] In-reply-to: <47166C00.20400@sun.com> Sender: John.Plocher@Sun.COM To: David Chieu Cc: PSARC-ext@Sun.COM, Neal Pollack , Andy Roach , "Garrett D'Amore" , Mark Logan , Amiram.Hayardeny@Sun.COM, Vincent Wang Message-id: <4716798B.3030501@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <471660A8.5030101@Sun.Com> <47166C00.20400@sun.com> User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) Status: RO Content-Length: 294 David Chieu wrote: > In the > meanwhile, please send your questions / comments to the project alias I added the project alias to the case's IAM:Interest list, so all email to PSARC-EXT at Sun with the case number (2007/601) in the Subject: line will automatically be sent to them. -John From Darren.Reed@sun.com Wed Oct 17 18:40:12 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9I1eBGn001807 for ; Wed, 17 Oct 2007 18:40:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9I1afVF026974 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Oct 2007 09:36:48 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ30035935BPM00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 17 Oct 2007 19:36:47 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ300LVS358X930@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 17 Oct 2007 19:36:45 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9I1aiWA000740 for ; Thu, 18 Oct 2007 01:36:44 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JQ300501301VN00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 18 Oct 2007 09:36:44 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JQ300HKY34YYDBD@mail-apac.sun.com>; Thu, 18 Oct 2007 09:36:36 +0800 (SGT) Date: Wed, 17 Oct 2007 18:36:34 -0700 From: Darren Reed Subject: Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> Sender: Darren.Reed@sun.com To: David Chieu Cc: PSARC-ext@sun.com, Mark.Logan@sun.com, Vincent.Wang@sun.com Message-id: <4716B8A2.7030703@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 343 Some further questions... Can the status of ME be controlled from Solaris via dladm? If not, what plans are there for managing it - only through the LMS daemon? How do we observe if the operational status of the ME? And most importantly... How does someone disable the ME on the card when a security vulnerability in it is found? Darren From David.Chieu@sun.com Wed Oct 17 19:54:54 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9I2srjv003413 for ; Wed, 17 Oct 2007 19:54:54 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9I2pLc0023945 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Oct 2007 10:51:30 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ3009016LR1Q00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 17 Oct 2007 20:51:27 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ300LBP6LQXE70@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 17 Oct 2007 20:51:26 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9I2pPYQ024245 for ; Wed, 17 Oct 2007 19:51:25 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ300B016K88P00@fe-sfbay-09.sun.com> (original mail from David.Chieu@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 17 Oct 2007 19:51:25 -0700 (PDT) Received: from [10.1.48.110] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ300GBH6LPDHA0@fe-sfbay-09.sun.com>; Wed, 17 Oct 2007 19:51:25 -0700 (PDT) Date: Wed, 17 Oct 2007 19:51:35 -0700 From: David Chieu Subject: Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <4716B8A2.7030703@Sun.COM> Sender: David.Chieu@sun.com To: Darren Reed Cc: David Chieu , PSARC-ext@sun.com, Mark.Logan@sun.com, Vincent.Wang@sun.com Message-id: <4716CA37.3080803@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <4716B8A2.7030703@Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 1517 Darren Reed wrote: > Some further questions... > > Can the status of ME be controlled from Solaris via dladm? Not with the current implementation. ME isn't a networking device, per se. Please send suggestions to our project alias, intel-amt-iteam@sun.com, with requirements from dladm. > If not, what plans are there for managing it - only through > the LMS daemon? > It is intended to be managed by system management applications which understands WSMAN protocol (XML/SOAP based), so yes, current implementation is to go through the daemon. For additional information on WSMAN see http://www.dmtf.org/standards/wsman > How do we observe if the operational status of the ME? > Also through WSMAN protocol. See Intel's usage of WSMAN from http://communities.intel.com/openport/blogs/proexpert/2007/09/28/adding-wsman-support-to-intel-amt-commander Additionally, we can write our own tools but that's phase II of the project. Good point, Darren. > And most importantly... > > How does someone disable the ME on the card when a > security vulnerability in it is found? > Each Intel AMT device must be provisioned with at least one username/password pair. Additionally, AMT supports Kerberos v5 (RFC 1510). Not running Solaris, you can turn off ME from most of PC BIOS that we've seen. There are some PCs where ME is not allowed to be disabled at all from the BIOS which could be a security hole once a vulnerability is found. However, this is beyond the scope of this project. -- David Chieu > Darren > From Darren.Reed@sun.com Wed Oct 17 20:14:44 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9I3Eh14003575 for ; Wed, 17 Oct 2007 20:14:44 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9I3B4Lh000595 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Oct 2007 11:11:20 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ3006057IUYG00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 17 Oct 2007 20:11:18 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ300IT07IT4R60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 17 Oct 2007 20:11:18 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9I3BH9D007871 for ; Thu, 18 Oct 2007 03:11:17 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JQ300M017ISPY00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 18 Oct 2007 11:11:17 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JQ30027O7IR5D1V@mail-apac.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 18 Oct 2007 11:11:17 +0800 (SGT) Date: Wed, 17 Oct 2007 20:11:14 -0700 From: Darren Reed Subject: Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <4716CA37.3080803@sun.com> Sender: Darren.Reed@sun.com To: David Chieu Cc: PSARC-ext@sun.com, Mark.Logan@sun.com, Vincent.Wang@sun.com Message-id: <4716CED2.3020506@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <4716B8A2.7030703@Sun.COM> <4716CA37.3080803@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 1393 David Chieu wrote: > Darren Reed wrote: > ... > >> And most importantly... >> >> How does someone disable the ME on the card when a >> security vulnerability in it is found? >> > Each Intel AMT device must be provisioned with at least one > username/password pair. Is there a default username/password pair that allows remote operations without these being set by the host? Is the username/password stored on the NIC itself so that it will survive the NIC being moved from one system to another? How does it defend against being brute forced? .... (many more questions) > Additionally, AMT supports Kerberos v5 (RFC 1510). I'm starting to agree more with Scott, there's a lot more to this case than is normal for a fast track - it seems like the security questionaire would be appropriate given there is a username/password pair in the mix here, along with Kerberos support. > Not running Solaris, you can turn off ME from most of PC BIOS that > we've seen. There are some PCs where ME is not allowed to be disabled > at all from the BIOS which could be a security hole once a > vulnerability is found. However, this is beyond the scope of this project. Thus to turn the ME on/off, you need to reboot and press a magic key as the system comes up and go into a special AMT configure screen? There is no way to configure the ME from solaris by making a call into the BIOS? Darren From David.Chieu@sun.com Wed Oct 17 21:53:02 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9I4r2b5004552 for ; Wed, 17 Oct 2007 21:53:02 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9I4nZ3L027942 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Oct 2007 05:49:38 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ300H03C2QGU00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 17 Oct 2007 22:49:38 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ300LCNC2PXCC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 17 Oct 2007 22:49:37 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9I4nbSj013629 for ; Wed, 17 Oct 2007 21:49:37 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ300901BS5IF00@fe-sfbay-09.sun.com> (original mail from David.Chieu@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 17 Oct 2007 21:49:37 -0700 (PDT) Received: from [10.1.48.110] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ300K6HC2OK140@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 17 Oct 2007 21:49:36 -0700 (PDT) Date: Wed, 17 Oct 2007 21:49:46 -0700 From: David Chieu Subject: Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <4716CED2.3020506@Sun.COM> Sender: David.Chieu@sun.com To: Darren Reed Cc: PSARC-ext@sun.com, Mark.Logan@sun.com, Vincent.Wang@sun.com Message-id: <4716E5EA.3080500@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <4716B8A2.7030703@Sun.COM> <4716CA37.3080803@sun.com> <4716CED2.3020506@Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 2090 Darren Reed wrote: > David Chieu wrote: > >> Darren Reed wrote: >> ... >> >>> And most importantly... >>> >>> How does someone disable the ME on the card when a >>> security vulnerability in it is found? >>> >> Each Intel AMT device must be provisioned with at least one >> username/password pair. > > > Is there a default username/password pair that allows > remote operations without these being set by the host? Yes. > Is the username/password stored on the NIC itself so > that it will survive the NIC being moved from one system > to another? The password is stored in ME, not on NIC. Hardware-wise, ME is part of the PC motherboard (North Bridge) and our test machines have on-board Intel NIC which can't be removed. > How does it defend against being brute forced? I don't understand the question. Can you give an example of brute forced? > ... > (many more questions) > >> Additionally, AMT supports Kerberos v5 (RFC 1510). > > > I'm starting to agree more with Scott, there's a lot more > to this case than is normal for a fast track - it seems like > the security questionaire would be appropriate given > there is a username/password pair in the mix here, along > with Kerberos support. > Agreed. >> Not running Solaris, you can turn off ME from most of PC BIOS that >> we've seen. There are some PCs where ME is not allowed to be disabled >> at all from the BIOS which could be a security hole once a >> vulnerability is found. However, this is beyond the scope of this >> project. > > > Thus to turn the ME on/off, you need to reboot and press > a magic key as the system comes up and go into a special > AMT configure screen? Correct. The systems that we've seen so far in the labs give you some of following simple choices, e.g. a) AMT 2.0 or AMT 3.0 b) ASF, AMT, or None c) AMT only ASF is Alert Standard Format - see http://www.dmtf.org/standards/asf > There is no way to configure the ME from solaris by making > a call into the BIOS? > We've not yet explored the possibility to call into ME via BIOS from Solaris. Good question. -- David Chieu > Darren > > From Darren.Reed@sun.com Wed Oct 17 21:59:00 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9I4wxjv005027 for ; Wed, 17 Oct 2007 21:58:59 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9I4tYjC029815 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Oct 2007 05:55:36 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ300N05CCN0700@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 17 Oct 2007 21:55:35 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ3002X1CCMX670@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 17 Oct 2007 21:55:34 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9I4tX0h015807 for ; Thu, 18 Oct 2007 04:55:33 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JQ300H01C8RQ000@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 18 Oct 2007 12:55:33 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JQ300ETDCCJNFA4@mail-apac.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 18 Oct 2007 12:55:33 +0800 (SGT) Date: Wed, 17 Oct 2007 21:55:31 -0700 From: Darren Reed Subject: Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <4716E5EA.3080500@sun.com> Sender: Darren.Reed@sun.com To: David Chieu Cc: PSARC-ext@sun.com, Mark.Logan@sun.com, Vincent.Wang@sun.com Message-id: <4716E743.5080006@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <4716B8A2.7030703@Sun.COM> <4716CA37.3080803@sun.com> <4716CED2.3020506@Sun.COM> <4716E5EA.3080500@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 420 David Chieu wrote: > Darren Reed wrote: > ... > >> How does it defend against being brute forced? > > I don't understand the question. Can you give an example of brute forced? I use a dictionary as a source of usernames and passwords and send correctly formatted data at the NIC (using a combination of usernames and passwords) until it respods with a message indicating a successful authentication attempt. Darren From David.Chieu@Sun.COM Wed Oct 17 22:55:36 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9I5talE006109 for ; Wed, 17 Oct 2007 22:55:36 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9I5qDHM001936 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Oct 2007 22:52:13 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ300L01EZ0W700@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 23:52:12 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ300LOJEYZXCE0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 23:52:11 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9I5qBLs029201 for ; Wed, 17 Oct 2007 22:52:11 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ300B01EVHP500@fe-sfbay-10.sun.com> (original mail from David.Chieu@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 22:52:11 -0700 (PDT) Received: from [10.1.48.110] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ300G9YEYY88F0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Oct 2007 22:52:11 -0700 (PDT) Date: Wed, 17 Oct 2007 22:52:21 -0700 From: David Chieu Subject: Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <4716E743.5080006@Sun.COM> Sender: David.Chieu@Sun.COM To: Darren Reed Cc: PSARC-ext@Sun.COM, Mark.Logan@Sun.COM, Vincent.Wang@Sun.COM Message-id: <4716F495.7090506@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <4716B8A2.7030703@Sun.COM> <4716CA37.3080803@sun.com> <4716CED2.3020506@Sun.COM> <4716E5EA.3080500@sun.com> <4716E743.5080006@Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 4488 Darren Reed wrote: > David Chieu wrote: > >> Darren Reed wrote: >> ... >> >>> How does it defend against being brute forced? >> >> I don't understand the question. Can you give an example of brute >> forced? > > > I use a dictionary as a source of usernames and passwords > and send correctly formatted data at the NIC (using a combination > of usernames and passwords) until it respods with a message > indicating a successful authentication attempt. > > Darren > I see. A stronger password (w/ symbols e.g. !,@, etc.) reduces vulnerability of a dictionary attack. I image that an AMD engineer could explore the like :-) If stronger security model is needed, AMT supports certificate-based authentication as well. I'm not an expert in this field, so I quote the following excerpt from the Intel website. http://softwarecommunity.intel.com/articles/eng/1004.htm ... "Authentication and Authorization Network communications with an Intel AMT-enabled platform should be performed in the most secure way available. An IT administrator can configure for certificate-based authentication and optionally select mutual authentication. Intel AMT has an Access Control List used to authorize all access requests. Intel AMT can use the Kerberos option of Microsoft Active Directory to simplify the authorization process. A remote setup and configuration server is required to prepare Intel AMT for secure operations. Configuring the Intel AMT Security Model Both the Intel AMT platform and the Setup and Configuration (S&C) Server start with two pieces of shared information – a platform ID and a pre-shared key (PSK). The first communication between Intel AMT and the setup and configuration server is an unencrypted “hello” message from Intel AMT to the server that contains the platform identifier. The S&C Server then performs the setup and configuration process using the PSK and the TLS-PSK protocol for authentication and encryption of the configuration traffic. The S&C Server downloads Certificates to the Intel AMT platform, which stores them in non-volatile memory. The certificates trace to an enterprise certificate authority and are used by Intel AMT to authenticate to Management Console applications. If Intel AMT is configured for mutual authentication, the S&C Server must provide a client certificate for each application that will communicate with Intel AMT. The S&C server also establishes an Access Control List, enables certain Intel AMT features, and configures device settings. At the end of the setup and configuration process, the keys generated and used during the process are deleted. All subsequent communications use the certificates and Transport Layer Security (TLS) for authentication, confidentiality (encryption), and integrity (mutual authentication). Intel AMT performs authorization using the Access Control List, as described in the following section. HTTP Digest authentication is used for the SOAP over HTTP communications. The Redirection feature uses secure sockets layer (SSL) to establish a secure connection between the remote console and the Intel AMT platform. See the User’s Guide to the Sample Setup and Configuration Application for additional information. Access Control Lists and Realms The Intel AMT Access Control List (ACL) manages who has access to which capabilities within the device. An ACL entry has a user ID and a list of realms to which a user has access. This access is required to use the functionality associated with a realm. In the table above, each interface or service is listed with its realm. A user can be granted access to one or more realms. The single default user is named “admin” and has “PTAdministrationRealm” privileges, which includes privileges for all Intel AMT realms. The admin user can use the commands in the Security Administration interface to create additional ACL entries for additional users. As part of the setup and configuration process, create the users necessary for an ISV application, subject to the limits on the number of available ACL entries. There are two kinds of ACL entries: Kerberos and non-Kerberos. The main difference between them is that Kerberos entries have an Active Directory SID to identify a user or group of users. Non-Kerberos entries have a username and password for user identification. See Intel AMT Integration with Active Directory for a description of the difference between these entries." From casper@holland.sun.com Thu Oct 18 00:08:06 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9I7856n008086 for ; Thu, 18 Oct 2007 00:08:06 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9I74fJk033886; Thu, 18 Oct 2007 01:04:42 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ300L07IBTCL00@nwk-avmta-2.sfbay.sun.com>; Thu, 18 Oct 2007 00:04:41 -0700 (PDT) Received: from dm-holland-01.uk.sun.com ([129.156.101.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ300I9FIBS4SF0@nwk-avmta-2.sfbay.sun.com>; Thu, 18 Oct 2007 00:04:41 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [129.159.130.93]) by dm-holland-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l9I74XbV028596; Thu, 18 Oct 2007 08:04:33 +0100 (BST) Date: Thu, 18 Oct 2007 09:04:32 +0200 From: Casper.Dik@sun.com Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <471636D1.7080109@sun.com> Sender: casper@holland.sun.com To: Vincent Wang Cc: Paul Jakma , David Chieu , James Carlson , Mark Logan , daleg@elemental.org, gdamore@sun.com, PSARC-ext@sun.com Message-id: <200710180704.l9I74XbV028596@dm-holland-01.uk.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <471636D1.7080109@sun.com> Status: RO Content-Length: 437 >No. Even in promiscuous mode the host OS does not receive AMT packets. >Don't know how it's done. Pretty much the same as can be observed on BMC systems with shared management such as the LX50. Questions: - Can AMT be configured from Solaris (IP, MAC, everything) - Can it be switched off (from Solaris) - Will Solaris' settings have precedence or are these settings stored in the AMT BIOS and gotten from/set there? Casper From casper@holland.sun.com Thu Oct 18 01:25:07 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9I8P6Hx009269 for ; Thu, 18 Oct 2007 01:25:07 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9I8LMSI026038; Thu, 18 Oct 2007 16:21:41 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ300M09LW2EC00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 18 Oct 2007 01:21:38 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ300ECZLW0A780@nwk-avmta-1.sfbay.Sun.COM>; Thu, 18 Oct 2007 01:21:36 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [129.159.130.93]) by dm-holland-02.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l9I8LRU6027241; Thu, 18 Oct 2007 09:21:27 +0100 (BST) Date: Thu, 18 Oct 2007 10:21:27 +0200 From: Casper.Dik@sun.com Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <200710171941.l9HJf80k021384@marduk.eng.sun.com> Sender: casper@holland.sun.com To: Gary Winiger Cc: Mark.Carlson@sun.com, gdamore@sun.com, David.Chieu@sun.com, Mark.Logan@sun.com, PSARC-ext@sun.com, Paul.Jakma@sun.com, Vincent.Wang@sun.com, James.D.Carlson@sun.com, sommerfeld@sun.com Message-id: <200710180821.l9I8LRU6027241@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710171941.l9HJf80k021384@marduk.eng.sun.com> Status: RO Content-Length: 465 >> Mark A. Carlson wrote: >> > Which case is the AMT firmware part of? >> >> None. AMT is delivered by Intel as part of their chipset. It falls >> outside the scope of things that PSARC really has any influence over. > > Hummm, so there's no longer any FWARC (or is FWARC not Sun wide- > but just SPARC)? C'mon Gary, FWARC has no say on non-Sun firmware shipped embedded in non-Sun hardware. You're going to claim my PC's BIOS is unsupported next. Casper From Vincent.Wang@sun.com Thu Oct 18 01:36:43 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9I8ahsF009309 for ; Thu, 18 Oct 2007 01:36:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9I8XKCO017313 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Oct 2007 01:33:20 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ30031LMFKJ900@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 18 Oct 2007 01:33:20 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ300LKMMF8FR90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 18 Oct 2007 01:33:19 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9I8X7s0001269 for ; Thu, 18 Oct 2007 08:33:07 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JQ300101MB0OY00@mail-apac.sun.com> (original mail from Vincent.Wang@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 18 Oct 2007 16:33:07 +0800 (SGT) Received: from [129.158.218.87] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JQ30020NMF65DJV@mail-apac.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 18 Oct 2007 16:33:07 +0800 (SGT) Date: Thu, 18 Oct 2007 16:25:40 +0800 From: Vincent R Wang Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <200710180704.l9I74XbV028596@dm-holland-01.uk.sun.com> Sender: Vincent.Wang@sun.com To: Casper.Dik@sun.com Cc: Paul Jakma , David Chieu , James Carlson , Mark Logan , daleg@elemental.org, gdamore@sun.com, PSARC-ext@sun.com Message-id: <47171884.50902@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en, zh-cn X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <471636D1.7080109@sun.com> <200710180704.l9I74XbV028596@dm-holland-01.uk.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041101 Status: RO Content-Length: 1373 Casper.Dik@Sun.COM wrote: >>No. Even in promiscuous mode the host OS does not receive AMT packets. >>Don't know how it's done. >> >> > >Pretty much the same as can be observed on BMC systems with shared >management such as the LX50. > >Questions: > > - Can AMT be configured from Solaris (IP, MAC, everything) > > AFAIK, No. The configuration related APIs exported by ME are only available for remote nodes. The ME can tell if the request comes from the Host OS or from remote. I guess the advantage of this is that, if the OS is compromised by virus, it'll never have the chance to turn off/change the System Defense policies (Intrusion Detection) configured in ME. > - Can it be switched off (from Solaris) > > I haven't found a way to do this from the Host OS. Unprovisioning (restoring it to factory mode) can only be done from the BIOS menu or from a remote, trusted console. > - Will Solaris' settings have precedence or are these settings > stored in the AMT BIOS and gotten from/set there? > > > In AMT's non-volatile memory. Configuration can be done in two ways: 1. TLS-PSK (1-touch configuration, which requires at least one touch of the machine to enter a pre-shared key). 2. Remote configuration (0-touch configuration, e.g. the firmware can have one or more root certificate hashes from recognized vendors). This is cool. Vincent. From Darren.Reed@sun.com Thu Oct 18 07:41:22 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9IEfL50013925 for ; Thu, 18 Oct 2007 07:41:21 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9IEbk9x028957 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 18 Oct 2007 22:37:57 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ40001D3B8OB00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Thu, 18 Oct 2007 07:37:56 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ400IDP3B31Y80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Thu, 18 Oct 2007 07:37:52 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9IEbpTJ015858 for ; Thu, 18 Oct 2007 14:37:51 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JQ400I0134ZKF00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Thu, 18 Oct 2007 22:37:51 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JQ400H163B1YN8Y@mail-apac.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Thu, 18 Oct 2007 22:37:51 +0800 (SGT) Date: Thu, 18 Oct 2007 07:37:48 -0700 From: Darren Reed Subject: Re: Intel AMT [PSARC/2007/601 Self Review] In-reply-to: <4716F495.7090506@sun.com> Sender: Darren.Reed@sun.com To: David Chieu Cc: PSARC-ext@sun.com, Mark.Logan@sun.com, Vincent.Wang@sun.com Message-id: <47176FBC.8080500@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.2.0.264296 References: <200710162044.l9GKiffU015797@sac.sfbay.sun.com> <4716B8A2.7030703@Sun.COM> <4716CA37.3080803@sun.com> <4716CED2.3020506@Sun.COM> <4716E5EA.3080500@sun.com> <4716E743.5080006@Sun.COM> <4716F495.7090506@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 1092 David Chieu wrote: > Darren Reed wrote: > >> David Chieu wrote: >> >>> Darren Reed wrote: >>> ... >>> >>>> How does it defend against being brute forced? >>> >>> >>> I don't understand the question. Can you give an example of brute >>> forced? >> >> >> >> I use a dictionary as a source of usernames and passwords >> and send correctly formatted data at the NIC (using a combination >> of usernames and passwords) until it respods with a message >> indicating a successful authentication attempt. >> >> Darren >> > I see. A stronger password (w/ symbols e.g. !,@, etc.) reduces > vulnerability of a dictionary attack. I image that an AMD engineer > could explore the like :-) If stronger security model is needed, AMT > supports certificate-based authentication as well. I'm not an expert > in this field, so I quote the following excerpt from the Intel website. David, There was some great information in there, can you please make sure this (and other relevant bits and pieces) can be found in its entirity in the case directory, distinct from the email archive? Thanks, Darren From gww@eng.sun.com Thu Oct 18 07:50:22 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9IEoLPX014064 for ; Thu, 18 Oct 2007 07:50:21 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9IEkrrC003148; Thu, 18 Oct 2007 22:46:55 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ400E183Q3SS00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 18 Oct 2007 07:46:51 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ4008DA3Q17450@nwk-avmta-1.sfbay.Sun.COM>; Thu, 18 Oct 2007 07:46:49 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l9IEkjuN017720; Thu, 18 Oct 2007 07:46:45 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l9IEms05022511; Thu, 18 Oct 2007 07:48:54 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l9IEmr5J022510; Thu, 18 Oct 2007 07:48:53 -0700 (PDT) Date: Thu, 18 Oct 2007 07:48:53 -0700 (PDT) From: Gary Winiger Subject: Re: Intel AMT [PSARC/2007/601 Self Review To: gww@eng.sun.com, Casper.Dik@sun.com Cc: Mark.Carlson@sun.com, gdamore@sun.com, David.Chieu@sun.com, Mark.Logan@sun.com, PSARC-ext@sun.com, Paul.Jakma@sun.com, Vincent.Wang@sun.com, James.D.Carlson@sun.com, sommerfeld@sun.com Message-id: <200710181448.l9IEmr5J022510@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 907 > >> Mark A. Carlson wrote: > >> > Which case is the AMT firmware part of? > >> > >> None. AMT is delivered by Intel as part of their chipset. It falls > >> outside the scope of things that PSARC really has any influence over. > > > > Hummm, so there's no longer any FWARC (or is FWARC not Sun wide- > > but just SPARC)? > > > C'mon Gary, FWARC has no say on non-Sun firmware shipped embedded in > non-Sun hardware. > > You're going to claim my PC's BIOS is unsupported next. Well I was answering the question of the case AMT should have been part of. If it ships in Sun branded HW, there should be a reference to how it was integrated. Recall the period of time when NCSC was doing TCSEC evaluations, part of the evidence required was the architectural review for FW/HW as well as SW. While Sun was only doing SPARC and Motorolla then, there was still FW/HW architectural review. Gary.. From Brian.Xu@Sun.COM Thu Oct 18 21:39:26 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9J4dPmh002794 for ; Thu, 18 Oct 2007 21:39:26 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9J4a13p013499; Fri, 19 Oct 2007 12:36:02 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ50020763Y2A00@brm-avmta-1.central.sun.com>; Thu, 18 Oct 2007 22:35:58 -0600 (MDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ5008DY63XXJC0@brm-avmta-1.central.sun.com>; Thu, 18 Oct 2007 22:35:58 -0600 (MDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9J4ZudL009649; Fri, 19 Oct 2007 04:35:56 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JQ5001015YIZK00@mail-apac.sun.com> (original mail from Brian.Xu@Sun.COM) ; Fri, 19 Oct 2007 12:35:56 +0800 (SGT) Received: from [192.168.128.140] ([68.178.104.162]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JQ5002T663M5MRC@mail-apac.sun.com>; Fri, 19 Oct 2007 12:35:56 +0800 (SGT) Date: Fri, 19 Oct 2007 12:35:46 +0800 From: "brian.xu" Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <4716329D.8060501@sun.com> Sender: Brian.Xu@Sun.COM To: "Garrett D'Amore" Cc: Paul Jakma , Nicolas Williams , Bill Sommerfeld , James Carlson , PSARC-ext@Sun.COM, David Chieu , Vincent Wang , Mark Logan Message-id: <47183422.6080503@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <20071017154427.GD29257@Sun.COM> <4716329D.8060501@sun.com> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) Status: RO Content-Length: 541 Garrett D'Amore ??: > Paul Jakma wrote: >> On Wed, 17 Oct 2007, Nicolas Williams wrote: >> >>> My impression was that the AMT chip gets its own IPv4 address. >> >> I'd be curious if the MAC address is still shared for this case or >> not though. >> >> regards, > > No, in that config they have separate MAC addresses. And this option > is only available with wired ethernet, not wifi. Wifi may also have separate MAC address. The intel 4965 chipset does have separate and unique MAC address for the Host and AMT. --Brian > > -- Garrett From gdamore@sun.com Thu Oct 18 22:41:50 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9J5fnYh003708 for ; Thu, 18 Oct 2007 22:41:49 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9J5c5R6003388; Fri, 19 Oct 2007 13:38:26 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ5005058ZZDD00@nwk-avmta-2.sfbay.sun.com>; Thu, 18 Oct 2007 22:38:23 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ500C7D8ZZ0990@nwk-avmta-2.sfbay.sun.com>; Thu, 18 Oct 2007 22:38:23 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9J5cN4L029919; Thu, 18 Oct 2007 22:38:23 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQ500E018V9EY00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Thu, 18 Oct 2007 22:38:23 -0700 (PDT) Received: from [192.168.251.11] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQ5006J38ZYHBF0@fe-sfbay-09.sun.com>; Thu, 18 Oct 2007 22:38:23 -0700 (PDT) Date: Thu, 18 Oct 2007 22:35:33 -0700 From: "Garrett D'Amore" Subject: Re: Intel AMT [PSARC/2007/601 Self Review In-reply-to: <47183422.6080503@sun.com> Sender: Garrett.Damore@sun.com To: "brian.xu" Cc: Paul Jakma , Nicolas Williams , Bill Sommerfeld , James Carlson , PSARC-ext@sun.com, David Chieu , Vincent Wang , Mark Logan Message-id: <47184225.5020102@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47156E73.3060207@sun.com> <4715F129.2010704@sun.com> <47160F4D.9040704@sun.com> <18198.6735.800976.111283@gargle.gargle.HOWL> <1192634666.3938.66.camel@localhost> <20071017154427.GD29257@Sun.COM> <4716329D.8060501@sun.com> <47183422.6080503@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 710 brian.xu wrote: > Garrett D'Amore ??: >> Paul Jakma wrote: >>> On Wed, 17 Oct 2007, Nicolas Williams wrote: >>> >>>> My impression was that the AMT chip gets its own IPv4 address. >>> >>> I'd be curious if the MAC address is still shared for this case or >>> not though. >>> >>> regards, >> >> No, in that config they have separate MAC addresses. And this option >> is only available with wired ethernet, not wifi. > Wifi may also have separate MAC address. The intel 4965 chipset does > have separate and unique MAC address for the Host and AMT. Neat. I think that must be a new feature, because we were told the 3965 at least did not have such a feature. - Garrett > > --Brian >> >> -- Garrett > From David.Chieu@sun.com Wed Nov 28 19:02:11 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAT32ALY018754 for ; Wed, 28 Nov 2007 19:02:10 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lAT31qG6006832; Thu, 29 Nov 2007 11:02:09 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JS800207Z3IHQ00@nwk-avmta-2.sfbay.sun.com>; Wed, 28 Nov 2007 19:02:06 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS800GUAZ3IVJB0@nwk-avmta-2.sfbay.sun.com>; Wed, 28 Nov 2007 19:02:06 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lAT326Ld021579; Wed, 28 Nov 2007 19:02:06 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS800M01Z1Y0F00@fe-sfbay-10.sun.com> (original mail from David.Chieu@Sun.COM); Wed, 28 Nov 2007 19:02:06 -0800 (PST) Received: from [129.153.3.97] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS800DUMZ3H3A50@fe-sfbay-10.sun.com>; Wed, 28 Nov 2007 19:02:06 -0800 (PST) Date: Wed, 28 Nov 2007 19:02:24 -0800 From: David Chieu Subject: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory Sender: David.Chieu@sun.com To: PSARC-ext@sun.com Cc: intel-amt-iteam@sun.com Message-id: <474E2BC0.2020203@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.6 (X11/20070924) Status: RO Content-Length: 968 As you know, we've submitted PSARC 2007/601 Intel AMT case about a month ago. There were a barrage of interested questions asked immediately, so we've taken our case off of the fast-track and started to prepare a more detailed documentation. With gracious helps from some of the PSARC members, we've generated a "spec.txt" which is numbered/initialed with detailed answers of already asked + expected questions. We also have broken this doc into major pertinent areas of Intel's AMT: intro, admin/config, security, network, use cases, driver, proxy, virtualization, FMA, and potential customers. Please see the case directory for either spec_amt_draft_v.1.6.pdf or spec_amt_draft_v.1.6.sxw. Please note, the luminary index for Q&A: Garrett D'Amore = (gd) James Carlson = (jc) Bill Sommerfeld = (bs) Nicolas Williams = (nw) Paul Jakma = (pj) Gary Winiger = (gw) Randy Fishel = (rf) The timer for this case is now set to 12/05/2007 -- The Solaris AMT team From Mark.Carlson@Sun.COM Thu Nov 29 07:36:05 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lATFa5F7002076 for ; Thu, 29 Nov 2007 07:36:05 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lATFa4WU024971; Thu, 29 Nov 2007 08:36:04 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JS900G2XY044900@brm-avmta-1.central.sun.com>; Thu, 29 Nov 2007 08:36:04 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS900AK1XYWZY40@brm-avmta-1.central.sun.com>; Thu, 29 Nov 2007 08:35:20 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lATFZK4T023729; Thu, 29 Nov 2007 15:35:20 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS900D01WDLEX00@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM); Thu, 29 Nov 2007 08:35:20 -0700 (MST) Received: from Macintosh-4.local ([129.150.37.166]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS9003K9XY56Z00@mail-amer.sun.com>; Thu, 29 Nov 2007 08:34:53 -0700 (MST) Date: Thu, 29 Nov 2007 08:34:53 -0700 From: "Mark A. Carlson" Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory In-reply-to: <474E2BC0.2020203@sun.com> Sender: Mark.Carlson@Sun.COM To: David Chieu Cc: PSARC-ext@Sun.COM, intel-amt-iteam@Sun.COM Message-id: <474EDC1D.3060200@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <474E2BC0.2020203@sun.com> User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Status: RO Content-Length: 1185 David, I would like to see the AMT and CIM Schema exported by this project listed as a Committed interface in the interface table. Thanks, -- mark David Chieu wrote: > As you know, we've submitted PSARC 2007/601 Intel AMT case about a > month ago. There were a barrage of interested questions asked > immediately, so we've taken our case off of the fast-track and started > to prepare a more detailed documentation. With gracious helps from > some of the PSARC members, we've generated a "spec.txt" which is > numbered/initialed with detailed answers of already asked + expected > questions. We also have broken this doc into major pertinent areas of > Intel's AMT: intro, admin/config, security, network, use cases, > driver, proxy, virtualization, FMA, and potential customers. Please > see the case directory for either spec_amt_draft_v.1.6.pdf or > spec_amt_draft_v.1.6.sxw. > > Please note, the luminary index for Q&A: > > Garrett D'Amore = (gd) > James Carlson = (jc) > Bill Sommerfeld = (bs) > Nicolas Williams = (nw) > Paul Jakma = (pj) > Gary Winiger = (gw) > Randy Fishel = (rf) > > The timer for this case is now set to 12/05/2007 > > -- The Solaris AMT team From gdamore@sun.com Thu Nov 29 08:00:06 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lATG05RA002784 for ; Thu, 29 Nov 2007 08:00:06 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lATG03MV025436; Thu, 29 Nov 2007 16:00:04 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JS90020RZ420400@nwk-avmta-1.sfbay.Sun.COM>; Thu, 29 Nov 2007 08:00:02 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS9007IUZ40WSB0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 29 Nov 2007 08:00:00 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lATG00JV007044; Thu, 29 Nov 2007 08:00:00 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS900701Z1XWY00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) ; Thu, 29 Nov 2007 08:00:00 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS900JS4Z3USL20@fe-sfbay-10.sun.com>; Thu, 29 Nov 2007 07:59:54 -0800 (PST) Date: Thu, 29 Nov 2007 07:54:54 -0800 From: "Garrett D'Amore" Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory In-reply-to: <474EDC1D.3060200@sun.com> Sender: Garrett.Damore@sun.com To: "Mark A. Carlson" Cc: David Chieu , PSARC-ext@sun.com, intel-amt-iteam@sun.com Message-id: <474EE0CE.5030903@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <474E2BC0.2020203@sun.com> <474EDC1D.3060200@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 1493 Mark A. Carlson wrote: > David, > > I would like to see the AMT and CIM Schema exported by this project > listed as a Committed interface in the interface table. Hmm... I'm not sure how stable they are from Intel. Committed Volatile? Again, this project is just an HTTP proxy in what it passes. The HTTP *content* is beyond the projects control, as it is supplied by Intel firmware. -- Garrett > > Thanks, > > -- mark > > David Chieu wrote: >> As you know, we've submitted PSARC 2007/601 Intel AMT case about a >> month ago. There were a barrage of interested questions asked >> immediately, so we've taken our case off of the fast-track and >> started to prepare a more detailed documentation. With gracious helps >> from some of the PSARC members, we've generated a "spec.txt" which is >> numbered/initialed with detailed answers of already asked + expected >> questions. We also have broken this doc into major pertinent areas of >> Intel's AMT: intro, admin/config, security, network, use cases, >> driver, proxy, virtualization, FMA, and potential customers. Please >> see the case directory for either spec_amt_draft_v.1.6.pdf or >> spec_amt_draft_v.1.6.sxw. >> >> Please note, the luminary index for Q&A: >> >> Garrett D'Amore = (gd) >> James Carlson = (jc) >> Bill Sommerfeld = (bs) >> Nicolas Williams = (nw) >> Paul Jakma = (pj) >> Gary Winiger = (gw) >> Randy Fishel = (rf) >> >> The timer for this case is now set to 12/05/2007 >> >> -- The Solaris AMT team From Mark.Carlson@sun.com Thu Nov 29 08:10:03 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lATGA2cm003255 for ; Thu, 29 Nov 2007 08:10:03 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lATG9nH8021620; Fri, 30 Nov 2007 00:10:01 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JS900J0RZKLTL00@nwk-avmta-2.sfbay.sun.com>; Thu, 29 Nov 2007 08:09:57 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS9005FPZKJ2HC0@nwk-avmta-2.sfbay.sun.com>; Thu, 29 Nov 2007 08:09:55 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lATG9tYf010140; Thu, 29 Nov 2007 16:09:55 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS900401YW6QC00@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM); Thu, 29 Nov 2007 09:09:55 -0700 (MST) Received: from Macintosh-4.local ([129.150.37.166]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS900GW9ZKEU8G0@mail-amer.sun.com>; Thu, 29 Nov 2007 09:09:51 -0700 (MST) Date: Thu, 29 Nov 2007 09:09:53 -0700 From: "Mark A. Carlson" Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory In-reply-to: <474EE0CE.5030903@sun.com> Sender: Mark.Carlson@sun.com To: "Garrett D'Amore" Cc: David Chieu , PSARC-ext@sun.com, intel-amt-iteam@sun.com Message-id: <474EE451.5050002@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <474E2BC0.2020203@sun.com> <474EDC1D.3060200@sun.com> <474EE0CE.5030903@sun.com> User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Status: RO Content-Length: 1866 Actually, it is based on the industry standard CIM schema with AMT extensions. It may even implement some standard SMASH profiles from the DMTF as well, but I can't seem to find documentation of that. What a consumer of this interface actually programs to is the schema, not the protocol. -- mark Garrett D'Amore wrote: > Mark A. Carlson wrote: >> David, >> >> I would like to see the AMT and CIM Schema exported by this project >> listed as a Committed interface in the interface table. > > Hmm... I'm not sure how stable they are from Intel. Committed Volatile? > > Again, this project is just an HTTP proxy in what it passes. The HTTP > *content* is beyond the projects control, as it is supplied by Intel > firmware. > > -- Garrett >> >> Thanks, >> >> -- mark >> >> David Chieu wrote: >>> As you know, we've submitted PSARC 2007/601 Intel AMT case about a >>> month ago. There were a barrage of interested questions asked >>> immediately, so we've taken our case off of the fast-track and >>> started to prepare a more detailed documentation. With gracious >>> helps from some of the PSARC members, we've generated a "spec.txt" >>> which is numbered/initialed with detailed answers of already asked + >>> expected questions. We also have broken this doc into major >>> pertinent areas of Intel's AMT: intro, admin/config, security, >>> network, use cases, driver, proxy, virtualization, FMA, and >>> potential customers. Please see the case directory for either >>> spec_amt_draft_v.1.6.pdf or spec_amt_draft_v.1.6.sxw. >>> >>> Please note, the luminary index for Q&A: >>> >>> Garrett D'Amore = (gd) >>> James Carlson = (jc) >>> Bill Sommerfeld = (bs) >>> Nicolas Williams = (nw) >>> Paul Jakma = (pj) >>> Gary Winiger = (gw) >>> Randy Fishel = (rf) >>> >>> The timer for this case is now set to 12/05/2007 >>> >>> -- The Solaris AMT team > From Vincent.Wang@sun.com Thu Nov 29 08:47:46 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lATGlkGj003747 for ; Thu, 29 Nov 2007 08:47:46 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lATGldgm026716; Thu, 29 Nov 2007 08:47:46 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSA00L1L1BLBZ00@brm-avmta-1.central.sun.com>; Thu, 29 Nov 2007 09:47:45 -0700 (MST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSA00B9D1BJ0090@brm-avmta-1.central.sun.com>; Thu, 29 Nov 2007 09:47:44 -0700 (MST) Received: from fe-apac-03.sun.com (fe-apac-03.sun.com [192.18.19.174] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lATGlhqf018316; Thu, 29 Nov 2007 16:47:43 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JSA0070110HHE00@mail-apac.sun.com> (original mail from Vincent.Wang@Sun.COM); Fri, 30 Nov 2007 00:47:42 +0800 (SGT) Received: from [61.51.113.34] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JSA008CT1BFXDT5@mail-apac.sun.com>; Fri, 30 Nov 2007 00:47:42 +0800 (SGT) Date: Fri, 30 Nov 2007 00:52:07 +0800 From: Vincent Wang Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory In-reply-to: <474EE451.5050002@sun.com> Sender: Vincent.Wang@sun.com To: "Mark A. Carlson" Cc: "Garrett D'Amore" , David Chieu , PSARC-ext@sun.com, intel-amt-iteam@sun.com Message-id: <474EEE37.5030506@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <474E2BC0.2020203@sun.com> <474EDC1D.3060200@sun.com> <474EE0CE.5030903@sun.com> <474EE451.5050002@sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 Status: RO Content-Length: 2536 Mark, You're right it is based on standard CIM schema, but the AMT extensions are not standard AFAIK. The schema can be found in AMT SDK. It has been evolving from v1.0 to v3.0. And we've already heard about AMT 5.0 (not yet released) AMT is currently an 'Intel only' technology. We basically have no control over these interfaces. What this project ships is LMS&HECI which understands neither the protocol nor the schema. A consumer needs to reference the AMT SDK corresponding to a specific version of the firmware. These are beyond our control. Vincent. Mark A. Carlson wrote: > Actually, it is based on the industry standard CIM schema > with AMT extensions. It may even implement some standard SMASH profiles > from the DMTF as well, but I can't seem to find documentation of that. > > What a consumer of this interface actually programs to is the schema, > not the protocol. > > -- mark > > Garrett D'Amore wrote: > >> Mark A. Carlson wrote: >> >>> David, >>> >>> I would like to see the AMT and CIM Schema exported by this project >>> listed as a Committed interface in the interface table. >> >> >> Hmm... I'm not sure how stable they are from Intel. Committed Volatile? >> >> Again, this project is just an HTTP proxy in what it passes. The >> HTTP *content* is beyond the projects control, as it is supplied by >> Intel firmware. >> >> -- Garrett >> >>> >>> Thanks, >>> >>> -- mark >>> >>> David Chieu wrote: >>> >>>> As you know, we've submitted PSARC 2007/601 Intel AMT case about a >>>> month ago. There were a barrage of interested questions asked >>>> immediately, so we've taken our case off of the fast-track and >>>> started to prepare a more detailed documentation. With gracious >>>> helps from some of the PSARC members, we've generated a "spec.txt" >>>> which is numbered/initialed with detailed answers of already asked >>>> + expected questions. We also have broken this doc into major >>>> pertinent areas of Intel's AMT: intro, admin/config, security, >>>> network, use cases, driver, proxy, virtualization, FMA, and >>>> potential customers. Please see the case directory for either >>>> spec_amt_draft_v.1.6.pdf or spec_amt_draft_v.1.6.sxw. >>>> >>>> Please note, the luminary index for Q&A: >>>> >>>> Garrett D'Amore = (gd) >>>> James Carlson = (jc) >>>> Bill Sommerfeld = (bs) >>>> Nicolas Williams = (nw) >>>> Paul Jakma = (pj) >>>> Gary Winiger = (gw) >>>> Randy Fishel = (rf) >>>> >>>> The timer for this case is now set to 12/05/2007 >>>> >>>> -- The Solaris AMT team >>> >> From John.Plocher@sun.com Thu Nov 29 09:22:35 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lATHMZho004613 for ; Thu, 29 Nov 2007 09:22:35 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lATHMYm4013982; Thu, 29 Nov 2007 10:22:34 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSA000052XMQO00@brm-avmta-1.central.sun.com>; Thu, 29 Nov 2007 10:22:34 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSA00B002XM03B0@brm-avmta-1.central.sun.com>; Thu, 29 Nov 2007 10:22:34 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lATHMY9H016996; Thu, 29 Nov 2007 09:22:34 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSA003012SXV800@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Thu, 29 Nov 2007 09:22:34 -0800 (PST) Received: from wp668.SFBay.Sun.COM ([129.146.58.87]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSA00GFA2XJSK20@fe-sfbay-09.sun.com>; Thu, 29 Nov 2007 09:22:31 -0800 (PST) Date: Thu, 29 Nov 2007 09:22:30 -0800 From: John Plocher Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory In-reply-to: <474EEE37.5030506@sun.com> Sender: John.Plocher@sun.com To: Vincent Wang Cc: "Mark A. Carlson" , David Chieu , PSARC-ext@sun.com, "Garrett D'Amore" , intel-amt-iteam@sun.com Message-id: <474EF556.7070008@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <474E2BC0.2020203@sun.com> <474EDC1D.3060200@sun.com> <474EE0CE.5030903@sun.com> <474EE451.5050002@sun.com> <474EEE37.5030506@sun.com> User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Status: RO Content-Length: 736 Vincent Wang wrote: > AMT is currently an 'Intel only' technology. What is obvious here is that of the two failure modes: A) "being different from Intel" and B) "evolving incompatibly", the first is much much more undesirable. Vincent's comment that "It has been evolving from v1.0 to v3.0. And we've already heard about AMT 5.0" suggests strongly that this project needs to include the version number AND to support the coexistence of multiple versions on/in a system (i.e., this project shouldn't be hardcoded to just support version 2.3...). I'm not sure of the usage model, but it should be possible to find out which version(s) of AMT is/are being exposed and to tailor ones interactions appropriately... -John From David.Chieu@sun.com Thu Nov 29 12:41:28 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lATKfRuP013273 for ; Thu, 29 Nov 2007 12:41:27 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lATKfOQL008603; Thu, 29 Nov 2007 20:41:26 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSA00809C507K00@nwk-avmta-2.sfbay.sun.com>; Thu, 29 Nov 2007 12:41:24 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSA002EBC4Z8R90@nwk-avmta-2.sfbay.sun.com>; Thu, 29 Nov 2007 12:41:23 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lATKfN6D018115; Thu, 29 Nov 2007 12:41:23 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSA00101C0N1100@fe-sfbay-10.sun.com> (original mail from David.Chieu@Sun.COM); Thu, 29 Nov 2007 12:41:23 -0800 (PST) Received: from [129.153.3.97] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSA007JLC4YHV90@fe-sfbay-10.sun.com>; Thu, 29 Nov 2007 12:41:22 -0800 (PST) Date: Thu, 29 Nov 2007 12:41:40 -0800 From: David Chieu Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory In-reply-to: <474EF556.7070008@Sun.Com> Sender: David.Chieu@sun.com To: John Plocher Cc: Vincent Wang , "Mark A. Carlson" , PSARC-ext@sun.com, "Garrett D'Amore" , intel-amt-iteam@sun.com Message-id: <474F2404.303@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <474E2BC0.2020203@sun.com> <474EDC1D.3060200@sun.com> <474EE0CE.5030903@sun.com> <474EE451.5050002@sun.com> <474EEE37.5030506@sun.com> <474EF556.7070008@Sun.Com> User-Agent: Thunderbird 2.0.0.6 (X11/20070924) Status: RO Content-Length: 1102 John Plocher wrote: > Vincent Wang wrote: >> AMT is currently an 'Intel only' technology. > > > What is obvious here is that of the two failure modes: > A) "being different from Intel" and > B) "evolving incompatibly", > > the first is much much more undesirable. > > Vincent's comment that "It has been evolving from v1.0 to v3.0. > And we've already heard about AMT 5.0" suggests strongly that this > project needs to include the version number AND to support the > coexistence of multiple versions on/in a system (i.e., this > project shouldn't be hardcoded to just support version 2.3...). > This project supports AMT 3.x and higher systems. Intel states future versions will be forward compatible. So, e.g. AMT 5.x is expected to work with our implementation. However, AMT 1.x & 2.x are not supported in this project. We've not received marketing requirements to support versions less than AMT 3.x. > I'm not sure of the usage model, but it should be possible to > find out which version(s) of AMT is/are being exposed and to > tailor ones interactions appropriately... > > -John From John.Plocher@sun.com Thu Nov 29 13:12:35 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lATLCYG4014278 for ; Thu, 29 Nov 2007 13:12:34 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lATLCVxa010045; Fri, 30 Nov 2007 05:12:33 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSA00I01DKVTG00@brm-avmta-1.central.sun.com>; Thu, 29 Nov 2007 14:12:31 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSA00IHLDKUBV00@brm-avmta-1.central.sun.com>; Thu, 29 Nov 2007 14:12:30 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lATLCUir018380; Thu, 29 Nov 2007 13:12:30 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSA00I01DJ87200@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Thu, 29 Nov 2007 13:12:30 -0800 (PST) Received: from wp668.SFBay.Sun.COM ([129.146.58.87]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSA00GXEDKU22B0@fe-sfbay-09.sun.com>; Thu, 29 Nov 2007 13:12:30 -0800 (PST) Date: Thu, 29 Nov 2007 13:12:28 -0800 From: John Plocher Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory In-reply-to: <474F2404.303@sun.com> Sender: John.Plocher@sun.com To: David Chieu Cc: Vincent Wang , "Mark A. Carlson" , PSARC-ext@sun.com, "Garrett D'Amore" , intel-amt-iteam@sun.com Message-id: <474F2B3C.5080801@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <474E2BC0.2020203@sun.com> <474EDC1D.3060200@sun.com> <474EE0CE.5030903@sun.com> <474EE451.5050002@sun.com> <474EEE37.5030506@sun.com> <474EF556.7070008@Sun.Com> <474F2404.303@sun.com> User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Status: RO Content-Length: 369 David Chieu wrote: > This project supports AMT 3.x and higher systems. Intel states future > versions will be forward compatible. So, e.g. AMT 5.x is expected to > work with our implementation. However, AMT 1.x & 2.x are not supported > in this project. We've not received marketing requirements to support > versions less than AMT 3.x. OK, I'm happy. -John From gww@eng.sun.com Wed Dec 5 10:42:00 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB5IfxiD009208 for ; Wed, 5 Dec 2007 10:41:59 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lB5IfnZg006166; Thu, 6 Dec 2007 02:41:57 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSL00F4FALUMX00@brm-avmta-1.central.sun.com>; Wed, 05 Dec 2007 11:41:54 -0700 (MST) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSL0057HALTV680@brm-avmta-1.central.sun.com>; Wed, 05 Dec 2007 11:41:53 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id lB5IfraH011738; Wed, 05 Dec 2007 10:41:53 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id lB5IeDt0008028; Wed, 05 Dec 2007 10:40:13 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id lB5IeDUJ008027; Wed, 05 Dec 2007 10:40:13 -0800 (PST) Date: Wed, 05 Dec 2007 10:40:13 -0800 (PST) From: Gary Winiger Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory To: David.Chieu@sun.com, PSARC-ext@sun.com Cc: intel-amt-iteam@sun.com Message-id: <200712051840.lB5IeDUJ008027@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1909 > As you know, we've submitted PSARC 2007/601 Intel AMT case about a month > ago. There were a barrage of interested questions asked immediately, so > The timer for this case is now set to 12/05/2007 > -- The Solaris AMT team Team, thanks for the excellent update. Still a few open questions: * Other than the IOCTL, I've missed seeing interface taxonomies. * I've also missed seeing the release binding. * What's the set of exported interface? * 5.6-5.8 seem incomplete to me. What privileges? What Rights Profiles, and why? Perhaps more explicitly, what's the method_context of svc:/network/lms and how does this proposed service comply to the SMF policy: http://opensolaris.org/os/community/arc/policies/SMF-policy/ (which unfortunately is 2 revs behind the internal http://sac.eng/cgi-bin/bp.cgi?NAME=SMF.bp) Yes I'm sending John email once again ;-{ * 6.15 " is there any way for other software in the system ... that a given network interface is running AMT?" Answer: "It *should* be possible ..." will this be done? * 7 "? Remotely Protect Computing Assets : Through Out of Band communication, each system's software version numbers are checked and, if necessary, system software and virus protection are remotely updated with the most recent patches and virus definitions. Viruses and worms can also be contained at their source, if needed, by means of built-in circuit-breaker functionality. "Intel AMT infrastructure supports the creation of setup and configuration interfaces for management applications, as well as network, security, and storage administration." What does this mean relative to this project? How are Solaris veriion numbers (service tags ;-) being checked? How is Solaris system software and virus protection being remotely updated with the most recent patches and virus definitions? Gary.. From David.Chieu@sun.com Wed Dec 5 17:55:08 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB61t8rZ019254 for ; Wed, 5 Dec 2007 17:55:08 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lB61t70m000547; Wed, 5 Dec 2007 17:55:07 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSL00M0HUNVL500@nwk-avmta-2.sfbay.sun.com>; Wed, 05 Dec 2007 17:55:07 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSL00GA6UNUA1C0@nwk-avmta-2.sfbay.sun.com>; Wed, 05 Dec 2007 17:55:06 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lB61t6Qk014998; Wed, 05 Dec 2007 17:55:06 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSL00M01ULYXR00@fe-sfbay-10.sun.com> (original mail from David.Chieu@Sun.COM); Wed, 05 Dec 2007 17:55:06 -0800 (PST) Received: from [129.153.3.97] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSL00LA7UNUP5A0@fe-sfbay-10.sun.com>; Wed, 05 Dec 2007 17:55:06 -0800 (PST) Date: Wed, 05 Dec 2007 17:55:25 -0800 From: David Chieu Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory In-reply-to: <200712051840.lB5IeDUJ008027@marduk.eng.sun.com> Sender: David.Chieu@sun.com To: Gary Winiger Cc: psarc-ext@sun.com, intel-amt-iteam@sun.com Message-id: <4757568D.2000402@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712051840.lB5IeDUJ008027@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070924) Status: RO Content-Length: 2181 Gary, I'm working with the Beijing team to detail out the answers to you. Meanwhile, I've adjusted timeout to 12/12/2007. -- David Chieu Gary Winiger wrote: >> As you know, we've submitted PSARC 2007/601 Intel AMT case about a month >> ago. There were a barrage of interested questions asked immediately, so >> > > >> The timer for this case is now set to 12/05/2007 >> > > >> -- The Solaris AMT team >> > > Team, thanks for the excellent update. Still a few open questions: > > * Other than the IOCTL, I've missed seeing interface taxonomies. > * I've also missed seeing the release binding. > * What's the set of exported interface? > * 5.6-5.8 seem incomplete to me. What privileges? What Rights > Profiles, and why? Perhaps more explicitly, what's the > method_context of svc:/network/lms and how does this proposed > service comply to the SMF policy: > http://opensolaris.org/os/community/arc/policies/SMF-policy/ > (which unfortunately is 2 revs behind the internal > http://sac.eng/cgi-bin/bp.cgi?NAME=SMF.bp) > Yes I'm sending John email once again ;-{ > * 6.15 " is there any way for other software in the system ... > that a given network interface is running AMT?" > Answer: "It *should* be possible ..." > will this be done? > * 7 "? Remotely Protect Computing Assets : Through Out of Band > communication, each system's software version numbers are checked > and, if necessary, system software and virus protection are > remotely updated with the most recent patches and virus definitions. > Viruses and worms can also be contained at their source, if needed, > by means of built-in circuit-breaker functionality. > > "Intel AMT infrastructure supports the creation of setup and > configuration interfaces for management applications, as well > as network, security, and storage administration." > > What does this mean relative to this project? How are Solaris > veriion numbers (service tags ;-) being checked? How is Solaris > system software and virus protection being remotely updated > with the most recent patches and virus definitions? > > Gary.. > From David.Chieu@sun.com Thu Dec 6 14:54:30 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB6MsTM4017352 for ; Thu, 6 Dec 2007 14:54:29 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lB6MsRIX029852; Fri, 7 Dec 2007 06:54:28 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSN0090TGYPGK00@nwk-avmta-2.sfbay.sun.com>; Thu, 06 Dec 2007 14:54:25 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSN00MH9GYPWHB0@nwk-avmta-2.sfbay.sun.com>; Thu, 06 Dec 2007 14:54:25 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lB6MsPYn005394; Thu, 06 Dec 2007 14:54:25 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSN00D01GRT9800@fe-sfbay-09.sun.com> (original mail from David.Chieu@Sun.COM); Thu, 06 Dec 2007 14:54:25 -0800 (PST) Received: from [129.153.3.97] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSN00229GYO6ME0@fe-sfbay-09.sun.com>; Thu, 06 Dec 2007 14:54:24 -0800 (PST) Date: Thu, 06 Dec 2007 14:54:44 -0800 From: David Chieu Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory In-reply-to: <200712051840.lB5IeDUJ008027@marduk.eng.sun.com> Sender: David.Chieu@sun.com To: Gary Winiger Cc: psarc-ext@sun.com, intel-amt-iteam@sun.com Message-id: <47587DB4.8020206@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712051840.lB5IeDUJ008027@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070924) Status: RO Content-Length: 3217 Gary Winiger wrote: > ... > Team, thanks for the excellent update. Still a few open questions: > > * Other than the IOCTL, I've missed seeing interface taxonomies. > * I've also missed seeing the release binding. > * What's the set of exported interface? > The interface taxonomy for the IOCTLs is "project private", release binding: micro/patch. Other than that there's no other exported interface. The users are directly talking to the firmware which is AMT's real interface-provider. This project only provides an HTTP(s) service on TCP port 16992/16993 to relay the messages to/from the firmware. > * 5.6-5.8 seem incomplete to me. What privileges? What Rights > Profiles, and why? Perhaps more explicitly, what's the > method_context of svc:/network/lms and how does this proposed > service comply to the SMF policy: > http://opensolaris.org/os/community/arc/policies/SMF-policy/ > (which unfortunately is 2 revs behind the internal > http://sac.eng/cgi-bin/bp.cgi?NAME=SMF.bp) > Yes I'm sending John email once again ;-{ > The method_context section of LMS includes a limited set of privileges: basic,sys_net_config,net_rawaccess This is to grant LMS the rights to open /dev/heci and send IOCTLs. A new authorization "solaris.smf.manage.lms" will be defined and listed under the "Network Management" profile in /etc/security/prof_attr. Using RBAC, Only users with the "solaris.smf.manage.lms" authorization can enable/disable the LMS service. > * 6.15 " is there any way for other software in the system ... > that a given network interface is running AMT?" > Answer: "It *should* be possible ..." > will this be done? > Lacking hardware related information from Intel, this will not be done in phase I. However, it's added to the plan for Phase II. Good catch. > * 7 "? Remotely Protect Computing Assets : Through Out of Band > communication, each system's software version numbers are checked > and, if necessary, system software and virus protection are > remotely updated with the most recent patches and virus definitions. > Viruses and worms can also be contained at their source, if needed, > by means of built-in circuit-breaker functionality. > > "Intel AMT infrastructure supports the creation of setup and > configuration interfaces for management applications, as well > as network, security, and storage administration." > > What does this mean relative to this project? How are Solaris > veriion numbers (service tags ;-) being checked? How is Solaris > system software and virus protection being remotely updated > with the most recent patches and virus definitions? > > Gary.. > This project currently does not deliver these features for phase I. But after the integration of this project will work with ISVs (i.e. anti-virus vendors, etc.) to add the above mentioned feature. The implementation detail is TDB. However, we realize/document the following AMT capabilities e.g. Remote software version checking/updating can be done by the using the EEPROM named 3PDS (3rd Party Data Storage), and share it with remote management console. See 6.18 about StorageRealm. -- The Solaris AMT team From Mark.Logan@sun.com Tue Dec 11 11:40:27 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBBJeQOK011036 for ; Tue, 11 Dec 2007 11:40:27 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBBJeKTN023790; Wed, 12 Dec 2007 03:40:26 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSW00207HBB2U00@nwk-avmta-2.sfbay.sun.com>; Tue, 11 Dec 2007 11:40:23 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSW00I6DHBA19A0@nwk-avmta-2.sfbay.sun.com>; Tue, 11 Dec 2007 11:40:22 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBBJeMmq015119; Tue, 11 Dec 2007 11:40:22 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSW00D01GVMOE00@fe-sfbay-09.sun.com> (original mail from Mark.Logan@Sun.COM); Tue, 11 Dec 2007 11:40:22 -0800 (PST) Received: from [10.1.48.235] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSW003NVHB9A4A0@fe-sfbay-09.sun.com>; Tue, 11 Dec 2007 11:40:21 -0800 (PST) Date: Tue, 11 Dec 2007 11:38:37 -0800 From: Mark Logan Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory In-reply-to: <200712051840.lB5IeDUJ008027@marduk.eng.sun.com> Sender: Mark.Logan@sun.com To: Gary Winiger Cc: David.Chieu@sun.com, psarc-ext@sun.com, intel-amt-iteam@sun.com Message-id: <475EE73D.9030006@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712051840.lB5IeDUJ008027@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 2271 Hi Gary, I have an answer to one of your questions: Gary Winiger wrote: > > Team, thanks for the excellent update. Still a few open questions: > > * Other than the IOCTL, I've missed seeing interface taxonomies. > * I've also missed seeing the release binding. > * What's the set of exported interface? > * 5.6-5.8 seem incomplete to me. What privileges? What Rights > Profiles, and why? Perhaps more explicitly, what's the > method_context of svc:/network/lms and how does this proposed > service comply to the SMF policy: > http://opensolaris.org/os/community/arc/policies/SMF-policy/ > (which unfortunately is 2 revs behind the internal > http://sac.eng/cgi-bin/bp.cgi?NAME=SMF.bp) > Yes I'm sending John email once again ;-{ > Here is the method_context. The lms daemon needs no additional privileges beyond opening the /dev/heci device: > * 6.15 " is there any way for other software in the system ... > that a given network interface is running AMT?" > Answer: "It *should* be possible ..." > will this be done? > * 7 "? Remotely Protect Computing Assets : Through Out of Band > communication, each system's software version numbers are checked > and, if necessary, system software and virus protection are > remotely updated with the most recent patches and virus definitions. > Viruses and worms can also be contained at their source, if needed, > by means of built-in circuit-breaker functionality. > > "Intel AMT infrastructure supports the creation of setup and > configuration interfaces for management applications, as well > as network, security, and storage administration." > > What does this mean relative to this project? How are Solaris > veriion numbers (service tags ;-) being checked? How is Solaris > system software and virus protection being remotely updated > with the most recent patches and virus definitions? > > Gary.. > From gww@eng.sun.com Tue Dec 11 12:25:20 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBBKPJSC012926 for ; Tue, 11 Dec 2007 12:25:20 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBBKPDON010863; Tue, 11 Dec 2007 20:25:18 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSW0030RJE6TZ00@nwk-avmta-2.sfbay.sun.com>; Tue, 11 Dec 2007 12:25:18 -0800 (PST) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSW00IJ1JE20VD0@nwk-avmta-2.sfbay.sun.com>; Tue, 11 Dec 2007 12:25:14 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id lBBKPEPj029297; Tue, 11 Dec 2007 12:25:14 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id lBBKNQx9015929; Tue, 11 Dec 2007 12:23:26 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id lBBKNPRV015928; Tue, 11 Dec 2007 12:23:25 -0800 (PST) Date: Tue, 11 Dec 2007 12:23:25 -0800 (PST) From: Gary Winiger Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory To: David.Chieu@sun.com, gww@eng.sun.com Cc: intel-amt-iteam@sun.com, psarc-ext@sun.com Message-id: <200712112023.lBBKNPRV015928@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 3813 > From David.Chieu@sun.com Thu Dec 6 14:54:30 2007 > Date: Thu, 06 Dec 2007 14:54:44 -0800 > From: David Chieu > Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to > the materials directory > To: Gary Winiger > Cc: psarc-ext@sun.com, intel-amt-iteam@sun.com > Content-transfer-encoding: 7BIT > X-PMX-Version: 5.2.0.264296 > User-Agent: Thunderbird 2.0.0.6 (X11/20070924) > > Gary Winiger wrote: > > ... > > Team, thanks for the excellent update. Still a few open questions: > > > > * Other than the IOCTL, I've missed seeing interface taxonomies. > > * I've also missed seeing the release binding. > > * What's the set of exported interface? > > > The interface taxonomy for the IOCTLs is "project private", release > binding: micro/patch. > Other than that there's no other exported interface. The users are > directly talking > to the firmware which is AMT's real interface-provider. This project > only provides > an HTTP(s) service on TCP port 16992/16993 to relay the messages to/from > the firmware. > > * 5.6-5.8 seem incomplete to me. What privileges? What Rights > > Profiles, and why? Perhaps more explicitly, what's the > > method_context of svc:/network/lms and how does this proposed > > service comply to the SMF policy: > > http://opensolaris.org/os/community/arc/policies/SMF-policy/ > > (which unfortunately is 2 revs behind the internal > > http://sac.eng/cgi-bin/bp.cgi?NAME=SMF.bp) > > Yes I'm sending John email once again ;-{ > > > The method_context section of LMS includes a limited set of privileges: > basic,sys_net_config,net_rawaccess > This is to grant LMS the rights to open /dev/heci and send IOCTLs. > > A new authorization "solaris.smf.manage.lms" will be defined and listed > under the > "Network Management" profile in /etc/security/prof_attr. Using RBAC, > Only users with the > "solaris.smf.manage.lms" authorization can enable/disable the LMS service. > > * 6.15 " is there any way for other software in the system ... > > that a given network interface is running AMT?" > > Answer: "It *should* be possible ..." > > will this be done? > > > Lacking hardware related information from Intel, this will not be done > in phase I. However, it's added to the plan for Phase II. Good catch. > > * 7 "? Remotely Protect Computing Assets : Through Out of Band > > communication, each system's software version numbers are checked > > and, if necessary, system software and virus protection are > > remotely updated with the most recent patches and virus definitions. > > Viruses and worms can also be contained at their source, if needed, > > by means of built-in circuit-breaker functionality. > > > > "Intel AMT infrastructure supports the creation of setup and > > configuration interfaces for management applications, as well > > as network, security, and storage administration." > > > > What does this mean relative to this project? How are Solaris > > veriion numbers (service tags ;-) being checked? How is Solaris > > system software and virus protection being remotely updated > > with the most recent patches and virus definitions? > > > > Gary.. > > > This project currently does not deliver these features for phase I. But > after the integration of > this project will work with ISVs (i.e. anti-virus vendors, etc.) to add > the above mentioned feature. > The implementation detail is TDB. However, we realize/document the > following AMT capabilities > e.g. > Remote software version checking/updating can be done by the using the > EEPROM > named 3PDS (3rd Party Data Storage), and share it with remote management > console. > See 6.18 about StorageRealm. > > -- The Solaris AMT team > !v From gww@eng.sun.com Tue Dec 11 13:03:20 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBBL3JrU014585 for ; Tue, 11 Dec 2007 13:03:19 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBBL37aY027319; Tue, 11 Dec 2007 21:03:18 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSW0050BL5HHA00@nwk-avmta-2.sfbay.sun.com>; Tue, 11 Dec 2007 13:03:17 -0800 (PST) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSW00IUIL5F12E0@nwk-avmta-2.sfbay.sun.com>; Tue, 11 Dec 2007 13:03:15 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id lBBL3FA6014277; Tue, 11 Dec 2007 13:03:15 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id lBBL1Rlr016035; Tue, 11 Dec 2007 13:01:27 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id lBBL1RTx016034; Tue, 11 Dec 2007 13:01:27 -0800 (PST) Date: Tue, 11 Dec 2007 13:01:27 -0800 (PST) From: Gary Winiger Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory To: David.Chieu@sun.com, gww@eng.sun.com Cc: intel-amt-iteam@sun.com, psarc-ext@sun.com Message-id: <200712112101.lBBL1RTx016034@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 4004 OOPS looks like an empty reply escaped my try to kill it. Sorry... > Gary Winiger wrote: > > ... > > Team, thanks for the excellent update. Still a few open questions: > > > > * Other than the IOCTL, I've missed seeing interface taxonomies. > > * I've also missed seeing the release binding. > > * What's the set of exported interface? > > > The interface taxonomy for the IOCTLs is "project private", release > binding: micro/patch. > Other than that there's no other exported interface. The users are > directly talking > to the firmware which is AMT's real interface-provider. This project > only provides > an HTTP(s) service on TCP port 16992/16993 to relay the messages to/from > the firmware. Nits, that could be edifying. It seems to me there might well be other interfaces other than just the IOCTLs lurking about. Yes as I said, I read that the IOCTLs were project private. Other interfaces might be the device name, the service name and service properties. Presumably this is the case that exports the device (/dev/heci), either that or it has a case dependency that I missed. Presumably this is the case that exports the service (svc:/network/lms). Are there any service specific properties? > > * 5.6-5.8 seem incomplete to me. What privileges? What Rights > > Profiles, and why? Perhaps more explicitly, what's the > > method_context of svc:/network/lms and how does this proposed > > service comply to the SMF policy: > > http://opensolaris.org/os/community/arc/policies/SMF-policy/ > > (which unfortunately is 2 revs behind the internal > > http://sac.eng/cgi-bin/bp.cgi?NAME=SMF.bp) > > Yes I'm sending John email once again ;-{ > > > The method_context section of LMS includes a limited set of privileges: > basic,sys_net_config,net_rawaccess > This is to grant LMS the rights to open /dev/heci and send IOCTLs. Hummm, this seems to be different than a later reply. The point is to run with the least effective and permitted privileges an non-system (viz "noaccess" user/group) ids as possible. Anything above that needs some justification. > > * 7 "? Remotely Protect Computing Assets : Through Out of Band > > communication, each system's software version numbers are checked > > and, if necessary, system software and virus protection are > > remotely updated with the most recent patches and virus definitions. > > Viruses and worms can also be contained at their source, if needed, > > by means of built-in circuit-breaker functionality. > > > > "Intel AMT infrastructure supports the creation of setup and > > configuration interfaces for management applications, as well > > as network, security, and storage administration." > > > > What does this mean relative to this project? How are Solaris > > veriion numbers (service tags ;-) being checked? How is Solaris > > system software and virus protection being remotely updated > > with the most recent patches and virus definitions? > > > > Gary.. > > > This project currently does not deliver these features for phase I. But > after the integration of > this project will work with ISVs (i.e. anti-virus vendors, etc.) to add > the above mentioned feature. > The implementation detail is TDB. However, we realize/document the > following AMT capabilities > e.g. > Remote software version checking/updating can be done by the using the > EEPROM > named 3PDS (3rd Party Data Storage), and share it with remote management > console. > See 6.18 about StorageRealm. Hummm, not for phase I seem OK, but remotely nuking Solaris components without administrative requests seems overall bad. There's the whole "Connected Customer" group under Steve Wilson that needs to be brought into the picture for anything related to Software Updating. I suspect there's a parallel group for Firmware Updating some place in John Fowler's orginization. I'd suggest contacting FWARC before proceeding along those lines. Gary.. From gdamore@sun.com Tue Dec 11 15:00:29 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBBN0SFZ017138 for ; Tue, 11 Dec 2007 15:00:28 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBBMxx9J021499; Tue, 11 Dec 2007 23:00:26 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSW00D29QKPPJ00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Dec 2007 15:00:25 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSW008YWQKEWW10@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Dec 2007 15:00:15 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBBN0Ec2008450; Tue, 11 Dec 2007 15:00:14 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSW00001QH9QI00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) ; Tue, 11 Dec 2007 15:00:14 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSW00F55QKDI240@fe-sfbay-10.sun.com>; Tue, 11 Dec 2007 15:00:13 -0800 (PST) Date: Tue, 11 Dec 2007 14:54:45 -0800 From: "Garrett D'Amore" Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory In-reply-to: <200712112101.lBBL1RTx016034@marduk.eng.sun.com> Sender: Garrett.Damore@sun.com To: Gary Winiger Cc: David.Chieu@sun.com, intel-amt-iteam@sun.com, psarc-ext@sun.com Message-id: <475F1535.7050904@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712112101.lBBL1RTx016034@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 4655 FWIW, I'd recommend *against* stashing a node in /dev. Better to just access the /devices node directly IMO. The /dev links are a convenience that is appropriate for "quasi-public" interfaces... you're not going to need the /dev link (won't this just live in some fixed location like /devices/pseudo or somesuch?) and its one less thing you need to publish. (Plus then no need for devfsadm changes to support the /dev/heci interface.) -- Garrett Gary Winiger wrote: > OOPS looks like an empty reply escaped my try to kill it. > Sorry... > > >> Gary Winiger wrote: >> >>> ... >>> Team, thanks for the excellent update. Still a few open questions: >>> >>> * Other than the IOCTL, I've missed seeing interface taxonomies. >>> * I've also missed seeing the release binding. >>> * What's the set of exported interface? >>> >>> >> The interface taxonomy for the IOCTLs is "project private", release >> binding: micro/patch. >> Other than that there's no other exported interface. The users are >> directly talking >> to the firmware which is AMT's real interface-provider. This project >> only provides >> an HTTP(s) service on TCP port 16992/16993 to relay the messages to/from >> the firmware. >> > > Nits, that could be edifying. > It seems to me there might well be other interfaces other than > just the IOCTLs lurking about. Yes as I said, I read that the > IOCTLs were project private. > Other interfaces might be the device name, the service name > and service properties. > Presumably this is the case that exports the device (/dev/heci), > either that or it has a case dependency that I missed. > Presumably this is the case that exports the service > (svc:/network/lms). > > Are there any service specific properties? > > >>> * 5.6-5.8 seem incomplete to me. What privileges? What Rights >>> Profiles, and why? Perhaps more explicitly, what's the >>> method_context of svc:/network/lms and how does this proposed >>> service comply to the SMF policy: >>> http://opensolaris.org/os/community/arc/policies/SMF-policy/ >>> (which unfortunately is 2 revs behind the internal >>> http://sac.eng/cgi-bin/bp.cgi?NAME=SMF.bp) >>> Yes I'm sending John email once again ;-{ >>> >>> >> The method_context section of LMS includes a limited set of privileges: >> basic,sys_net_config,net_rawaccess >> This is to grant LMS the rights to open /dev/heci and send IOCTLs. >> > > Hummm, this seems to be different than a later reply. The point > is to run with the least effective and permitted privileges > an non-system (viz "noaccess" user/group) ids as possible. > Anything above that needs some justification. > > >>> * 7 "? Remotely Protect Computing Assets : Through Out of Band >>> communication, each system's software version numbers are checked >>> and, if necessary, system software and virus protection are >>> remotely updated with the most recent patches and virus definitions. >>> Viruses and worms can also be contained at their source, if needed, >>> by means of built-in circuit-breaker functionality. >>> >>> "Intel AMT infrastructure supports the creation of setup and >>> configuration interfaces for management applications, as well >>> as network, security, and storage administration." >>> >>> What does this mean relative to this project? How are Solaris >>> veriion numbers (service tags ;-) being checked? How is Solaris >>> system software and virus protection being remotely updated >>> with the most recent patches and virus definitions? >>> >>> Gary.. >>> >>> >> This project currently does not deliver these features for phase I. But >> after the integration of >> this project will work with ISVs (i.e. anti-virus vendors, etc.) to add >> the above mentioned feature. >> The implementation detail is TDB. However, we realize/document the >> following AMT capabilities >> e.g. >> Remote software version checking/updating can be done by the using the >> EEPROM >> named 3PDS (3rd Party Data Storage), and share it with remote management >> console. >> See 6.18 about StorageRealm. >> > > Hummm, not for phase I seem OK, but remotely nuking Solaris > components without administrative requests seems overall bad. > There's the whole "Connected Customer" group under Steve Wilson > that needs to be brought into the picture for anything related > to Software Updating. I suspect there's a parallel group for > Firmware Updating some place in John Fowler's orginization. > I'd suggest contacting FWARC before proceeding along those > lines. > > Gary.. > From Mark.Logan@sun.com Tue Dec 11 19:11:47 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBC3BkBh024010 for ; Tue, 11 Dec 2007 19:11:47 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBC3BWXo016994; Wed, 12 Dec 2007 03:11:45 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSX00M0527KC000@nwk-avmta-2.sfbay.sun.com>; Tue, 11 Dec 2007 19:11:44 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSX00HN627J9Q40@nwk-avmta-2.sfbay.sun.com>; Tue, 11 Dec 2007 19:11:43 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBC3BhIn025680; Tue, 11 Dec 2007 19:11:43 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSX00F0124N8R00@fe-sfbay-10.sun.com> (original mail from Mark.Logan@Sun.COM); Tue, 11 Dec 2007 19:11:43 -0800 (PST) Received: from [10.1.48.235] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSX00GP727ISJ80@fe-sfbay-10.sun.com>; Tue, 11 Dec 2007 19:11:43 -0800 (PST) Date: Tue, 11 Dec 2007 19:09:58 -0800 From: Mark Logan Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory In-reply-to: <200712112101.lBBL1RTx016034@marduk.eng.sun.com> Sender: Mark.Logan@sun.com To: Gary Winiger Cc: David.Chieu@sun.com, intel-amt-iteam@sun.com, psarc-ext@sun.com Message-id: <475F5106.5010005@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712112101.lBBL1RTx016034@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 4332 I'm not sure what you mean by "noaccess". Do you want us to change the method_context for LMS from "root:root" to "noaccess:noaccess"? Gary Winiger wrote: > OOPS looks like an empty reply escaped my try to kill it. > Sorry... > > >> Gary Winiger wrote: >> >>> ... >>> Team, thanks for the excellent update. Still a few open questions: >>> >>> * Other than the IOCTL, I've missed seeing interface taxonomies. >>> * I've also missed seeing the release binding. >>> * What's the set of exported interface? >>> >>> >> The interface taxonomy for the IOCTLs is "project private", release >> binding: micro/patch. >> Other than that there's no other exported interface. The users are >> directly talking >> to the firmware which is AMT's real interface-provider. This project >> only provides >> an HTTP(s) service on TCP port 16992/16993 to relay the messages to/from >> the firmware. >> > > Nits, that could be edifying. > It seems to me there might well be other interfaces other than > just the IOCTLs lurking about. Yes as I said, I read that the > IOCTLs were project private. > Other interfaces might be the device name, the service name > and service properties. > Presumably this is the case that exports the device (/dev/heci), > either that or it has a case dependency that I missed. > Presumably this is the case that exports the service > (svc:/network/lms). > > Are there any service specific properties? > > >>> * 5.6-5.8 seem incomplete to me. What privileges? What Rights >>> Profiles, and why? Perhaps more explicitly, what's the >>> method_context of svc:/network/lms and how does this proposed >>> service comply to the SMF policy: >>> http://opensolaris.org/os/community/arc/policies/SMF-policy/ >>> (which unfortunately is 2 revs behind the internal >>> http://sac.eng/cgi-bin/bp.cgi?NAME=SMF.bp) >>> Yes I'm sending John email once again ;-{ >>> >>> >> The method_context section of LMS includes a limited set of privileges: >> basic,sys_net_config,net_rawaccess >> This is to grant LMS the rights to open /dev/heci and send IOCTLs. >> > > Hummm, this seems to be different than a later reply. The point > is to run with the least effective and permitted privileges > an non-system (viz "noaccess" user/group) ids as possible. > Anything above that needs some justification. > > >>> * 7 "? Remotely Protect Computing Assets : Through Out of Band >>> communication, each system's software version numbers are checked >>> and, if necessary, system software and virus protection are >>> remotely updated with the most recent patches and virus definitions. >>> Viruses and worms can also be contained at their source, if needed, >>> by means of built-in circuit-breaker functionality. >>> >>> "Intel AMT infrastructure supports the creation of setup and >>> configuration interfaces for management applications, as well >>> as network, security, and storage administration." >>> >>> What does this mean relative to this project? How are Solaris >>> veriion numbers (service tags ;-) being checked? How is Solaris >>> system software and virus protection being remotely updated >>> with the most recent patches and virus definitions? >>> >>> Gary.. >>> >>> >> This project currently does not deliver these features for phase I. But >> after the integration of >> this project will work with ISVs (i.e. anti-virus vendors, etc.) to add >> the above mentioned feature. >> The implementation detail is TDB. However, we realize/document the >> following AMT capabilities >> e.g. >> Remote software version checking/updating can be done by the using the >> EEPROM >> named 3PDS (3rd Party Data Storage), and share it with remote management >> console. >> See 6.18 about StorageRealm. >> > > Hummm, not for phase I seem OK, but remotely nuking Solaris > components without administrative requests seems overall bad. > There's the whole "Connected Customer" group under Steve Wilson > that needs to be brought into the picture for anything related > to Software Updating. I suspect there's a parallel group for > Firmware Updating some place in John Fowler's orginization. > I'd suggest contacting FWARC before proceeding along those > lines. > > Gary.. > From Artem.Kachitchkin@sun.com Tue Dec 11 20:45:28 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBC4jRPm024950 for ; Tue, 11 Dec 2007 20:45:27 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBC4jRNT003043; Tue, 11 Dec 2007 21:45:27 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSX00D036JRUH00@brm-avmta-1.central.sun.com>; Tue, 11 Dec 2007 21:45:27 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSX007LE6JQLA20@brm-avmta-1.central.sun.com>; Tue, 11 Dec 2007 21:45:26 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBC4jQ6B029147; Tue, 11 Dec 2007 20:45:26 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSX003016C6ZB00@fe-sfbay-10.sun.com> (original mail from Artem.Kachitchkin@Sun.COM); Tue, 11 Dec 2007 20:45:26 -0800 (PST) Received: from [129.150.18.129] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSX00A9Y6JKTS70@fe-sfbay-10.sun.com>; Tue, 11 Dec 2007 20:45:24 -0800 (PST) Date: Tue, 11 Dec 2007 20:44:13 -0800 From: Artem Kachitchkine Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory In-reply-to: <475F1535.7050904@sun.com> Sender: Artem.Kachitchkin@sun.com To: "Garrett D'Amore" Cc: Gary Winiger , David.Chieu@sun.com, intel-amt-iteam@sun.com, psarc-ext@sun.com Message-id: <475F671D.80908@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712112101.lBBL1RTx016034@marduk.eng.sun.com> <475F1535.7050904@sun.com> User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 1058 Garrett D'Amore wrote: > FWIW, I'd recommend *against* stashing a node in /dev. Better to just > access the /devices node directly IMO. The /dev links are a convenience > that is appropriate for "quasi-public" interfaces... you're not going to > need the /dev link (won't this just live in some fixed location like > /devices/pseudo or somesuch?) and its one less thing you need to > publish. (Plus then no need for devfsadm changes to support the > /dev/heci interface.) I disagree. Stability is hardly relevant here, because /devices essentially is not an interface, it is precisely what the man page says: All content at or below the /devices name space is an imple- mentation artifact and subject to incompatible change or removal without notification. It is true that managing of the /dev namespace could be made easier (esp. for leaf driver developers). I believe the issue is well recognized among the I/O framework folks, however the work started by the devname project is affected by lack of resources. -Artem From gdamore@sun.com Tue Dec 11 20:51:02 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBC4p1ND025053 for ; Tue, 11 Dec 2007 20:51:02 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBC4owih012618; Wed, 12 Dec 2007 12:51:00 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSX004036SZEG00@nwk-avmta-2.sfbay.sun.com>; Tue, 11 Dec 2007 20:50:59 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSX00H5P6SY9Q80@nwk-avmta-2.sfbay.sun.com>; Tue, 11 Dec 2007 20:50:58 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBC4owGc002334; Tue, 11 Dec 2007 20:50:58 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSX00K016QNYI00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Tue, 11 Dec 2007 20:50:58 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSX008Y36SXPA50@fe-sfbay-09.sun.com>; Tue, 11 Dec 2007 20:50:58 -0800 (PST) Date: Tue, 11 Dec 2007 20:45:28 -0800 From: "Garrett D'Amore" Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory In-reply-to: <475F671D.80908@sun.com> Sender: Garrett.Damore@sun.com To: Artem Kachitchkine Cc: Gary Winiger , David.Chieu@sun.com, intel-amt-iteam@sun.com, psarc-ext@sun.com Message-id: <475F6768.5060708@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712112101.lBBL1RTx016034@marduk.eng.sun.com> <475F1535.7050904@sun.com> <475F671D.80908@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1387 Artem Kachitchkine wrote: > Garrett D'Amore wrote: >> FWIW, I'd recommend *against* stashing a node in /dev. Better to >> just access the /devices node directly IMO. The /dev links are a >> convenience that is appropriate for "quasi-public" interfaces... >> you're not going to need the /dev link (won't this just live in some >> fixed location like /devices/pseudo or somesuch?) and its one less >> thing you need to publish. (Plus then no need for devfsadm changes >> to support the /dev/heci interface.) > > I disagree. Stability is hardly relevant here, because /devices > essentially is not an interface, it is precisely what the man page says: > > All content at or below the /devices name space is an imple- > mentation artifact and subject to incompatible change or > removal without notification. > > It is true that managing of the /dev namespace could be made easier > (esp. for leaf driver developers). I believe the issue is well > recognized among the I/O framework folks, however the work started by > the devname project is affected by lack of resources. My point is that the project needs only a private interface between its user and kernel bits. It need not be visible to anything else. Yes, relying on it for unbundled software is probably a bad idea. But for things that are part of ON, I don't see a problem. -- Garrett From Artem.Kachitchkin@sun.com Tue Dec 11 21:44:42 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBC5iglt025933 for ; Tue, 11 Dec 2007 21:44:42 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBC5ig8W019212; Tue, 11 Dec 2007 21:44:42 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSX00I099AET700@brm-avmta-1.central.sun.com>; Tue, 11 Dec 2007 22:44:38 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSX0076V9AEKT40@brm-avmta-1.central.sun.com>; Tue, 11 Dec 2007 22:44:38 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBC5ib0T001398; Tue, 11 Dec 2007 21:44:38 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSX0040194DAU00@fe-sfbay-10.sun.com> (original mail from Artem.Kachitchkin@Sun.COM); Tue, 11 Dec 2007 21:44:37 -0800 (PST) Received: from [129.150.18.129] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSX003T69ADEN00@fe-sfbay-10.sun.com>; Tue, 11 Dec 2007 21:44:37 -0800 (PST) Date: Tue, 11 Dec 2007 21:43:30 -0800 From: Artem Kachitchkine Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory In-reply-to: <475F6768.5060708@sun.com> Sender: Artem.Kachitchkin@sun.com To: "Garrett D'Amore" Cc: Gary Winiger , David.Chieu@sun.com, intel-amt-iteam@sun.com, psarc-ext@sun.com Message-id: <475F7502.6040108@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712112101.lBBL1RTx016034@marduk.eng.sun.com> <475F1535.7050904@sun.com> <475F671D.80908@sun.com> <475F6768.5060708@sun.com> User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 490 > My point is that the project needs only a private interface between its > user and kernel bits. It need not be visible to anything else. The project's kernel and user bits utilize devfs as an interface intermediary. It is not a direct interaction. > Yes, > relying on it for unbundled software is probably a bad idea. But for > things that are part of ON, I don't see a problem. Like I said, interface stability only applies to interfaces. /devices is not an interface. -Artem From gdamore@sun.com Tue Dec 11 22:02:43 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBC62hB7026394 for ; Tue, 11 Dec 2007 22:02:43 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBC62hxL023196; Tue, 11 Dec 2007 22:02:43 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSX00K13A4G9D00@brm-avmta-1.central.sun.com>; Tue, 11 Dec 2007 23:02:40 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSX007W1A4CKT40@brm-avmta-1.central.sun.com>; Tue, 11 Dec 2007 23:02:37 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBC62a7r001979; Tue, 11 Dec 2007 22:02:36 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSX003019ZHWC00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Tue, 11 Dec 2007 22:02:36 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSX001FKA4CLF10@fe-sfbay-09.sun.com>; Tue, 11 Dec 2007 22:02:36 -0800 (PST) Date: Tue, 11 Dec 2007 21:57:06 -0800 From: "Garrett D'Amore" Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory In-reply-to: <475F7502.6040108@sun.com> Sender: Garrett.Damore@sun.com To: Artem Kachitchkine Cc: Gary Winiger , David.Chieu@sun.com, intel-amt-iteam@sun.com, psarc-ext@sun.com Message-id: <475F7832.5020407@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712112101.lBBL1RTx016034@marduk.eng.sun.com> <475F1535.7050904@sun.com> <475F671D.80908@sun.com> <475F6768.5060708@sun.com> <475F7502.6040108@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1384 Artem Kachitchkine wrote: > > Like I said, interface stability only applies to interfaces. /devices > is not an interface. If /devices is "not an interface", even an ON-private one, then lots of things that use it are doomed. :-) I never understood that that /devices wasn't suitable for use within ON. (I do understand that some day in the future it could change, so its not appropriate for unbundled software.) On the other hand, stating that /devices isn't an interface seems, to me, akin to putting ones head in the sand. Its been around, unchanged for so long, with the same basic relationship, that I think its almost a "de-facto" interface. I can probably name half a dozen separate projects that rely on it. And its exposed to administrators. If the devfs team really believes that nothing should use those device nodes in /devices, then we should just go ahead and get rid of them (or make the ddi-internal-pathname only components...) and force everyone to use /dev. Of course, then fallout from such a change would be giganormous. Every cfgadm plugin, libdevinfo, etc. relies on /devices paths, and the fact that readlink() on /dev nodes is a way to determine the position in the devinfo tree. I should probably have you review my sdcard cfgadm plugin, which does just this.... modeled after the sata cfgadm plugin, of course. -- Garrett From Artem.Kachitchkin@sun.com Tue Dec 11 22:16:12 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBC6GCjY026434 for ; Tue, 11 Dec 2007 22:16:12 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBC6G3Up021834; Wed, 12 Dec 2007 06:16:10 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSX00L01AQXDX00@brm-avmta-1.central.sun.com>; Tue, 11 Dec 2007 23:16:09 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSX0073VAQWKU50@brm-avmta-1.central.sun.com>; Tue, 11 Dec 2007 23:16:09 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBC6G8kr004791; Tue, 11 Dec 2007 22:16:08 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSX00J01AJR2F00@fe-sfbay-10.sun.com> (original mail from Artem.Kachitchkin@Sun.COM); Tue, 11 Dec 2007 22:16:08 -0800 (PST) Received: from [129.150.18.129] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSX003P3AQWEN50@fe-sfbay-10.sun.com>; Tue, 11 Dec 2007 22:16:08 -0800 (PST) Date: Tue, 11 Dec 2007 22:15:01 -0800 From: Artem Kachitchkine Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory In-reply-to: <475F7832.5020407@sun.com> Sender: Artem.Kachitchkin@sun.com To: "Garrett D'Amore" Cc: Gary Winiger , David.Chieu@sun.com, intel-amt-iteam@sun.com, psarc-ext@sun.com Message-id: <475F7C65.5000401@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712112101.lBBL1RTx016034@marduk.eng.sun.com> <475F1535.7050904@sun.com> <475F671D.80908@sun.com> <475F6768.5060708@sun.com> <475F7502.6040108@sun.com> <475F7832.5020407@sun.com> User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 517 Maintaining good programming practices is largely orthogonal to the bundled/unbundled discussion. If it's easier for someone to think in terms of consolidations, recall that the driver consolidation has been on the table and imagine that it happened. If I can uninstall a driver package (and those that depend on it) and still end up with a perfectly functional system, consider it not an integral part of the core system and continue using DDI like any other disciplined driver developer, ON or not. -Artem From gdamore@sun.com Tue Dec 11 22:41:54 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBC6fr0A026667 for ; Tue, 11 Dec 2007 22:41:54 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBC6fOjo000945; Wed, 12 Dec 2007 06:41:52 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSX0090BBXIWA00@nwk-avmta-2.sfbay.sun.com>; Tue, 11 Dec 2007 22:41:42 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSX00HG3BXI9KC0@nwk-avmta-2.sfbay.sun.com>; Tue, 11 Dec 2007 22:41:42 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBC6fgiN003369; Tue, 11 Dec 2007 22:41:42 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSX00701BQICF00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) ; Tue, 11 Dec 2007 22:41:42 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSX003VPBXHEN90@fe-sfbay-10.sun.com>; Tue, 11 Dec 2007 22:41:41 -0800 (PST) Date: Tue, 11 Dec 2007 22:36:11 -0800 From: "Garrett D'Amore" Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory In-reply-to: <475F7C65.5000401@sun.com> Sender: Garrett.Damore@sun.com To: Artem Kachitchkine Cc: Gary Winiger , David.Chieu@sun.com, intel-amt-iteam@sun.com, psarc-ext@sun.com Message-id: <475F815B.6030409@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712112101.lBBL1RTx016034@marduk.eng.sun.com> <475F1535.7050904@sun.com> <475F671D.80908@sun.com> <475F6768.5060708@sun.com> <475F7502.6040108@sun.com> <475F7832.5020407@sun.com> <475F7C65.5000401@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1945 Artem Kachitchkine wrote: > > Maintaining good programming practices is largely orthogonal to the > bundled/unbundled discussion. If it's easier for someone to think in > terms of consolidations, recall that the driver consolidation has been > on the table and imagine that it happened. If I can uninstall a driver > package (and those that depend on it) and still end up with a > perfectly functional system, consider it not an integral part of the > core system and continue using DDI like any other disciplined driver > developer, ON or not. > > -Artem Heh. That's a nice theory. Except for one "itsy bitsy little issue". Except for drivers for a few well known classes, you *cannot* adhere to the DDI simply because there is no DDI compliant way to populate /dev! The devfsadm plugin framework is clearly not public (and its entirely unsuited to being so right now... take a look at a plugin if you want proof). There is, I guess, /etc/devlink.tab, from legacy ... although I don't know that it was ever "documented" as such, apart from the inline contents in the file. (And folks aren't supposed to be using that anymore, are they? devfsadm plugins is the "preferred" way, although like GLDv3, and probably a bunch of other things besides, it remains "undocumented".) Believe me, I'm all for the DDI. You can go and look at afe, which apart from being GLDv3 is DDI compliant. (It was previously a DDI compliant GLDv2 driver... even passed DDICT.) I don't think this particular fight (the one with /devices) is worth it, though. Anyway, if the only reasonable way for the heci driver to expose itself to userland is via /dev, requiring a devfsadm plugin (ugh), then so be it. I'll withdraw my suggestion, and instead request that if we are not to use /devices for "internal communication", then the devfs project team needs to gives us an easier and documented way to publish devlinks. -- Garrett From Artem.Kachitchkin@sun.com Tue Dec 11 22:55:29 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBC6tTwK027078 for ; Tue, 11 Dec 2007 22:55:29 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBC6tSpM017220; Tue, 11 Dec 2007 22:55:29 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSX00A07CKGNV00@nwk-avmta-2.sfbay.sun.com>; Tue, 11 Dec 2007 22:55:28 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSX00H1XCKF9KD0@nwk-avmta-2.sfbay.sun.com>; Tue, 11 Dec 2007 22:55:27 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBC6tRdc003842; Tue, 11 Dec 2007 22:55:27 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSX00501CCCFH00@fe-sfbay-09.sun.com> (original mail from Artem.Kachitchkin@Sun.COM); Tue, 11 Dec 2007 22:55:27 -0800 (PST) Received: from [192.168.1.100] ([75.7.42.131]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSX0015LCKFLFA0@fe-sfbay-09.sun.com>; Tue, 11 Dec 2007 22:55:27 -0800 (PST) Date: Tue, 11 Dec 2007 22:54:19 -0800 From: Artem Kachitchkine Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory In-reply-to: <475F815B.6030409@sun.com> Sender: Artem.Kachitchkin@sun.com To: "Garrett D'Amore" Cc: Gary Winiger , David.Chieu@sun.com, intel-amt-iteam@sun.com, psarc-ext@sun.com Message-id: <475F859B.8000208@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712112101.lBBL1RTx016034@marduk.eng.sun.com> <475F1535.7050904@sun.com> <475F671D.80908@sun.com> <475F6768.5060708@sun.com> <475F7502.6040108@sun.com> <475F7832.5020407@sun.com> <475F7C65.5000401@sun.com> <475F815B.6030409@sun.com> User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 888 > Heh. That's a nice theory. Except for one "itsy bitsy little issue". > Except for drivers for a few well known classes, you *cannot* adhere to > the DDI simply because there is no DDI compliant way to populate /dev! > The devfsadm plugin framework is clearly not public (and its entirely > unsuited to being so right now... "It is true that managing of the /dev namespace could be made easier (esp. for leaf driver developers). I believe the issue is well recognized among the I/O framework folks, however the work started by the devname project is affected by lack of resources." :) The advantage is that when/if someone needs to change devfs, they would only need to look in "well known" places like devfsadm and libdevinfo, and not chase consumers all around the place (they would have to anyway, but minimizing the number of such places is everyone's job). -Artem From gdamore@sun.com Tue Dec 11 23:06:22 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBC76LC3027191 for ; Tue, 11 Dec 2007 23:06:22 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBC76F1l005902; Wed, 12 Dec 2007 15:06:20 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSX0020XD2JKC00@brm-avmta-1.central.sun.com>; Wed, 12 Dec 2007 00:06:19 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSX007BAD2HLA70@brm-avmta-1.central.sun.com>; Wed, 12 Dec 2007 00:06:17 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBC76HrM006196; Tue, 11 Dec 2007 23:06:17 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSX00B01CY3MT00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Tue, 11 Dec 2007 23:06:16 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSX00165D2GLFC0@fe-sfbay-09.sun.com>; Tue, 11 Dec 2007 23:06:16 -0800 (PST) Date: Tue, 11 Dec 2007 23:00:46 -0800 From: "Garrett D'Amore" Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory In-reply-to: <475F859B.8000208@sun.com> Sender: Garrett.Damore@sun.com To: Artem Kachitchkine Cc: Gary Winiger , David.Chieu@sun.com, intel-amt-iteam@sun.com, psarc-ext@sun.com Message-id: <475F871E.5060202@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712112101.lBBL1RTx016034@marduk.eng.sun.com> <475F1535.7050904@sun.com> <475F671D.80908@sun.com> <475F6768.5060708@sun.com> <475F7502.6040108@sun.com> <475F7832.5020407@sun.com> <475F7C65.5000401@sun.com> <475F815B.6030409@sun.com> <475F859B.8000208@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1539 Artem Kachitchkine wrote: > >> Heh. That's a nice theory. Except for one "itsy bitsy little >> issue". Except for drivers for a few well known classes, you >> *cannot* adhere to the DDI simply because there is no DDI compliant >> way to populate /dev! The devfsadm plugin framework is clearly not >> public (and its entirely >> unsuited to being so right now... > > "It is true that managing of the /dev namespace could be made easier > (esp. for leaf driver developers). I believe the issue is well > recognized among the I/O framework folks, however the work started by > the devname project is affected by lack of resources." :) > > The advantage is that when/if someone needs to change devfs, they > would only need to look in "well known" places like devfsadm and > libdevinfo, and not chase consumers all around the place (they would > have to anyway, but minimizing the number of such places is everyone's > job). Maybe its time to just bite the bullet and raise the commitment level of /devices? I'd think that would be a lot easier. :-) I don't know what the fear behind this is, that kept the devfs team from committing to it already, but I can assure that the number of unbundled (and in some cases non-Sun!) bits of software that rely on /devices is non-trivial. For a number of us, /devices is also hardcoded into our human brains. Changing the way /devices works would be akin to the change involving SMF.... a lot of pain, and probably a need to retain backwards compatibility. -- Garrett From edward.pilatowicz@sun.com Tue Dec 11 23:18:14 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBC7IDgg027255 for ; Tue, 11 Dec 2007 23:18:14 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBC7Hx2Q015891; Wed, 12 Dec 2007 07:18:06 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSX00I0BDM3JA00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Dec 2007 23:18:03 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSX00FTEDM3S400@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Dec 2007 23:18:03 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lBC7I2l6849927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Dec 2007 23:18:02 -0800 (PST) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id lBC7I2GO849916; Tue, 11 Dec 2007 23:18:02 -0800 (PST) Date: Tue, 11 Dec 2007 23:18:02 -0800 From: Edward Pilatowicz Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory In-reply-to: <475F871E.5060202@sun.com> To: "Garrett D'Amore" Cc: Artem Kachitchkine , David.Chieu@sun.com, intel-amt-iteam@sun.com, psarc-ext@sun.com, Gary Winiger Message-id: <20071212071802.GO680864@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200712112101.lBBL1RTx016034@marduk.eng.sun.com> <475F1535.7050904@sun.com> <475F671D.80908@sun.com> <475F6768.5060708@sun.com> <475F7502.6040108@sun.com> <475F7832.5020407@sun.com> <475F7C65.5000401@sun.com> <475F815B.6030409@sun.com> <475F859B.8000208@sun.com> <475F871E.5060202@sun.com> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 1800 On Tue, Dec 11, 2007 at 11:00:46PM -0800, Garrett D'Amore wrote: > Artem Kachitchkine wrote: > > > >> Heh. That's a nice theory. Except for one "itsy bitsy little > >> issue". Except for drivers for a few well known classes, you > >> *cannot* adhere to the DDI simply because there is no DDI compliant > >> way to populate /dev! The devfsadm plugin framework is clearly not > >> public (and its entirely > >> unsuited to being so right now... > > > > "It is true that managing of the /dev namespace could be made easier > > (esp. for leaf driver developers). I believe the issue is well > > recognized among the I/O framework folks, however the work started by > > the devname project is affected by lack of resources." :) > > > > The advantage is that when/if someone needs to change devfs, they > > would only need to look in "well known" places like devfsadm and > > libdevinfo, and not chase consumers all around the place (they would > > have to anyway, but minimizing the number of such places is everyone's > > job). > > Maybe its time to just bite the bullet and raise the commitment level of > /devices? I'd think that would be a lot easier. :-) I don't know what > the fear behind this is, that kept the devfs team from committing to it > already, but I can assure that the number of unbundled (and in some > cases non-Sun!) bits of software that rely on /devices is non-trivial. > For a number of us, /devices is also hardcoded into our human brains. > Changing the way /devices works would be akin to the change involving > SMF.... a lot of pain, and probably a need to retain backwards > compatibility. > um. no. /devices should not be public. /dev is the way to go. if we put resources behind anything it should be coming up with public ways to manage and populate /dev. ed From gww@eng.sun.com Wed Dec 12 11:47:27 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBCJlQAK013494 for ; Wed, 12 Dec 2007 11:47:27 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBCJlNQT000562; Thu, 13 Dec 2007 03:47:25 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSY0024RCB1AA00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 12 Dec 2007 11:47:25 -0800 (PST) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSY009CDCAZTUC0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 12 Dec 2007 11:47:23 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id lBCJlNE2027094; Wed, 12 Dec 2007 11:47:23 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id lBCJjYeS017948; Wed, 12 Dec 2007 11:45:34 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id lBCJjYjb017947; Wed, 12 Dec 2007 11:45:34 -0800 (PST) Date: Wed, 12 Dec 2007 11:45:34 -0800 (PST) From: Gary Winiger Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory To: Mark.Logan@sun.com, gww@eng.sun.com Cc: David.Chieu@sun.com, intel-amt-iteam@sun.com, psarc-ext@sun.com Message-id: <200712121945.lBCJjYjb017947@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 651 > I'm not sure what you mean by "noaccess". Do you want us to change the > method_context for LMS from "root:root" to "noaccess:noaccess"? As stated in the security best practice: http://opensolaris.org/os/community/arc/bestpractices/security-questions "If this project uses any privileged operations beyond what a common user (e.g. "noaccess") can perform, why those are necessary and how they are granted." The point is to implement the principle of least privilege, not to say you must run as noaccess:noaccess. What is the minimum needed for this service? That is anything above noaccess:noaccess permitted set = "basic'? Gary.. From Mark.Logan@sun.com Fri Dec 14 12:34:09 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBEKY93p014000 for ; Fri, 14 Dec 2007 12:34:09 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBEKY59o022918; Fri, 14 Dec 2007 20:34:07 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT200E093STAB00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 14 Dec 2007 12:34:06 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT200BR33STCBB0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 14 Dec 2007 12:34:05 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBEKY5eL028942; Fri, 14 Dec 2007 12:34:05 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JT200C013EU9500@fe-sfbay-10.sun.com> (original mail from Mark.Logan@Sun.COM); Fri, 14 Dec 2007 12:34:05 -0800 (PST) Received: from [192.168.1.47] ([71.106.212.37]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JT20057T3SJEUE0@fe-sfbay-10.sun.com>; Fri, 14 Dec 2007 12:33:57 -0800 (PST) Date: Fri, 14 Dec 2007 12:33:54 -0800 From: Mark Logan Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory In-reply-to: <200712121945.lBCJjYjb017947@marduk.eng.sun.com> Sender: Mark.Logan@sun.com To: Gary Winiger Cc: David.Chieu@sun.com, intel-amt-iteam@sun.com, psarc-ext@sun.com Message-id: <4762E8B2.5070005@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712121945.lBCJjYjb017947@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 766 I understand now, thanks. We will work on this. Mark Gary Winiger wrote: >> I'm not sure what you mean by "noaccess". Do you want us to change the >> method_context for LMS from "root:root" to "noaccess:noaccess"? >> > > As stated in the security best practice: > http://opensolaris.org/os/community/arc/bestpractices/security-questions > "If this project uses any privileged operations beyond what > a common user (e.g. "noaccess") can perform, why those are > necessary and how they are granted." > > The point is to implement the principle of least privilege, > not to say you must run as noaccess:noaccess. > > What is the minimum needed for this service? That is anything > above noaccess:noaccess permitted set = "basic'? > > Gary.. > From Mark.Logan@sun.com Thu Dec 20 11:04:39 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBKJ4cJ4024875 for ; Thu, 20 Dec 2007 11:04:38 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBKJ4aJ7016780; Thu, 20 Dec 2007 19:04:37 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTD00G0H3NNTR00@brm-avmta-1.central.sun.com>; Thu, 20 Dec 2007 12:04:35 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTD00AWA3NMZI30@brm-avmta-1.central.sun.com>; Thu, 20 Dec 2007 12:04:35 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBKJ4YrM023280; Thu, 20 Dec 2007 11:04:34 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JTD00G013LJS900@fe-sfbay-09.sun.com> (original mail from Mark.Logan@Sun.COM); Thu, 20 Dec 2007 11:04:34 -0800 (PST) Received: from [10.1.48.235] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JTD007IY3NC7MA0@fe-sfbay-09.sun.com>; Thu, 20 Dec 2007 11:04:24 -0800 (PST) Date: Thu, 20 Dec 2007 11:02:40 -0800 From: Mark Logan Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory In-reply-to: <200712121945.lBCJjYjb017947@marduk.eng.sun.com> Sender: Mark.Logan@sun.com To: Gary Winiger Cc: David.Chieu@sun.com, intel-amt-iteam@sun.com, psarc-ext@sun.com Message-id: <476ABC50.8060302@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_9pA3BkxmLXiNluM1uEVMzA)" X-PMX-Version: 5.2.0.264296 References: <200712121945.lBCJjYjb017947@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 3983 This is a multi-part message in MIME format. --Boundary_(ID_9pA3BkxmLXiNluM1uEVMzA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi Gary, Thanks for meeting with us Tuesday. Here is my understanding of our conversation: Keep /dev/heci owned by root, r/w by owner only. In the the SMF service description for LMS, run as root, privileges='basic'. (I have attached the file.) Change the LMS daemon to use setuid to "noaccess" after opening /dev/heci. Mark Gary Winiger wrote: >> I'm not sure what you mean by "noaccess". Do you want us to change the >> method_context for LMS from "root:root" to "noaccess:noaccess"? >> > > As stated in the security best practice: > http://opensolaris.org/os/community/arc/bestpractices/security-questions > "If this project uses any privileged operations beyond what > a common user (e.g. "noaccess") can perform, why those are > necessary and how they are granted." > > The point is to implement the principle of least privilege, > not to say you must run as noaccess:noaccess. > > What is the minimum needed for this service? That is anything > above noaccess:noaccess permitted set = "basic'? > > Gary.. > --Boundary_(ID_9pA3BkxmLXiNluM1uEVMzA) Content-type: text/xml; name=lms.xml Content-transfer-encoding: 7BIT Content-disposition: inline; filename=lms.xml --Boundary_(ID_9pA3BkxmLXiNluM1uEVMzA)-- From David.Chieu@sun.com Tue Jan 8 11:28:03 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m08JS2H7022767 for ; Tue, 8 Jan 2008 11:28:03 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m08JRsKL015218; Tue, 8 Jan 2008 19:28:01 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUC00A0BBEPRR00@nwk-avmta-2.sfbay.sun.com>; Tue, 08 Jan 2008 11:28:01 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUC004HBBENSD70@nwk-avmta-2.sfbay.sun.com>; Tue, 08 Jan 2008 11:28:00 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m08JRxZS000743; Tue, 08 Jan 2008 11:27:59 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUC00501BAO4100@fe-sfbay-10.sun.com> (original mail from David.Chieu@Sun.COM); Tue, 08 Jan 2008 11:27:59 -0800 (PST) Received: from [10.1.48.114] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUC00GJ0BEDX800@fe-sfbay-10.sun.com>; Tue, 08 Jan 2008 11:27:57 -0800 (PST) Date: Tue, 08 Jan 2008 11:28:11 -0800 From: David Chieu Subject: Re: PSARC 2007/601 FastTrack timeout 12/05/2007 - "spec.txt" added to the materials directory In-reply-to: <476ABC50.8060302@sun.com> Sender: David.Chieu@sun.com To: Gary Winiger Cc: Mark Logan , intel-amt-iteam@sun.com, PSARC-EXT@sun.com Message-id: <4783CECB.9070003@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712121945.lBCJjYjb017947@marduk.eng.sun.com> <476ABC50.8060302@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 1382 Gary, Happy New Year! Just want to touch bases with you on 2007/601. The project team has implemented your suggestions over the break. If there is no other comment, we believe this case is converged. Thanks again for your generous help. -- David Chieu Mark Logan wrote: > Hi Gary, > Thanks for meeting with us Tuesday. > Here is my understanding of our conversation: > Keep /dev/heci owned by root, r/w by owner only. > In the the SMF service description for LMS, run as root, > privileges='basic'. (I have attached the file.) > Change the LMS daemon to use setuid to "noaccess" after opening > /dev/heci. > Mark > > Gary Winiger wrote: >>> I'm not sure what you mean by "noaccess". Do you want us to change >>> the method_context for LMS from "root:root" to "noaccess:noaccess"? >>> >> >> As stated in the security best practice: >> http://opensolaris.org/os/community/arc/bestpractices/security-questions >> "If this project uses any privileged operations beyond what >> a common user (e.g. "noaccess") can perform, why those are >> necessary and how they are granted." >> >> The point is to implement the principle of least privilege, >> not to say you must run as noaccess:noaccess. >> >> What is the minimum needed for this service? That is anything >> above noaccess:noaccess permitted set = "basic'? >> >> Gary.. >> >