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
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
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
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
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,
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
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
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
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.
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
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
(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
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:
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
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
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
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
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
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.
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
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
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
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
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
28 matches
Mail list logo