On 03/09/16 15:07, Paolo Bonzini wrote:
>
>
> On 09/03/2016 15:06, Laszlo Ersek wrote:
>> However: despite reusing the core SMM code identically in the guest,
>> there is at least one stark behavioral difference: in QEMU the SMI is
>> raised only on the processor that triggers it. This exercises
On 09/03/2016 15:06, Laszlo Ersek wrote:
> However: despite reusing the core SMM code identically in the guest,
> there is at least one stark behavioral difference: in QEMU the SMI is
> raised only on the processor that triggers it. This exercises paths in
> the core SMM code where processors hav
On 03/08/16 14:06, Paolo Bonzini wrote:
> On 08/03/2016 13:50, Ard Biesheuvel wrote:
>> Note that, for KVM, it is unlikely that we will ever support all of
>> this inside the guest. It makes *much* more sense to lock down the
>> emulated flash, and implement the UEFI Runtime Services using a thin
>
On 8 March 2016 at 19:16, Ard Biesheuvel wrote:
> The UEFI code is loaded into DRAM by the secure firmware, and
> relocated and executed from there.
Incidentally, since we're using the semihosting API to do this at
the moment, this makes the whole thing completely dependent on the
nonsecure guest
On 8 March 2016 at 20:06, Paolo Bonzini wrote:
> I cannot think of a good reason for hardware not to let you virtualize
> hypervisor or secure mode
Regardless of whether you can think of a good reason or not,
it doesn't let you do it...
thanks
-- PMM
On 08/03/2016 13:50, Ard Biesheuvel wrote:
> Note that, for KVM, it is unlikely that we will ever support all of
> this inside the guest. It makes *much* more sense to lock down the
> emulated flash, and implement the UEFI Runtime Services using a thin
> layer in UEFI that hooks up to interfaces ex
On 8 March 2016 at 19:41, Paolo Bonzini wrote:
>
>
> On 08/03/2016 13:16, Ard Biesheuvel wrote:
>> > > > As far as this QEMU port is concerned, having some flash in secure and
>> > > > some in non-secure is going to be useful regardless, and 64 MB is
>> > > > plenty for both the code and the data.
On 08/03/2016 13:16, Ard Biesheuvel wrote:
> > > > As far as this QEMU port is concerned, having some flash in secure and
> > > > some in non-secure is going to be useful regardless, and 64 MB is
> > > > plenty for both the code and the data. So if users of the Trustzone
> > > > port (which is di
On 8 March 2016 at 19:14, Paolo Bonzini wrote:
>
>
> On 08/03/2016 13:13, Ard Biesheuvel wrote:
>> > As far as this QEMU port is concerned, having some flash in secure and
>> > some in non-secure is going to be useful regardless, and 64 MB is
>> > plenty for both the code and the data. So if users
On 08/03/2016 13:13, Ard Biesheuvel wrote:
> > As far as this QEMU port is concerned, having some flash in secure and
> > some in non-secure is going to be useful regardless, and 64 MB is
> > plenty for both the code and the data. So if users of the Trustzone
> > port (which is disjoint from the
On 8 March 2016 at 19:10, Ard Biesheuvel wrote:
> On 8 March 2016 at 19:02, Paolo Bonzini wrote:
>>
>>
>> On 08/03/2016 00:34, Peter Maydell wrote:
> I think that, if UEFI secure boot is in use, the UEFI environment
> variables should also be only accessible from TrustZone, because they
On 8 March 2016 at 19:02, Paolo Bonzini wrote:
>
>
> On 08/03/2016 00:34, Peter Maydell wrote:
>>> > I think that, if UEFI secure boot is in use, the UEFI environment
>>> > variables should also be only accessible from TrustZone, because they
>>> > store the key database. At least that's how it w
On 08/03/2016 00:34, Peter Maydell wrote:
>> > I think that, if UEFI secure boot is in use, the UEFI environment
>> > variables should also be only accessible from TrustZone, because they
>> > store the key database. At least that's how it works on x86, where both
>> > pflash devices have the se
On 7 March 2016 at 22:20, Paolo Bonzini wrote:
>
>
> On 12/02/2016 15:45, Peter Maydell wrote:
>> This patchset adds some more secure-only devices to the virt board:
>> (1) a 16MB secure-only RAM
>> (2) the first flash device is secure-only
>>
>> The second of these is strictly speaking a breaki
On 12/02/2016 15:45, Peter Maydell wrote:
> This patchset adds some more secure-only devices to the virt board:
> (1) a 16MB secure-only RAM
> (2) the first flash device is secure-only
>
> The second of these is strictly speaking a breaking change, but I don't
> expect it in practice to break
Ping? Review appreciated especially for the loader.c change...
thanks
-- PMM
On 12 February 2016 at 14:45, Peter Maydell wrote:
> This patchset adds some more secure-only devices to the virt board:
> (1) a 16MB secure-only RAM
> (2) the first flash device is secure-only
>
> The second of these
On 12/02/16 14:45, Peter Maydell wrote:
> NOTE: to get the -bios option to correctly load to the secure-only
> flash I had to implement a new function in loader.c. load_image_mr()
> is just like load_image_targphys() except that it requests loading
> to a MemoryRegion rather than a physaddr. I thi
This patchset adds some more secure-only devices to the virt board:
(1) a 16MB secure-only RAM
(2) the first flash device is secure-only
The second of these is strictly speaking a breaking change, but I don't
expect it in practice to break anybody:
(a) there's not much use of the secure support
18 matches
Mail list logo
