The following set of patches add TPM and Trusted Computing support to SeaBIOS.
In particular the patches add:
- a TPM driver for the Qemu's TPM TIS emulation (not yet in Qemu git)
- ACPI support for the TPM device (SSDT table)
- ACPI support for measurement logging (TCPA table)
- Support for initialzation of the TPM
- Support for the TCG BIOS extensions (1ah handler [ah = 0xbb])
(used by trusted grub; http://trousers.sourceforge.net/grub.html)
- Static Root of Trusted for Measurement (SRTM) support
- Support for S3 resume (sends command to TPM upon resume)
- TPM-specific menu for controlling aspects of the TPM
- [An optional test suite for the TIS interface]
All implementations necessarily follow specifications.
When all patches are applied the following services are available
- SSDT ACPI table for TPM support
- initialization of the TPM upon VM start and S3 resume
- Static root of trust for measurements (SRTM) that measures (some) data
of SeaBIOS in TCPA ACPI table
- 1ah interrupt handler offering APIs for measuring and sending commands to
the TPM (trusted grub uses them)
- User menu for controlling aspects of the state of the TPM
v7:
- adapted patches to checkout of 83012de (Aug 31)
- fixed compilation error reported by Andreas Niederl
v6:
- adapted patches to checkout of 8e30147 (Aug 9)
- use timeouts/durations for commands as reported by TPM
- following Andreas Niederl's suggestion regarding the ACPI SSDT
v5:
- adapted patches to checkout of 76b5e71 (June 21)
- bugfixes (see individual patches)
- added patch to support the transfer of Qemu-provided measurements via
firmware interface
v4:
- if ! has_working_tpm() now returns error code everywhere
- tis_test.c now also under LGPLv3
- in inthandler, pulled set_cf() out of switch and then only call it in
the default case where we need to indicate that a function is not
implemented
v3:
- some nits here and there
- calling timer_setup now after S3 resume
v2:
- following Kevin's comment
- refactoring code so that every patch compiles
Regards,
Stefan
QEMU does not provide a HPET block if it was configured with -no-hpet,
other machines SeaBIOS runs on may lack a HPET as well. Perform basic
checks the ID register for a reasonable vendor ID and a clock period
within the valid range, do not build the HPET table if that fails.
Signed-off-by: Jan Kiszka <jan.kiszka(a)siemens.com>
---
This allows to postpone the hpet_fw_cfg vs. ACPI discussion until we
have >1 HPET blocks and/or put them at non-standard addresses.
src/acpi.c | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/src/acpi.c b/src/acpi.c
index ea7b171..29160f4 100644
--- a/src/acpi.c
+++ b/src/acpi.c
@@ -158,6 +158,9 @@ struct acpi_20_hpet {
} PACKED;
#define ACPI_HPET_ADDRESS 0xFED00000UL
+#define HPET_ID 0x000
+#define HPET_PERIOD 0x004
+
/*
* SRAT (NUMA topology description) table
*/
@@ -464,7 +467,16 @@ build_ssdt(void)
static void*
build_hpet(void)
{
- struct acpi_20_hpet *hpet = malloc_high(sizeof(*hpet));
+ struct acpi_20_hpet *hpet;
+ const void *hpet_base = (void *)ACPI_HPET_ADDRESS;
+ u32 hpet_vendor = readl(hpet_base + HPET_ID) >> 16;
+ u32 hpet_period = readl(hpet_base + HPET_PERIOD);
+
+ if (hpet_vendor == 0 || hpet_vendor == 0xffff ||
+ hpet_period == 0 || hpet_period > 0x05F5E100)
+ return NULL;
+
+ hpet = malloc_high(sizeof(*hpet));
if (!hpet) {
warn_noalloc();
return NULL;
--
1.7.3.4
On Mon, 2011-08-29 at 13:36 +0100, Daniel Castro wrote:
> On Mon, Aug 29, 2011 at 1:15 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote:
> > On Thu, Aug 25, 2011 at 10:22:43AM +0100, Ian Campbell wrote:
> >> On Tue, 2011-08-23 at 21:10 -0400, Kevin O'Connor wrote:
> >> > It looks to me like this patch series adds capabilities that a later
> >> > patch series will use. The patch series itself looks okay to me
> >> > (though, I do find the multiple copyright statements in the middle of
> >> > xen.h confusing).
> >>
> >> That is a consequence of mashing bits of multiple Xen public headers
> >> into a single xen.h. We could fracture it into xen/*.h instead if that
> >> would be preferable?
> >
> > How about just moving all the copyright notices next to the license
> > text.
>
> I think it is important to be able to trace the header to a specific
> file in the xen headers. It will make it easier to read and
> understand.
That's certainly a good argument for keeping the comments which indicate
which file each definition came from. I'm not 100% sure of the legal
implications but I expect we could amalgamate all the copywrite
statements underneath the license statement, that would leave just a
single line comment at the head of each "file". e.g. instead of:
/******************************************************************************
* arch-x86/xen.h
*
* Guest OS interface to x86 Xen.
*
* Copyright (c) 2004-2006, K A Fraser
*/
It could be the much less intrusive:
/* arch-x86/xen.h: Guest OS interface to x86 Xen */
and the Copyright line would be in the original license header comment
with far less duplication (since many of them are the same).
Ian.
On Mon, Aug 29, 2011 at 1:15 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote:
> On Thu, Aug 25, 2011 at 10:22:43AM +0100, Ian Campbell wrote:
>> On Tue, 2011-08-23 at 21:10 -0400, Kevin O'Connor wrote:
>> > It looks to me like this patch series adds capabilities that a later
>> > patch series will use. The patch series itself looks okay to me
>> > (though, I do find the multiple copyright statements in the middle of
>> > xen.h confusing).
>>
>> That is a consequence of mashing bits of multiple Xen public headers
>> into a single xen.h. We could fracture it into xen/*.h instead if that
>> would be preferable?
>
> How about just moving all the copyright notices next to the license
> text.
I think it is important to be able to trace the header to a specific
file in the xen headers. It will make it easier to read and
understand.
>
> -Kevin
>
--
+-=====---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| | | Daniel Castro, |
| | | Consultant/Programmer.|
| | | U Andes |
+-------------------------------------+
As part of Google Summer of Code we are in the process to add Block PV-drivers to
Seabios, in order to this, first we have to be able to communicate with xenstore
so we can exchange information before the front and back ends connect. To communicate
with xenstore we need to make seabios Xen-friendly so support for hypercalls has been
added to Seabios. In the next month, Seabios will become a front-end for the block devices,
connecting to dom0 back-end block device when used with Xen.
There is an issue, if you issue a query and the ring did not prepare the answer
fast enough, after the event signal hypercall, the ring will force a ring wait for
an event that will never arrive. For now this is solved by doing a dprintf after the
hypercall, this gives enough time to the ring.
This patch should be applied to Seabios and must be used with qemu-upstream with
xen4.1, please follow this guide for this:
http://wiki.xensource.com/xenwiki/QEMUUpstream
Some more documentation on this can be found here:
http://wiki.xensource.com/xenwiki/SeaBIOS
Daniel Castro (10):
Xen: Guest Handlers and Copyrights
Move PAGE_SHIFT to memmap.h
Xen: Use PAGE_SHIFT as a constant
Xen: Support for interdomain event channel
Xen: Support for HVM_op Hypercall
Xen: Support for memory_op Hypercall
Xen: Support for sched_op hypercall
Xen: Shared info for CPU yield support and xenbus protocol
Xen: Xenstore communication via xenbus
Xen: Xenstore example -do not apply
Makefile | 2 +-
src/bitops.h | 14 ++
src/memmap.h | 2 +
src/post.c | 2 +
src/virtio-ring.h | 2 +-
src/xen-xs.c | 251 +++++++++++++++++++++++++++++++++++++
src/xen-xs.h | 9 ++
src/xen.c | 20 +++-
src/xen.h | 357 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
9 files changed, 653 insertions(+), 6 deletions(-)
create mode 100644 src/bitops.h
create mode 100644 src/xen-xs.c
create mode 100644 src/xen-xs.h
--
1.7.4.1
On 2011-08-28 20:54, Alexander Graf wrote:
>
> On 28.08.2011, at 02:42, Avi Kivity wrote:
>
>> On 08/26/2011 08:32 AM, ya su wrote:
>>> hi,Avi:
>>>
>>> I met the same problem, tons of hpet vm_exits(vector 209, fault
>>> address is in the guest vm's hpet mmio range), even I disable hpet
>>> device in win7 guest vm, it still produce a larget amount of vm_exits
>>> when trace-cmd ; I add -no-hpet to start the vm, it still has HPET
>>> device inside VM.
>>>
>>> Does that means the HPET device in VM does not depend on the
>>> emulated hpet device in qemu-kvm? Is there any way to disable the VM
>>> HPET device to prevent so many vm_exits? Thansk.
>>>
>>
>> Looks like a bug to me.
>
> IIRC disabling the HPET device doesn't remove the entry from the DSDT, no? So the guest OS might still think it's there while nothing responds (read returns -1).
Exactly. We have a fw_cfg interface in place for quite a while now
(though I wonder how the firmware is supposed to tell -no-hpet apart
from QEMU versions that don't provide this data - both return count =
255), but SeaBios still exposes one HPET block at a hard-coded address
unconditionally.
There was quite some discussion about the corresponding Seabios patches
back then but apparently no consensus was found. Re-reading it, I think
Kevin asked for passing the necessary DSDT fragments from QEMU to the
firmware instead of using a new, proprietary fw_cfg format. Is that
still the key requirement for any patch finally fixing this bug?
Jan
On 8/4/2011 6:45 PM, Marc Jones wrote:
> On Thu, Aug 4, 2011 at 4:07 PM, Marc Jones<marcj303(a)gmail.com> wrote:
>> On Wed, Aug 3, 2011 at 5:22 PM, Kevin O'Connor<kevin(a)koconnor.net> wrote:
>>> On Wed, Aug 03, 2011 at 02:47:19PM -0600, Marc Jones wrote:
>>>> I'm having a problem with booting a usb flash key that worked
>>>> previously in version 0.6.2. The USB device is identified but then
>>>> gets a read error when booting from it. This is the Persimmon, sb800
>>>> platform. Any thoughts on what might have changed to cause this?
>>> Could it be just a sporatic failure? The only real USB changes since
>>> v0.6.2 were book keeping changes for 'struct pcidevice' - I don't
>>> think they would cause drive read errors. Can you post the log?
>>>
>>> -Kevin
>>>
>>
>> This is the error I am getting:
>>
>> enter handle_13:
>> a=00204280 b=00002400 c=0000000a d=00000080 ds=0000 es=07c0 ss=0000
>> si=00007ba2 di=00002000 bp=000007be sp=00007ba2 cs=07c0 ip=0147 f=0202
>> disk_op d=0x0000d5e0 lba=2097280 buf=0x0000a000 count=1 cmd=2
>> ehci_send_bulk qh=0x0009ff00 dir=0 data=0x0009fad8 size=31
>> ehci_send_bulk qh=0x0009ff80 dir=128 data=0x0000a000 size=512
>> ehci_send_bulk qh=0x0009ff80 dir=128 data=0x0009faf7 size=13
>> enter handle_13:
>> a=00204281 b=00002400 c=00000000 d=00000780 ds=0000 es=07e0 ss=0000
>> si=00007ba2 di=00002000 bp=000007be sp=00007ba2 cs=07c0 ip=0147 f=0206
>> disk_op d=0x0000d5e0 lba=2097281 buf=0x0000a200 count=1 cmd=2
>> ehci_send_bulk qh=0x0009ff00 dir=0 data=0x0009fad8 size=31
>> WARNING - Timeout at ehci_wait_td:570!
>> ehci_send_bulk failed
>> USB transmission failed
>> invalid extended_access:143:
>> a=00204281 b=00002400 c=00000000 d=00000780 ds=0000 es=07e0 ss=0000
>> si=00007ba2 di=00002000 bp=000007be sp=00007ba2 cs=07c0 ip=0147 f=0206
>>
>> I now suspect that this is a coreboot problem. The old working seabios
>> with current coreboot fails as well.
>
> I bisected it to this change in coreboot:
> 8fed77ae4c46122859d0718678e54546e126d4bc is the first bad commit
> commit 8fed77ae4c46122859d0718678e54546e126d4bc
> Author: Scott Duplichan<scott(a)notabs.org>
> Date: Sat Jun 18 10:46:45 2011 -0500
>
> ASRock E350M1: Configure SB800 GPP ports to support onboard pcie nic
>
> Scott Duplichan's patch from the mailing list:
> sb800 cimx wrapper: Run the complete sb800 cimx sbBeforePciInit() function
> once, after determining device 0x15 function enables.
>
> 1) Update the asrock e350m1 devicetree.cb to match the hardware.
> 2) Change the way the sb800 cimx wrapper code works. The original
> cimx code calls sb800 cimx function sbBeforePciInit() once. When
> ported to coreboot, the gpp component of this function was called
> once for each gpp port, as the gpp port's enable/disable state
> became known. A 05/15/2011 change makes the early gpp code run
> only once, triggered by processing the 4th gpp port. This method
> is not general enough because the 4th gpp port is not enabled on
> all boards. With the current change, the early gpp code runs when
> the first gpp port is processed. If any gpp ports are enabled, the
> first must be enabled. Tested with Win7 and linux on asrock e350m1.
> This change will also affect amd inagua, and has not been tested
> on that board.
>
> Change-Id: I93d44c216bfcab3c3a8fbb79d23dab43a65850e6
> Signed-off-by: Scott Duplichan<scott(a)notabs.org>
> Acked-by: Marshall Buschman<mbuschman(a)lucidmachines.com>
> Reviewed-on: http://review.coreboot.org/44
> Tested-by: build bot (Jenkins)
> Reviewed-by: Cristian Măgherușan-Stanciu<cristi.magherusan(a)gmail.com>
>
> I'll see if I can figure out why it breaks stuff.
>
> Marshall,
> Can you try before and after this change?
>
> Marc
>
>
>
>
Understood. I'll roll that back and see if I can still reproduce the USB
error.
-Marshall
On 08/19/2011 01:33 PM, Marc Jones wrote:
> On Wed, Aug 10, 2011 at 10:51 AM, Stefan Berger
> <stefanb(a)linux.vnet.ibm.com> wrote:
>> This patch adds an implementation of a TPM TIS driver for the TPM TIS
>> emulation supported by Qemu (patches posted, not in git yet). Usage of the
>> driver is broken up into several functions. The driver is cleanly separated
>> from the rest of the code through an interface holding pointers to the driver's
>> functions. A client using this driver first probes whether the TPM TIS
>> interface is available (probe function) and then invokes the interface
>> function to initialze the interface and send requests and receive responses.
>>
>> Possible future extensions *could* include a virtio interface for the TPM
>> with a corresponding driver here.
>>
>> v6:
>> - reworked timeouts; not hardcoded anymore
>>
>> v5:
>> - introducing a configurable threashold as part of the driver interface
>> structure below which the TPM is used for calculating the sha1
>>
>> v2:
>> - adapted tpm_drivers.c to be under LGPLv3
>>
>> Signed-off-by: Stefan Berger<stefanb(a)linux.vnet.ibm.com>
> Hi Stefan,
>
> Please excuse my TPM ignorance, but is the emulation of a specific
> hardware device or has the TCG defined the registers etc for TPM
> hardware?
>
Qemu patches provide the emulation of the specific hardware device that
TCG (trusted comp. group) has defined the registers for. SeaBIOS
implements a driver for it.
Stefan