This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] [PATCH] txt: 2/3 - Xen per-domain S3 tboot interface

To: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "xense-devel@xxxxxxxxxxxxxxxxxxx" <xense-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: [Xen-devel] [PATCH] txt: 2/3 - Xen per-domain S3 tboot interface
From: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>
Date: Mon, 2 Mar 2009 12:38:52 -0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Wang, Shane" <shane.wang@xxxxxxxxx>
Delivery-date: Mon, 02 Mar 2009 12:41:14 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcmbduXzpAEgsUB2RdmnqFfPsAVp3g==
Thread-topic: [PATCH] txt: 2/3 - Xen per-domain S3 tboot interface
This patch adds the code that performs the per-domain (and frametable and 
xenheap) MAC on entry into S3 and verification on resume.

The MAC algorithm is called VMAC and was developed by Ted Krovetz and Wei Dai 
(more details are in the files).  It is based on a universal hash function.  
The universal hash is passed through a pseudo-random function, implemented 
using AES.  More details can be found at http://fastcrypto.org/vmac/.  The AES 
code comes from the OpenBSD implementation (which is derived from the 
implementation referenced in VMAC site).

As Xen does not have a good source of entropy to generate its own key (for the 
keyed hash), it uses the key that tboot passes in.

Although the code attempts to MAC all of a domain's pages (code/data, VT-d 
tables) based on its s3_integrity flag, some of a domain's memory may always be 
MAC'ed, e.g. shadow page tables.  Only xenheap pages that are in use are 
MAC'ed.  We believe that the memory MAC'ed by the Xen code and the ranges 
passed to tboot to MAC cover all of the memory whose integrity needs to be 
protected on S3.  Any suggestions or ranges that we missed are welcome.

Signed-off-by: Shane Wang <shane.wang@xxxxxxxxx>
Signed-off-by: Joseph Cihula <joseph.cihula@xxxxxxxxx>

Attachment: xen-tboot-dom_integ.patch
Description: xen-tboot-dom_integ.patch

Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] [PATCH] txt: 2/3 - Xen per-domain S3 tboot interface, Cihula, Joseph <=