On Sat, Apr 23, 2016 at 02:57:55PM +0200, Kevin Kofler wrote:
> Matthew Garrett wrote:
> > Measured boot is a process whereby each component in the boot chain
> > "measures" the next component. In the TPM 1.x world (which is where most
> > of us still are), that measurement is in the form of a
On Sat, Apr 23, 2016 at 8:57 AM, Kevin Kofler wrote:
> Matthew Garrett wrote:
>> Measured boot is a process whereby each component in the boot chain
>> "measures" the next component. In the TPM 1.x world (which is where most
>> of us still are), that measurement is in the
On Sun, Apr 24, 2016 at 01:15:15AM +0200, Lars Seipel wrote:
> On Sat, Apr 23, 2016 at 02:57:55PM +0200, Kevin Kofler wrote:
> > Matthew Garrett wrote:
> > > Remote attestation is a mechanism by which […]
> >
> > How does the remote machine know that what is answering is a physical TPM
> > and
On Sat, Apr 23, 2016 at 02:57:55PM +0200, Kevin Kofler wrote:
> Matthew Garrett wrote:
> > Remote attestation is a mechanism by which […]
>
> How does the remote machine know that what is answering is a physical TPM
> and not a software emulation? Does it need to have the individual TPM's
>
Kevin Kofler wrote:
> Matthew Garrett wrote:
> > Measured boot is a process whereby each component in the boot chain
> > "measures" the next component. In the TPM 1.x world (which is where
> > most of us still are), that measurement is in the form of a SHA1
> > hash of the next component. So, on a
Matthew Garrett wrote:
> Measured boot is a process whereby each component in the boot chain
> "measures" the next component. In the TPM 1.x world (which is where most
> of us still are), that measurement is in the form of a SHA1 hash of the
> next component. So, on a BIOS system, the firmware
On Fri, Apr 22, 2016 at 9:48 AM, Chris Murphy wrote:
> On Fri, Apr 22, 2016 at 7:31 AM, Josh Boyer wrote:
>> On Fri, Apr 22, 2016 at 2:35 AM, Matthew Garrett wrote:
>>> On Thu, Apr 21, 2016 at 02:35:21PM +0200, Harald
On Fri, Apr 22, 2016 at 7:31 AM, Josh Boyer wrote:
> On Fri, Apr 22, 2016 at 2:35 AM, Matthew Garrett wrote:
>> On Thu, Apr 21, 2016 at 02:35:21PM +0200, Harald Hoyer wrote:
>>> On 08.04.2016 18:56, Matthew Garrett wrote:
>>> > initrd is certainly
On Fri, Apr 22, 2016 at 2:35 AM, Matthew Garrett wrote:
> On Thu, Apr 21, 2016 at 02:35:21PM +0200, Harald Hoyer wrote:
>> On 08.04.2016 18:56, Matthew Garrett wrote:
>> > initrd is certainly a more difficult one. One thing we can do is work on
>> > making dracut builds
On Thu, Apr 21, 2016 at 02:35:21PM +0200, Harald Hoyer wrote:
> On 08.04.2016 18:56, Matthew Garrett wrote:
> > initrd is certainly a more difficult one. One thing we can do is work on
> > making dracut builds reproducible - that way they should be consistent
> > across identical machines in a
On 08.04.2016 18:56, Matthew Garrett wrote:
> On Fri, Apr 08, 2016 at 09:23:07AM +, Petr Pisar wrote:
>
>> I'm curious how you would predict hash of initramfs because it is
>> generated on the host and depends on dracut configuration and presence
>> of various optionally installed packages.
>
On Fri, Apr 08, 2016 at 11:36:33AM +0200, Florian Weimer wrote:
> On 04/08/2016 10:28 AM, Matthew Garrett wrote:
> > With what we now know about malicious actors targeting the system boot
> > chain (even down to the firmware), this kind of TPM-based work is a
> > vital part of helping keep our
On Fri, Apr 08, 2016 at 09:23:07AM +, Petr Pisar wrote:
> I'm curious how you would predict hash of initramfs because it is
> generated on the host and depends on dracut configuration and presence
> of various optionally installed packages.
initrd is certainly a more difficult one. One thing
On Fri, Apr 08, 2016 at 09:09:23AM +, Gregory Maxwell wrote:
> The TPM style of remote attest is quite unfriendly to free software.
> It puts basically the entire operating system in the trusted domain,
> and you cannot change even a bit of it without "breaking the seal".
> So if you want any
On Fri, Apr 8, 2016, at 05:36 AM, Florian Weimer wrote:
> Remote attestation only works with a trusted counterpart who rejects
> access once a breach is detected. Who do you expect to be the
> counterpart for Fedora users? Is there anyone who offers such a service
> without also requiring to
On Fri, Apr 8, 2016, at 05:23 AM, Petr Pisar wrote:
> I'm curious how you would predict hash of initramfs because it is
> generated on the host and depends on dracut configuration and presence
> of various optionally installed packages.
That's true for a system managed by yum/dnf, but
On 04/08/2016 10:28 AM, Matthew Garrett wrote:
> With what we now know about malicious actors targeting the system boot
> chain (even down to the firmware), this kind of TPM-based work is a
> vital part of helping keep our users secure.
On the other hand, it can easily be abused to restrict
On 2016-04-08, Matthew Garrett wrote:
> Doing this well involves knowing what the expected values are to begin
> with. Some of these values come from the firmware, and so we can't do
> much about them without the assistance of the system vendors. But these
> values don't
On Fri, Apr 8, 2016 at 8:28 AM, Matthew Garrett wrote:
[snip]
> Remote attestation is a mechanism by which a remote machine can request
> (but not compel) another machine to provide evidence of the PCR state.
> The TPM provides a signed bundle of information including the PCR
Some people who installed the Fedora 24 Alpha from scratch on bare-metal
BIOS-based systems may have found that their system didn't boot. Sorry
about that - it's my fault, and it's fixed now. But it happened as a
result of some new code in grub that gives us some really exciting
functionality.
20 matches
Mail list logo