From wyllys@ardbeg.sfbay.sun.com Thu Nov 20 11:02:56 2008 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 mAKJ2uWp005977 for ; Thu, 20 Nov 2008 11:02:56 -0800 (PST) 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 mAKJ2tft002219 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.Com>; Thu, 20 Nov 2008 12:02:55 -0700 (MST) 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 <0KAN00801BKVBK00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Thu, 20 Nov 2008 11:02:55 -0800 (PST) Received: from ardbeg.sfbay.sun.com ([10.6.50.166]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAN00HEGBKUDI90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Thu, 20 Nov 2008 11:02:54 -0800 (PST) Received: from ardbeg.sfbay.sun.com (localhost [127.0.0.1]) by ardbeg.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mAKJ2rUB028809; Thu, 20 Nov 2008 11:02:53 -0800 (PST) Received: (from wyllys@localhost) by ardbeg.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id mAKJ2rOI028805; Thu, 20 Nov 2008 11:02:53 -0800 (PST) Date: Thu, 20 Nov 2008 11:02:53 -0800 (PST) From: Wyllys Ingersoll Subject: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] To: PSARC-ext@sun.com Message-id: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 12343 Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: TPM Support 1.2. Name of Document Author/Supplier: Author: Wyllys Ingersoll 1.3 Date of This Document: 20 November, 2008 4. Technical Description Project Name: TPM Support for Solaris Review Request: Fast-Track Submitter: Wyllys Ingersoll Description ----------- The Trusted Computing Group (TCG) develops and promote open standards for hardware enabling trusted computing and security technologies, including hardware building blocks and software interfaces. The Trusted Platform Module (TPM), which is a hardware device usually attached directly to the motherboard of a computing platform, and which is designed according to the TPM specifications put forth by the TCG. The current TPM standard is version 1.2. The TPM spec details the design and functionality of the TPM device itself as well as the data formats of the commands used to communicate with a TPM. A TPM device is a subsystem that is intended to provide protected storage and protected capabilities on an inexpensive component with restricted resources. Because the TPM's resources are limited, functions not requiring protected storage capabilities are separated from those that do and are put into the platform's main processor and memory space. The modules and components that provide this non-protected support are part of the TCG Software Stack (TSS). The TSS specification (version 1.2) provides details about the various components that are provide the interfaces upon which secure computing applications can be built. Solaris runs on many platforms that currently have TPM devices, but Solaris does not deliver a device driver for the TPM nor does it deliver the TSS that enables development of secure computing applications. This project will deliver a TPM device driver that works with a 1.2 compliant TPM device, a TSS (TCG Software Stack) that meets the TSS 1.2 specifications, and a PKCS#11 provider for the Solaris Cryptographic Framework taht uses the TSS to provide mechanisms for doing cryptographic operations on the secure device, and administrative tools for managing the TPM and the PKCS11 provider. Deliverables ------------ * TPM Device driver (tpm) The TPM device driver was developed in a joint effort between the Solaris Security group and Dartmouth College and will be delivered on x86/64 based platforms as part of the core Solaris installation. We intend to defer delivery of a TPM driver for SPARC systems to a later integration, as TPM hardware is predominantly found on x86 systems. All components of the TPM driver are independent of processor architecture. The TPM driver will communicate with the TPM device using the protocols described in the TPM 1.2 specification available at: https://www.trustedcomputinggroup.org/specs This driver will deliver in /kernel/drv/tpm and /kernel/drv/amd64/tpm on x86 systems. It will have suspend/resume support. **NOTE** Though we are not introducing SPARC support with the initial putback, we are seeking approval for both x86 and SPARC versions of the software so that when a functional SPARC based TPM is available, we can deliver the driver and software on SPARC platforms without another review. * TSS Software This project will deliver TrouSerS (http://sourceforge.net/projects/trousers) (v0.3.1) software as the TSS into the SFW consolidation. This is an open source package originally developed by IBM which supports the TSS 1.2 specification (https://www.trustedcomputinggroup.org/specs/TSS) and which works with the Solaris TPM driver. We plan on making minimal changes to TrouSerS - just enough to get it to compile and work correctly on Solaris and to enable it to use features such as least-privilege as necessary. TrouSerS is available for Linux today, we are playing catchup in this area. This project will also deliver a full set of man pages documenting the public programming interfaces provided by TrouSerS. * PKCS11 Provider A PKCS11 provider that will allow users to create individual tokens that use the TPM to generate keys and perform sensitive operations (encrypt/decrypt/sign/verify) will be delivered into ON. This provider will protect all private data objects by encrypting them with keys that can only be used inside the TPM device. The PKCS11 TPM provider will support the following mechanisms: CKM_RSA_PKCS_KEY_PAIR_GEN (2048 bit max) (hardware) CKM_RSA_PKCS (2048 bit max) (hardware) CKM_RSA_PKCS_OAEP (2048 bit max) (hardware) CKM_RSA_X_509 (2048 bit max) (hardware) CKM_MD5_RSA_PKCS (2048 bit max) (hardware) CKM_SHA1_RSA_PKCS (2048 bit max) (hardware) CKM_SHA_1 CKM_SHA_1_HMAC CKM_SHA_1_HMAC_GENERAL CKM_MD5 CKM_MD5_HMAC CKM_MD5_HMAC_GENERAL * Administrative Tools A utility (tpmadm) for performing TPM administration will be delivered. This utility is necessary to perform operations such as taking ownership of a TPM and managing registered keys in a TPM. The full man page for this utility is included as part of the case materials. Additionally, pktool(1) will be modified to support a new command, "inittoken", which allows the user to initialize a token. When applied to the TPM token, this will result in the user's own personal token namespace to be configured and become available for use to that user. Cross-Consolidation Issues -------------------------- The TPM device driver will be delivered into the ON consolidation. The TrouSerS TSS stack software will be delivered to the SFW consolidation because we want to be able to keep the structure of the code and the configuration & building process for it as close to the open source (upstream) original as possible. The SFW consolidation allows for us to just drop the latest .tar.gz file and (modulo a few patches) configure and compile the package. Although the TPM and TSS are really not useful on the same platform if one of the 2 is missing, there are no build-time dependencies on the two. As long as they are delivering into the same build and will be available together there are no cross-consolidation issues. The PKCS#11 provider that uses the TPM must be delivered into the ON consolidation because it must be cryptographically signed. There is no process in place for signing cryptographic modules in the SFW consolidation. The PKCS11 TPM provider and the administrative utility require the presence of the TSS software (headers and shared object library) to compile and those objects are not available in the ON consolidation. In order to be able to build and deliver TSS-dependent software in ON, we will have to wait 1 or 2 builds and issue a flag-day to build machine maintainers to mandate that the new TSS packages be present on all build machines in order to go forward with an ON build that contains the PKCS11 TPM software and TPM administrative utility. The putback schedule will look something like this: Putback #1 (ON) build X: TPM device driver Putback #2 (SFW)build X: TSS software Putback #3 (ON) build X + 2: PKCS11 TPM provider (ON), TPM Admin utility (ON) Design Notes ------------ By design the TPM device and TSS protocols specify that direct access to the TPM device be managed only by the TSS daemon (TCSD). All TSS commands from applications are designed to be funneled through the TCSD which listens on the localhost interface (port 30003 by default) and (optionally) to any other network interfaces available. Because access to the TPM is limited to one application at a time, the TPM device will only be available in the global zone. If other local zones want to use it, they can talk to it over the well-known port (if it is configured to allow such connections). Port 30003 is the default standard port that the TrouSerS software project has chosen to use. It is part of an unregistered block of ports according to IANA (30003-30998 - unregistered). Applications access the TPM by calling the TSS interfaces (libtspi) which ultimately talk to the TCS Daemon (tcsd, part of TrouSerS) which listens on the localhost to the TPM device. The tcsd daemon has a configuration file that allows for various settings to be changed (see the associated tcsd man page in the case materials directory for more details). The TSS library connects to the tcsd over TCP connections and uses a data protocol specified in the TSS 1.2 specification. Network access to the tcsd is managed by the tcsd configuration file (/etc/security/tcsd.conf) which allows the administrator to configure what operations a remote application may perform on the local TSS. By default, the tcsd allows no remote operations and listens only on the localhost address. The case materials for sample tcsd.conf and the tcsd.conf manpage contain a full list of possible remote operations. Least Privilege/RBAC -------------------- This project will modify the standard TrouSerS software so that the tcsd daemon is privilege aware and will drop all unnecessary privileges after forking to the background (the following privs will be dropped: exec, fork, link_any, info, session). The following new authorizations will be added to /etc/security/auth_attr: solaris.smf.value.tcsd:::Change tcsd value properties:: solaris.smf.manage.tcsd:::Manage tcsd service states:: The following rights profile will be added to /etc/security/prof_attr: TCSD Administration::::auths=solaris.smf.manage.tcsd,solaris.smf.value.tcsd SMF --- This project will deliver an SMF manifest and scripts to allow the tcsd to be configured and restarted via SMF. The SMF service will be "svc:/application/security/tcsd:default (TCS Daemon)" and it will also contain a "config/local_only" property that controls whether or not it will listen for network connections. This will allow the tcsd to be included in the set of applications affected by the netservices(1M) command. An entry in the "generic_limited_net" profile will be added for the tcsd. The SMF profile will support the RBAC action and value authorizations (solaris.smf.manage.tcsd, solaris.smf.value.tcsd). The TCS daemon will continue to read it's configuration parameters from /etc/security/tcsd.conf file. We will not convert everything to SMF because the software that relies on the tcsd.conf is from an established open source project and we want to avoid deviating from it as much as possible. Packaging Modifications ----------------------- SUNWtpm TPM device driver (New package) SUNWtss Trousers software for /usr (New package) SUNWtss-root Trousers configuration files, SMF manifest, and RBAC updates (New package) SUNWcsl Modified to deliver pkcs11_tpm.so.1 provider and tpmadm utility on x86 platforms. List of Deliverables, Consolidations, and Taxonomies ---------------------------------------------------- /kernel/drv/tpm ON Committed /kernel/drv/amd64/tpm ON Committed /usr/lib/security/pkcs11_tpm.so.1 ON Committed /usr/lib/security/amd64/pkcs11_tpm.so.1 ON Committed /usr/bin/tpmadm ON Committed /usr/share/man/man5/pkcs11_tpm.5 ON Committed /usr/share/man/man1/tpmadm.1 ON Committed /etc/security/tcsd.conf SFW Uncommitted /var/svc/manifest/application/security/tcsd.xml SFW Uncommitted /usr/lib/libtspi.so.1.1.1 SFW Committedc Standard /usr/lib/amd64/libtspi.so.1.1.1 SFW Uncommitted /usr/lib/tcsd SFW Uncommitted /lib/svc/method/tcsd SFW Uncommitted /usr/include/tss [TSS headers ] SFW Uncommitted /usr/include/trousers [TSS headers] SFW Uncommitted /usr/share/man/man3/ [ libtspi API man pages] SFW Committed Standard /usr/share/man/man4/tcsd.conf.4 SFW Uncommitted /usr/share/man/man1m/tcsd.1m SFW Uncommitted Standards (Committed Standards) -------------------------------- TCG Software Stack Specification: https://www.trustedcomputinggroup.org/specs/TSS/TSS_1_2_Errata_A-final.pdf Trusted Platform Module Specifications: https://www.trustedcomputinggroup.org/specs/TPM OpenSource ---------- TrouSerS Project: http://sourceforge.net/projects/trousers 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON, SFW 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From wyllys.ingersoll@sun.com Thu Nov 20 11:10:28 2008 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 mAKJASfr006159 for ; Thu, 20 Nov 2008 11:10:28 -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 mAKJAPUj007633 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 Nov 2008 12:10:28 -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 <0KAN00913BXF0600@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 Nov 2008 12:10:27 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAN00E8ZBXEBVE0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 Nov 2008 12:10:26 -0700 (MST) Received: from [10.7.251.182] (punchin-wyllys.SFBay.Sun.COM [10.7.251.182]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mAKJAPoD257168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Nov 2008 11:10:26 -0800 (PST) Date: Thu, 20 Nov 2008 14:10:25 -0500 From: Wyllys Ingersoll Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> To: PSARC-ext@sun.com Message-id: <4925B621.1030208@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 86 The man pages associated with this case are in the materials directory. -Wyllys From gww@eng.sun.com Thu Nov 20 11:22:24 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAKJMNYC006485 for ; Thu, 20 Nov 2008 11:22:23 -0800 (PST) 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 mAKJMLU5008894 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 Nov 2008 11:22:23 -0800 (PST) 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 <0KAN00A19CHBUT00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 Nov 2008 11:22:23 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAN00HOYCHADGA0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 Nov 2008 11:22:22 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAKJMMgp041819; Thu, 20 Nov 2008 11:22:22 -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 mAKJMosP028504; Thu, 20 Nov 2008 11:22:50 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id mAKJMoog028503; Thu, 20 Nov 2008 11:22:50 -0800 (PST) Date: Thu, 20 Nov 2008 11:22:50 -0800 (PST) From: Gary Winiger Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] To: PSARC-ext@sun.com, wyllys.ingersoll@sun.com Message-id: <200811201922.mAKJMoog028503@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 114 > The man pages associated with this case are in the materials directory. tmpadm.1 seems to be missing. Gary.. From wyllys.ingersoll@sun.com Thu Nov 20 11:24:45 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 mAKJOiv0006646 for ; Thu, 20 Nov 2008 11:24:44 -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 mAKJOhYJ001621 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 Nov 2008 19:24:43 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 <0KAN00I03CL5W100@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 Nov 2008 11:24:41 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAN009KCCL3SD90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 Nov 2008 11:24:39 -0800 (PST) Received: from [10.7.251.182] (punchin-wyllys.SFBay.Sun.COM [10.7.251.182]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mAKJOcLO262886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 11:24:38 -0800 (PST) Date: Thu, 20 Nov 2008 14:24:37 -0500 From: Wyllys Ingersoll Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <200811201922.mAKJMoog028503@marduk.eng.sun.com> To: Gary Winiger Cc: PSARC-ext@sun.com Message-id: <4925B975.60300@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811201922.mAKJMoog028503@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 205 Gary Winiger wrote: >> The man pages associated with this case are in the materials directory. >> > > tmpadm.1 seems to be missing. > > Gary.. > Thanks for the reminder, it's there now. -Wyllys From darren.moffat@sun.com Thu Nov 20 12:25:41 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAKKPftx022949 for ; Thu, 20 Nov 2008 12:25:41 -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 mAKKPeo1012711 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 Nov 2008 12:25:41 -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 <0KAN00M1DFESCG00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 Nov 2008 12:25:40 -0800 (PST) Received: from gmp-eb-inf-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 <0KAN009RDFERSDE0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 Nov 2008 12:25:40 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mAKKPdGo015686 for ; Thu, 20 Nov 2008 20:25:39 +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 <0KAN00E01FDJCG00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 Nov 2008 20:25:39 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAN00IINFENYE40@fe-emea-09.sun.com>; Thu, 20 Nov 2008 20:25:37 +0000 (GMT) Date: Thu, 20 Nov 2008 20:25:35 +0000 From: Darren J Moffat Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> Sender: darren.moffat@sun.com To: Wyllys Ingersoll Cc: PSARC-ext@sun.com Message-id: <4925C7BF.1020204@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 272 I've read and understood the full proposal and I'm happy with all the parts of the architecture. This is a very valuable addition to Solaris that will be able to be used by components such IKE, and ZFS Crypto for master key storage. So +1 from me. -- Darren J Moffat From wyllys.ingersoll@sun.com Mon Nov 24 13:03:04 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAOL34Vx006542 for ; Mon, 24 Nov 2008 13:03:04 -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 mAOL2vQL002063 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 24 Nov 2008 13:03:04 -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 <0KAU0030XVT2EF00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 24 Nov 2008 14:03:02 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAU00M3EVT1K240@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 24 Nov 2008 14:03:01 -0700 (MST) Received: from [129.148.19.32] (punchin-client-129-148-19-32.East.Sun.COM [129.148.19.32]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mAOL2KVF975520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2008 13:02:27 -0800 (PST) Date: Mon, 24 Nov 2008 16:02:20 -0500 From: Wyllys Ingersoll Subject: PSARC 2008/725 TPM Support - man page updated To: PSARC-ext@sun.com Cc: kmf-discuss@opensolaris.org Message-id: <492B165C.5040005@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Zws969gh5K/4OPx1g7z8MA)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 3577 This is a multi-part message in MIME format. --Boundary_(ID_Zws969gh5K/4OPx1g7z8MA) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT I updated the modified man page proposed for pktool(1) in the case materials directory. The changes are also attached here for anyone who wants a quick look. -Wyllys --Boundary_(ID_Zws969gh5K/4OPx1g7z8MA) Content-type: text/plain; name=pktool.1.diffs Content-transfer-encoding: 7BIT Content-disposition: inline; filename=pktool.1.diffs *** pktool.1.orig Mon Nov 24 12:33:57 2008 --- pktool.1.new Mon Nov 24 12:33:12 2008 *************** *** 429,435 **** --- 429,447 ---- genkey subcommand prompts the user to enter a PIN for token-based keystore. + inittoken + The format of the inittoken subcommand is as follows: + pktool inittoken [ slotid=slot number ] + [ currlabel=token[:manuf[:serial]]] + [ newlabel=new token label ] + This command initializes a PKCS#11 token (using C_InitToken API). + The preferred method of locating a token is to specify its default label. + A new label may be assigned to the token (optionally) by using the "newlabel" + argument. If "newlabel" is not present, the token label is not modified. + The user will be prompted to enter the security officer (SO) PIN for this + command to proceed. + import The format for the import subcommand is as follows: *************** *** 601,606 **** --- 613,619 ---- pktool setpin [ keystore=pkcs11] [token=token[:manuf[:serial]]] + [usertype=user|so] Changes the passphrase used to authenticate a user to *************** *** 621,626 **** --- 634,643 ---- is needed to initialize and set the passphrase to a newly created token object store. + If the "usertype=so" option is given for PKCS#11 based tokens, the + Security Officer (SO) user PIN will be changed as opposed to + the normal user PIN. By default the usertype is assumed to be + "user". signcsr *************** *** 741,746 **** --- 758,768 ---- being critical. altname="critical:EMAIL=first.last@company.com" + currlabel=token label + This option is only used by the "inittoken" command. This + is used to locate the default token that is being initialized. + See the "token" option (below) for details about the format + of the token name to be used. dir=directory_path *************** *** 934,939 **** --- 956,967 ---- option might be: lifetime=1-hour, lifetime=2-day, lifetime=3-year + newlabel=token label + This option is only used by the "inittoken" command. This + is used to change the label assigned to the token that is + being initialized. + See the "token" option (below) for details about the format + of the token name to be used. nickname=cert-nickname *************** *** 1139,1145 **** --- 1167,1180 ---- for NSS certificates and that the standard NSS syntax applies. + usertype=user | so + Specifies the type of user for which the "setpin" command + is being performed. The default is for a standard user, + but "so" may be specified in order to set the PIN for + the security officer of the token. + + url=url_string Specifies the URL to download a CRL or a certificate --Boundary_(ID_Zws969gh5K/4OPx1g7z8MA)-- From wyllys.ingersoll@sun.com Wed Nov 26 07:52:00 2008 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 mAQFq0TZ019871 for ; Wed, 26 Nov 2008 07:52:00 -0800 (PST) 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 mAQFpuQb030229 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 26 Nov 2008 08:52:00 -0700 (MST) 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 <0KAY00J116QNKY00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 26 Nov 2008 07:51:59 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAY00GP46QMN910@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 26 Nov 2008 07:51:58 -0800 (PST) Received: from [129.148.19.16] (punchin-client-129-148-19-16.East.Sun.COM [129.148.19.16]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mAQFpvgG255669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Nov 2008 07:51:58 -0800 (PST) Date: Wed, 26 Nov 2008 10:51:57 -0500 From: Wyllys Ingersoll Subject: PSARC 2008/725 TPM Support To: PSARC-ext@sun.com Message-id: <492D709D.4010101@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_UMVXAS/vcmBUH71C0CYJxA)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 4692 This is a multi-part message in MIME format. --Boundary_(ID_UMVXAS/vcmBUH71C0CYJxA) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT The manpage for the tpmadm(1M) command has been updated in the case materials directory. Attached is the updated version for interested readers. -Wyllys --Boundary_(ID_UMVXAS/vcmBUH71C0CYJxA) Content-type: text/plain; name=tpmadm.1m Content-transfer-encoding: 7BIT Content-disposition: inline; filename=tpmadm.1m tpmadm(1M) NAME tpmadm - administer Trusted Platform Module SYNOPSIS tpmadm status tpmadm init tpmadm passwd tpmadm resetlock tpmadm keyinfo [ ] tpmadm deletekey DESCRIPTION A Trusted Platform Module (TPM) is a hardware component that provides for protected key storage and reliable measurements of software used to boot the operating system. The tpmadm utility is used to initialize and administer the TPM so that it can be used by the operating system and other programs. The TPM subsystem can store and manage an unlimited number of keys for use by the operating system and by users. Each key is identified by a Universally Unique Identifier, or UUID. Although the TPM can hold only a limited number of keys at any given time, the supporting software automatically loads and unloads keys as needed. When a key is stored outside the TPM, it is always encrypted or "wrapped" by its parent key so that the key is never exposed in readable form outside the TPM. Before the TPM can be used, it must be initialized by the platform owner. This process involves setting an owner password which is used to authorize privileged operations. Although the TPM owner is similar to a traditional superuser, there are two important differences. First, process privilege is irrelevant for access to TPM functions. All privileged operations require knowledge of the owner password, regardless of the privilege level of the calling process. Second, the TPM owner is not able to override access controls for data protected by TPM keys. The owner can effectively destroy data by re-initializing the TPM, but he cannot access data that has been encrypted using TPM keys owned by other users. SUBCOMMANDS tpmadm status Report status information about the TPM. Output includes basic information about whether ownership of the TPM has been established, current PCR contents, and the usage of TPM resources such as communication sessions and loaded keys. tpmadm init Initialize the TPM for use. This involves taking ownership of the TPM by setting the owner authorization password. Taking ownership of the TPM creates a new storage root key, which is the ancestor of all keys created by this TPM. Once this command is issued, the TPM must be reset using BIOS operations before it can be re-initialized. tpmadm passwd Change the owner authorization password for the TPM. tpmadm resetlock Reset the count of failed authentication attempts. After a number of failed authentication attempts, the TPM responds more slowly to subsequent attempts, in an effort to thwart attempts to find the owner password by exhaustive search. This command, which requires the correct owner password, resets the count of failed attempts. tpmadm keyinfo [ ] Report information about keys stored in the TPM subsystem. Without additional arguments, this subcommand produces a brief listing of all keys. If the UUID of an individual key is specified, detailed information about that key is printed. tpmadm deletekey Delete the key with the specified UUID from the TPM subsystem's persistent storage. EXIT STATUS After completing the requested operation, tpmadm exits with one of the following status values. 0 Successful termination 1 Failure - The requested operation could not be completed. 2 Usage error - The tpmadm command was invoked with invalid arguments. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: _____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Availability | SUNWcsu | |_____________________________|_____________________________| | Interface Stability | Committed | |_____________________________|_____________________________| SEE ALSO attributes(5) TCG Software Stack (TSS) Specifications: https://www.trustedcomputinggroup.org/specs/TSS --Boundary_(ID_UMVXAS/vcmBUH71C0CYJxA)-- From edward.pilatowicz@sun.com Wed Nov 26 14:41:41 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 mAQMfehP022257 for ; Wed, 26 Nov 2008 14:41:41 -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 mAQMfVDm029924; Wed, 26 Nov 2008 22:41:38 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 <0KAY00A05PPDR600@brm-avmta-1.central.sun.com>; Wed, 26 Nov 2008 15:41:37 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAY00KF2PPC3GA0@brm-avmta-1.central.sun.com>; Wed, 26 Nov 2008 15:41:36 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mAQMeiKk327031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Nov 2008 14:40:50 -0800 (PST) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id mAQMeWVv327025; Wed, 26 Nov 2008 14:40:32 -0800 (PST) Date: Wed, 26 Nov 2008 14:40:32 -0800 From: Edward Pilatowicz Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> To: Wyllys Ingersoll Cc: PSARC-ext@sun.com Message-id: <20081126224032.GD200954@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.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 2002 i have some concerns about the zones integration proposed by this case. in general, we recommend that applications be deployed within zones since that provides an easy way to contain application configuration. with this proposal, if an administrator deploys an application in a zone which tries to use the TSS library, then they have to modify the tcsd.conf file in the global zone. this breaks up the application configuration across multiple zones and impacts zone migration, there by eliminating the application encapsulation benefits that zones provides. this proposal also assumes that any zones which want to use the TSS library functionality will have network access to the global zone. this is an invalid assumption. exclusive ip stack zones allow for zones with network configurations which are compleatly independent of the global zone. depending on the deployment, the global zone may not even be accessible via the network. i also don't see any discussion of security issues wrt allowing remote access to the TSS daemon. once an admin decides to enable remote host access via tcsd.conf, how is authentication and authorisation of remote clients handled? looking at the tcsd.conf file, it seems that a zone administrator might want to tune these configuration parameters locally within a zone depending on the behaviour of the TSS library consumers running within the zone. that's not possible with this proposal. to me it seems to me that each zone should have it's own copy of TSS daemon with it's own tcsd.conf configuration file. It should be the responsibility of the TPM device driver to manage requests from multiple zones, with any zone device specific configuration being managed via zonecfg. (that said, i don't have a complete understanding of the TPM/TSS device interfaces, so there may be other better ways to virtualize this subsystem to work with zones, and hence i'd be more than willing to discuss options to improve the zones integration of this feature.) ed From wyllys.ingersoll@sun.com Thu Nov 27 11:21:55 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 mARJLs4V025595 for ; Thu, 27 Nov 2008 11:21:55 -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 mARJLfSJ023731; Thu, 27 Nov 2008 19:21: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 <0KB000803B4E6H00@nwk-avmta-2.sfbay.sun.com>; Thu, 27 Nov 2008 11:21:50 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KB000MWFB4E9K90@nwk-avmta-2.sfbay.sun.com>; Thu, 27 Nov 2008 11:21:50 -0800 (PST) Received: from [129.148.19.16] (punchin-client-129-148-19-16.East.Sun.COM [129.148.19.16]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mARJLRPV422601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Nov 2008 11:21:34 -0800 (PST) Date: Thu, 27 Nov 2008 14:21:27 -0500 From: Wyllys Ingersoll Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <20081126224032.GD200954@eng.sun.com> To: Edward Pilatowicz Cc: PSARC-ext@sun.com Message-id: <492EF337.7080100@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 4061 Edward Pilatowicz wrote: > i have some concerns about the zones integration proposed by this case. > > in general, we recommend that applications be deployed within zones > since that provides an easy way to contain application configuration. > with this proposal, if an administrator deploys an application in a zone > which tries to use the TSS library, then they have to modify the > tcsd.conf file in the global zone. this breaks up the application > configuration across multiple zones and impacts zone migration, there by > eliminating the application encapsulation benefits that zones provides. > > this proposal also assumes that any zones which want to use the TSS > library functionality will have network access to the global zone. this > is an invalid assumption. exclusive ip stack zones allow for zones with > network configurations which are compleatly independent of the global > zone. depending on the deployment, the global zone may not even be > accessible via the network. > > i also don't see any discussion of security issues wrt allowing remote > access to the TSS daemon. once an admin decides to enable remote host > access via tcsd.conf, how is authentication and authorisation of remote > clients handled? By default, network access is disabled. Authentication of sensitive commands is defined in the TSS specifications, the remote application would have to know the correct passphrases (which are encrypted) to be able to perform sensitive operations. The authentication and authorization is handled by the TCS Daemon according to the specifications and the settings in the tcsd.conf file. > looking at the tcsd.conf file, it seems that a zone administrator might > want to tune these configuration parameters locally within a zone > depending on the behaviour of the TSS library consumers running within > the zone. that's not possible with this proposal. This project is basically proposing to putback the current open source TSS stack (TrouSerS v0.3.1) and the above design comes from TrouSerS not from us. TrouSerS is currently being used on many Linux platforms that have TPM devices, all of which have the same configuration model. Deviating from the implementation in the ways you are proposing may be possible, but I would prefer to take that on as an RFE for later and work with the community to implement it in the original project code and not have to apply unique feature patches in our version. Presumably, this would involve adding new configurations that would allow for access to the TCS from a zone on the same system, but not from an external host. Our first priority is to get TrouSerS into Solaris. Improving it and making it take advantage of more of the unique Solaris features is more of a long term goal that I would be happy to work on once we have the first phase in place. > > to me it seems to me that each zone should have it's own copy of TSS > daemon with it's own tcsd.conf configuration file. It should be the > responsibility of the TPM device driver to manage requests from multiple > zones, with any zone device specific configuration being managed via > zonecfg. (that said, i don't have a complete understanding of the > TPM/TSS device interfaces, so there may be other better ways to > virtualize this subsystem to work with zones, and hence i'd be more than > willing to discuss options to improve the zones integration of this > feature.) Allowing for multiple TCS daemons in multiple zones would violate the spec and would not be acceptable to the upstream development community for TrouSerS. The TSS specification specifically states that the TPM should only handle accept connection at a time. The TSS daemon (tcsd) is also part of the specification and it is responsible for handling all direct access to the TPM. There are specifications for Virtualized TPM devices, but those are not yet implemented by our driver or the TSS libraries. I do believe working on the virtual TPM support is something we do plan to investigate in the future, though. -Wyllys From edward.pilatowicz@sun.com Thu Nov 27 15:17:50 2008 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 mARNHnhM013918 for ; Thu, 27 Nov 2008 15:17:49 -0800 (PST) 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 mARNHlTi002621; Thu, 27 Nov 2008 16:17:49 -0700 (MST) 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 <0KB000603M1O9A00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 27 Nov 2008 15:17:48 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KB000265M1OR310@nwk-avmta-1.sfbay.Sun.COM>; Thu, 27 Nov 2008 15:17:48 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mARNHTqH437164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Nov 2008 15:17:35 -0800 (PST) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id mARNHNB8437161; Thu, 27 Nov 2008 15:17:23 -0800 (PST) Date: Thu, 27 Nov 2008 15:17:23 -0800 From: Edward Pilatowicz Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <492EF337.7080100@sun.com> To: Wyllys Ingersoll Cc: PSARC-ext@sun.com Message-id: <20081127231723.GH348957@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.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 7236 On Thu, Nov 27, 2008 at 02:21:27PM -0500, Wyllys Ingersoll wrote: > Edward Pilatowicz wrote: >> i have some concerns about the zones integration proposed by this case. >> >> in general, we recommend that applications be deployed within zones >> since that provides an easy way to contain application configuration. >> with this proposal, if an administrator deploys an application in a zone >> which tries to use the TSS library, then they have to modify the >> tcsd.conf file in the global zone. this breaks up the application >> configuration across multiple zones and impacts zone migration, there by >> eliminating the application encapsulation benefits that zones provides. >> >> this proposal also assumes that any zones which want to use the TSS >> library functionality will have network access to the global zone. this >> is an invalid assumption. exclusive ip stack zones allow for zones with >> network configurations which are compleatly independent of the global >> zone. depending on the deployment, the global zone may not even be >> accessible via the network. >> >> i also don't see any discussion of security issues wrt allowing remote >> access to the TSS daemon. once an admin decides to enable remote host >> access via tcsd.conf, how is authentication and authorisation of remote >> clients handled? > > By default, network access is disabled. Authentication of sensitive > commands > is defined in the TSS specifications, the remote application would have to > know the > correct passphrases (which are encrypted) to be able to perform sensitive > operations. > The authentication and authorization is handled by the TCS Daemon according > to the specifications and the settings in the tcsd.conf file. > ah. ok. i looked briefly through the TPM spec to try and determine the device/daemon interfaces, but unfortunately there's a whole lot of spec out there that this case covers. ;) good to hear this functionality is present. (although having authentication still doesn't address the portability and network configuration limitations of the current implementation.) >> looking at the tcsd.conf file, it seems that a zone administrator might >> want to tune these configuration parameters locally within a zone >> depending on the behaviour of the TSS library consumers running within >> the zone. that's not possible with this proposal. > This project is basically proposing to putback the current open source > TSS stack (TrouSerS v0.3.1) and the above design comes from TrouSerS > not from us. TrouSerS is currently being used on many Linux > platforms that have TPM devices, all of which have the same > configuration model. > > Deviating from the implementation in the ways you are proposing may be > possible, but I would prefer to take that on as an RFE for later and work > with > the community to implement it in the original project code and not have to > apply unique feature patches in our version. > > Presumably, this would involve adding new configurations that would allow > for access to the TCS from a zone on the same system, but not from an > external host. > > Our first priority is to get TrouSerS into Solaris. Improving it and making > it take advantage of more of the unique Solaris features is more of a long > term goal that I would be happy to work on once we have the first phase in > place. > well, there could be multiple implementation options. one option (which you seem to refer to above) would be to allow zones to communicate to a tss daemon in the global zone via some other non-network based transport (like say doors). as you mention, this would require modifications to community code. another option (and the first one that i'd recommend investigating) would be to virtualize the TPM device driver. it sounds like your implementing the driver component yourself (instead of delivering community developed driver code). if this is the case then virtualizing at this layer wouldn't involve any deviation from the community code. >> to me it seems to me that each zone should have it's own copy of TSS >> daemon with it's own tcsd.conf configuration file. It should be the >> responsibility of the TPM device driver to manage requests from multiple >> zones, with any zone device specific configuration being managed via >> zonecfg. (that said, i don't have a complete understanding of the >> TPM/TSS device interfaces, so there may be other better ways to >> virtualize this subsystem to work with zones, and hence i'd be more than >> willing to discuss options to improve the zones integration of this >> feature.) > Allowing for multiple TCS daemons in multiple zones would violate the spec > and would > not be acceptable to the upstream development community for TrouSerS. > The TSS specification specifically states that the TPM should > only handle accept connection at a time. The TSS daemon (tcsd) is also > part of the specification and it is responsible for handling all direct > access to the TPM. well, i wasn't suggesting that you'd want to support multiple TCS daemons in a single zone, just one in each zone. this is why i would initially recommended investigating virtualization at the device layer, since presumably if done correctly, each zone would believe that it has exclusive access to the TPM device. could you point me to the TPM device driver interfaces that will be delivered? (i'd be interested in looking at them to determine the difficulty of virtualizing them.) > ... There are specifications for Virtualized TPM devices, > but those are not yet implemented by our driver or the TSS libraries. I do > believe working on the virtual TPM support is something we do plan to > investigate > in the future, though. > it's good to hear that the community is working on a Virtualized TPM devices. are you at all involved in this process? i ask because zones virtualization is different than other system/platform types of virtualization, so there's no guarantee that their virtualization approach will be applicable to and/or leveragable by zones. i know that you just want to deliver the community tpm/tss code into solaris, but i'd like to know what the long term architecture is for supporting this functionality with zones (even if you plan to deliver that functionality in a subsequent putback). looking at this from a zones perspective, ideally, we'd like non-global zones to look exactly like the global zone. anything which can be done in the global zone should be do-able in the non-global zone in the same manner as in the global zone (assuming that the zone has been given access to any required physical resources necessary to do the requested operation). with that in mind, at a minimum level, couldn't you deliver the userland stack (daemon and libraries) into each zone, and then if an admin wants to deploy a tss based application in a zone they could simply disable the tss daemon in the global zone, add /dev/tpm (or whatever) into the zonecfg device spec, and enable the tss daemon within that zone. this would allow any one zone on the system to use tpm at a time and would at least address the configuration containment and network configuration limitations in the current proposal. ed From wyllys.ingersoll@sun.com Thu Nov 27 17:52:03 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAS1q39d017599 for ; Thu, 27 Nov 2008 17:52:03 -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 mAS1q2tK025389; Thu, 27 Nov 2008 17:52:02 -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 <0KB000305T6PW000@brm-avmta-1.central.sun.com>; Thu, 27 Nov 2008 18:52:01 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KB0000E1T6OPUA0@brm-avmta-1.central.sun.com>; Thu, 27 Nov 2008 18:52:00 -0700 (MST) Received: from [129.148.19.16] (punchin-client-129-148-19-16.East.Sun.COM [129.148.19.16]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mAS1pel1444567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Nov 2008 17:51:47 -0800 (PST) Date: Thu, 27 Nov 2008 20:51:40 -0500 From: Wyllys Ingersoll Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <20081127231723.GH348957@eng.sun.com> To: Edward Pilatowicz Cc: PSARC-ext@sun.com Message-id: <492F4EAC.1020905@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 6216 Edward Pilatowicz wrote: > >> This project is basically proposing to putback the current open source >> TSS stack (TrouSerS v0.3.1) and the above design comes from TrouSerS >> not from us. TrouSerS is currently being used on many Linux >> platforms that have TPM devices, all of which have the same >> configuration model. >> >> Deviating from the implementation in the ways you are proposing may be >> possible, but I would prefer to take that on as an RFE for later and work >> with >> the community to implement it in the original project code and not have to >> apply unique feature patches in our version. >> >> Presumably, this would involve adding new configurations that would allow >> for access to the TCS from a zone on the same system, but not from an >> external host. >> >> Our first priority is to get TrouSerS into Solaris. Improving it and making >> it take advantage of more of the unique Solaris features is more of a long >> term goal that I would be happy to work on once we have the first phase in >> place. >> >> > > well, there could be multiple implementation options. > > one option (which you seem to refer to above) would be to allow zones to > communicate to a tss daemon in the global zone via some other > non-network based transport (like say doors). as you mention, this > would require modifications to community code. > > another option (and the first one that i'd recommend investigating) > would be to virtualize the TPM device driver. it sounds like your > implementing the driver component yourself (instead of delivering > community developed driver code). if this is the case then virtualizing > at this layer wouldn't involve any deviation from the community code. > It's true that the TPM driver is not from open source or from an external community. However, virtualization of the TPM is a concern of the TCG and is being addressed by a working group within the TCG. I don't think there has been a final spec delivered as of yet that addresses virtualization. In the interest of getting basic TPM support into Solaris (an area in which we are already way behind Microsoft and Linux), I would like to go forward with our current plan and address virtualization later. >>> to me it seems to me that each zone should have it's own copy of TSS >>> daemon with it's own tcsd.conf configuration file. It should be the >>> responsibility of the TPM device driver to manage requests from multiple >>> zones, with any zone device specific configuration being managed via >>> zonecfg. (that said, i don't have a complete understanding of the >>> TPM/TSS device interfaces, so there may be other better ways to >>> virtualize this subsystem to work with zones, and hence i'd be more than >>> willing to discuss options to improve the zones integration of this >>> feature.) >>> >> Allowing for multiple TCS daemons in multiple zones would violate the spec >> and would >> not be acceptable to the upstream development community for TrouSerS. >> The TSS specification specifically states that the TPM should >> only handle accept connection at a time. The TSS daemon (tcsd) is also >> part of the specification and it is responsible for handling all direct >> access to the TPM. >> > > well, i wasn't suggesting that you'd want to support multiple TCS > daemons in a single zone, just one in each zone. this is why i would > initially recommended investigating virtualization at the device layer, > since presumably if done correctly, each zone would believe that it has > exclusive access to the TPM device. > > could you point me to the TPM device driver interfaces that will be > delivered? (i'd be interested in looking at them to determine the > difficulty of virtualizing them.) > Do you want pointer to the source code or the specs? >> ... There are specifications for Virtualized TPM devices, >> but those are not yet implemented by our driver or the TSS libraries. I do >> believe working on the virtual TPM support is something we do plan to >> investigate >> in the future, though. >> >> > > it's good to hear that the community is working on a Virtualized TPM > devices. are you at all involved in this process? i ask because zones > virtualization is different than other system/platform types of > virtualization, so there's no guarantee that their virtualization > approach will be applicable to and/or leveragable by zones. > I am active in the TCG but have not been following the virtualization working groups. Perhaps once we have basic TPM support, I will start following the virtualization WG and find out what direction they are headed in. > i know that you just want to deliver the community tpm/tss code into > solaris, but i'd like to know what the long term architecture is for > supporting this functionality with zones (even if you plan to deliver > that functionality in a subsequent putback). looking at this from a > zones perspective, ideally, we'd like non-global zones to look exactly > like the global zone. anything which can be done in the global zone > should be do-able in the non-global zone in the same manner as in the > global zone (assuming that the zone has been given access to any > required physical resources necessary to do the requested operation). > > with that in mind, at a minimum level, couldn't you deliver the userland > stack (daemon and libraries) into each zone, and then if an admin wants > to deploy a tss based application in a zone they could simply disable > the tss daemon in the global zone, add /dev/tpm (or whatever) into the > zonecfg device spec, and enable the tss daemon within that zone. this > would allow any one zone on the system to use tpm at a time and would at > least address the configuration containment and network configuration > limitations in the current proposal. > That might work. Obviously, there is no problem delivering the daemon and libraries in all zones. As long as there is only 1 instance of the TPM device in the kernel, and one reader/write of that device in userland (across all zones), I see no problem having the tpm device be located in whatever zone the admin prefers to install it. -Wyllys From edward.pilatowicz@sun.com Thu Nov 27 23:58:44 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAS7wirk013084 for ; Thu, 27 Nov 2008 23:58:44 -0800 (PST) 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 mAS7wgCH017463; Thu, 27 Nov 2008 23:58:43 -0800 (PST) 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 <0KB100C03A5TXL00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 27 Nov 2008 23:58:41 -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 <0KB1003OXA5TZ1E0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 27 Nov 2008 23:58:41 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mAS7wNuX459312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Nov 2008 23:58:29 -0800 (PST) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id mAS7wHlS459307; Thu, 27 Nov 2008 23:58:17 -0800 (PST) Date: Thu, 27 Nov 2008 23:58:16 -0800 From: Edward Pilatowicz Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <492F4EAC.1020905@sun.com> To: Wyllys Ingersoll Cc: PSARC-ext@sun.com Message-id: <20081128075816.GL348957@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.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 7710 On Thu, Nov 27, 2008 at 08:51:40PM -0500, Wyllys Ingersoll wrote: > Edward Pilatowicz wrote: >> >>> This project is basically proposing to putback the current open source >>> TSS stack (TrouSerS v0.3.1) and the above design comes from TrouSerS >>> not from us. TrouSerS is currently being used on many Linux >>> platforms that have TPM devices, all of which have the same >>> configuration model. >>> >>> Deviating from the implementation in the ways you are proposing may be >>> possible, but I would prefer to take that on as an RFE for later and work >>> with >>> the community to implement it in the original project code and not have to >>> apply unique feature patches in our version. >>> >>> Presumably, this would involve adding new configurations that would allow >>> for access to the TCS from a zone on the same system, but not from an >>> external host. >>> >>> Our first priority is to get TrouSerS into Solaris. Improving it and making >>> it take advantage of more of the unique Solaris features is more of a long >>> term goal that I would be happy to work on once we have the first phase in >>> place. >>> >> >> well, there could be multiple implementation options. >> >> one option (which you seem to refer to above) would be to allow zones to >> communicate to a tss daemon in the global zone via some other >> non-network based transport (like say doors). as you mention, this >> would require modifications to community code. >> >> another option (and the first one that i'd recommend investigating) >> would be to virtualize the TPM device driver. it sounds like your >> implementing the driver component yourself (instead of delivering >> community developed driver code). if this is the case then virtualizing >> at this layer wouldn't involve any deviation from the community code. >> > > It's true that the TPM driver is not from open source or from an external > community. > However, virtualization of the TPM is a concern of the TCG and is being > addressed > by a working group within the TCG. I don't think there has been a final > spec delivered > as of yet that addresses virtualization. > > In the interest of getting basic TPM support into Solaris (an area in which > we > are already way behind Microsoft and Linux), I would like to go forward with > our current plan and address virtualization later. > given the current situation, i don't think it would make sense to hold up this proposal to wait for full tpm support within zones. but as we've discussed offline, to continue to support application deployment within zones, there needs to be a plan for fully virtualized tpm support within zones. (with this support potentially being independent of any virtualization work done by the TCG working group.) there for please update your future roadmap appropriately. (and feel free to contact me to discuss any zones plans or interactions wrt future projects.) >>>> to me it seems to me that each zone should have it's own copy of TSS >>>> daemon with it's own tcsd.conf configuration file. It should be the >>>> responsibility of the TPM device driver to manage requests from multiple >>>> zones, with any zone device specific configuration being managed via >>>> zonecfg. (that said, i don't have a complete understanding of the >>>> TPM/TSS device interfaces, so there may be other better ways to >>>> virtualize this subsystem to work with zones, and hence i'd be more than >>>> willing to discuss options to improve the zones integration of this >>>> feature.) >>>> >>> Allowing for multiple TCS daemons in multiple zones would violate the spec >>> and would >>> not be acceptable to the upstream development community for TrouSerS. >>> The TSS specification specifically states that the TPM should >>> only handle accept connection at a time. The TSS daemon (tcsd) is also >>> part of the specification and it is responsible for handling all direct >>> access to the TPM. >>> >> >> well, i wasn't suggesting that you'd want to support multiple TCS >> daemons in a single zone, just one in each zone. this is why i would >> initially recommended investigating virtualization at the device layer, >> since presumably if done correctly, each zone would believe that it has >> exclusive access to the TPM device. >> >> could you point me to the TPM device driver interfaces that will be >> delivered? (i'd be interested in looking at them to determine the >> difficulty of virtualizing them.) >> > > Do you want pointer to the source code or the specs? > a pointer to the tpm driver source would be great. (i looked at the tpm specs online and i couldn't really discern what the driver / daemon interfaces boundary, but perhaps i just missed it.) >>> ... There are specifications for Virtualized TPM devices, >>> but those are not yet implemented by our driver or the TSS libraries. I do >>> believe working on the virtual TPM support is something we do plan to >>> investigate >>> in the future, though. >>> >>> >> >> it's good to hear that the community is working on a Virtualized TPM >> devices. are you at all involved in this process? i ask because zones >> virtualization is different than other system/platform types of >> virtualization, so there's no guarantee that their virtualization >> approach will be applicable to and/or leveragable by zones. >> > > I am active in the TCG but have not been following the virtualization > working > groups. Perhaps once we have basic TPM support, I will start following the > virtualization WG and find out what direction they are headed in. > that would be greatly appreciated. >> i know that you just want to deliver the community tpm/tss code into >> solaris, but i'd like to know what the long term architecture is for >> supporting this functionality with zones (even if you plan to deliver >> that functionality in a subsequent putback). looking at this from a >> zones perspective, ideally, we'd like non-global zones to look exactly >> like the global zone. anything which can be done in the global zone >> should be do-able in the non-global zone in the same manner as in the >> global zone (assuming that the zone has been given access to any >> required physical resources necessary to do the requested operation). >> >> with that in mind, at a minimum level, couldn't you deliver the userland >> stack (daemon and libraries) into each zone, and then if an admin wants >> to deploy a tss based application in a zone they could simply disable >> the tss daemon in the global zone, add /dev/tpm (or whatever) into the >> zonecfg device spec, and enable the tss daemon within that zone. this >> would allow any one zone on the system to use tpm at a time and would at >> least address the configuration containment and network configuration >> limitations in the current proposal. >> > > That might work. Obviously, there is no problem delivering the daemon and > libraries > in all zones. As long as there is only 1 instance of the TPM device in > the kernel, > and one reader/write of that device in userland (across all zones), I see > no problem > having the tpm device be located in whatever zone the admin prefers to > install it. > i think this would be a good stop-gap measure. it would simplify the deployment of tss based application in one non-global zone. as an implementation detail, you'll probably want to enhance zoneadm to detect when a zone is booting with a tpm device allocated to it, and have it verify that there are no other booted zones with tpm devices and that the tss daemon is not running in the global zone. (this keeps things user friendly, and zoneadm already does similar checks to verify that other required smf services are running.) ed From wyllys.ingersoll@sun.com Mon Dec 1 07:18:33 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 mB1FIW6I001072 for ; Mon, 1 Dec 2008 07:18:33 -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 mB1FIQ9a007957; Mon, 1 Dec 2008 15:18:30 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 <0KB700H07EITJZ00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Dec 2008 07:18:29 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KB700AAFEIT8G70@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Dec 2008 07:18:29 -0800 (PST) Received: from [10.7.251.182] (punchin-wyllys.SFBay.Sun.COM [10.7.251.182]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB1FIQTS841211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 01 Dec 2008 07:18:29 -0800 (PST) Date: Mon, 01 Dec 2008 10:18:26 -0500 From: Wyllys Ingersoll Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <20081128075816.GL348957@eng.sun.com> To: Edward Pilatowicz Cc: PSARC-ext@sun.com Message-id: <49340042.20807@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 1210 >> That might work. Obviously, there is no problem delivering the daemon and >> libraries >> in all zones. As long as there is only 1 instance of the TPM device in >> the kernel, >> and one reader/write of that device in userland (across all zones), I see >> no problem >> having the tpm device be located in whatever zone the admin prefers to >> install it. >> >> > > i think this would be a good stop-gap measure. it would simplify the > deployment of tss based application in one non-global zone. > > as an implementation detail, you'll probably want to enhance zoneadm to detect > when a zone is booting with a tpm device allocated to it, and have it verify > that there are no other booted zones with tpm devices and that the tss daemon > is not running in the global zone. (this keeps things user friendly, and > zoneadm already does similar checks to verify that other required smf services > are running.) > > ed > The tpm device itself will not allow multiple readers, so I'm not sure if any external tool modification (zoneadm, etc) is even necessary. The device will respond to the first app to open it, no other apps can open the device until it gets closed again. -Wyllys From carlsonj@phorcys.east.sun.com Mon Dec 1 07:37:45 2008 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 mB1FbiPf001425 for ; Mon, 1 Dec 2008 07:37:45 -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 mB1FbUXf029668; Mon, 1 Dec 2008 23:37:41 +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 <0KB70062BFEQ5U00@brm-avmta-1.central.sun.com>; Mon, 01 Dec 2008 08:37:38 -0700 (MST) 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 <0KB700I4KFEMG7D0@brm-avmta-1.central.sun.com>; Mon, 01 Dec 2008 08:37:34 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB1FbYaP002493; Mon, 01 Dec 2008 10:37:34 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mB1FbY7h002490; Mon, 01 Dec 2008 10:37:34 -0500 (EST) Date: Mon, 01 Dec 2008 10:37:34 -0500 From: James Carlson Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <49340042.20807@sun.com> To: Wyllys Ingersoll Cc: Edward Pilatowicz , PSARC-ext@sun.com Message-id: <18740.1214.256920.275347@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.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> Status: RO Content-Length: 1161 Wyllys Ingersoll writes: > > i think this would be a good stop-gap measure. it would simplify the > > deployment of tss based application in one non-global zone. > > > > as an implementation detail, you'll probably want to enhance zoneadm to detect > > when a zone is booting with a tpm device allocated to it, and have it verify > > that there are no other booted zones with tpm devices and that the tss daemon > > is not running in the global zone. (this keeps things user friendly, and > > zoneadm already does similar checks to verify that other required smf services > > are running.) > > > > ed > > > > > The tpm device itself will not allow multiple readers, so I'm not sure > if any external > tool modification (zoneadm, etc) is even necessary. The device will > respond to the first > app to open it, no other apps can open the device until it gets closed > again. Is opening it and doing nothing an effective DoS? -- 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 wyllys.ingersoll@sun.com Mon Dec 1 08:07:05 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB1G7593000555 for ; Mon, 1 Dec 2008 08:07:05 -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 mB1G74OK011826; Mon, 1 Dec 2008 08:07:04 -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 <0KB700B4BGRRQ400@nwk-avmta-2.sfbay.sun.com>; Mon, 01 Dec 2008 08:07:03 -0800 (PST) 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 <0KB7008WWGRNAH80@nwk-avmta-2.sfbay.sun.com>; Mon, 01 Dec 2008 08:06:59 -0800 (PST) Received: from [10.7.251.182] (punchin-wyllys.SFBay.Sun.COM [10.7.251.182]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB1G6vJ0849091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 01 Dec 2008 08:06:59 -0800 (PST) Date: Mon, 01 Dec 2008 11:06:56 -0500 From: Wyllys Ingersoll Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <18740.1214.256920.275347@gargle.gargle.HOWL> To: James Carlson Cc: PSARC-ext@sun.com Message-id: <49340BA0.2000209@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <18740.1214.256920.275347@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 1074 James Carlson wrote: > Wyllys Ingersoll writes: > >>> i think this would be a good stop-gap measure. it would simplify the >>> deployment of tss based application in one non-global zone. >>> >>> as an implementation detail, you'll probably want to enhance zoneadm to detect >>> when a zone is booting with a tpm device allocated to it, and have it verify >>> that there are no other booted zones with tpm devices and that the tss daemon >>> is not running in the global zone. (this keeps things user friendly, and >>> zoneadm already does similar checks to verify that other required smf services >>> are running.) >>> >>> ed >>> >>> >> The tpm device itself will not allow multiple readers, so I'm not sure >> if any external >> tool modification (zoneadm, etc) is even necessary. The device will >> respond to the first >> app to open it, no other apps can open the device until it gets closed >> again. >> > > Is opening it and doing nothing an effective DoS? > The device should be 0600 root:sys to prevent just anyone from locking it up. From carlsonj@phorcys.east.sun.com Mon Dec 1 08:14:33 2008 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 mB1GEWJN018005 for ; Mon, 1 Dec 2008 08:14:32 -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 mB1GENhi019937; Tue, 2 Dec 2008 00:14: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 <0KB70001LH42YV00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Dec 2008 08:14:26 -0800 (PST) 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 <0KB700AQ1H418GD0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Dec 2008 08:14:25 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB1GEO4R002751; Mon, 01 Dec 2008 11:14:24 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mB1GEOci002748; Mon, 01 Dec 2008 11:14:24 -0500 (EST) Date: Mon, 01 Dec 2008 11:14:24 -0500 From: James Carlson Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <49340BA0.2000209@sun.com> To: Wyllys Ingersoll Cc: PSARC-ext@sun.com Message-id: <18740.3424.876649.44875@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.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <18740.1214.256920.275347@gargle.gargle.HOWL> <49340BA0.2000209@sun.com> Status: RO Content-Length: 478 Wyllys Ingersoll writes: > James Carlson wrote: > > Is opening it and doing nothing an effective DoS? > > > > The device should be 0600 root:sys to prevent just anyone from locking > it up. OK. That approach, though, wouldn't be enough for Zones. -- 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 wyllys.ingersoll@sun.com Mon Dec 1 09:14:20 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB1HEKTG019157 for ; Mon, 1 Dec 2008 09:14:20 -0800 (PST) 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 mB1HEHnZ027881; Mon, 1 Dec 2008 09:14:19 -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 <0KB700F0DJVUPY00@brm-avmta-1.central.sun.com>; Mon, 01 Dec 2008 10:14:18 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KB700FAWJVU0710@brm-avmta-1.central.sun.com>; Mon, 01 Dec 2008 10:14:18 -0700 (MST) Received: from [10.7.251.182] (punchin-wyllys.SFBay.Sun.COM [10.7.251.182]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB1HEHtF860424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 01 Dec 2008 09:14:17 -0800 (PST) Date: Mon, 01 Dec 2008 12:14:16 -0500 From: Wyllys Ingersoll Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <18740.6212.622080.851881@gargle.gargle.HOWL> To: James Carlson , PSARC-ext@sun.com Message-id: <49341B68.5000103@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <18740.1214.256920.275347@gargle.gargle.HOWL> <49340BA0.2000209@sun.com> <18740.3424.876649.44875@gargle.gargle.HOWL> <49341599.1020205@sun.com> <18740.6212.622080.851881@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 1758 >> >> What would you suggest in this case? I'm not very familiar with the unique >> requirements of Zones and device drivers. > > The unique requirement here is that if you're assuming in the kernel > that there's only one valid stream open on the device at a time, you'd > end up with one zone user blocking another from gaining access. Yes, that is correct. The TPM specification states that the TPM can handle only 1 at a time. Other connections are rejected. The TCS Daemon (userland) is designed to handle the sequencing and manage the access to a single TPM from multiple sources. That is why I originally suggested that the TPM should only reside in the global zone and that local zones would access it over the network and be subject to access controls as specified in the tcsd.conf. I still believe that is probably preferable in this situation. A non-global zone should be treated as a system without a resident TPM and would have to use the network to access the TCS instead of getting it's own direct access to the device. I suggested that we could deliver the TPM device and libraries in all zones but that the administrator would have to know that only 1 zone per-system is allowed to access the TPM. That would at least allow the administrator to configure any single zone to run the TCS daemon instead of forcing it to be in the global zone, but it still has the restriction of only 1 TCS daemon per TPM. > > If it really must be a single user at a time, then it'd have to be > set up so that you can handle multiple simultaneous users within the > kernel, but with just one per zoneid_t. The TCS daemon is designed to be the primary access point, applications are never supposed to access the device directly. -Wyllys From carlsonj@phorcys.east.sun.com Mon Dec 1 09:29:22 2008 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 mB1HTLBH019464 for ; Mon, 1 Dec 2008 09:29:21 -0800 (PST) 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 mB1HTHAq028775; Mon, 1 Dec 2008 10:29:21 -0700 (MST) 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 <0KB700B09KKW0M00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Dec 2008 09:29:20 -0800 (PST) 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 <0KB7003QBKKVE950@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Dec 2008 09:29:20 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB1HTJwh003233; Mon, 01 Dec 2008 12:29:19 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mB1HTJew003230; Mon, 01 Dec 2008 12:29:19 -0500 (EST) Date: Mon, 01 Dec 2008 12:29:19 -0500 From: James Carlson Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <49341B68.5000103@sun.com> To: Wyllys Ingersoll Cc: PSARC-ext@sun.com Message-id: <18740.7919.563335.922968@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.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <18740.1214.256920.275347@gargle.gargle.HOWL> <49340BA0.2000209@sun.com> <18740.3424.876649.44875@gargle.gargle.HOWL> <49341599.1020205@sun.com> <18740.6212.622080.851881@gargle.gargle.HOWL> <49341B68.5000103@sun.com> Status: RO Content-Length: 1115 Wyllys Ingersoll writes: > sources. That is why I originally suggested that the TPM should only > reside > in the global zone and that local zones would access it over the network > and be subject to access controls as specified in the tcsd.conf. It sounds to me like the complete Zones solution will require a non-network-based cross-zone communication mechanism. > I suggested that we could deliver the TPM device and libraries in all zones > but that the administrator would have to know that only 1 zone per-system > is allowed to access the TPM. That would at least allow the administrator > to configure any single zone to run the TCS daemon instead of forcing it to > be in the global zone, but it still has the restriction of only 1 TCS > daemon per TPM. That doesn't make sense to me. Why would the administrator _NOT_ want to have access to the TPM in more than one zone? -- 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 Mon Dec 1 09:43:53 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 mB1HhrJu019608 for ; Mon, 1 Dec 2008 09:43:53 -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 mB1Hhjql028253 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 1 Dec 2008 17:43:52 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 <0KB700I09L93PS00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Dec 2008 10:43:51 -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 <0KB700FY6L920750@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Dec 2008 10:43:50 -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 mB1HhoZR019679 for ; Mon, 01 Dec 2008 09:43:50 -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 <0KB700I01KQ3N700@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Dec 2008 09:43:50 -0800 (PST) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KB70027XL922JB0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Dec 2008 09:43:50 -0800 (PST) Date: Mon, 01 Dec 2008 09:37:07 -0800 From: "Garrett D'Amore" Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <49341B68.5000103@sun.com> Sender: Garrett.Damore@sun.com To: Wyllys Ingersoll Cc: James Carlson , PSARC-ext@sun.com Message-id: <493420C3.9000706@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <18740.1214.256920.275347@gargle.gargle.HOWL> <49340BA0.2000209@sun.com> <18740.3424.876649.44875@gargle.gargle.HOWL> <49341599.1020205@sun.com> <18740.6212.622080.851881@gargle.gargle.HOWL> <49341B68.5000103@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 2677 Wyllys Ingersoll wrote: > >>> >>> What would you suggest in this case? I'm not very familiar with the >>> unique >>> requirements of Zones and device drivers. >> >> The unique requirement here is that if you're assuming in the kernel >> that there's only one valid stream open on the device at a time, you'd >> end up with one zone user blocking another from gaining access. > > Yes, that is correct. The TPM specification states that the TPM can > handle only > 1 at a time. Other connections are rejected. The TCS Daemon > (userland) is designed > to handle the sequencing and manage the access to a single TPM from > multiple > sources. That is why I originally suggested that the TPM should > only reside > in the global zone and that local zones would access it over the network > and be subject to access controls as specified in the tcsd.conf. > > I still believe that is probably preferable in this situation. A > non-global zone > should be treated as a system without a resident TPM and would have to > use the network to access the TCS instead of getting it's own direct > access > to the device. > > I suggested that we could deliver the TPM device and libraries in all > zones > but that the administrator would have to know that only 1 zone per-system > is allowed to access the TPM. That would at least allow the > administrator > to configure any single zone to run the TCS daemon instead of forcing > it to > be in the global zone, but it still has the restriction of only 1 TCS > daemon per TPM. > >> >> If it really must be a single user at a time, then it'd have to be >> set up so that you can handle multiple simultaneous users within the >> kernel, but with just one per zoneid_t. > The TCS daemon is designed to be the primary access point, applications > are never supposed to access the device directly. > -Wyllys > > > This really sounds, to me at least, like the TPM/TCS should be a global zone only thing. I see little merit in making possible to run it anywhere else. Someday, might we not want the TPM stack to do more than just PKCS#11 and generic crypto? (I.e. TPM was also designed to support trusted verification of the platform itself -- the kernel bit.) I think if we want to allow for future developments in that area, it might be better to constrain the daemon to the global zone only for now. (This shouldn't be too much of a limitation for local zones, since for various reasons the global zone has to be trusted with at least the same level of privilege as the local zone. The local zones just need to be configured to use a network interface to access the TCS on the global zone.) -- Garrett From wyllys.ingersoll@sun.com Mon Dec 1 10:20:35 2008 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 mB1IKY09021405 for ; Mon, 1 Dec 2008 10:20: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 mB1IKNXX009507; Tue, 2 Dec 2008 02:20: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 <0KB700M03MY4LI00@brm-avmta-1.central.sun.com>; Mon, 01 Dec 2008 11:20:28 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KB700E85MY3ZXA0@brm-avmta-1.central.sun.com>; Mon, 01 Dec 2008 11:20:27 -0700 (MST) Received: from [10.7.251.182] (punchin-wyllys.SFBay.Sun.COM [10.7.251.182]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB1IKQuJ873054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 01 Dec 2008 10:20:27 -0800 (PST) Date: Mon, 01 Dec 2008 13:20:26 -0500 From: Wyllys Ingersoll Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <18740.7919.563335.922968@gargle.gargle.HOWL> To: James Carlson Cc: PSARC-ext@sun.com Message-id: <49342AEA.6050708@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <18740.1214.256920.275347@gargle.gargle.HOWL> <49340BA0.2000209@sun.com> <18740.3424.876649.44875@gargle.gargle.HOWL> <49341599.1020205@sun.com> <18740.6212.622080.851881@gargle.gargle.HOWL> <49341B68.5000103@sun.com> <18740.7919.563335.922968@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 1431 James Carlson wrote: > Wyllys Ingersoll writes: > >> sources. That is why I originally suggested that the TPM should only >> reside >> in the global zone and that local zones would access it over the network >> and be subject to access controls as specified in the tcsd.conf. >> > > It sounds to me like the complete Zones solution will require a > non-network-based cross-zone communication mechanism. > Yes. That is something we would prefer to develop with the involvement of the Trousers community later. >> I suggested that we could deliver the TPM device and libraries in all zones >> but that the administrator would have to know that only 1 zone per-system >> is allowed to access the TPM. That would at least allow the administrator >> to configure any single zone to run the TCS daemon instead of forcing it to >> be in the global zone, but it still has the restriction of only 1 TCS >> daemon per TPM. >> > > That doesn't make sense to me. Why would the administrator _NOT_ want > to have access to the TPM in more than one zone? > By "access" do you mean having the ability to use the TPM through the standard TSS interfaces or do you mean having the ability to actually open /dev/tpm directly ? The first case is possible now by accessing the TCS daemon over the network using standard TSS APIs. The latter is prohibited by the TPM spec if another app is holding it open. -Wyllys From wyllys.ingersoll@sun.com Mon Dec 1 10:25:48 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB1IPmhf021479 for ; Mon, 1 Dec 2008 10:25:48 -0800 (PST) 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 mB1IPjaX018183; Mon, 1 Dec 2008 10:25:46 -0800 (PST) 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 <0KB700H2NN6YYL00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Dec 2008 10:25:46 -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 <0KB7003Q5N6UE8D0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Dec 2008 10:25:42 -0800 (PST) Received: from [10.7.251.182] (punchin-wyllys.SFBay.Sun.COM [10.7.251.182]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB1IPeEi874441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 01 Dec 2008 10:25:41 -0800 (PST) Date: Mon, 01 Dec 2008 13:25:40 -0500 From: Wyllys Ingersoll Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <493420C3.9000706@sun.com> To: "Garrett D'Amore" Cc: James Carlson , PSARC-ext@sun.com Message-id: <49342C24.1060208@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <18740.1214.256920.275347@gargle.gargle.HOWL> <49340BA0.2000209@sun.com> <18740.3424.876649.44875@gargle.gargle.HOWL> <49341599.1020205@sun.com> <18740.6212.622080.851881@gargle.gargle.HOWL> <49341B68.5000103@sun.com> <493420C3.9000706@sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 1609 Garrett D'Amore wrote: >> The TCS daemon is designed to be the primary access point, applications >> are never supposed to access the device directly. >> -Wyllys >> >> >> > This really sounds, to me at least, like the TPM/TCS should be a > global zone only thing. I see little merit in making possible to run > it anywhere else. I agree. > > Someday, might we not want the TPM stack to do more than just PKCS#11 > and generic crypto? (I.e. TPM was also designed to support trusted > verification of the platform itself -- the kernel bit.) I think if we > want to allow for future developments in that area, it might be better > to constrain the daemon to the global zone only for now. (This > shouldn't be too much of a limitation for local zones, since for > various reasons the global zone has to be trusted with at least the > same level of privilege as the local zone. The local zones just need > to be configured to use a network interface to access the TCS on the > global zone.) > > -- Garrett Yes, eventually we do want the TPM to be used for more. There are projects that are planning to use the TPM and TSS interfaces in the future (ZFS crypto, Validated Execution). Though, for the most part they only need the crypto and verification interfaces. The TPM device itself is a pretty simple and really only offers limited functionality, the critical piece is the TSS (TCG Software Stack). The TSS that we are delivering (TrouSerS) does have interfaces for doing more than just crypto, there just isn't much software written to take advantage of it yet. -Wyllys From carlsonj@phorcys.east.sun.com Mon Dec 1 10:31:45 2008 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 mB1IViEh021495 for ; Mon, 1 Dec 2008 10:31:44 -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 mB1IVapF017163; Tue, 2 Dec 2008 02:31:41 +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 <0KB700005NGRV200@brm-avmta-1.central.sun.com>; Mon, 01 Dec 2008 11:31:39 -0700 (MST) 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 <0KB700E5INGQZXC0@brm-avmta-1.central.sun.com>; Mon, 01 Dec 2008 11:31:39 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB1IVcmd003633; Mon, 01 Dec 2008 13:31:38 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mB1IVcca003630; Mon, 01 Dec 2008 13:31:38 -0500 (EST) Date: Mon, 01 Dec 2008 13:31:38 -0500 From: James Carlson Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <49342AEA.6050708@sun.com> To: Wyllys Ingersoll Cc: PSARC-ext@sun.com Message-id: <18740.11658.760626.641575@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.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <18740.1214.256920.275347@gargle.gargle.HOWL> <49340BA0.2000209@sun.com> <18740.3424.876649.44875@gargle.gargle.HOWL> <49341599.1020205@sun.com> <18740.6212.622080.851881@gargle.gargle.HOWL> <49341B68.5000103@sun.com> <18740.7919.563335.922968@gargle.gargle.HOWL> <49342AEA.6050708@sun.com> Status: RO Content-Length: 1422 Wyllys Ingersoll writes: > James Carlson wrote: > > That doesn't make sense to me. Why would the administrator _NOT_ want > > to have access to the TPM in more than one zone? > > > > By "access" do you mean having the ability to use the TPM through the > standard > TSS interfaces or do you mean having the ability to actually open > /dev/tpm directly ? Either. As a user of it, I shouldn't have to care how I get access, should I? I assume "standard" TSS interfaces are better, though. > The first case is possible now by accessing the TCS daemon over the > network using > standard TSS APIs. That doesn't work. There's no network connection that's necessarily available between global and non-global zones. > The latter is prohibited by the TPM spec if another app is holding it open. It sounds like the device is really an implementation detail, and not something that needs to be discussed as architecture. I don't see why assigning that internal device node (with its strange limitations) to non-global zones would ever be a useful thing to do. If the limitations can be removed, then there's a reason to do this, as it allows a TCS daemon per zone. Otherwise, not so much. -- 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 wyllys.ingersoll@sun.com Mon Dec 1 10:40:47 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 mB1IekKa022083 for ; Mon, 1 Dec 2008 10:40:46 -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 mB1IehNl014188; Mon, 1 Dec 2008 18:40:44 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 <0KB700K2BNVV9H00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Dec 2008 10:40:43 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KB7003OENVUE9E0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Dec 2008 10:40:42 -0800 (PST) Received: from [10.7.251.182] (punchin-wyllys.SFBay.Sun.COM [10.7.251.182]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB1IefVc877616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 01 Dec 2008 10:40:42 -0800 (PST) Date: Mon, 01 Dec 2008 13:40:41 -0500 From: Wyllys Ingersoll Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <18740.11658.760626.641575@gargle.gargle.HOWL> To: James Carlson Cc: PSARC-ext@sun.com Message-id: <49342FA9.1060500@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <18740.1214.256920.275347@gargle.gargle.HOWL> <49340BA0.2000209@sun.com> <18740.3424.876649.44875@gargle.gargle.HOWL> <49341599.1020205@sun.com> <18740.6212.622080.851881@gargle.gargle.HOWL> <49341B68.5000103@sun.com> <18740.7919.563335.922968@gargle.gargle.HOWL> <49342AEA.6050708@sun.com> <18740.11658.760626.641575@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 945 James Carlson wrote: >> The first case is possible now by accessing the TCS daemon over the >> network using >> standard TSS APIs. >> > > That doesn't work. There's no network connection that's necessarily > available between global and non-global zones. > > Yes, obviously. One must have network access, unless we come up with a different method for zones later. >> The latter is prohibited by the TPM spec if another app is holding it open. >> > > It sounds like the device is really an implementation detail, and not > something that needs to be discussed as architecture. > > I don't see why assigning that internal device node (with its strange > limitations) to non-global zones would ever be a useful thing to do. > If the limitations can be removed, then there's a reason to do this, > as it allows a TCS daemon per zone. Otherwise, not so much. > OK, we'll leave it as a global-zone-only device then. -Wyllys From edward.pilatowicz@Sun.COM Mon Dec 1 12:22:44 2008 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 mB1KMiEI010388 for ; Mon, 1 Dec 2008 12:22:44 -0800 (PST) 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 mB1KMeYg044356; Mon, 1 Dec 2008 13:22:42 -0700 (MST) 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 <0KB700909SLUX600@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Dec 2008 12:22:42 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KB700K7ISLTEQ90@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Dec 2008 12:22:41 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB1KMfnJ900431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 01 Dec 2008 12:22:41 -0800 (PST) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id mB1KMfuc900430; Mon, 01 Dec 2008 12:22:41 -0800 (PST) Date: Mon, 01 Dec 2008 12:22:41 -0800 From: Edward Pilatowicz Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <493420C3.9000706@sun.com> To: "Garrett D'Amore" Cc: Wyllys Ingersoll , James Carlson , PSARC-ext@Sun.COM Message-id: <20081201202241.GA898062@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.4.1.325704 References: <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <18740.1214.256920.275347@gargle.gargle.HOWL> <49340BA0.2000209@sun.com> <18740.3424.876649.44875@gargle.gargle.HOWL> <49341599.1020205@sun.com> <18740.6212.622080.851881@gargle.gargle.HOWL> <49341B68.5000103@sun.com> <493420C3.9000706@sun.com> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 2833 On Mon, Dec 01, 2008 at 09:37:07AM -0800, Garrett D'Amore wrote: > Wyllys Ingersoll wrote: >> >>>> >>>> What would you suggest in this case? I'm not very familiar with the >>>> unique >>>> requirements of Zones and device drivers. >>> >>> The unique requirement here is that if you're assuming in the kernel >>> that there's only one valid stream open on the device at a time, you'd >>> end up with one zone user blocking another from gaining access. >> >> Yes, that is correct. The TPM specification states that the TPM can >> handle only >> 1 at a time. Other connections are rejected. The TCS Daemon (userland) >> is designed >> to handle the sequencing and manage the access to a single TPM from >> multiple >> sources. That is why I originally suggested that the TPM should only >> reside >> in the global zone and that local zones would access it over the network >> and be subject to access controls as specified in the tcsd.conf. >> >> I still believe that is probably preferable in this situation. A >> non-global zone >> should be treated as a system without a resident TPM and would have to >> use the network to access the TCS instead of getting it's own direct >> access >> to the device. >> >> I suggested that we could deliver the TPM device and libraries in all >> zones >> but that the administrator would have to know that only 1 zone per-system >> is allowed to access the TPM. That would at least allow the administrator >> to configure any single zone to run the TCS daemon instead of forcing it >> to >> be in the global zone, but it still has the restriction of only 1 TCS >> daemon per TPM. >> >>> >>> If it really must be a single user at a time, then it'd have to be >>> set up so that you can handle multiple simultaneous users within the >>> kernel, but with just one per zoneid_t. >> The TCS daemon is designed to be the primary access point, applications >> are never supposed to access the device directly. >> -Wyllys >> >> > This really sounds, to me at least, like the TPM/TCS should be a global > zone only thing. I see little merit in making possible to run it anywhere > else. > i disagree. i got the impression that what we're really delivering here is TSS support for applications and that the underly TPM device is an implementation detail (since apps use TSS libraries, which access the TSS daemon which is the component that knows about underlying (or remote via a network) TPM provider.) by not supporting TPM within zones what we're actually saying is that any application which uses TSS is not sutibale for deployment within non-global zones. (unless you happen to have a specific networking config, and you do special configuration in your global zone, and you don't use zone migration, etc...) this seems to go against the idea that zones are application containers. ed From edward.pilatowicz@sun.com Mon Dec 1 12:36:40 2008 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 mB1Kadan010795 for ; Mon, 1 Dec 2008 12:36:40 -0800 (PST) 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 mB1KabSu054722; Mon, 1 Dec 2008 13:36:39 -0700 (MST) 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 <0KB70040PT91SG00@nwk-avmta-2.sfbay.sun.com>; Mon, 01 Dec 2008 12:36:37 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KB700L9OT8Z7K80@nwk-avmta-2.sfbay.sun.com>; Mon, 01 Dec 2008 12:36:35 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB1KaZV2903605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 01 Dec 2008 12:36:35 -0800 (PST) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id mB1KaZU8903603; Mon, 01 Dec 2008 12:36:35 -0800 (PST) Date: Mon, 01 Dec 2008 12:36:35 -0800 From: Edward Pilatowicz Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <49340042.20807@sun.com> To: Wyllys Ingersoll Cc: PSARC-ext@sun.com Message-id: <20081201203635.GB898062@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.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 3245 [ replies to multiple included below. ] On Mon, Dec 01, 2008 at 10:18:26AM -0500, Wyllys Ingersoll wrote: > >>> That might work. Obviously, there is no problem delivering the daemon and >>> libraries >>> in all zones. As long as there is only 1 instance of the TPM device in >>> the kernel, >>> and one reader/write of that device in userland (across all zones), I see >>> no problem >>> having the tpm device be located in whatever zone the admin prefers to >>> install it. >>> >>> >> >> i think this would be a good stop-gap measure. it would simplify the >> deployment of tss based application in one non-global zone. >> >> as an implementation detail, you'll probably want to enhance zoneadm to detect >> when a zone is booting with a tpm device allocated to it, and have it verify >> that there are no other booted zones with tpm devices and that the tss daemon >> is not running in the global zone. (this keeps things user friendly, and >> zoneadm already does similar checks to verify that other required smf services >> are running.) >> >> ed >> > > The tpm device itself will not allow multiple readers, so I'm not sure if > any external > tool modification (zoneadm, etc) is even necessary. The device will > respond to the first > app to open it, no other apps can open the device until it gets closed > again. > leveraging this behavior will result in poor failure modes. if the global zone is using the device, then the tss daemon in non-global zone will fail to start, there by requiring the non-global zone administrator (who may not have access to the global zone) to figure out why this service is failing, and if/once they do, contact the global zone admin and ask them to disable the service there (which also assumes that other zones don't have the service enabled as well). On Mon, Dec 01, 2008 at 01:31:38PM -0500, James Carlson wrote: > Wyllys Ingersoll writes: > > The latter is prohibited by the TPM spec if another app is holding it open. > > It sounds like the device is really an implementation detail, and not > something that needs to be discussed as architecture. > > I don't see why assigning that internal device node (with its strange > limitations) to non-global zones would ever be a useful thing to do. > If the limitations can be removed, then there's a reason to do this, > as it allows a TCS daemon per zone. Otherwise, not so much. > well (working on the assumption that this case won't deliver seamless TPM support to all zones), the reason i was advocating this is that it makes it easy to deploy TSS based applications in at least one non-global zone. (right now, admins can't deploy to any non-global rather unless they have a certain network config, admins can't migrate zones with TSS unless the migrate the TPM config from the global zone as well, etc.) i agree that the tpm device is an implementation detail. so perhaps instead of adding a device match to zonecfg, the admin could just create a zonecfg attribute. say: add attr set type=boolean set name=tpm set value=true end and then zonecfg would know how to translate this into a device match for the tpm device. (and this implementation could change in the future as the tpm support for zones is improved.) ed From carlsonj@phorcys.east.sun.com Mon Dec 1 13:00:36 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 mB1L0Zsq011822 for ; Mon, 1 Dec 2008 13:00:36 -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 mB1L0TeA029069; Mon, 1 Dec 2008 21:00:33 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 <0KB700617UCVL400@nwk-avmta-2.sfbay.sun.com>; Mon, 01 Dec 2008 13:00:31 -0800 (PST) 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 <0KB700L00UCU7KA0@nwk-avmta-2.sfbay.sun.com>; Mon, 01 Dec 2008 13:00:31 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB1L0U23004849; Mon, 01 Dec 2008 16:00:30 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mB1L0UUb004846; Mon, 01 Dec 2008 16:00:30 -0500 (EST) Date: Mon, 01 Dec 2008 16:00:30 -0500 From: James Carlson Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <20081201203635.GB898062@eng.sun.com> To: Edward Pilatowicz Cc: Wyllys Ingersoll , PSARC-ext@sun.com Message-id: <18740.20590.289553.86618@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.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <20081201203635.GB898062@eng.sun.com> Status: RO Content-Length: 2417 Edward Pilatowicz writes: > On Mon, Dec 01, 2008 at 01:31:38PM -0500, James Carlson wrote: > > Wyllys Ingersoll writes: > > > The latter is prohibited by the TPM spec if another app is holding it open. > > > > It sounds like the device is really an implementation detail, and not > > something that needs to be discussed as architecture. > > > > I don't see why assigning that internal device node (with its strange > > limitations) to non-global zones would ever be a useful thing to do. > > If the limitations can be removed, then there's a reason to do this, > > as it allows a TCS daemon per zone. Otherwise, not so much. > > > > well (working on the assumption that this case won't deliver seamless > TPM support to all zones), the reason i was advocating this is that it > makes it easy to deploy TSS based applications in at least one non-global > zone. We end up being forced to support that wart going forward. Since it's clear that (for whatever reason) the device driver "can't" be fixed to behave reasonably, I think that means you need a different IPC in order to be able to use it from within a non-global zone. This won't be the first "doesn't play nicely with Zones" feature in the system. I agree that it's not good that it doesn't, but I'm much less sure that the 'assign it to one zone' approach is useful enough that it's both interesting and worth the effort compared to a real solution. > add attr > set type=boolean > set name=tpm > set value=true That's exactly what I mean about being forced to support a wart. What does the system do if multiple zones have this attribute? Just fail to boot some of them? Once we fix TSS so that it can be accessed normally from within a non-global zone, what does that attribute do? It doesn't disable TPM in the global zone anymore. > and then zonecfg would know how to translate this into a device match > for the tpm device. (and this implementation could change in the > future as the tpm support for zones is improved.) I can see how it can be removed in favor of a completely different scheme that doesn't involve the daemon running inside the zone at all ... but it's not clear how it could be improved. -- 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 Mon Dec 1 13:50:46 2008 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 mB1Lojft012604 for ; Mon, 1 Dec 2008 13:50:45 -0800 (PST) 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 mB1Loimo046584 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 1 Dec 2008 14:50:45 -0700 (MST) 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 <0KB700L0DWOJJN00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 01 Dec 2008 13:50:43 -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 <0KB700K96WOJETD0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 01 Dec 2008 13:50: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 mB1LogQx012110 for ; Mon, 01 Dec 2008 13:50: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 <0KB700301WLSVR00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 01 Dec 2008 13:50:42 -0800 (PST) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KB7001J1WOCS080@fe-sfbay-10.sun.com>; Mon, 01 Dec 2008 13:50:37 -0800 (PST) Date: Mon, 01 Dec 2008 13:43:53 -0800 From: "Garrett D'Amore" Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <20081201202241.GA898062@eng.sun.com> Sender: Garrett.Damore@sun.com To: Edward Pilatowicz Cc: Wyllys Ingersoll , James Carlson , PSARC-ext@sun.com Message-id: <49345A99.6040502@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <18740.1214.256920.275347@gargle.gargle.HOWL> <49340BA0.2000209@sun.com> <18740.3424.876649.44875@gargle.gargle.HOWL> <49341599.1020205@sun.com> <18740.6212.622080.851881@gargle.gargle.HOWL> <49341B68.5000103@sun.com> <493420C3.9000706@sun.com> <20081201202241.GA898062@eng.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 3331 Edward Pilatowicz wrote: > On Mon, Dec 01, 2008 at 09:37:07AM -0800, Garrett D'Amore wrote: > >> Wyllys Ingersoll wrote: >> >>>>> What would you suggest in this case? I'm not very familiar with the >>>>> unique >>>>> requirements of Zones and device drivers. >>>>> >>>> The unique requirement here is that if you're assuming in the kernel >>>> that there's only one valid stream open on the device at a time, you'd >>>> end up with one zone user blocking another from gaining access. >>>> >>> Yes, that is correct. The TPM specification states that the TPM can >>> handle only >>> 1 at a time. Other connections are rejected. The TCS Daemon (userland) >>> is designed >>> to handle the sequencing and manage the access to a single TPM from >>> multiple >>> sources. That is why I originally suggested that the TPM should only >>> reside >>> in the global zone and that local zones would access it over the network >>> and be subject to access controls as specified in the tcsd.conf. >>> >>> I still believe that is probably preferable in this situation. A >>> non-global zone >>> should be treated as a system without a resident TPM and would have to >>> use the network to access the TCS instead of getting it's own direct >>> access >>> to the device. >>> >>> I suggested that we could deliver the TPM device and libraries in all >>> zones >>> but that the administrator would have to know that only 1 zone per-system >>> is allowed to access the TPM. That would at least allow the administrator >>> to configure any single zone to run the TCS daemon instead of forcing it >>> to >>> be in the global zone, but it still has the restriction of only 1 TCS >>> daemon per TPM. >>> >>> >>>> If it really must be a single user at a time, then it'd have to be >>>> set up so that you can handle multiple simultaneous users within the >>>> kernel, but with just one per zoneid_t. >>>> >>> The TCS daemon is designed to be the primary access point, applications >>> are never supposed to access the device directly. >>> -Wyllys >>> >>> >>> >> This really sounds, to me at least, like the TPM/TCS should be a global >> zone only thing. I see little merit in making possible to run it anywhere >> else. >> >> > > i disagree. i got the impression that what we're really delivering here > is TSS support for applications and that the underly TPM device is an > implementation detail (since apps use TSS libraries, which access the > TSS daemon which is the component that knows about underlying (or remote > via a network) TPM provider.) > > by not supporting TPM within zones what we're actually saying is that > any application which uses TSS is not sutibale for deployment within > non-global zones. (unless you happen to have a specific networking > config, and you do special configuration in your global zone, and you > don't use zone migration, etc...) > > this seems to go against the idea that zones are application containers. > Can the TSS apps use a network to talk to the TPM and TCS daemon? The applications here in question are mostly just PKCS#11 apps, right? TPM is just a "better" (more secure) key store, at least for those apps. Are there other kinds of TSS apps besides PKCS#11 clients that are relevant for zones? -- Garrett > ed > From wyllys.ingersoll@sun.com Mon Dec 1 13:59:42 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB1Lxgst013211 for ; Mon, 1 Dec 2008 13:59: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 mB1Lxe2r019313; Mon, 1 Dec 2008 13:59:41 -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 <0KB700M0FX3EKT00@brm-avmta-1.central.sun.com>; Mon, 01 Dec 2008 14:59:38 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KB7002LSX3EVAE0@brm-avmta-1.central.sun.com>; Mon, 01 Dec 2008 14:59:38 -0700 (MST) Received: from [10.7.251.182] (punchin-wyllys.SFBay.Sun.COM [10.7.251.182]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB1Lxa2K921853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 01 Dec 2008 13:59:37 -0800 (PST) Date: Mon, 01 Dec 2008 16:59:36 -0500 From: Wyllys Ingersoll Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <49345A99.6040502@sun.com> To: "Garrett D'Amore" Cc: Edward Pilatowicz , James Carlson , PSARC-ext@sun.com Message-id: <49345E48.9060900@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <18740.1214.256920.275347@gargle.gargle.HOWL> <49340BA0.2000209@sun.com> <18740.3424.876649.44875@gargle.gargle.HOWL> <49341599.1020205@sun.com> <18740.6212.622080.851881@gargle.gargle.HOWL> <49341B68.5000103@sun.com> <493420C3.9000706@sun.com> <20081201202241.GA898062@eng.sun.com> <49345A99.6040502@sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 2067 >> >> i disagree. i got the impression that what we're really delivering here >> is TSS support for applications and that the underly TPM device is an >> implementation detail (since apps use TSS libraries, which access the >> TSS daemon which is the component that knows about underlying (or remote >> via a network) TPM provider.) >> >> by not supporting TPM within zones what we're actually saying is that >> any application which uses TSS is not sutibale for deployment within >> non-global zones. (unless you happen to have a specific networking >> config, and you do special configuration in your global zone, and you >> don't use zone migration, etc...) >> >> this seems to go against the idea that zones are application containers. >> > > Can the TSS apps use a network to talk to the TPM and TCS daemon? They talk to the TCS daemon which talks to the TPM. Apps don't talk to the TPM device directly, even on the same host, they always go thru the TCS Daemon (via the TSS library). > > The applications here in question are mostly just PKCS#11 apps, > right? TPM is just a "better" (more secure) key store, at least for > those apps. Not necessarily just PKCS#11. The TSS spec is a large collection of APIs for performing TPM operations, not all of them map directly to PKCS#11. We are delivering a PKCS#11 provider so that current crypto consumers can continue to use the standard PKCS11 APIs and take advantage of *some* of the secure key storage features of the TPM, but there are lots of TSS functions that cannot be covered by PKCS#11. > > Are there other kinds of TSS apps besides PKCS#11 clients that are > relevant for zones? There are lots of potential TSS applications that would not require PKCS#11 that *could* be relevant for zones, but none are written yet. The 2 projects I mentioned earlier (ZFS Crypto and Validated Execution) could possibly be TSS consumers in a zone depending on how they are implemented and depending on how we address the zones and virtualization problem for the TPM in general. -Wyllys From edward.pilatowicz@sun.com Mon Dec 1 14:02:48 2008 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 mB1M2lU1013627 for ; Mon, 1 Dec 2008 14:02:48 -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 mB1M2V1l027093; Tue, 2 Dec 2008 06:02:43 +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 <0KB700A01X8I7U00@nwk-avmta-2.sfbay.sun.com>; Mon, 01 Dec 2008 14:02:42 -0800 (PST) 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 <0KB700LM3X8I7BE0@nwk-avmta-2.sfbay.sun.com>; Mon, 01 Dec 2008 14:02:42 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB1M2gAh923749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 01 Dec 2008 14:02:42 -0800 (PST) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id mB1M2gvh923748; Mon, 01 Dec 2008 14:02:42 -0800 (PST) Date: Mon, 01 Dec 2008 14:02:41 -0800 From: Edward Pilatowicz Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <18740.20590.289553.86618@gargle.gargle.HOWL> To: James Carlson Cc: Wyllys Ingersoll , PSARC-ext@sun.com Message-id: <20081201220241.GD898062@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.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <20081201203635.GB898062@eng.sun.com> <18740.20590.289553.86618@gargle.gargle.HOWL> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 4166 On Mon, Dec 01, 2008 at 04:00:30PM -0500, James Carlson wrote: > Edward Pilatowicz writes: > > On Mon, Dec 01, 2008 at 01:31:38PM -0500, James Carlson wrote: > > > Wyllys Ingersoll writes: > > > > The latter is prohibited by the TPM spec if another app is holding it open. > > > > > > It sounds like the device is really an implementation detail, and not > > > something that needs to be discussed as architecture. > > > > > > I don't see why assigning that internal device node (with its strange > > > limitations) to non-global zones would ever be a useful thing to do. > > > If the limitations can be removed, then there's a reason to do this, > > > as it allows a TCS daemon per zone. Otherwise, not so much. > > > > > > > well (working on the assumption that this case won't deliver seamless > > TPM support to all zones), the reason i was advocating this is that it > > makes it easy to deploy TSS based applications in at least one non-global > > zone. > > We end up being forced to support that wart going forward. > eventually if the tpm device is virtualized (or another communication mechanism comes along that makes the zones support seamless) then we just EOL this attribute and zonecfg/zoneadm can ignore it if it's present. > Since it's clear that (for whatever reason) the device driver "can't" > be fixed to behave reasonably, I think that means you need a different > IPC in order to be able to use it from within a non-global zone. > i don't recall anyone saying that this device "can't" be virtualized. (i do recall an offline discussion where the project team said they were on a tight schedule and attempting to do this would now would compromise that schedule, but i don't recall anyone saying that this is not technically possible.) > This won't be the first "doesn't play nicely with Zones" feature in > the system. I agree that it's not good that it doesn't, but I'm much > less sure that the 'assign it to one zone' approach is useful enough > that it's both interesting and worth the effort compared to a real > solution. > well, the existence of poorly integrated features is hardly a justification for introducing new features with poor integration. i guess i thought that providing this type of 'one zone' integration would be pretty trivial (requiring only some zonecfg/zoneadm changes) compared to virtualizing the tpm device driver. > > add attr > > set type=boolean > > set name=tpm > > set value=true > > That's exactly what I mean about being forced to support a wart. > > What does the system do if multiple zones have this attribute? Just > fail to boot some of them? > yep. and give out a reasonable error message telling the admin that multiple zones can't support tpm at the same time. > Once we fix TSS so that it can be accessed normally from within a > non-global zone, what does that attribute do? It doesn't disable TPM > in the global zone anymore. > once TPM/TSS zones support is fixed, the attribute can be ignored. also, the presence of the attribute wouldn't disable tpm in the global zone, the admin has to do this themselves. (just like today when you try to boot a zone that uses dynamic pools, if poold isn't running zoneadm doesn't start it, instead it tells the admin that they need to enable it.) > > and then zonecfg would know how to translate this into a device match > > for the tpm device. (and this implementation could change in the > > future as the tpm support for zones is improved.) > > I can see how it can be removed in favour of a completely different > scheme that doesn't involve the daemon running inside the zone at all > ... but it's not clear how it could be improved. > i was expecting this kludge would be removed if TPM/TSS zones support becomes seamless in the future. (note that i called this a stop-gap earlier, since it really isn't a replacement for full tpm/tss zones support.) that said, we could always just forgo this kludge and wait for the full feature integration. the project team is now aware of the deficiencies in their currently proposed zones integration, so it seems like this is something we'll see them address in a future case. ed From carlsonj@phorcys.east.sun.com Mon Dec 1 14:14:31 2008 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 mB1MEUae013959 for ; Mon, 1 Dec 2008 14:14:30 -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 mB1MEJPf062496; Mon, 1 Dec 2008 15:14:29 -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 <0KB70011JXS52T00@brm-avmta-1.central.sun.com>; Mon, 01 Dec 2008 15:14:29 -0700 (MST) 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 <0KB7002WSXS4VEE0@brm-avmta-1.central.sun.com>; Mon, 01 Dec 2008 15:14:29 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB1MES0R005713; Mon, 01 Dec 2008 17:14:28 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mB1MES0D005710; Mon, 01 Dec 2008 17:14:28 -0500 (EST) Date: Mon, 01 Dec 2008 17:14:28 -0500 From: James Carlson Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <20081201220241.GD898062@eng.sun.com> To: Edward Pilatowicz Cc: Wyllys Ingersoll , PSARC-ext@sun.com Message-id: <18740.25028.656733.450415@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.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <20081201203635.GB898062@eng.sun.com> <18740.20590.289553.86618@gargle.gargle.HOWL> <20081201220241.GD898062@eng.sun.com> Status: RO Content-Length: 4045 Edward Pilatowicz writes: > On Mon, Dec 01, 2008 at 04:00:30PM -0500, James Carlson wrote: > > We end up being forced to support that wart going forward. > > > > eventually if the tpm device is virtualized (or another communication > mechanism comes along that makes the zones support seamless) then we > just EOL this attribute and zonecfg/zoneadm can ignore it if it's > present. The question I'm asking is whether it's worth expending effort to put that one-zone-at-a-time hack in place rather than putting in a more lasting TSS-IPC-to-the-global-zone mechanism. > > Since it's clear that (for whatever reason) the device driver "can't" > > be fixed to behave reasonably, I think that means you need a different > > IPC in order to be able to use it from within a non-global zone. > > > > i don't recall anyone saying that this device "can't" be virtualized. > (i do recall an offline discussion where the project team said they were > on a tight schedule and attempting to do this would now would compromise > that schedule, but i don't recall anyone saying that this is not > technically possible.) At least in the on-line discussion, this seems to be the case. The driver is intentionally not set up to handle more than one open stream at a time, and that's why they have that daemon. Why bother with the daemon to coordinate requests if the driver can do it? > > This won't be the first "doesn't play nicely with Zones" feature in > > the system. I agree that it's not good that it doesn't, but I'm much > > less sure that the 'assign it to one zone' approach is useful enough > > that it's both interesting and worth the effort compared to a real > > solution. > > > > well, the existence of poorly integrated features is hardly a > justification for introducing new features with poor integration. Agreed. I just don't think that it's an excuse to hack around the problem, either, and I think the one-zone assignment idea is a hack. > i guess i thought that providing this type of 'one zone' integration > would be pretty trivial (requiring only some zonecfg/zoneadm changes) > compared to virtualizing the tpm device driver. I doubt it's substantially more complex than providing (say) a door or AF_UNIX socket in each zone that provides redirection to the global-zone resident daemon. > > Once we fix TSS so that it can be accessed normally from within a > > non-global zone, what does that attribute do? It doesn't disable TPM > > in the global zone anymore. > > > > once TPM/TSS zones support is fixed, the attribute can be ignored. Yuck. > also, the presence of the attribute wouldn't disable tpm in the global > zone, the admin has to do this themselves. (just like today when you > try to boot a zone that uses dynamic pools, if poold isn't running > zoneadm doesn't start it, instead it tells the admin that they need to > enable it.) That sounds like the recipe for confusion. I would actually expect that the global zone's daemon would start early enough in the boot process that it would _have to_ be disabled administratively in order to make use of that one-zone-hot mechanism. Otherwise, it would take exclusive control, and the zone assigned to use the TPM would fail. (Either block on open() or fail out; not clear which.) The upgrade scenario would involve reenabling the global zone's service and ignoring those defunct parameters. > that said, we could always just forgo this kludge and wait for the full > feature integration. the project team is now aware of the deficiencies > in their currently proposed zones integration, so it seems like this is > something we'll see them address in a future case. If we going to specify or even mandate something from the ARC level, I'd rather that it be a clean solution rather than a kludge that needs to be removed later. -- 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 edward.pilatowicz@sun.com Mon Dec 1 14:54:11 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB1MsBNd015078 for ; Mon, 1 Dec 2008 14:54:11 -0800 (PST) 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 mB1Ms9Hh015029; Mon, 1 Dec 2008 14:54:10 -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 <0KB700409ZM9ZB00@brm-avmta-1.central.sun.com>; Mon, 01 Dec 2008 15:54:09 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KB7002CFZM71P30@brm-avmta-1.central.sun.com>; Mon, 01 Dec 2008 15:54:08 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB1Ms7bK932544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 01 Dec 2008 14:54:07 -0800 (PST) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id mB1Ms75w932543; Mon, 01 Dec 2008 14:54:07 -0800 (PST) Date: Mon, 01 Dec 2008 14:54:07 -0800 From: Edward Pilatowicz Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <18740.25028.656733.450415@gargle.gargle.HOWL> To: James Carlson Cc: Wyllys Ingersoll , PSARC-ext@sun.com Message-id: <20081201225407.GB928235@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.4.1.325704 References: <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <20081201203635.GB898062@eng.sun.com> <18740.20590.289553.86618@gargle.gargle.HOWL> <20081201220241.GD898062@eng.sun.com> <18740.25028.656733.450415@gargle.gargle.HOWL> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 1093 On Mon, Dec 01, 2008 at 05:14:28PM -0500, James Carlson wrote: > Edward Pilatowicz writes: > > > that said, we could always just forgo this kludge and wait for the full > > feature integration. the project team is now aware of the deficiencies > > in their currently proposed zones integration, so it seems like this is > > something we'll see them address in a future case. > > If we going to specify or even mandate something from the ARC level, > I'd rather that it be a clean solution rather than a kludge that needs > to be removed later. > sure... but not being an arc member, and not wanting to stand in way of generally good forward progress, i don't really feel comfortable "mandating" anything... hence i was viewing this more as a constructive discussion and i was trying to suggest something that i thought might be an "easy" interim solution (and i could be wrong about the "easy" part) before a real solution is delivered (which could realistically be never since i don't really have any authority in this process, nor do i have a budget with which to fund future work). ed From gdamore@sun.com Mon Dec 1 14:55:10 2008 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 mB1MtAbH015090 for ; Mon, 1 Dec 2008 14:55:10 -0800 (PST) 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 mB1Mt2tY025744 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 1 Dec 2008 15:55:09 -0700 (MST) 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 <0KB700D27ZNVE300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Dec 2008 14: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 <0KB700ALYZNUCRD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Dec 2008 14:55:06 -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 mB1Mt6ne021211 for ; Mon, 01 Dec 2008 14:55:06 -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 <0KB700A01ZBEV700@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 01 Dec 2008 14:55:06 -0800 (PST) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KB700CD1ZNR9690@fe-sfbay-09.sun.com>; Mon, 01 Dec 2008 14:55:04 -0800 (PST) Date: Mon, 01 Dec 2008 14:48:20 -0800 From: "Garrett D'Amore" Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <18740.25028.656733.450415@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: James Carlson Cc: Edward Pilatowicz , Wyllys Ingersoll , PSARC-ext@sun.com Message-id: <493469B4.9000508@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <20081201203635.GB898062@eng.sun.com> <18740.20590.289553.86618@gargle.gargle.HOWL> <20081201220241.GD898062@eng.sun.com> <18740.25028.656733.450415@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 5892 A few thoughts here: #1: This is a fast track. If we are going to start insisting that the project team make significant changes to the project (especially changes to which the project team doesn't readily agree), then the project should probably be derailed. #2: The only interesting consumers *right now* are PKCS#11. I think enabling PKCS#11 in the global zone is useful enough, that it ought to be allowed to proceed even if the final solution isn't quite what we want. This is especially true since PKCS#11 by its very nature shields applications from changes to underlying plumbing that might be necessary later. #3: I propose that in the meantime, the TSS API be reduced to Consolidation Private binding, if not already at that level. Since there are no consumers yet, this seems fairly reasonable and unlikely to cause undue harm to projects. #4: If the only reason that the daemon exists is to serialize access to the TPM device (and I confess I'm not entirely convinced that this assertion is true), then at some point in the future, It Would Be Nice if the daemon could be eliminated, replaced with a fully zone-aware and concurrent version of the TPM driver. I'm not sure what the challenges to solve in that are, but hopefully the project team can elucidate them when the time comes. So, in the mean time, I think we need to either move ahead with a global zone only solution (for now) and hope the project team will follow up with a future case that addresses the virtualization problem, or we need to take the first option and derail. My opinion personally is against derailing, and to let this case through with incomplete support for virtualization for now. If another member feels differently, he can (and perhaps should!) press that derail button. -- Garrett James Carlson wrote: > Edward Pilatowicz writes: > >> On Mon, Dec 01, 2008 at 04:00:30PM -0500, James Carlson wrote: >> >>> We end up being forced to support that wart going forward. >>> >>> >> eventually if the tpm device is virtualized (or another communication >> mechanism comes along that makes the zones support seamless) then we >> just EOL this attribute and zonecfg/zoneadm can ignore it if it's >> present. >> > > The question I'm asking is whether it's worth expending effort to put > that one-zone-at-a-time hack in place rather than putting in a more > lasting TSS-IPC-to-the-global-zone mechanism. > > >>> Since it's clear that (for whatever reason) the device driver "can't" >>> be fixed to behave reasonably, I think that means you need a different >>> IPC in order to be able to use it from within a non-global zone. >>> >>> >> i don't recall anyone saying that this device "can't" be virtualized. >> (i do recall an offline discussion where the project team said they were >> on a tight schedule and attempting to do this would now would compromise >> that schedule, but i don't recall anyone saying that this is not >> technically possible.) >> > > At least in the on-line discussion, this seems to be the case. The > driver is intentionally not set up to handle more than one open stream > at a time, and that's why they have that daemon. Why bother with the > daemon to coordinate requests if the driver can do it? > > >>> This won't be the first "doesn't play nicely with Zones" feature in >>> the system. I agree that it's not good that it doesn't, but I'm much >>> less sure that the 'assign it to one zone' approach is useful enough >>> that it's both interesting and worth the effort compared to a real >>> solution. >>> >>> >> well, the existence of poorly integrated features is hardly a >> justification for introducing new features with poor integration. >> > > Agreed. I just don't think that it's an excuse to hack around the > problem, either, and I think the one-zone assignment idea is a hack. > > >> i guess i thought that providing this type of 'one zone' integration >> would be pretty trivial (requiring only some zonecfg/zoneadm changes) >> compared to virtualizing the tpm device driver. >> > > I doubt it's substantially more complex than providing (say) a door or > AF_UNIX socket in each zone that provides redirection to the > global-zone resident daemon. > > >>> Once we fix TSS so that it can be accessed normally from within a >>> non-global zone, what does that attribute do? It doesn't disable TPM >>> in the global zone anymore. >>> >>> >> once TPM/TSS zones support is fixed, the attribute can be ignored. >> > > Yuck. > > >> also, the presence of the attribute wouldn't disable tpm in the global >> zone, the admin has to do this themselves. (just like today when you >> try to boot a zone that uses dynamic pools, if poold isn't running >> zoneadm doesn't start it, instead it tells the admin that they need to >> enable it.) >> > > That sounds like the recipe for confusion. > > I would actually expect that the global zone's daemon would start > early enough in the boot process that it would _have to_ be disabled > administratively in order to make use of that one-zone-hot mechanism. > Otherwise, it would take exclusive control, and the zone assigned to > use the TPM would fail. (Either block on open() or fail out; not > clear which.) > > The upgrade scenario would involve reenabling the global zone's > service and ignoring those defunct parameters. > > >> that said, we could always just forgo this kludge and wait for the full >> feature integration. the project team is now aware of the deficiencies >> in their currently proposed zones integration, so it seems like this is >> something we'll see them address in a future case. >> > > If we going to specify or even mandate something from the ARC level, > I'd rather that it be a clean solution rather than a kludge that needs > to be removed later. > > From edward.pilatowicz@sun.com Mon Dec 1 15:51:45 2008 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 mB1Npin1017303 for ; Mon, 1 Dec 2008 15:51:44 -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 mB1Npbou004557; Tue, 2 Dec 2008 07:51:37 +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 <0KB800A0T29ZR200@brm-avmta-1.central.sun.com>; Mon, 01 Dec 2008 16:51:35 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KB8002LR29X1J90@brm-avmta-1.central.sun.com>; Mon, 01 Dec 2008 16:51:33 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB1NpXUw941704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 01 Dec 2008 15:51:33 -0800 (PST) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id mB1NpXE9941703; Mon, 01 Dec 2008 15:51:33 -0800 (PST) Date: Mon, 01 Dec 2008 15:51:33 -0800 From: Edward Pilatowicz Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <493469B4.9000508@sun.com> To: "Garrett D'Amore" Cc: James Carlson , Wyllys Ingersoll , PSARC-ext@sun.com Message-id: <20081201235133.GC928235@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.4.1.325704 References: <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <20081201203635.GB898062@eng.sun.com> <18740.20590.289553.86618@gargle.gargle.HOWL> <20081201220241.GD898062@eng.sun.com> <18740.25028.656733.450415@gargle.gargle.HOWL> <493469B4.9000508@sun.com> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 6435 i'm not an arc member and i don't have the authority to derail. that said, if i did have the authority, i wouldn't derail and i'd let the project team continue. (since while this project is not perfect, it is a very valuable improvement to the system.) after this discussion, the project team is aware of the relevant virtualization issues and it's probably safe to expect that they'll address them in a future case. ed On Mon, Dec 01, 2008 at 02:48:20PM -0800, Garrett D'Amore wrote: > A few thoughts here: > > #1: This is a fast track. If we are going to start insisting that the > project team make significant changes to the project (especially changes to > which the project team doesn't readily agree), then the project should > probably be derailed. > #2: The only interesting consumers *right now* are PKCS#11. I think > enabling PKCS#11 in the global zone is useful enough, that it ought to be > allowed to proceed even if the final solution isn't quite what we want. > This is especially true since PKCS#11 by its very nature shields > applications from changes to underlying plumbing that might be necessary > later. > > #3: I propose that in the meantime, the TSS API be reduced to Consolidation > Private binding, if not already at that level. Since there are no > consumers yet, this seems fairly reasonable and unlikely to cause undue > harm to projects. > > #4: If the only reason that the daemon exists is to serialize access to the > TPM device (and I confess I'm not entirely convinced that this assertion is > true), then at some point in the future, It Would Be Nice if the daemon > could be eliminated, replaced with a fully zone-aware and concurrent > version of the TPM driver. I'm not sure what the challenges to solve in > that are, but hopefully the project team can elucidate them when the time > comes. > > So, in the mean time, I think we need to either move ahead with a global > zone only solution (for now) and hope the project team will follow up with > a future case that addresses the virtualization problem, or we need to take > the first option and derail. > > My opinion personally is against derailing, and to let this case through > with incomplete support for virtualization for now. If another member > feels differently, he can (and perhaps should!) press that derail button. > > -- Garrett > > James Carlson wrote: >> Edward Pilatowicz writes: >> >>> On Mon, Dec 01, 2008 at 04:00:30PM -0500, James Carlson wrote: >>> >>>> We end up being forced to support that wart going forward. >>>> >>>> >>> eventually if the tpm device is virtualized (or another communication >>> mechanism comes along that makes the zones support seamless) then we >>> just EOL this attribute and zonecfg/zoneadm can ignore it if it's >>> present. >>> >> >> The question I'm asking is whether it's worth expending effort to put >> that one-zone-at-a-time hack in place rather than putting in a more >> lasting TSS-IPC-to-the-global-zone mechanism. >> >> >>>> Since it's clear that (for whatever reason) the device driver "can't" >>>> be fixed to behave reasonably, I think that means you need a different >>>> IPC in order to be able to use it from within a non-global zone. >>>> >>>> >>> i don't recall anyone saying that this device "can't" be virtualized. >>> (i do recall an offline discussion where the project team said they were >>> on a tight schedule and attempting to do this would now would compromise >>> that schedule, but i don't recall anyone saying that this is not >>> technically possible.) >>> >> >> At least in the on-line discussion, this seems to be the case. The >> driver is intentionally not set up to handle more than one open stream >> at a time, and that's why they have that daemon. Why bother with the >> daemon to coordinate requests if the driver can do it? >> >> >>>> This won't be the first "doesn't play nicely with Zones" feature in >>>> the system. I agree that it's not good that it doesn't, but I'm much >>>> less sure that the 'assign it to one zone' approach is useful enough >>>> that it's both interesting and worth the effort compared to a real >>>> solution. >>>> >>>> >>> well, the existence of poorly integrated features is hardly a >>> justification for introducing new features with poor integration. >>> >> >> Agreed. I just don't think that it's an excuse to hack around the >> problem, either, and I think the one-zone assignment idea is a hack. >> >> >>> i guess i thought that providing this type of 'one zone' integration >>> would be pretty trivial (requiring only some zonecfg/zoneadm changes) >>> compared to virtualizing the tpm device driver. >>> >> >> I doubt it's substantially more complex than providing (say) a door or >> AF_UNIX socket in each zone that provides redirection to the >> global-zone resident daemon. >> >> >>>> Once we fix TSS so that it can be accessed normally from within a >>>> non-global zone, what does that attribute do? It doesn't disable TPM >>>> in the global zone anymore. >>>> >>>> >>> once TPM/TSS zones support is fixed, the attribute can be ignored. >>> >> >> Yuck. >> >> >>> also, the presence of the attribute wouldn't disable tpm in the global >>> zone, the admin has to do this themselves. (just like today when you >>> try to boot a zone that uses dynamic pools, if poold isn't running >>> zoneadm doesn't start it, instead it tells the admin that they need to >>> enable it.) >>> >> >> That sounds like the recipe for confusion. >> >> I would actually expect that the global zone's daemon would start >> early enough in the boot process that it would _have to_ be disabled >> administratively in order to make use of that one-zone-hot mechanism. >> Otherwise, it would take exclusive control, and the zone assigned to >> use the TPM would fail. (Either block on open() or fail out; not >> clear which.) >> >> The upgrade scenario would involve reenabling the global zone's >> service and ignoring those defunct parameters. >> >> >>> that said, we could always just forgo this kludge and wait for the full >>> feature integration. the project team is now aware of the deficiencies >>> in their currently proposed zones integration, so it seems like this is >>> something we'll see them address in a future case. >>> >> >> If we going to specify or even mandate something from the ARC level, >> I'd rather that it be a clean solution rather than a kludge that needs >> to be removed later. >> >> From carlsonj@phorcys.east.sun.com Tue Dec 2 05:08:28 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB2D8SmP002538 for ; Tue, 2 Dec 2008 05:08:28 -0800 (PST) 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 mB2D8RC7010729; Tue, 2 Dec 2008 05:08:27 -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 <0KB90030P3620W00@brm-avmta-1.central.sun.com>; Tue, 02 Dec 2008 06:08:26 -0700 (MST) 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 <0KB900GPI3611H80@brm-avmta-1.central.sun.com>; Tue, 02 Dec 2008 06:08:25 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB2D8P3B007602; Tue, 02 Dec 2008 08:08:25 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mB2D8O3D007599; Tue, 02 Dec 2008 08:08:24 -0500 (EST) Date: Tue, 02 Dec 2008 08:08:24 -0500 From: James Carlson Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <493469B4.9000508@sun.com> To: "Garrett D'Amore" Cc: PSARC-ext@sun.com, Wyllys Ingersoll , Edward Pilatowicz Message-id: <18741.13128.940889.396973@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.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <20081201203635.GB898062@eng.sun.com> <18740.20590.289553.86618@gargle.gargle.HOWL> <20081201220241.GD898062@eng.sun.com> <18740.25028.656733.450415@gargle.gargle.HOWL> <493469B4.9000508@sun.com> Status: RO Content-Length: 1099 Garrett D'Amore writes: > #1: This is a fast track. If we are going to start insisting that the > project team make significant changes to the project (especially changes > to which the project team doesn't readily agree), then the project > should probably be derailed. True; but I don't think we're quite at that point yet. > #3: I propose that in the meantime, the TSS API be reduced to > Consolidation Private binding, if not already at that level. Since > there are no consumers yet, this seems fairly reasonable and unlikely to > cause undue harm to projects. I disagree. The API is already a standard item, and making it private is just going to lead to unnecessary confusion. The problem here hasn't been with the existence or stability of the API, but rather the internal design's usefulness in (and conformance to) Zones. The two should be separate. -- 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 Tue Dec 2 05:14:57 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB2DEuUE002577 for ; Tue, 2 Dec 2008 05:14:57 -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 mB2DEuD3019457; Tue, 2 Dec 2008 05:14:56 -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 <0KB9003173GVNZ00@nwk-avmta-2.sfbay.sun.com>; Tue, 02 Dec 2008 05:14:55 -0800 (PST) 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 <0KB900DTM3GOJ7C0@nwk-avmta-2.sfbay.sun.com>; Tue, 02 Dec 2008 05:14:48 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB2DEmOK007627; Tue, 02 Dec 2008 08:14:48 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mB2DEmEt007624; Tue, 02 Dec 2008 08:14:48 -0500 (EST) Date: Tue, 02 Dec 2008 08:14:48 -0500 From: James Carlson Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <20081201225407.GB928235@eng.sun.com> To: Edward Pilatowicz Cc: Wyllys Ingersoll , PSARC-ext@sun.com Message-id: <18741.13512.38715.471538@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.4.1.325704 References: <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <20081201203635.GB898062@eng.sun.com> <18740.20590.289553.86618@gargle.gargle.HOWL> <20081201220241.GD898062@eng.sun.com> <18740.25028.656733.450415@gargle.gargle.HOWL> <20081201225407.GB928235@eng.sun.com> Status: RO Content-Length: 2160 Edward Pilatowicz writes: > On Mon, Dec 01, 2008 at 05:14:28PM -0500, James Carlson wrote: > > Edward Pilatowicz writes: > > > > > that said, we could always just forgo this kludge and wait for the full > > > feature integration. the project team is now aware of the deficiencies > > > in their currently proposed zones integration, so it seems like this is > > > something we'll see them address in a future case. > > > > If we going to specify or even mandate something from the ARC level, > > I'd rather that it be a clean solution rather than a kludge that needs > > to be removed later. > > > > sure... but not being an arc member, and not wanting to stand in way of > generally good forward progress, i don't really feel comfortable > "mandating" anything... hence i was viewing this more as a constructive > discussion and i was trying to suggest something that i thought might be > an "easy" interim solution (and i could be wrong about the "easy" part) > before a real solution is delivered (which could realistically be never > since i don't really have any authority in this process, nor do i have a > budget with which to fund future work). As someone with useful engineering experience in Zones, you're an important part of the ARC community. Not being a member means that you can't actually vote on a case and a few other minor issues, but your opinion *does* matter quite a bit here. The ARC members aren't and can't be experts in everything, which is where the rest of engineering comes in. This is first, and foremost, a technical review; not a star chamber. ;-} You've been describing an alternate solution. In doing so (and trying to make trade-offs), there's always the risk that the project team sees it as "what the ARC told them to do." As long as we're in that area, I want to make sure we're looking at all the options and not jumping to one answer that seems like an expedient, but temporary, fix. -- 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 wyllys.ingersoll@sun.com Tue Dec 2 07:32:38 2008 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 mB2FWcs3006737 for ; Tue, 2 Dec 2008 07:32:38 -0800 (PST) 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 mB2FWW36046492; Tue, 2 Dec 2008 08:32:36 -0700 (MST) 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 <0KB900BAR9UBB000@nwk-avmta-2.sfbay.sun.com>; Tue, 02 Dec 2008 07:32:35 -0800 (PST) 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 <0KB9009FB9U9TL30@nwk-avmta-2.sfbay.sun.com>; Tue, 02 Dec 2008 07:32:33 -0800 (PST) Received: from [10.7.251.182] (punchin-wyllys.SFBay.Sun.COM [10.7.251.182]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB2FWDOZ186429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 02 Dec 2008 07:32:20 -0800 (PST) Date: Tue, 02 Dec 2008 10:32:13 -0500 From: Wyllys Ingersoll Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <493469B4.9000508@sun.com> To: "Garrett D'Amore" Cc: James Carlson , Edward Pilatowicz , PSARC-ext@sun.com Message-id: <493554FD.7080005@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <20081201203635.GB898062@eng.sun.com> <18740.20590.289553.86618@gargle.gargle.HOWL> <20081201220241.GD898062@eng.sun.com> <18740.25028.656733.450415@gargle.gargle.HOWL> <493469B4.9000508@sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 4210 Garrett D'Amore wrote: > A few thoughts here: > > #1: This is a fast track. If we are going to start insisting that the > project team make significant changes to the project (especially > changes to which the project team doesn't readily agree), then the > project should probably be derailed. I hope it doesn't come to that. I'd like to converge and get consensus today so this case can be closed/approved in the meeting tomorrow. > #2: The only interesting consumers *right now* are PKCS#11. I think > enabling PKCS#11 in the global zone is useful enough, that it ought to > be allowed to proceed even if the final solution isn't quite what we > want. This is especially true since PKCS#11 by its very nature > shields applications from changes to underlying plumbing that might be > necessary later. > > #3: I propose that in the meantime, the TSS API be reduced to > Consolidation Private binding, if not already at that level. Since > there are no consumers yet, this seems fairly reasonable and unlikely > to cause undue harm to projects. I disagree here. The TSS API is a documented standard interface, there are apps that write to the TSS API available that someone may want to port to Solaris once we have the interface delivered. There is already an open source community developing TCG applications for TSS, so I think it would be bad to deliver it and close it off. > > #4: If the only reason that the daemon exists is to serialize access > to the TPM device (and I confess I'm not entirely convinced that this > assertion is true), then at some point in the future, It Would Be Nice > if the daemon could be eliminated, replaced with a fully zone-aware > and concurrent version of the TPM driver. I'm not sure what the > challenges to solve in that are, but hopefully the project team can > elucidate them when the time comes. The TCS daemon provides many services that do not belong in the kernel (TPM driver). It manages a registry of "persistent keys" that apps may use in addition to swapping of contexts when multiple applications are accessing it at the same time. The behavior and design of the TCS is also documented in the TSS specifications. Additionally, the TCS Daemon is a critical part of the TrouSerS package which is what we are delivering and to remove it would be to effectively fork from the upstream community that we are trying to follow, thus creating a significant amount of work for us. > > So, in the mean time, I think we need to either move ahead with a > global zone only solution (for now) and hope the project team will > follow up with a future case that addresses the virtualization > problem, or we need to take the first option and derail. Agreed, we would like to move ahead with the global-zone-only solution for now. The workaround for any Zone based app that wants to use the TSS will be to enable and interface and talk to the global zone over that network interface like any other network-based host. It's not ideal, but it is a workable solution for now, IMO. I would like to find a clean, long-term solution to the Zones and Virtualization problems. There is a TCG Working Group that is developing standards for Virtualizing TPMs and we will follow up with that group and hopefully be able to implement their final spec at some point. The Zones issue boils down to a problem of communicating between zones without using a network interface. Personally, I don't see why one would not have the interface enabled, but I am sure someone can counter with many examples of where that is desirable. I don't think this is a problem unique to the TPM Support project. What has the ARC advised in the past? Is anyone working on a standard method for communicating between zones without the network interfaces or coming up with a way to listen on the localhost interface and still accept connections from zones? I guess door calls are one possible way. It would be nice if there were a way to open a socket that listened on "localhost + local zones" on the server and also be able to create sockets on the local zones that talk to the global-zone without going over the wire. -Wyllys From Darren.Moffat@sun.com Tue Dec 2 07:43:19 2008 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 mB2FhIu3007133 for ; Tue, 2 Dec 2008 07:43:19 -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 mB2Fgkaw016149 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 2 Dec 2008 23:43:17 +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 <0KB900B05AC2ZR00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Dec 2008 07:43:14 -0800 (PST) Received: from gmp-eb-inf-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 <0KB9009BXAC1TK40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Dec 2008 07:43:13 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mB2FhCwp018758 for ; Tue, 02 Dec 2008 15:43:12 +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 <0KB900A0195T8I00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Dec 2008 15:43:12 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KB900CIEABU2P50@fe-emea-10.sun.com>; Tue, 02 Dec 2008 15:43:07 +0000 (GMT) Date: Tue, 02 Dec 2008 15:43:06 +0000 From: Darren J Moffat Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <493554FD.7080005@sun.com> Sender: Darren.Moffat@sun.com To: Wyllys Ingersoll Cc: "Garrett D'Amore" , PSARC-ext@sun.com, James Carlson , Edward Pilatowicz Message-id: <4935578A.7050504@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <20081201203635.GB898062@eng.sun.com> <18740.20590.289553.86618@gargle.gargle.HOWL> <20081201220241.GD898062@eng.sun.com> <18740.25028.656733.450415@gargle.gargle.HOWL> <493469B4.9000508@sun.com> <493554FD.7080005@sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081104) Status: RO Content-Length: 663 Wyllys Ingersoll wrote: > The Zones issue boils down to a problem of communicating between zones > without using a network interface. Personally, > I don't see why one would not have the interface enabled, but I am sure > someone can counter with many examples It isn't that the Zones may not have networking interfaces but that the zones can't talk to each other over those interfaces and can't talk to the global zone. One such deployment case is Trusted Extensions, where I very much want access to the TPM via PKCS#11 at multiple different labels (and thus zones). However I think that can be a separate project from this one. -- Darren J Moffat From gdamore@sun.com Tue Dec 2 08:11:27 2008 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 mB2GBQOm011170 for ; Tue, 2 Dec 2008 08:11:26 -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 mB2GBLP3002899 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 3 Dec 2008 00:11:25 +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 <0KB900D0BBN0IV00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Dec 2008 08:11:24 -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 <0KB9009QZBMZTV60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Dec 2008 08:11:23 -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 mB2GBNNi018502 for ; Tue, 02 Dec 2008 08:11:23 -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 <0KB900B01BKHKQ00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Dec 2008 08:11:23 -0800 (PST) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KB9006DGBMV8320@fe-sfbay-09.sun.com>; Tue, 02 Dec 2008 08:11:20 -0800 (PST) Date: Tue, 02 Dec 2008 08:04:33 -0800 From: "Garrett D'Amore" Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <493554FD.7080005@sun.com> Sender: Garrett.Damore@sun.com To: Wyllys Ingersoll Cc: James Carlson , Edward Pilatowicz , PSARC-ext@sun.com Message-id: <49355C91.7050508@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <20081201203635.GB898062@eng.sun.com> <18740.20590.289553.86618@gargle.gargle.HOWL> <20081201220241.GD898062@eng.sun.com> <18740.25028.656733.450415@gargle.gargle.HOWL> <493469B4.9000508@sun.com> <493554FD.7080005@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 5730 Wyllys Ingersoll wrote: > Garrett D'Amore wrote: >> A few thoughts here: >> >> #1: This is a fast track. If we are going to start insisting that >> the project team make significant changes to the project (especially >> changes to which the project team doesn't readily agree), then the >> project should probably be derailed. > > I hope it doesn't come to that. I'd like to converge and get > consensus today so this case can be closed/approved in > the meeting tomorrow. Me too. > >> #2: The only interesting consumers *right now* are PKCS#11. I think >> enabling PKCS#11 in the global zone is useful enough, that it ought >> to be allowed to proceed even if the final solution isn't quite what >> we want. This is especially true since PKCS#11 by its very nature >> shields applications from changes to underlying plumbing that might >> be necessary later. >> >> #3: I propose that in the meantime, the TSS API be reduced to >> Consolidation Private binding, if not already at that level. Since >> there are no consumers yet, this seems fairly reasonable and unlikely >> to cause undue harm to projects. > > I disagree here. The TSS API is a documented standard interface, > there are apps that write to the TSS API > available that someone may want to port to Solaris once we have the > interface delivered. There is already > an open source community developing TCG applications for TSS, so I > think it would be bad to deliver it > and close it off. > So there *are* interesting apps in existence already. That wasn't my understanding. Note that making the interface Consolidation Private, while possibly confusing to external consumers, would primarily mean that others that wanted to use it outside of the consolidation would need to talk to you. I'm mostly concerned about whether or not there are "interesting" applications that have relevance in a non-global zone. I'm willing to concede this point, in the meantime. > >> >> #4: If the only reason that the daemon exists is to serialize access >> to the TPM device (and I confess I'm not entirely convinced that this >> assertion is true), then at some point in the future, It Would Be >> Nice if the daemon could be eliminated, replaced with a fully >> zone-aware and concurrent version of the TPM driver. I'm not sure >> what the challenges to solve in that are, but hopefully the project >> team can elucidate them when the time comes. > > The TCS daemon provides many services that do not belong in the kernel > (TPM driver). It manages a registry of > "persistent keys" that apps may use in addition to swapping of > contexts when multiple applications are accessing > it at the same time. Ah, I suspected as much. > The behavior and design of the TCS is also documented in the TSS > specifications. Additionally, > the TCS Daemon is a critical part of the TrouSerS package which is > what we are delivering and to remove it would > be to effectively fork from the upstream community that we are trying > to follow, thus creating a significant amount > of work for us. Okay, that makes sense. Surely the problem of operation of TCS/TSS/TPM with Xen^WxVM is not unique to Solaris. It would be interesting to learn what other design approaches the upstream community is considering to deal with this problem. > > >> >> So, in the mean time, I think we need to either move ahead with a >> global zone only solution (for now) and hope the project team will >> follow up with a future case that addresses the virtualization >> problem, or we need to take the first option and derail. > Agreed, we would like to move ahead with the global-zone-only solution > for now. The workaround for any > Zone based app that wants to use the TSS will be to enable and > interface and talk to the global zone > over that network interface like any other network-based host. It's > not ideal, but it is a workable solution > for now, IMO. > > I would like to find a clean, long-term solution to the Zones and > Virtualization problems. There is a TCG Working > Group that is developing standards for Virtualizing TPMs and we will > follow up with that group and hopefully be > able to implement their final spec at some point. Okay, I'll look forward to seeing the update. :-) > > The Zones issue boils down to a problem of communicating between zones > without using a network interface. Personally, > I don't see why one would not have the interface enabled, but I am > sure someone can counter with many examples > of where that is desirable. I don't think this is a problem unique > to the TPM Support project. What has the > ARC advised in the past? Is anyone working on a standard method for > communicating between zones > without the network interfaces or coming up with a way to listen on > the localhost interface and still > accept connections from zones? I guess door calls are one possible > way. It would be nice if there > were a way to open a socket that listened on "localhost + local zones" > on the server and also be able > to create sockets on the local zones that talk to the global-zone > without going over the wire. Actually, I think what would be nice here would be some form of UNIX domain socket or named pipes that crossed zone boundaries. The problem with using TCP/IP is that once you have an open interface, you have to either have sophisticated filtering rules and a firewall, or allow for *all* IP traffic to go back and forth. I can think of many situations where you don't want any actual network connectivity between zones or between the global zone and local zones. All this is totally out of scope for this project, though. -- Garrett From wyllys.ingersoll@sun.com Tue Dec 2 08:42:43 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB2Ggh5r025012 for ; Tue, 2 Dec 2008 08:42: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 mB2GgdDF004825; Tue, 2 Dec 2008 08:42:41 -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 <0KB900017D35S400@brm-avmta-1.central.sun.com>; Tue, 02 Dec 2008 09:42:41 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KB900H3UD33YP80@brm-avmta-1.central.sun.com>; Tue, 02 Dec 2008 09:42:39 -0700 (MST) Received: from [10.7.251.182] (punchin-wyllys.SFBay.Sun.COM [10.7.251.182]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB2GgMUk199859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 02 Dec 2008 08:42:26 -0800 (PST) Date: Tue, 02 Dec 2008 11:42:19 -0500 From: Wyllys Ingersoll Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <49355C91.7050508@sun.com> To: "Garrett D'Amore" Cc: James Carlson , Edward Pilatowicz , PSARC-ext@sun.com Message-id: <4935656B.80905@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <20081201203635.GB898062@eng.sun.com> <18740.20590.289553.86618@gargle.gargle.HOWL> <20081201220241.GD898062@eng.sun.com> <18740.25028.656733.450415@gargle.gargle.HOWL> <493469B4.9000508@sun.com> <493554FD.7080005@sun.com> <49355C91.7050508@sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 2724 Garrett D'Amore wrote: >> >> I disagree here. The TSS API is a documented standard interface, >> there are apps that write to the TSS API >> available that someone may want to port to Solaris once we have the >> interface delivered. There is already >> an open source community developing TCG applications for TSS, so I >> think it would be bad to deliver it >> and close it off. >> > > So there *are* interesting apps in existence already. That wasn't my > understanding. > > Note that making the interface Consolidation Private, while possibly > confusing to external consumers, would primarily mean that others that > wanted to use it outside of the consolidation would need to talk to > you. I'm mostly concerned about whether or not there are > "interesting" applications that have relevance in a non-global zone. > I'm willing to concede this point, in the meantime. Whether or not they are "interesting" is debatable :) But here are a few apps that are using the TSS: EAP-TLS using TPM identities: http://diuf.unifr.ch/people/latzec/prototyping/first Trusted GRUB - http://trousers.sourceforge.net/grub.html TPM-Tools: http://sourceforge.net/project/showfiles.php?group_id=126012&package_id=153880 >> >> The Zones issue boils down to a problem of communicating between >> zones without using a network interface. Personally, >> I don't see why one would not have the interface enabled, but I am >> sure someone can counter with many examples >> of where that is desirable. I don't think this is a problem unique >> to the TPM Support project. What has the >> ARC advised in the past? Is anyone working on a standard method for >> communicating between zones >> without the network interfaces or coming up with a way to listen on >> the localhost interface and still >> accept connections from zones? I guess door calls are one possible >> way. It would be nice if there >> were a way to open a socket that listened on "localhost + local >> zones" on the server and also be able >> to create sockets on the local zones that talk to the global-zone >> without going over the wire. > > Actually, I think what would be nice here would be some form of UNIX > domain socket or named pipes that crossed zone boundaries. The > problem with using TCP/IP is that once you have an open interface, you > have to either have sophisticated filtering rules and a firewall, or > allow for *all* IP traffic to go back and forth. I can think of many > situations where you don't want any actual network connectivity > between zones or between the global zone and local zones. > > All this is totally out of scope for this project, though. Agreed. Thanks for the comments. -Wyllys From Darren.Moffat@sun.com Tue Dec 2 08:58:18 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB2GwIwW027411 for ; Tue, 2 Dec 2008 08:58:18 -0800 (PST) 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 mB2GwI6m017053 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 2 Dec 2008 08:58:18 -0800 (PST) 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 <0KB900E0NDT5M300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Dec 2008 08:58:17 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KB900DQRDT3PR00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Dec 2008 08:58:16 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mB2GwFQT003209 for ; Tue, 02 Dec 2008 16:58:15 +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 <0KB900K01CYWKI00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Dec 2008 16:58:15 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KB900CBBDSN2PA0@fe-emea-10.sun.com>; Tue, 02 Dec 2008 16:58:00 +0000 (GMT) Date: Tue, 02 Dec 2008 16:57:59 +0000 From: Darren J Moffat Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <49355C91.7050508@sun.com> Sender: Darren.Moffat@sun.com To: "Garrett D'Amore" Cc: Wyllys Ingersoll , James Carlson , Edward Pilatowicz , PSARC-ext@sun.com Message-id: <49356917.9050305@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <20081201203635.GB898062@eng.sun.com> <18740.20590.289553.86618@gargle.gargle.HOWL> <20081201220241.GD898062@eng.sun.com> <18740.25028.656733.450415@gargle.gargle.HOWL> <493469B4.9000508@sun.com> <493554FD.7080005@sun.com> <49355C91.7050508@sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081104) Status: RO Content-Length: 1709 Garrett D'Amore wrote: > Note that making the interface Consolidation Private, while possibly > confusing to external consumers, would primarily mean that others that > wanted to use it outside of the consolidation would need to talk to > you. I'm mostly concerned about whether or not there are "interesting" > applications that have relevance in a non-global zone. I'm willing to > concede this point, in the meantime. That would be pointless though because the TSS 1.2 API won't change even if we do virtualise access via a Zone or hypervisor. If there is a change needed to the API to support virtualisation it will be a new rev of the API from the TCG. I'm very strongly against making the API any form of Private. > Okay, that makes sense. Surely the problem of operation of TCS/TSS/TPM > with Xen^WxVM is not unique to Solaris. It would be interesting to > learn what other design approaches the upstream community is considering > to deal with this problem. It isn't. IBM has to my knowlege developed an experimental Xen driver for virtualising the TPM for Xen. However as Wyllys has already mentioned virtualisation of the TPM is the subject of an active TCG working group and he as agreed to participate in that to make sure that what is done works for Zones as well. > Actually, I think what would be nice here would be some form of UNIX > domain socket or named pipes that crossed zone boundaries. Already discussed in other PSARC cases and already works in some configurations. For example in Trusted Extensions configuration there are doors and UNIX domain sockets that the global zone helps sets up to the local zones for various servces. -- Darren J Moffat From Alan.Coopersmith@sun.com Tue Dec 2 09:04:17 2008 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 mB2H4H4Q029031 for ; Tue, 2 Dec 2008 09:04:17 -0800 (PST) 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 mB2H4G1h058731 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 2 Dec 2008 10:04:16 -0700 (MST) 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 <0KB900G35E34Q800@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Dec 2008 09:04:16 -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 <0KB9009MIE32TVB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Dec 2008 09:04:14 -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 mB2H4E1e025252 for ; Tue, 02 Dec 2008 09:04: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 <0KB900G01D0OVV00@fe-sfbay-10.sun.com> (original mail from Alan.Coopersmith@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Dec 2008 09:04:14 -0800 (PST) Received: from [10.6.102.118] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KB9009S5E2PKA70@fe-sfbay-10.sun.com>; Tue, 02 Dec 2008 09:04:01 -0800 (PST) Date: Tue, 02 Dec 2008 09:04:01 -0800 From: Alan Coopersmith Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <49355C91.7050508@sun.com> Sender: Alan.Coopersmith@sun.com To: "Garrett D'Amore" Cc: Wyllys Ingersoll , James Carlson , Edward Pilatowicz , PSARC-ext@sun.com Message-id: <49356A81.6040805@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <20081201203635.GB898062@eng.sun.com> <18740.20590.289553.86618@gargle.gargle.HOWL> <20081201220241.GD898062@eng.sun.com> <18740.25028.656733.450415@gargle.gargle.HOWL> <493469B4.9000508@sun.com> <493554FD.7080005@sun.com> <49355C91.7050508@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 893 Garrett D'Amore wrote: > Actually, I think what would be nice here would be some form of UNIX > domain socket or named pipes that crossed zone boundaries. We already have those, as long as the endpoint is in a filesystem location visible to both zones. See for instance LSARC 2008/506, in which X11 clients in TX labeled zones connect to the Unix domain socket listener opened by the X server in the global zone. (There was a bug for quite a while preventing cross-zone communication across Unix domain sockets, but as discovered during LSARC 2008/506, that was a bug, since the original Zones case specified they'd just work [1].) [1] Chapter 13 of PSARC 2002/174 Design Spec: http://opensolaris.org/os/community/arc/caselog/2002/174/zones-design.spec.opensolaris.pdf -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From gdamore@sun.com Tue Dec 2 09:14:50 2008 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 mB2HEoNW001641 for ; Tue, 2 Dec 2008 09:14:50 -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 mB2HEnud002103 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 2 Dec 2008 10:14:50 -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 <0KB90030HEKOO900@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Dec 2008 10:14:48 -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 <0KB900HG6EKNYYB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Dec 2008 10:14:47 -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 mB2HEkIY026786 for ; Tue, 02 Dec 2008 09:14:46 -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 <0KB900J01D3GQU00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Dec 2008 09:14:46 -0800 (PST) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KB900MELEKH4JG0@fe-sfbay-09.sun.com>; Tue, 02 Dec 2008 09:14:42 -0800 (PST) Date: Tue, 02 Dec 2008 09:07:55 -0800 From: "Garrett D'Amore" Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <49356A81.6040805@sun.com> Sender: Garrett.Damore@sun.com To: Alan Coopersmith Cc: Wyllys Ingersoll , James Carlson , Edward Pilatowicz , PSARC-ext@sun.com Message-id: <49356B6B.3030604@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <20081126224032.GD200954@eng.sun.com> <492EF337.7080100@sun.com> <20081127231723.GH348957@eng.sun.com> <492F4EAC.1020905@sun.com> <20081128075816.GL348957@eng.sun.com> <49340042.20807@sun.com> <20081201203635.GB898062@eng.sun.com> <18740.20590.289553.86618@gargle.gargle.HOWL> <20081201220241.GD898062@eng.sun.com> <18740.25028.656733.450415@gargle.gargle.HOWL> <493469B4.9000508@sun.com> <493554FD.7080005@sun.com> <49355C91.7050508@sun.com> <49356A81.6040805@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1433 Alan Coopersmith wrote: > Garrett D'Amore wrote: > >> Actually, I think what would be nice here would be some form of UNIX >> domain socket or named pipes that crossed zone boundaries. >> > > We already have those, as long as the endpoint is in a filesystem location > visible to both zones. See for instance LSARC 2008/506, in which X11 clients > in TX labeled zones connect to the Unix domain socket listener opened by the > X server in the global zone. (There was a bug for quite a while preventing > cross-zone communication across Unix domain sockets, but as discovered during > LSARC 2008/506, that was a bug, since the original Zones case specified they'd > just work [1].) > Cool. Shows how little I know about xVM zones.. :-) So this is the kind of IPC that I guess these things should be using. The only question that remains is locating a common directory where software can rendezvous with these things. Sort of like /var/run, but with a predictable location both in the global zone and in local zones. ( E.g. /var/run/zones/ in the global zone, and /var/run/zones/self in the local zone, or something similar.) I imagine that could be a fairly trivial fast track and RFE for someone who really wants to implement it. -- Garrett > [1] Chapter 13 of PSARC 2002/174 Design Spec: > http://opensolaris.org/os/community/arc/caselog/2002/174/zones-design.spec.opensolaris.pdf > > From gww@sac.sfbay.sun.com Tue Dec 2 11:41:29 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 mB2JfS6b019166 for ; Tue, 2 Dec 2008 11:41: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 mB2JfOwO020067 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 2 Dec 2008 19:41:27 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 <0KB900C09LD26300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Dec 2008 11:41:26 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KB900D2XLD2PRF0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Dec 2008 11:41:26 -0800 (PST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mB2JfQkO003086; Tue, 02 Dec 2008 11:41:26 -0800 (PST) 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 mB2JfMqj019163; Tue, 02 Dec 2008 11:41:22 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id mB2JfMIO019162; Tue, 02 Dec 2008 11:41:22 -0800 (PST) Date: Tue, 02 Dec 2008 11:41:22 -0800 (PST) From: Gary Winiger Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] To: PSARC-ext@sun.com, wyllys@ardbeg.sfbay.sun.com Message-id: <200812021941.mB2JfMIO019162@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 4994 I'm just getting back to this (after the prereview) and getting my P1 project under control. As I mentioned in the prereview, if the TMP stack is to be part of the next Solaris Common Criteria evaluation (or anything build upon it is to be part of that evaluation), I believe this project needs to participate in Solaris Audit. I'm sorry to keep bringing this up. (I'd be happy if management would tell me that I didn't need to bring this up for all cases that seem to need it.) Perhaps I missed it in the discussion and spec. Gary.. ====== gw-1 Presumably all functionality (including tpmadm(1m)) goes through tcsd(1m). I saw mention of it doing authentication and authorization. As the project team knows from the prereview, both require to be auditable in the Solaris Audit trail. From today's reading of the case log, tpadm, tcsd, I've missed seeing where authorization (in the Solaris sense) is supported. Is the reference here, the generic if user foo knows password bar, foo is authorized to do actions baz? (It would seem those actions should be auditable.) gw-1a Additionally, setting parameters and taking/switching ownership require audit. They both are security relevant (and possibly administrative actions). gw-1b How are the applicable subset of the 13 MRPP (see below) required audit events generated by this project? What is that subset? gw-1c Introduction of an object (storage or otherwise) into a subject's address space requires auditability. gw-2 As the TPM can be switched between various owners, what it the object reuse policy/implementation? gw-3 Only indirectly related to this case: Since Validated Execution (PSARC/2008/195) is mentioned as a consumer, one presumes validated execution is to be done within zones, what does that imply for cross/multi-zone use of this project? Will that require opening the daemon to listening for requests from off machine? Same question about TX and its use of zones as labeled separation. gw-99 Nits: tcsd(8) should be tscd(1M) tcsd.conf(5) should be tcsd.conf(4) There doesn't seem to be a sample tcsd.conf tcsd.conf(5) says /etc/tcsd.conf, the spec says /etc/security/tcsd.conf tcsd(1M) man page should describe the FMRI, config/local_only property and authorizations. =============================================================================== From the Medium Robustness Protection Profile(s) The basic Audit requirement reads: Explicit: Baseline Cryptographic Module (FCS_BCM_EXP.1) Cryptographic Key Generation (for symmetric keys) (FCS_CKM.1(1)) Failure of the symmetric key generation process 9 Cryptographic Key Generation (for asymmetric keys) (FCS_CKM.1(2)) Failure of the asymmetric key generation process 9. Cryptographic Key Distribution (FCS_CKM.2) Failure to properly complete the key distribution process 9 Cryptographic Key Destruction (FCS_CKM.4) Failure of the key zeroization process 9 Explicit: Cryptographic Key Validation and Packaging (FCS_CKM_EXP.1) Failure of a key validation technique 9. Explicit: Cryptographic Key Handling and Storage (FCS_CKM_EXP.2) Failure in key handling or storage 9. Cryptographic Operations Availability (FCS_COA_EXP.1) Cryptographic Operation (for data encryption/decryption) (FCS_COP.1(1)) Failure in encryption or decryption 9. Cryptographic Operation (for cryptographic signature) (FCS_COP.1(2)) Failure in cryptographic signature 9. Cryptographic Operation (for cryptographic hashing) (FCS_COP.1(3)) Failure in hashing function 9. Cryptographic Operation (for cryptographic key agreement) (FCS_COP.1(4)) Failure in cryptographic key exchange 9. Explicit: Random Number Generation (FCS_COP_EXP.1) Failure in the randomization process 9 FootNote 9: Typically, upon detection of a crypto-related failure, a system indication should be generated, and the system should transition to a known safe (secure) state. The generation of an audit log can provide a mechanism for capturing more information about a failed event. The exact content of the crypto-related audit log is implementation-dependent. However, the log should include information that could help pinpoint the part of the crypto-related process that failed, but without compromising the value of any critical cryptographic security parameters. In addition, the audit record requirements specified in FAU_GEN.1.2 should be considered and included where appropriate. As a simple example, detection of a key checkword error during an internal transfer of key might be implemented as follows: Generate a "Bad Key" error message to the system, prevent use of the bad key and zeroize it, and generate an audit record that includes the date of the event, the time of the event, "key checkword error", bad key ID tag or subject/user associated with the bad key, and "failed key transfer during internal handling". The FCS_ stuff refers to other parts of the Protection Profile. From wyllys.ingersoll@sun.com Tue Dec 2 12:09:56 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB2K9uhe022872 for ; Tue, 2 Dec 2008 12:09:56 -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 mB2K9tAc026255 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 2 Dec 2008 12:09:56 -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 <0KB90051FMOJ2100@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Dec 2008 12:09:55 -0800 (PST) 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 <0KB900JKNMOIFBA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Dec 2008 12:09:54 -0800 (PST) Received: from [10.7.251.182] (punchin-wyllys.SFBay.Sun.COM [10.7.251.182]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB2K8fxF239849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 02 Dec 2008 12:08:54 -0800 (PST) Date: Tue, 02 Dec 2008 15:08:38 -0500 From: Wyllys Ingersoll Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <200812021941.mB2JfMIO019162@sac.sfbay.sun.com> To: Gary Winiger Cc: PSARC-ext@sun.com, wyllys@ardbeg.sfbay.sun.com Message-id: <493595C6.5040108@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200812021941.mB2JfMIO019162@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 4860 Gary Winiger wrote: > I'm just getting back to this (after the prereview) and getting my P1 > project under control. > > As I mentioned in the prereview, if the TMP stack is to be part of the next > Solaris Common Criteria evaluation (or anything build upon it is to be > part of that evaluation), I believe this project needs to participate in > Solaris Audit. I'm sorry to keep bringing this up. (I'd be happy if > management would tell me that I didn't need to bring this up for all > cases that seem to need it.) Perhaps I missed it in the discussion and spec. > I'd be happy if you stopped bringing it up as well. Especially this late in the review process. > Gary.. > ====== > gw-1 > Presumably all functionality (including tpmadm(1m)) goes through tcsd(1m). > I saw mention of it doing authentication and authorization. As the > project team knows from the prereview, both require to be auditable > in the Solaris Audit trail. > TCSD does not do authentication and authorization in the Solaris/Unix sense. We have discussed this and I thought we had consensus that audit was NOT needed in this case. > From today's reading of the case log, tpadm, tcsd, I've missed > seeing where authorization (in the Solaris sense) is supported. > Is the reference here, the generic if user foo knows password > bar, foo is authorized to do actions baz? (It would seem those > actions should be auditable.) > No, that example is not quite applicable in this situation. "actions" w.r.t the TCS Daemon are not authenticated on a per-user basis. TCSD "authorizes" certain commands to be performed from a remote client depending on the configuration parameters in the tcsd.conf file, not based on passwords. It also has no concept of a "user" and doesn't have support to filter based on IP addresses. > gw-1a > Additionally, setting parameters and taking/switching ownership require > audit. They both are security relevant (and possibly administrative > actions). > Possibly auditable from the tpmadm utility, not sure though. This command is also not necessarily associated with a specific person/user and could be automated. > gw-1b > How are the applicable subset of the 13 MRPP (see below) required > audit events generated by this project? What is that subset? > This project is not auditing them any moreso than openssl or pktool or any number of other utilities already in Solaris audit them. The utility doing the key generation is a 3rd party utility which obviously doesn't care about Solaris audit. If we think it is important (big if, IMO), we can work with the TSS community and get the code fixed in the main source branch later. I'm not inclined to delay delivery in order to add auditing and further fork us away from the baseline source. > gw-1c > Introduction of an object (storage or otherwise) into a subject's > address space requires auditability. > For example? > gw-2 > As the TPM can be switched between various owners, what it the > object reuse policy/implementation? > I don't quite understand the question. The TPM doesn't switch between owners. The platform owner issues the "takeownership" command 1 time when the system is first provisioned (or whenever the owner wants to start using the TPM). It is not something that is done repeatedly for different users. As mentioned earlier, this is possibly a good candidate for auditing later. > gw-3 > Only indirectly related to this case: Since Validated Execution > (PSARC/2008/195) is mentioned as a consumer, one presumes validated > execution is to be done within zones, what does that imply for > cross/multi-zone use of this project? Will that require opening > the daemon to listening for requests from off machine? > Same question about TX and its use of zones as labeled separation. > > The Zones issue and virtualization issue were discussed in-depth over the past few days, see the recent mail in the case logs. In Summary: We need a more robust long-term solution for communication from Zones and TX since network-communication is not always available or desirable. For now, the workaround is to use the existing network communication support already available and continue to monitor the TCG working groups that care about virtualization support. > gw-99 Nits: > tcsd(8) should be tscd(1M) > Yes, fixed. > tcsd.conf(5) should be tcsd.conf(4) > Fixed. > There doesn't seem to be a sample tcsd.conf > OK, I will add one to the materials. > tcsd.conf(5) says /etc/tcsd.conf, the spec says /etc/security/tcsd.conf > /etc/security/tcsd.conf is correct. > tcsd(1M) man page should describe the FMRI, config/local_only property > and authorizations. > OK, I will update it. -Wyllys From bhargava.yenduri@sun.com Tue Dec 2 12:34:39 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 mB2KYdGC025912 for ; Tue, 2 Dec 2008 12:34:39 -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 mB2KYVu4029035 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 2 Dec 2008 20:34:37 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 <0KB90062FNTPEM00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Dec 2008 12:34:37 -0800 (PST) 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 <0KB900J1JNTOFGC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 02 Dec 2008 12:34:36 -0800 (PST) Received: from [129.146.108.66] (bluesky.SFBay.Sun.COM [129.146.108.66]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB2KXs6k245035; Tue, 02 Dec 2008 12:34:06 -0800 (PST) Date: Tue, 02 Dec 2008 12:30:43 -0800 From: Krishna Yenduri Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> To: Wyllys Ingersoll Cc: PSARC-ext@sun.com Message-id: <49359AF3.5000706@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081023) Status: RO Content-Length: 1700 Wyllys Ingersoll wrote: > ... > * TPM Device driver (tpm) > The TPM device driver was developed in a joint effort between the Solaris > Security group and Dartmouth College and will be delivered on x86/64 based platforms > as part of the core Solaris installation. Some X86/X64 machines can enable and use the TPM at the BIOS level. Does the TPM driver recognize/use the existing objects on the chip? > We intend to defer delivery of a TPM > driver for SPARC systems to a later integration, as TPM hardware is predominantly > found on x86 systems. I believe the T5120 (Niagara 2) systems have a TPM chip. So, it is useful to deliver the driver for it soon. > * PKCS11 Provider > A PKCS11 provider that will allow users to create individual tokens that use the TPM > to generate keys and perform sensitive operations (encrypt/decrypt/sign/verify) will be > delivered into ON. This provider will protect all private data objects by encrypting them > with keys that can only be used inside the TPM device. > The PKCS11 TPM provider will support the following mechanisms: > CKM_RSA_PKCS_KEY_PAIR_GEN (2048 bit max) (hardware) > CKM_RSA_PKCS (2048 bit max) (hardware) > CKM_RSA_PKCS_OAEP (2048 bit max) (hardware) > CKM_RSA_X_509 (2048 bit max) (hardware) > CKM_MD5_RSA_PKCS (2048 bit max) (hardware) > CKM_SHA1_RSA_PKCS (2048 bit max) (hardware) > CKM_SHA_1 > CKM_SHA_1_HMAC > CKM_SHA_1_HMAC_GENERAL > CKM_MD5 > CKM_MD5_HMAC > CKM_MD5_HMAC_GENERAL > The chip can do random number generation too. So, do we plan to support the CKF_RNG and C_GenerateRandom() PKCS #11 interfaces? Regards, -Krishna From wyllys.ingersoll@sun.com Tue Dec 2 12:54:50 2008 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 mB2KsoHE028447 for ; Tue, 2 Dec 2008 12:54:50 -0800 (PST) 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 mB2Ksl7X046342; Tue, 2 Dec 2008 13:54:49 -0700 (MST) 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 <0KB900707ORBIX00@nwk-avmta-2.sfbay.sun.com>; Tue, 02 Dec 2008 12:54:47 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KB900JNXOR9FCE0@nwk-avmta-2.sfbay.sun.com>; Tue, 02 Dec 2008 12:54:45 -0800 (PST) Received: from [10.7.251.182] (punchin-wyllys.SFBay.Sun.COM [10.7.251.182]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB2Ks2tp249224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 02 Dec 2008 12:54:08 -0800 (PST) Date: Tue, 02 Dec 2008 15:54:01 -0500 From: Wyllys Ingersoll Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <49359AF3.5000706@sun.com> To: Krishna Yenduri Cc: Wyllys Ingersoll , PSARC-ext@sun.com Message-id: <4935A069.30401@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <49359AF3.5000706@sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 2270 Krishna Yenduri wrote: > Wyllys Ingersoll wrote: >> ... >> * TPM Device driver (tpm) >> The TPM device driver was developed in a joint effort between the >> Solaris >> Security group and Dartmouth College and will be delivered on x86/64 >> based platforms >> as part of the core Solaris installation. > > Some X86/X64 machines can enable and use the TPM at the BIOS level. > Does the TPM driver recognize/use the existing objects on the chip? enabling/disabling at the BIOS level is a prerequisite from using it in the OS. If the TPM is disabled in BIOS, the device will not work by definition. > >> We intend to defer delivery of a TPM >> driver for SPARC systems to a later integration, as TPM hardware is >> predominantly >> found on x86 systems. > > I believe the T5120 (Niagara 2) systems have a TPM chip. So, it is > useful to deliver the driver for it soon. We haven't had access to any of these for testing or developing yet, but hope to follow up with a SPARC version soon. > >> * PKCS11 Provider >> A PKCS11 provider that will allow users to create individual >> tokens that use the TPM to generate keys and perform sensitive >> operations (encrypt/decrypt/sign/verify) will be >> delivered into ON. This provider will protect all private data >> objects by encrypting them >> with keys that can only be used inside the TPM device. >> The PKCS11 TPM provider will support the following mechanisms: >> CKM_RSA_PKCS_KEY_PAIR_GEN (2048 bit max) (hardware) >> CKM_RSA_PKCS (2048 bit max) (hardware) >> CKM_RSA_PKCS_OAEP (2048 bit max) (hardware) >> CKM_RSA_X_509 (2048 bit max) (hardware) >> CKM_MD5_RSA_PKCS (2048 bit max) (hardware) >> CKM_SHA1_RSA_PKCS (2048 bit max) (hardware) >> CKM_SHA_1 >> CKM_SHA_1_HMAC >> CKM_SHA_1_HMAC_GENERAL >> CKM_MD5 >> CKM_MD5_HMAC >> CKM_MD5_HMAC_GENERAL >> > > The chip can do random number generation too. So, do we plan > to support the CKF_RNG and C_GenerateRandom() PKCS #11 interfaces? Yes. It does show up in the flags list and should work with C_GenerateRandom(). Flags: CKF_RNG CKF_LOGIN_REQUIRED CKF_USER_PIN_INITIALIZED CKF_CLOCK_ON_TOKEN CKF_TOKEN_INITIALIZED From bhargava.yenduri@sun.com Tue Dec 2 12:59:57 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB2KxvMQ029114 for ; Tue, 2 Dec 2008 12:59:57 -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 mB2Kxq6j026705; Tue, 2 Dec 2008 12:59:56 -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 <0KB90021LOZVYL00@brm-avmta-1.central.sun.com>; Tue, 02 Dec 2008 13:59:55 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KB90061UOZTI7F0@brm-avmta-1.central.sun.com>; Tue, 02 Dec 2008 13:59:54 -0700 (MST) Received: from [129.146.108.66] (bluesky.SFBay.Sun.COM [129.146.108.66]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB2KxZv6250080; Tue, 02 Dec 2008 12:59:41 -0800 (PST) Date: Tue, 02 Dec 2008 12:56:25 -0800 From: Krishna Yenduri Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <4935A069.30401@sun.com> To: Wyllys Ingersoll Cc: PSARC-ext@sun.com Message-id: <4935A0F9.2030901@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <49359AF3.5000706@sun.com> <4935A069.30401@sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081023) Status: RO Content-Length: 734 Wyllys Ingersoll wrote: > Krishna Yenduri wrote: >> Wyllys Ingersoll wrote: >>> ... >>> * TPM Device driver (tpm) >>> The TPM device driver was developed in a joint effort between >>> the Solaris >>> Security group and Dartmouth College and will be delivered on x86/64 >>> based platforms >>> as part of the core Solaris installation. >> >> Some X86/X64 machines can enable and use the TPM at the BIOS level. >> Does the TPM driver recognize/use the existing objects on the chip? > > enabling/disabling at the BIOS level is a prerequisite from using it > in the OS. > If the TPM is disabled in BIOS, the device will not work by definition. So, is TPM enabled by default on the X86/X64 platforms Sun ships? Regards, -Krishna From wyllys.ingersoll@sun.com Tue Dec 2 13:08:04 2008 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 mB2L84M8000128 for ; Tue, 2 Dec 2008 13:08:04 -0800 (PST) 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 mB2L7gD7057084; Tue, 2 Dec 2008 14:08:03 -0700 (MST) 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 <0KB90001VPDCA600@nwk-avmta-1.sfbay.Sun.COM>; Tue, 02 Dec 2008 13:08:00 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KB900G3FPD22B40@nwk-avmta-1.sfbay.Sun.COM>; Tue, 02 Dec 2008 13:07:50 -0800 (PST) Received: from [10.7.251.182] (punchin-wyllys.SFBay.Sun.COM [10.7.251.182]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB2L7VbY252223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 02 Dec 2008 13:07:37 -0800 (PST) Date: Tue, 02 Dec 2008 16:07:31 -0500 From: Wyllys Ingersoll Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <4935A0F9.2030901@sun.com> To: Krishna Yenduri Cc: PSARC-ext@sun.com Message-id: <4935A393.8000906@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811201902.mAKJ2rOI028805@ardbeg.sfbay.sun.com> <49359AF3.5000706@sun.com> <4935A069.30401@sun.com> <4935A0F9.2030901@sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 863 Krishna Yenduri wrote: > Wyllys Ingersoll wrote: >> Krishna Yenduri wrote: >>> Wyllys Ingersoll wrote: >>>> ... >>>> * TPM Device driver (tpm) >>>> The TPM device driver was developed in a joint effort between >>>> the Solaris >>>> Security group and Dartmouth College and will be delivered on >>>> x86/64 based platforms >>>> as part of the core Solaris installation. >>> >>> Some X86/X64 machines can enable and use the TPM at the BIOS level. >>> Does the TPM driver recognize/use the existing objects on the chip? >> >> enabling/disabling at the BIOS level is a prerequisite from using it >> in the OS. >> If the TPM is disabled in BIOS, the device will not work by definition. > > So, is TPM enabled by default on the X86/X64 platforms Sun ships? I'm not sure. I haven't received a brand-new, out-of-the-box platform in a while to check. -Wyllys From gww@eng.sun.com Wed Dec 3 09:44:40 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB3HieJx007280 for ; Wed, 3 Dec 2008 09:44:40 -0800 (PST) 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 mB3HiaqC017871 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 3 Dec 2008 09:44:39 -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 <0KBB00K0LAMF8900@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Dec 2008 10:44:39 -0700 (MST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBB006Z1AME0XB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Dec 2008 10:44:39 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mB3HicIJ055484; Wed, 03 Dec 2008 09:44:38 -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 mB3Hi7sp003979; Wed, 03 Dec 2008 09:44:07 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id mB3Hi7Ij003978; Wed, 03 Dec 2008 09:44:07 -0800 (PST) Date: Wed, 03 Dec 2008 09:44:07 -0800 (PST) From: Gary Winiger Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] To: gww@sac.sfbay.sun.com, wyllys.ingersoll@sun.com Cc: PSARC-ext@sun.com, wyllys@ardbeg.sfbay.sun.com Message-id: <200812031744.mB3Hi7Ij003978@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3845 > > gw-1 > > Presumably all functionality (including tpmadm(1m)) goes through tcsd(1m). > > I saw mention of it doing authentication and authorization. As the > > project team knows from the prereview, both require to be auditable > > in the Solaris Audit trail. > > > > TCSD does not do authentication and authorization in the Solaris/Unix sense. > We have discussed this and I thought we had consensus that audit was NOT > needed in > this case. > > > > From today's reading of the case log, tpadm, tcsd, I've missed > > seeing where authorization (in the Solaris sense) is supported. > > Is the reference here, the generic if user foo knows password > > bar, foo is authorized to do actions baz? (It would seem those > > actions should be auditable.) > > > No, that example is not quite applicable in this situation. "actions" > w.r.t the TCS Daemon > are not authenticated on a per-user basis. TCSD "authorizes" certain > commands to be > performed from a remote client depending on the configuration parameters > in the tcsd.conf > file, not based on passwords. It also has no concept of a "user" and > doesn't have support > to filter based on IP addresses. I guess I've completely misunderstood the architecture here. I thought tpmadm used the library which called to tcsd which was the policy engine for all the functions passed to the TPM. Thus it all seemed to fall within various audit requirements. More time please. Perhaps off line.... to clear it up. Could we talk later today? > > gw-1c > > Introduction of an object (storage or otherwise) into a subject's > > address space requires auditability. > > > > For example? > > > gw-2 > > As the TPM can be switched between various owners, what it the > > object reuse policy/implementation? > > > > I don't quite understand the question. The TPM doesn't switch between > owners. > The platform owner issues the "takeownership" command 1 time when the system > is first provisioned (or whenever the owner wants to start using the > TPM). It > is not something that is done repeatedly for different users. As mentioned > earlier, this is possibly a good candidate for auditing later. Please see the ObjectReuse file in the case directory. It is the quote of the relevant parts of the criteria. I'm not sure how else to state them. I thought the project team had seen them some time ago when I sent this all out to the management. > > gw-3 > > Only indirectly related to this case: Since Validated Execution > > (PSARC/2008/195) is mentioned as a consumer, one presumes validated > > execution is to be done within zones, what does that imply for > > cross/multi-zone use of this project? Will that require opening > > the daemon to listening for requests from off machine? > > Same question about TX and its use of zones as labeled separation. > > The Zones issue and virtualization issue were discussed in-depth over > the past few days, > see the recent mail in the case logs. > > In Summary: We need a more robust long-term solution > for communication from Zones and TX since network-communication is not > always available or desirable. For now, the workaround is to use the > existing network > communication support already available and continue to monitor the TCG > working groups that care about virtualization support. Yes, I got that from the discussion. Let me rephrase: It seems Validated Execution is a consumer of this project. Until the TPM virtualization project is completed, how will Validated Execution in non-global zones (TX) be effected by this project? For example: will tcsd need to listen for non-local connections? Is it just not applicable since ValEx only uses the TPM when booting the GZ? ... Gary.. From wyllys.ingersoll@sun.com Wed Dec 3 09:57:53 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB3Hvr7E011073 for ; Wed, 3 Dec 2008 09:57:53 -0800 (PST) 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 mB3HvqAJ025882 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 3 Dec 2008 09:57:53 -0800 (PST) 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 <0KBB00809B8GN400@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Dec 2008 09:57:52 -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 <0KBB0073CB8GPQ10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Dec 2008 09:57:52 -0800 (PST) Received: from [10.7.251.182] (punchin-wyllys.SFBay.Sun.COM [10.7.251.182]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB3Hvk1o425678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 03 Dec 2008 09:57:51 -0800 (PST) Date: Wed, 03 Dec 2008 12:57:46 -0500 From: Wyllys Ingersoll Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] In-reply-to: <200812031744.mB3Hi7Ij003978@marduk.eng.sun.com> To: Gary Winiger Cc: gww@sac.sfbay.sun.com, PSARC-ext@sun.com Message-id: <4936C89A.3010508@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200812031744.mB3Hi7Ij003978@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 2815 >> No, that example is not quite applicable in this situation. "actions" >> w.r.t the TCS Daemon >> are not authenticated on a per-user basis. TCSD "authorizes" certain >> commands to be >> performed from a remote client depending on the configuration parameters >> in the tcsd.conf >> file, not based on passwords. It also has no concept of a "user" and >> doesn't have support >> to filter based on IP addresses. > > I guess I've completely misunderstood the architecture here. > I thought tpmadm used the library which called to tcsd which > was the policy engine for all the functions passed to the > TPM. Thus it all seemed to fall within various audit requirements. It is potentially auditable, yes. But whether or not it is a "Required" auditable action is the question. > > More time please. Perhaps off line.... to clear it up. > Could we talk later today? Yes, but I'd prefer to get this approved TODAY and then talk about auditing. We can talk later, perhaps when Scott returns would be better so we can all be involved. gw-2 > > As the TPM can be switched between various owners, what it the > > object reuse policy/implementation? > > >> I don't quite understand the question. The TPM doesn't switch between >> owners. >> The platform owner issues the "takeownership" command 1 time when the system >> is first provisioned (or whenever the owner wants to start using the >> TPM). It >> is not something that is done repeatedly for different users. As mentioned >> earlier, this is possibly a good candidate for auditing later. > > Please see the ObjectReuse file in the case directory. It > is the quote of the relevant parts of the criteria. > I'm not sure how else to state them. I thought the project > team had seen them some time ago when I sent this all out > to the management. > Your original question was in the context of "switching between users". The TPM does not expose secrets between contexts. The TSS library has code for zeroing memory when sensitive objects are freed and released from use. I think that addresses the issue. > > Yes, I got that from the discussion. Let me rephrase: > It seems Validated Execution is a consumer of this project. > Until the TPM virtualization project is completed, how > will Validated Execution in non-global zones (TX) be effected > by this project? For example: will tcsd need to listen for > non-local connections? Is it just not applicable since > ValEx only uses the TPM when booting the GZ? ... Yes, if a non-global zone wants to use validated execution and the TPM, then the TCSD in the global zone will have to listen over the network. I'm not sure how ValEx is going to be using the TPM, I just know that they want to use it. Perhaps follow up with ValEx group. -Wyllys From gww@eng.sun.com Wed Dec 3 15:42:13 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB3NgDsl014698 for ; Wed, 3 Dec 2008 15:42:13 -0800 (PST) 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 mB3NgAnP013207 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 3 Dec 2008 15:42:13 -0800 (PST) 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 <0KBB0050BR6CLM00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Dec 2008 15:42:12 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBB0040NR6BR120@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Dec 2008 15:42:11 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mB3NgBci010657; Wed, 03 Dec 2008 15:42:11 -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 mB3NfeqG004711; Wed, 03 Dec 2008 15:41:40 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id mB3Nfe6U004710; Wed, 03 Dec 2008 15:41:40 -0800 (PST) Date: Wed, 03 Dec 2008 15:41:40 -0800 (PST) From: Gary Winiger Subject: Re: TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008] To: gww@eng.sun.com, wyllys.ingersoll@sun.com Cc: gww@sac.sfbay.sun.com, PSARC-ext@sun.com Message-id: <200812032341.mB3Nfe6U004710@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1049 > > More time please. Perhaps off line.... to clear it up. > > Could we talk later today? > > Yes, but I'd prefer to get this approved TODAY and then talk about auditing. > We can talk later, perhaps when Scott returns would be better so we can all > be involved. The project team and I discussed the issues relative to this post. Audit is the only remaining issue. It is my understanding (and I'm sure the project team will currect if I've misunderstood) that we agree the daemon should audit a number of the functions it adjudicates. The TPM and Audit project teams will determine the audit detail. The remaining part of the issue is that the project team would like ARC approval to defer that part of the project. As that is more a business than archtecture issue, both the TPM and Audit project management teams have been asked (offline) whether the project is complete without audit and what resolution to for completeness to accept. My Object Reuse and ValEx issues are resolved by the project team's answers. Gary.. From wyllys.ingersoll@sun.com Mon Dec 8 18:48:08 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB92m8gW015970 for ; Mon, 8 Dec 2008 18:48:08 -0800 (PST) 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 mB92m79W017807 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 8 Dec 2008 18:48:08 -0800 (PST) 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 <0KBL0081H947WH00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 08 Dec 2008 18:48:07 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBL001UO946ZM40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 08 Dec 2008 18:48:06 -0800 (PST) Received: from [10.7.251.182] (punchin-wyllys.SFBay.Sun.COM [10.7.251.182]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB92m4wF855654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 08 Dec 2008 18:48:06 -0800 (PST) Date: Mon, 08 Dec 2008 21:48:03 -0500 From: Wyllys Ingersoll Subject: PSARC 2008/725 TPM Support To: PSARC-ext@sun.com Message-id: <493DDC63.7000609@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 176 This case is being marked as "closed approved". The project team is resolving the auditing concerns with the interested parties in a separate meeting. -Wyllys Ingersoll From gww@sac.sfbay.sun.com Fri Sep 25 15:20:14 2009 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 n8PMKDgq023161 for ; Fri, 25 Sep 2009 15:20:13 -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 n8PMK1eR008768 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Sat, 26 Sep 2009 06:20:12 +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 <0KQJ00509SP9V800@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 25 Sep 2009 16:19:57 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQJ00JFNSP84NF0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 25 Sep 2009 16:19:56 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8PMJtQC030718; Fri, 25 Sep 2009 15:19:55 -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 n8PMJt80023156; Fri, 25 Sep 2009 15:19:55 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n8PMJtQF023155; Fri, 25 Sep 2009 15:19:55 -0700 (PDT) Date: Fri, 25 Sep 2009 15:19:55 -0700 (PDT) From: Gary Winiger Subject: contract for 2008/725 TMP Support to use 2000/517 audit interfaces and 2003/397 To: psarc-ext@sun.com Cc: Anup.Sekhar@sun.com, Craig.Payne@sun.com, Scott.Rotondo@sun.com, Steven.Detar@sun.com, Wyllys.Ingersoll@sun.com Message-id: <200909252219.n8PMJtQF023155@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 238 I've executed and recorded 2000/517-18 for PSARC/2008/725 TPM Support to use the project private interfaces described in the prototype contract approved in 2003/397. 2003/397 and 2008/725 have a symlink to the executed contract. Gary..