On 02/08/2018 02:30 PM, Marc-André Lureau wrote:
Hi
On Thu, Feb 8, 2018 at 5:35 PM, Stefan Berger
wrote:
On 02/08/2018 10:52 AM, Marc-André Lureau wrote:
Hi
On Wed, Feb 7, 2018 at 6:21 PM, Laszlo Ersek wrote:
On 02/07/18 17:44, Stefan Berger wrote:
On 02/07/2018 10:50 AM, Laszlo Ersek wro
Hi
On Thu, Feb 8, 2018 at 5:35 PM, Stefan Berger
wrote:
> On 02/08/2018 10:52 AM, Marc-André Lureau wrote:
>>
>> Hi
>>
>> On Wed, Feb 7, 2018 at 6:21 PM, Laszlo Ersek wrote:
>>>
>>> On 02/07/18 17:44, Stefan Berger wrote:
On 02/07/2018 10:50 AM, Laszlo Ersek wrote:
>
> OK, but
On 02/08/2018 10:52 AM, Marc-André Lureau wrote:
Hi
On Wed, Feb 7, 2018 at 6:21 PM, Laszlo Ersek wrote:
On 02/07/18 17:44, Stefan Berger wrote:
On 02/07/2018 10:50 AM, Laszlo Ersek wrote:
OK, but if the OS is allowed to modify this set of "queued operations",
then what protection is expected
On 02/08/18 16:52, Marc-André Lureau wrote:
> Hi
>
> On Wed, Feb 7, 2018 at 6:21 PM, Laszlo Ersek
> wrote:
>> On 02/07/18 17:44, Stefan Berger wrote:
>>> On 02/07/2018 10:50 AM, Laszlo Ersek wrote:
>>
OK, but if the OS is allowed to modify this set of "queued
operations", then what prote
Hi
On Wed, Feb 7, 2018 at 6:21 PM, Laszlo Ersek wrote:
> On 02/07/18 17:44, Stefan Berger wrote:
>> On 02/07/2018 10:50 AM, Laszlo Ersek wrote:
>
>>> OK, but if the OS is allowed to modify this set of "queued operations",
>>> then what protection is expected of SMM? Whether you can modify the TPM
On 02/07/18 17:44, Stefan Berger wrote:
> On 02/07/2018 10:50 AM, Laszlo Ersek wrote:
>> OK, but if the OS is allowed to modify this set of "queued operations",
>> then what protection is expected of SMM? Whether you can modify the TPM
>> directly, or queue random commands for it at libery, what's
On 02/07/2018 10:50 AM, Laszlo Ersek wrote:
On 02/07/18 15:57, Stefan Berger wrote:
On 02/07/2018 09:18 AM, Laszlo Ersek wrote:
On 02/07/18 14:51, Stefan Berger wrote:
To support SeaBIOS as well, we would have to be
able to distinguish a BIOS from the UEFI on the QEMU level so that we
could pr
On 02/07/18 15:57, Stefan Berger wrote:
> On 02/07/2018 09:18 AM, Laszlo Ersek wrote:
>> On 02/07/18 14:51, Stefan Berger wrote:
>>> To support SeaBIOS as well, we would have to be
>>> able to distinguish a BIOS from the UEFI on the QEMU level so that we
>>> could produce different ACPI
>> Yes and
On 02/07/18 15:57, Igor Mammedov wrote:
> On Wed, 7 Feb 2018 08:51:58 -0500
> Stefan Berger wrote:
>
>> On 01/10/2018 08:22 AM, Laszlo Ersek wrote:
>>> Stefan,
>>>
>>> On 01/09/18 20:02, Stefan Berger wrote:
>>>
> [...]
>
>
>> So the point is SMM is needed for UEFI. QEMU would need to provid
On 02/07/2018 09:18 AM, Laszlo Ersek wrote:
On 02/07/18 14:51, Stefan Berger wrote:
On 01/10/2018 08:22 AM, Laszlo Ersek wrote:
Stefan,
On 01/09/18 20:02, Stefan Berger wrote:
Another twist is that Intel's EDK2 also implements this but the data
structure layout is different and they use SMM
On Wed, 7 Feb 2018 08:51:58 -0500
Stefan Berger wrote:
> On 01/10/2018 08:22 AM, Laszlo Ersek wrote:
> > Stefan,
> >
> > On 01/09/18 20:02, Stefan Berger wrote:
> >
[...]
> So the point is SMM is needed for UEFI. QEMU would need to provide the
> ACPI code for it, which is basically a transl
On 02/07/18 14:51, Stefan Berger wrote:
> On 01/10/2018 08:22 AM, Laszlo Ersek wrote:
>> Stefan,
>>
>> On 01/09/18 20:02, Stefan Berger wrote:
>>
>>> Another twist is that Intel's EDK2 also implements this but the data
>>> structure layout is different and they use SMM + SMIs etc.
>>>
>>> https://g
On 01/10/2018 08:22 AM, Laszlo Ersek wrote:
Stefan,
On 01/09/18 20:02, Stefan Berger wrote:
Another twist is that Intel's EDK2 also implements this but the data
structure layout is different and they use SMM + SMIs etc.
https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Smm/Tpm
On 01/11/2018 12:38 PM, Laszlo Ersek wrote:
On 01/11/18 18:16, Stefan Berger wrote:
I can only point to the standard for the address. If QEMU has an API
where we can first try to allocate fed4 and if that fails ask for
another address, then we can use that. But does driver initialization
w
On 01/11/18 18:16, Stefan Berger wrote:
> I can only point to the standard for the address. If QEMU has an API
> where we can first try to allocate fed4 and if that fails ask for
> another address, then we can use that. But does driver initialization
> work that way that we can first let all
On 01/11/2018 11:44 AM, Laszlo Ersek wrote:
(I'm not trying to further argue for the idea below, just to clarify it:)
On 01/11/18 15:29, Stefan Berger wrote:
On 01/11/2018 09:02 AM, Laszlo Ersek wrote:
On 01/11/18 13:40, Igor Mammedov wrote:
On Wed, 10 Jan 2018 17:45:52 +0100
Laszlo Ersek wr
(I'm not trying to further argue for the idea below, just to clarify it:)
On 01/11/18 15:29, Stefan Berger wrote:
> On 01/11/2018 09:02 AM, Laszlo Ersek wrote:
>> On 01/11/18 13:40, Igor Mammedov wrote:
>>> On Wed, 10 Jan 2018 17:45:52 +0100
>>> Laszlo Ersek wrote:
(My understanding is that
On 01/11/2018 10:52 AM, Igor Mammedov wrote:
On Thu, 11 Jan 2018 09:29:14 -0500
Stefan Berger wrote:
On 01/11/2018 09:02 AM, Laszlo Ersek wrote:
On 01/11/18 13:40, Igor Mammedov wrote:
On Wed, 10 Jan 2018 17:45:52 +0100
Laszlo Ersek wrote:
(My understanding is that the guest has to populat
On Thu, 11 Jan 2018 09:29:14 -0500
Stefan Berger wrote:
> On 01/11/2018 09:02 AM, Laszlo Ersek wrote:
> > On 01/11/18 13:40, Igor Mammedov wrote:
> >> On Wed, 10 Jan 2018 17:45:52 +0100
> >> Laszlo Ersek wrote:
> >>> (My understanding is that the guest has to populate the CRB, and then
> >>>
On 01/11/2018 09:02 AM, Laszlo Ersek wrote:
On 01/11/18 13:40, Igor Mammedov wrote:
On Wed, 10 Jan 2018 17:45:52 +0100
Laszlo Ersek wrote:
(My understanding is that the guest has to populate the CRB, and then
kick the hypervisor, so at least the register used for kicking must be
in MMIO (or IO
On 01/11/18 13:40, Igor Mammedov wrote:
> On Wed, 10 Jan 2018 17:45:52 +0100
> Laszlo Ersek wrote:
>> (My understanding is that the guest has to populate the CRB, and then
>> kick the hypervisor, so at least the register used for kicking must be
>> in MMIO (or IO) space. And firmware cannot alloc
On Wed, 10 Jan 2018 17:45:52 +0100
Laszlo Ersek wrote:
> On 01/10/18 16:19, Marc-André Lureau wrote:
> > Hi
> >
> > - Original Message -
> >>
> >> BTW, from the "TCG PC Client Platform TPM Profile (PTP)
> >> Specification", it seems like the FIFO (TIS) interface is hard-coded
> >> *in t
On 01/10/18 19:45, Stefan Berger wrote:
> On 01/10/2018 11:45 AM, Laszlo Ersek wrote:
>> On 01/10/18 16:19, Marc-André Lureau wrote:
>>> Hi
>>>
>>> - Original Message -
BTW, from the "TCG PC Client Platform TPM Profile (PTP)
Specification", it seems like the FIFO (TIS) interface i
On 01/10/2018 10:19 AM, Marc-André Lureau wrote:
Hi
- Original Message -
BTW, from the "TCG PC Client Platform TPM Profile (PTP) Specification",
it seems like the FIFO (TIS) interface is hard-coded *in the spec* at
FED4_h – FED4_4FFFh. So we don't even have to make that dynamic.
Re
On 01/10/2018 11:45 AM, Laszlo Ersek wrote:
On 01/10/18 16:19, Marc-André Lureau wrote:
Hi
- Original Message -
BTW, from the "TCG PC Client Platform TPM Profile (PTP)
Specification", it seems like the FIFO (TIS) interface is hard-coded
*in the spec* at FED4_h FED4_4FFFh. So we d
On 01/10/18 16:19, Marc-André Lureau wrote:
> Hi
>
> - Original Message -
>>
>> BTW, from the "TCG PC Client Platform TPM Profile (PTP)
>> Specification", it seems like the FIFO (TIS) interface is hard-coded
>> *in the spec* at FED4_h FED4_4FFFh. So we don't even have
>> to make that
Hi
- Original Message -
>
> BTW, from the "TCG PC Client Platform TPM Profile (PTP) Specification",
> it seems like the FIFO (TIS) interface is hard-coded *in the spec* at
> FED4_h – FED4_4FFFh. So we don't even have to make that dynamic.
>
> Regarding CRB (as an alternative to TIS+C
Stefan,
On 01/09/18 20:02, Stefan Berger wrote:
> Another twist is that Intel's EDK2 also implements this but the data
> structure layout is different and they use SMM + SMIs etc.
>
> https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl#L81
As I described in my investig
On Tue, Jan 09, 2018 at 02:02:52PM -0500, Stefan Berger wrote:
> On 01/09/2018 10:14 AM, Kevin O'Connor wrote:
> > On Tue, Jan 09, 2018 at 10:00:44AM -0500, Stefan Berger wrote:
> > > is it possible to save a few bytes, a pointer, across a reboot? I have
> > > tried to do this by allocating a m
On 01/09/2018 10:14 AM, Kevin O'Connor wrote:
On Tue, Jan 09, 2018 at 10:00:44AM -0500, Stefan Berger wrote:
Kevin,
is it possible to save a few bytes, a pointer, across a reboot? I have
tried to do this by allocating a memory chunk in the fsegement and storing
the pointer there surrounded
On Tue, Jan 09, 2018 at 10:00:44AM -0500, Stefan Berger wrote:
> Kevin,
>
>is it possible to save a few bytes, a pointer, across a reboot? I have
> tried to do this by allocating a memory chunk in the fsegement and storing
> the pointer there surrounded by 2 'magic' 32 bit values. When trying
Kevin,
is it possible to save a few bytes, a pointer, across a reboot? I
have tried to do this by allocating a memory chunk in the fsegement and
storing the pointer there surrounded by 2 'magic' 32 bit values. When
trying to find the magic values on reboot early in handle_post() it
doesn't
32 matches
Mail list logo