this permits a fully
measured boot in a virtualised environment without the overhead of a full
TPM implementation.
This version of the implementation depends on port io, but if there's
interest I'll add mmio as well.
Signed-off-by: Matthew Garrett
---
Updated based on David's feedbac
On Fri, Aug 12, 2016 at 10:59 AM, Dr. David Alan Gilbert
wrote:
> * Matthew Garrett (mj...@coreos.com) wrote:
>> In combination with work in SeaBIOS and the kernel, this permits a fully
>> measured boot in a virtualised environment without the overhead of a full
>> TPM imple
this permits a fully
measured boot in a virtualised environment without the overhead of a full
TPM implementation.
This version of the implementation depends on port io, but if there's
interest I'll add mmio as well.
Signed-off-by: Matthew Garrett
---
Updated with Eric's feedback, an
On Fri, Aug 5, 2016 at 8:56 PM, Stefan Berger wrote:
> Matthew Garrett wrote on 08/05/2016 07:17:12 PM:
>> This version of the implementation depends on port io, but if there's
>> interest I'll add mmio as well.
>
> Port io is x86 specific, right? I don't
this permits a fully
measured boot in a virtualised environment without the overhead of a full
TPM implementation.
This version of the implementation depends on port io, but if there's
interest I'll add mmio as well.
Signed-off-by: Matthew Garrett
---
This should cover the initial review
Is there any mechanism for automatically mapping non-PCI MMIO devices
to an appropriate range? From what I've found so far it seems like
target machines tend to be responsible for mapping individual devices,
but I want to make sure that I'm not missing some generic "Just put
the device in a reasona
On Jul 18, 2016 17:46, "Stefan Berger" wrote:
>
>
> Matthew Garrett wrote on 07/18/2016 08:39:07 PM:
>
>
> >
> > On Jul 18, 2016 17:08, "Stefan Berger" wrote:
> > > The point of the TPM is that the device that holds the state of
> >
On Jul 18, 2016 17:08, "Stefan Berger" wrote:
> The point of the TPM is that the device that holds the state of the PCRs
provides the signatures over their state rather than some other 'entity'
whose trustworthiness wouldn't be clear. Admittedly the device comes with
its own set of challenges.
T
On Mon, Jul 18, 2016 at 4:40 PM, Stefan Berger wrote:
> The TPM security's model related to logs, the state of the PCRs, and
> attestation involves the following pieces:
>
> - PCRs
> - measurement log
> - EK + certificate
> - platform certificate
> - AIK + certificate
> - quotes (signatures) on PC
On Fri, Jul 15, 2016 at 11:11 AM, Stefan Berger wrote:
>
> Are you also providing a measurement log that goes along with these PCR
> extensions? Like a measurement log we have in the TCPA ACPI table? Just
> measurements without knowing what was measured wouldn't be all that helpful.
> Typically
On Fri, Jul 15, 2016 at 4:29 AM, Dr. David Alan Gilbert wrote:
> * Matthew Garrett (mj...@coreos.com) wrote:
>a) (one that works) 'are all the VMs on my hosts running trusted OSs'
> That works with this just as well as with a vTPM; you ask your
> hypervisor t
On Thu, Jul 14, 2016 at 11:54 PM, Daniel P. Berrange
wrote:
> On Thu, Jun 23, 2016 at 04:36:59PM -0700, Matthew Garrett wrote:
> > In combination with work in SeaBIOS and the kernel, this permits a fully
> measured
> > boot in a virtualised environment without the over
Any feedback on this?
ernel, this permits a fully
measured
boot in a virtualised environment without the overhead of a full TPM
implementation.
This version of the implementation depends on port io, but if there's interest
I'll
add mmio as well.
Signed-off-by: Matthew Garrett
---
default-configs/x86_64-so
ernel, this permits a fully
measured
boot in a virtualised environment without the overhead of a full TPM
implementation.
This version of the implementation depends on port io, but if there's interest
I'll
add mmio as well.
Signed-off-by: Matthew Garrett
---
default-configs/x86_64-so
will attempt to reconnect
> after the given number of seconds.
We're enthusiastic about this - we're using a virtio rng via egd, and
restarting our entropy distributor currently kills hwrng in the guest
because the socket has gone away.
--
Matthew Garrett | mj...@srcf.ucam.org
Any feedback on this?
On Mon, Nov 25, 2013 at 02:42:43PM -0500, Matthew Garrett wrote:
> The migration thread appears to want to allow writeout to occur at full
> speed rather than being rate limited during completion of state saving,
> but sets the limit to INT_MAX when xfer_limit is
bably ought to just be INT64_MAX instead.
Signed-off-by: Matthew Garrett
---
migration.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/migration.c b/migration.c
index 2b1ab20..ff00bfb 100644
--- a/migration.c
+++ b/migration.c
@@ -583,7 +583,7 @@ static void *migration_t
this?
Is the only reason for this to allow guests to notify the host that
they've panicked? It seems like making use of pstore to push the crash
dump to the host as well would be a useful thing to do.
--
Matthew Garrett | mj...@srcf.ucam.org
27;s no reason not to allow -vga cirrus at this point.
>
> Note to Matthew: cirrusdrmfb is a LOT SLOWER than offb for a similar
> SW only dumb framebuffer, probably has to do with the way it does the
> "dirty" stuff, not sure ...
>
> Why not draw directly into the emulated vram ?
>
> Cheers,
> Ben.
>
>
>
--
Matthew Garrett | mj...@srcf.ucam.org
gnment. I'm not sure quite what's going wrong, but I'll
look further.
--
Matthew Garrett | mj...@srcf.ucam.org
On Thu, Jun 17, 2010 at 04:48:09PM +0900, Isaku Yamahata wrote:
> Thanks for the patch.
> Does vista boot with the patch eventually?
Vista boots, but is unable to allocate resources for the pcie root
ports. I'm looking into that.
--
Matthew Garrett | mj...@srcf.ucam.org
On Wed, Jun 16, 2010 at 04:42:10PM +0100, Matthew Garrett wrote:
> Thanks for this - however, Vista gives me an ACPI error on boot (stop
> 0x00a5, 0x000d, which indicates that there's a malformed or
> undefined ACPI device). I don't suppose you have any idea what the
e any idea what the
problem here may be? Linux boots without complaint.
I also have a small patch that fixes some build warnings in the qemu
build. I'll send that separately.
--
Matthew Garrett | mj...@srcf.ucam.org
pository
which contains your patch sets?
Thank you,
--
Matthew Garrett | mj...@srcf.ucam.org
25 matches
Mail list logo