From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Fioravante Subject: Re: [PATCH 4/4] stubdom/vtpm: Support multiple backends and locality Date: Tue, 27 Nov 2012 14:48:29 -0500 Message-ID: <50B5190D.20604@jhuapl.edu> References: <50B4D060.9070403@jhuapl.edu> <1354029286-17652-1-git-send-email-dgdegra@tycho.nsa.gov> <1354029286-17652-5-git-send-email-dgdegra@tycho.nsa.gov> <50B5042B.7000602@jhuapl.edu> <50B50E3E.6050807@tycho.nsa.gov> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4424959312589603556==" Return-path: In-Reply-To: <50B50E3E.6050807@tycho.nsa.gov> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Daniel De Graaf , Samuel Thibault Cc: "Ian.Campbell@citrix.com" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org This is a cryptographically signed message in MIME format. --===============4424959312589603556== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040806030204010809090008" This is a cryptographically signed message in MIME format. --------------ms040806030204010809090008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 11/27/2012 02:02 PM, Daniel De Graaf wrote: > On 11/27/2012 01:19 PM, Matthew Fioravante wrote: >> On 11/27/2012 10:14 AM, Daniel De Graaf wrote: >>> The vTPM protocol now contains a field allowing the locality of a >>> command to be specified; pass this to the TPM when processing a packe= t. >>> This also enables a single vTPM to provide multiple tpmback interface= s >>> so that several closely related domains can share a vTPM (for example= , a >>> qemu device stubdom and its target domain). >>> >>> Signed-off-by: Daniel De Graaf >>> --- >>> stubdom/tpmemu-0.7.4.patch | 61 ++++++++++++++++++++++++++++++++++= ++++++++---- >>> stubdom/vtpm/vtpm.c | 16 +++--------- >>> 2 files changed, 59 insertions(+), 18 deletions(-) >>> >>> diff --git a/stubdom/tpmemu-0.7.4.patch b/stubdom/tpmemu-0.7.4.patch >>> index b84eff1..31ace1a 100644 >>> --- a/stubdom/tpmemu-0.7.4.patch >>> +++ b/stubdom/tpmemu-0.7.4.patch >>> @@ -1,9 +1,60 @@ >>> -diff -Naur tpm_emulator-x86_64-back/tpm/tpm_emulator_extern.c tpm_em= ulator-x86_64/tpm/tpm_emulator_extern.c >>> ---- tpm_emulator-x86_64-back/tpm/tpm_emulator_extern.c 2012-04-27= 10:55:46.581963398 -0400 >>> -+++ tpm_emulator-x86_64/tpm/tpm_emulator_extern.c 2012-04-27 10:5= 6:02.193034152 -0400 >>> -@@ -249,7 +249,7 @@ >>> +diff --git a/tpm/tpm_capability.c b/tpm/tpm_capability.c >>> +index 60bbb90..f8f7f0f 100644 >>> +--- a/tpm/tpm_capability.c >>> ++++ b/tpm/tpm_capability.c >>> +@@ -949,6 +949,8 @@ static TPM_RESULT set_vendor(UINT32 subCap, BYTE= *setValue, >>> + UINT32 setValueSize, BOOL ownerAuth, >>> + BOOL deactivated, BOOL disabled) >>> + { >>> ++ if (tpmData.stany.flags.localityModifier !=3D 8) >>> ++ return TPM_BAD_PARAMETER; >>> + /* set the capability area with the specified data, on failure >>> + deactivate the TPM */ >>> + switch (subCap) { >>> +diff --git a/tpm/tpm_cmd_handler.c b/tpm/tpm_cmd_handler.c >>> +index 288d1ce..9e1cfb4 100644 >>> +--- a/tpm/tpm_cmd_handler.c >>> ++++ b/tpm/tpm_cmd_handler.c >>> +@@ -4132,7 +4132,7 @@ void tpm_emulator_shutdown() >>> + tpm_extern_release(); >>> + } >>> + >>> +-int tpm_handle_command(const uint8_t *in, uint32_t in_size, uint8_t= **out, uint32_t *out_size) >>> ++int tpm_handle_command(const uint8_t *in, uint32_t in_size, uint8_t= **out, uint32_t *out_size, int locality) >>> + { >>> + TPM_REQUEST req; >>> + TPM_RESPONSE rsp; >>> +@@ -4140,7 +4140,9 @@ int tpm_handle_command(const uint8_t *in, uint= 32_t in_size, uint8_t **out, uint3 >>> + UINT32 len; >>> + BOOL free_out; >>> + >>> +- debug("tpm_handle_command()"); >>> ++ debug("tpm_handle_command(%d)", locality); >>> ++ if (locality !=3D -1) >>> ++ tpmData.stany.flags.localityModifier =3D locality; >>> + >>> + /* we need the whole packet at once, otherwise unmarshalling will= fail */ >>> + if (tpm_unmarshal_TPM_REQUEST((uint8_t**)&in, &in_size, &req) !=3D= 0) { >>> +diff --git a/tpm/tpm_emulator.h b/tpm/tpm_emulator.h >>> +index eed749e..4c228bd 100644 >>> +--- a/tpm/tpm_emulator.h >>> ++++ b/tpm/tpm_emulator.h >>> +@@ -59,7 +59,7 @@ void tpm_emulator_shutdown(void); >>> + * its usage. In case of an error, all internally allocated memory >>> + * is released and the the state of out and out_size is unspecified= =2E >>> + */ >>> +-int tpm_handle_command(const uint8_t *in, uint32_t in_size, uint8_t= **out, uint32_t *out_size); >>> ++int tpm_handle_command(const uint8_t *in, uint32_t in_size, uint8_t= **out, uint32_t *out_size, int locality); >>> + >>> + #endif /* _TPM_EMULATOR_H_ */ >>> + >>> +diff --git a/tpm/tpm_emulator_extern.c b/tpm/tpm_emulator_extern.c >>> +index aabe6c3..440a01b 100644 >>> +--- a/tpm/tpm_emulator_extern.c >>> ++++ b/tpm/tpm_emulator_extern.c >>> +@@ -249,7 +249,7 @@ int (*tpm_read_from_storage)(uint8_t **data, siz= e_t *data_length) =3D _tpm_read_fr >>> #else /* TPM_NO_EXTERN */ >>> - >>> + >>> int (*tpm_extern_init)(void) = =3D NULL; >>> -int (*tpm_extern_release)(void) = =3D NULL; >>> +void (*tpm_extern_release)(void) = =3D NULL; >>> diff --git a/stubdom/vtpm/vtpm.c b/stubdom/vtpm/vtpm.c >>> index c33e078..dcfc3b9 100644 >>> --- a/stubdom/vtpm/vtpm.c >>> +++ b/stubdom/vtpm/vtpm.c >>> @@ -141,8 +141,6 @@ int check_ordinal(tpmcmd_t* tpmcmd) { >>> static void main_loop(void) { >>> tpmcmd_t* tpmcmd =3D NULL; >>> - domid_t domid; /* Domid of frontend */ >>> - unsigned int handle; /* handle of frontend */ >>> int res =3D -1; >>> info("VTPM Initializing\n"); >>> @@ -162,15 +160,7 @@ static void main_loop(void) { >>> goto abort_postpcrs; >>> } >>> - /* Wait for the frontend domain to connect */ >>> - info("Waiting for frontend domain to connect.."); >>> - if(tpmback_wait_for_frontend_connect(&domid, &handle) =3D=3D 0) {= >>> - info("VTPM attached to Frontend %u/%u", (unsigned int) domid, = handle); >>> - } else { >>> - error("Unable to attach to a frontend"); >>> - } >>> - >>> - tpmcmd =3D tpmback_req(domid, handle); >>> + tpmcmd =3D tpmback_req_any(); >>> while(tpmcmd) { >>> /* Handle the request */ >>> if(tpmcmd->req_len) { >>> @@ -183,7 +173,7 @@ static void main_loop(void) { >>> } >>> /* If not disabled, do the command */ >>> else { >>> - if((res =3D tpm_handle_command(tpmcmd->req, tpmcmd->req_= len, &tpmcmd->resp, &tpmcmd->resp_len)) !=3D 0) { >>> + if((res =3D tpm_handle_command(tpmcmd->req, tpmcmd->req_= len, &tpmcmd->resp, &tpmcmd->resp_len, tpmcmd->locality)) !=3D 0) { >>> error("tpm_handle_command() failed"); >>> create_error_response(tpmcmd, TPM_FAIL); >>> } >>> @@ -194,7 +184,7 @@ static void main_loop(void) { >>> tpmback_resp(tpmcmd); >>> /* Wait for the next request */ >>> - tpmcmd =3D tpmback_req(domid, handle); >>> + tpmcmd =3D tpmback_req_any(); >>> } >> Before the vtpm would shut down on its own when the host domain discon= nects. This occurs because tpmback_req() returns NULL if the frontend dis= connected. Using tpmback_req_any(), this is no longer the case which now = means the user has to shut down the vtpm manually. How are you handling v= tpm shutdown on your end? > When a domain shuts down, "xl destroy" is called on its paired vTPM (by= some > scripting that may need to be incorporated into libxl). A graceful shut= down > is not really needed at this point, although it might be needed in the = short > term if the save-state operation is not atomic - but a method of recove= ring > from this type of failure is needed for vTPMs anyway. This is kind of a difficult problem. The save state operation is not by=20 any means atomic and it is very possible that the guest shuts down and=20 xl destroy is called before the save operation completes. This is=20 especially true if the guest is an embedded or even a mini-os domain=20 using tpmfront that shuts down very quickly. Its the reason why now the=20 vtpm shuts itself down after the guest disconnects. What is really needed is a way to do an xl shutdown on mini-os domains=20 to let vtpm-stubdom shutdown correctly. From what I understand there is=20 not yet any support for this in mini-os. How tricky would it be to add=20 that? Samuel any ideas? If thats not possible, another potential hack could be writing a key in=20 xenstore to trigger the shutdown or setting up some other kind of event=20 channel mechanism between the vtpm domain and libxl. --------------ms040806030204010809090008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4 NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50 ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz 4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMTEyNzE5NDgyOVowIwYJKoZIhvcNAQkEMRYEFG+HwdmIbURGVgv2 9Ms5oN6VcZhXMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCZE/SlDBq5qQFwzrYD2t6BKn0tnsUJ4yvA EGklNZJqUnEnEJ/IpRJQARf1BHUchI++5sy9rRj0G9cBab+kqG9ejkQZnJ15NAAe6PiNO75L LYTV4zEwdtLcqpzawAoj2bpV8hpaOfvwT7pzQRbX8yepksnIBASgXysbvVdj5NYAGgAAAAAA AA== --------------ms040806030204010809090008-- --===============4424959312589603556== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4424959312589603556==--