On Thu, 5 Sep 2019 15:08:31 +0200
Laszlo Ersek wrote:
> On 09/04/19 11:52, Igor Mammedov wrote:
>
> > it could be stolen RAM + black hole like TSEG, assuming fw can live
> > without RAM(0x3+128K) range
> > (in this case fwcfg interface would only work for locking down the range)
> >
> >
On 09/04/19 11:52, Igor Mammedov wrote:
> it could be stolen RAM + black hole like TSEG, assuming fw can live without
> RAM(0x3+128K) range
> (in this case fwcfg interface would only work for locking down the range)
>
> or
>
> we can actually have a dedicated SMRAM (like in my earlier
On Tue, 3 Sep 2019 19:20:25 +0200
Laszlo Ersek wrote:
> On 09/03/19 16:53, Igor Mammedov wrote:
> > On Mon, 2 Sep 2019 21:09:58 +0200
> > Laszlo Ersek wrote:
> >
> >> On 09/02/19 10:45, Igor Mammedov wrote:
> >>> On Fri, 30 Aug 2019 20:46:14 +0200
> >>> Laszlo Ersek wrote:
> >>>
> >>>
On 09/03/19 16:53, Igor Mammedov wrote:
> On Mon, 2 Sep 2019 21:09:58 +0200
> Laszlo Ersek wrote:
>
>> On 09/02/19 10:45, Igor Mammedov wrote:
>>> On Fri, 30 Aug 2019 20:46:14 +0200
>>> Laszlo Ersek wrote:
>>>
On 08/30/19 16:48, Igor Mammedov wrote:
> (01) On boot firmware map
On Mon, 2 Sep 2019 21:09:58 +0200
Laszlo Ersek wrote:
> On 09/02/19 10:45, Igor Mammedov wrote:
> > On Fri, 30 Aug 2019 20:46:14 +0200
> > Laszlo Ersek wrote:
> >
> >> On 08/30/19 16:48, Igor Mammedov wrote:
> >>
> >>> (01) On boot firmware maps and initializes SMI handler at default SMBASE
On 09/02/19 10:45, Igor Mammedov wrote:
> On Fri, 30 Aug 2019 20:46:14 +0200
> Laszlo Ersek wrote:
>
>> On 08/30/19 16:48, Igor Mammedov wrote:
>>
>>> (01) On boot firmware maps and initializes SMI handler at default SMBASE
>>> (3)
>>> (using dedicated SMRAM at 3 would allow us to a
On Fri, 30 Aug 2019 20:46:14 +0200
Laszlo Ersek wrote:
> On 08/30/19 16:48, Igor Mammedov wrote:
>
> > (01) On boot firmware maps and initializes SMI handler at default SMBASE
> > (3)
> > (using dedicated SMRAM at 3 would allow us to avoid save/restore
> > steps and make SMM
On 08/30/19 16:48, Igor Mammedov wrote:
> (01) On boot firmware maps and initializes SMI handler at default SMBASE
> (3)
> (using dedicated SMRAM at 3 would allow us to avoid save/restore
> steps and make SMM handler pointer not vulnerable to DMA attacks)
>
> (02) QEMU hotplug
On Thu, 29 Aug 2019 18:25:17 +0200
Laszlo Ersek wrote:
> On 08/28/19 14:01, Igor Mammedov wrote:
> > On Tue, 27 Aug 2019 22:11:15 +0200
> > Laszlo Ersek wrote:
> >
> >> On 08/27/19 18:23, Igor Mammedov wrote:
> >>> On Mon, 26 Aug 2019 17:30:43 +0200
> >>> Laszlo Ersek wrote:
> >>>
> On
On Thu, 29 Aug 2019 19:01:35 +0200
Laszlo Ersek wrote:
> On 08/27/19 20:31, Igor Mammedov wrote:
> > On Sat, 24 Aug 2019 01:48:09 +
> > "Yao, Jiewen" wrote:
>
> >> (05) Host CPU: (OS) Port 0xB2 write, all CPUs enter SMM (NOTE: New CPU
> >> will not enter CPU because SMI is disabled)
On 08/27/19 20:31, Igor Mammedov wrote:
> On Sat, 24 Aug 2019 01:48:09 +
> "Yao, Jiewen" wrote:
>> (05) Host CPU: (OS) Port 0xB2 write, all CPUs enter SMM (NOTE: New CPU
>> will not enter CPU because SMI is disabled)
> I think only CPU that does the write will enter SMM
That used to be
On 08/28/19 14:01, Igor Mammedov wrote:
> On Tue, 27 Aug 2019 22:11:15 +0200
> Laszlo Ersek wrote:
>
>> On 08/27/19 18:23, Igor Mammedov wrote:
>>> On Mon, 26 Aug 2019 17:30:43 +0200
>>> Laszlo Ersek wrote:
>>>
On 08/23/19 17:25, Kinney, Michael D wrote:
> Hi Jiewen,
>
> If a ho
On Tue, 27 Aug 2019 22:11:15 +0200
Laszlo Ersek wrote:
> On 08/27/19 18:23, Igor Mammedov wrote:
> > On Mon, 26 Aug 2019 17:30:43 +0200
> > Laszlo Ersek wrote:
> >
> >> On 08/23/19 17:25, Kinney, Michael D wrote:
> >>> Hi Jiewen,
> >>>
> >>> If a hot add CPU needs to run any code before the
> >
On 08/27/19 18:23, Igor Mammedov wrote:
> On Mon, 26 Aug 2019 17:30:43 +0200
> Laszlo Ersek wrote:
>
>> On 08/23/19 17:25, Kinney, Michael D wrote:
>>> Hi Jiewen,
>>>
>>> If a hot add CPU needs to run any code before the
>>> first SMI, I would recommend is only executes code
>>> from a write prot
ding ABI for initializing that SMRAM blocks from
another CPU which could be complicated.
> Solution #1 or #2 are simple solution.
lets first see if if we can ignore race and if it's not then
we probably end up with implementing some form of #1
>
> > Mike
> >
> > >
On Mon, 26 Aug 2019 17:30:43 +0200
Laszlo Ersek wrote:
> On 08/23/19 17:25, Kinney, Michael D wrote:
> > Hi Jiewen,
> >
> > If a hot add CPU needs to run any code before the
> > first SMI, I would recommend is only executes code
> > from a write protected FLASH range without a stack
> > and then
On 08/23/19 17:25, Kinney, Michael D wrote:
> Hi Jiewen,
>
> If a hot add CPU needs to run any code before the
> first SMI, I would recommend is only executes code
> from a write protected FLASH range without a stack
> and then wait for the first SMI.
"without a stack" looks very risky to me. Eve
io;
> qemu devel list ; Igor Mammedov
> ; Chen, Yingwen ;
> Nakajima, Jun ; Boris Ostrovsky
> ; Joao Marcal Lemos Martins
> ; Phillip Goerl
> Subject: RE: [edk2-rfc] [edk2-devel] CPU hotplug using SMM with
> QEMU+OVMF
>
> Hi Jiewen,
>
> If a hot add CPU needs to run
Igor Mammedov ;
> Chen, Yingwen ; Nakajima, Jun
> ; Boris Ostrovsky
> ; Joao Marcal Lemos Martins
> ; Phillip Goerl
>
> Subject: RE: [edk2-rfc] [edk2-devel] CPU hotplug using
> SMM with QEMU+OVMF
>
> Thank you Mike!
>
> That is good reference on the real hardware b
On 22/08/19 22:06, Kinney, Michael D wrote:
> The SMBASE register is internal and cannot be directly accessed
> by any CPU. There is an SMBASE field that is member of the SMM Save
> State area and can only be modified from SMM and requires the
> execution of an RSM instruction from SMM for the SM
On 23/08/19 00:32, Kinney, Michael D wrote:
> Paolo,
>
> It is my understanding that real HW hot plug uses the SDM defined
> methods. Meaning the initial SMI is to 3000:8000 and they rebase
> to TSEG in the first SMI. They must have chipset specific methods
> to protect 3000:8000 from DMA.
It w
On 08/22/19 20:51, Paolo Bonzini wrote:
> On 22/08/19 20:29, Laszlo Ersek wrote:
>> On 08/22/19 08:18, Paolo Bonzini wrote:
>>> On 21/08/19 22:17, Kinney, Michael D wrote:
DMA protection of memory ranges is a chipset feature. For the current
QEMU implementation, what ranges of memory are
qemu devel list > de...@nongnu.org>; Igor Mammedov ;
> > Chen, Yingwen ; Nakajima, Jun
> > ; Boris Ostrovsky
> > ; Joao Marcal Lemos Martins
> > ; Phillip Goerl
> >
> > Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug using
> > SMM with QEMU+OVMF
> >
@edk2.groups.io;
> Yao, Jiewen
> Cc: Alex Williamson ;
> devel@edk2.groups.io; qemu devel list de...@nongnu.org>; Igor Mammedov ;
> Chen, Yingwen ; Nakajima, Jun
> ; Boris Ostrovsky
> ; Joao Marcal Lemos Martins
> ; Phillip Goerl
>
> Subject: Re: [edk2-rfc] [edk2-
ject: Re: [edk2-rfc] [edk2-devel] CPU hotplug using
> SMM with QEMU+OVMF
>
> On 22/08/19 22:06, Kinney, Michael D wrote:
> > The SMBASE register is internal and cannot be directly
> accessed by any
> > CPU. There is an SMBASE field that is member of the
> SMM Save State
gt; Chen, Yingwen ; Nakajima, Jun
> ; Boris Ostrovsky
> ; Joao Marcal Lemos Martins
> ; Phillip Goerl
>
> Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug using
> SMM with QEMU+OVMF
>
> On 08/22/19 08:18, Paolo Bonzini wrote:
> > On 21/08/19 22:17, Kinney, Michael D w
gt;; Igor Mammedov ;
> Chen, Yingwen ; Nakajima, Jun
> ; Boris Ostrovsky
> ; Joao Marcal Lemos Martins
> ; Phillip Goerl
>
> Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug using
> SMM with QEMU+OVMF
>
> On 22/08/19 19:59, Laszlo Ersek wrote:
> > The firmware and QEMU
On 22/08/19 20:29, Laszlo Ersek wrote:
> On 08/22/19 08:18, Paolo Bonzini wrote:
>> On 21/08/19 22:17, Kinney, Michael D wrote:
>>> DMA protection of memory ranges is a chipset feature. For the current
>>> QEMU implementation, what ranges of memory are guaranteed to be
>>> protected from DMA? Is i
On 22/08/19 19:59, Laszlo Ersek wrote:
> The firmware and QEMU could agree on a formula, which would compute the
> CPU-specific SMBASE from a value pre-programmed by the firmware, and the
> initial APIC ID of the hot-added CPU.
>
> Yes, it would duplicate code -- the calculation -- between QEMU an
On 08/22/19 08:18, Paolo Bonzini wrote:
> On 21/08/19 22:17, Kinney, Michael D wrote:
>> Paolo,
>>
>> It makes sense to match real HW.
>
> Note that it'd also be fine to match some kind of official Intel
> specification even if no processor (currently?) supports it.
I agree, because...
>> That pu
On 08/21/19 19:05, Paolo Bonzini wrote:
> On 21/08/19 17:48, Kinney, Michael D wrote:
>> Perhaps there is a way to avoid the 3000:8000 startup
>> vector.
>>
>> If a CPU is added after a cold reset, it is already in a
>> different state because one of the active CPUs needs to
>> release it by intera
On 08/21/19 17:48, Kinney, Michael D wrote:
> Perhaps there is a way to avoid the 3000:8000 startup
> vector.
>
> If a CPU is added after a cold reset, it is already in a
> different state because one of the active CPUs needs to
> release it by interacting with the hot plug controller.
>
> Can the
On 21/08/19 22:17, Kinney, Michael D wrote:
> Paolo,
>
> It makes sense to match real HW.
Note that it'd also be fine to match some kind of official Intel
specification even if no processor (currently?) supports it.
> That puts us back to
> the reset vector and handling the initial SMI at
> 3000
On 21/08/19 19:25, Kinney, Michael D wrote:
> Could we have an initial SMBASE that is within TSEG.
>
> If we bring in hot plug CPUs one at a time, then initial
> SMBASE in TSEG can reprogram the SMBASE to the correct
> value for that CPU.
>
> Can we add a register to the hot plug controller that
@edk2.groups.io; Yao, Jiewen
> Cc: Alex Williamson ; Laszlo
> Ersek ; devel@edk2.groups.io; qemu
> devel list ; Igor Mammedov
> ; Chen, Yingwen
> ; Nakajima, Jun
> ; Boris Ostrovsky
> ; Joao Marcal Lemos Martins
> ; Phillip Goerl
>
> Subject: Re: [edk2-rfc] [edk2-
o
>> Ersek ; devel@edk2.groups.io; edk2-
>> rfc-groups-io ; qemu devel list
>> ; Igor Mammedov
>> ; Chen, Yingwen
>> ; Nakajima, Jun
>> ; Boris Ostrovsky
>> ; Joao Marcal Lemos Martins
>> ; Phillip Goerl
>>
>> Subject: Re: [edk2-rfc] [ed
oups.io; qemu
> devel list ; Igor Mammedov
> ; Chen, Yingwen
> ; Nakajima, Jun
> ; Boris Ostrovsky
> ; Joao Marcal Lemos Martins
> ; Phillip Goerl
>
> Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug using
> SMM with QEMU+OVMF
>
> On 21/08/19 17:48, Kinney, Michael
rovsky
> ; Joao Marcal Lemos Martins
> ; Phillip Goerl
>
> Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug using
> SMM with QEMU+OVMF
>
> in real world, we deprecate AB-seg usage because they
> are vulnerable to smm cache poison attack.
> I assume cache poison is out of s
On 08/19/19 16:10, Paolo Bonzini wrote:
> On 19/08/19 01:00, Yao, Jiewen wrote:
>> in real world, we deprecate AB-seg usage because they are vulnerable
>> to smm cache poison attack. I assume cache poison is out of scope in
>> the virtual world, or there is a way to prevent ABseg cache poison.
>
>
On 19/08/19 01:00, Yao, Jiewen wrote:
> in real world, we deprecate AB-seg usage because they are vulnerable
> to smm cache poison attack. I assume cache poison is out of scope in
> the virtual world, or there is a way to prevent ABseg cache poison.
Indeed the SMRR would not cover the A-seg on rea
On 17/08/19 02:20, Yao, Jiewen wrote:
> [Jiewen] That is OK. Then we MUST add the third adversary.
> -- Adversary: Simple hardware attacker, who can use device to perform DMA
> attack in the virtual world.
> NOTE: The DMA attack in the real world is out of scope. That is be handled by
> IOMMU in
> -Original Message-
> >>>> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> >>>> Sent: Friday, August 16, 2019 12:21 AM
> >>>> To: Laszlo Ersek ; devel@edk2.groups.io; Yao,
> >> Jiewen
> >>>>
> >>>> Cc: edk2-rfc-gro
in real world, we deprecate AB-seg usage because they are vulnerable to smm
cache poison attack.
I assume cache poison is out of scope in the virtual world, or there is a way
to prevent ABseg cache poison.
thank you!
Yao, Jiewen
> 在 2019年8月19日，上午3:50，Paolo Bonzini 写道：
>
>> On 17/08/19 02:20
en, Yingwen
> ; Nakajima, Jun ; Boris
> Ostrovsky ; Joao Marcal Lemos Martins
> ; Phillip Goerl
> Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
>
> On Fri, 16 Aug 2019 22:15:15 +0200
> Laszlo Ersek wrote:
>
> > +Alex (direct question at th
.groups.io
>> Cc: edk2-rfc-groups-io ; qemu devel list
>> ; Igor Mammedov ;
>> Chen, Yingwen ; Nakajima, Jun
>> ; Boris Ostrovsky ;
>> Joao Marcal Lemos Martins ; Phillip Goerl
>>
>> Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
>>
&g
On 08/15/19 18:21, Paolo Bonzini wrote:
> On 15/08/19 17:00, Laszlo Ersek wrote:
>> On 08/14/19 16:04, Paolo Bonzini wrote:
>>> On 14/08/19 15:20, Yao, Jiewen wrote:
> - Does this part require a new branch somewhere in the OVMF SEC code?
> How do we determine whether the CPU executing SEC
On 15/08/19 18:07, Igor Mammedov wrote:
> Looking at Q35 code and Seabios SMM relocation as example, if I see it
> right QEMU has:
> - SMRAM is aliased from DRAM at 0xa
> - and TSEG steals from the top of low RAM when configured
>
> Now problem is that default SMBASE at 0x3 isn't b
On 15/08/19 17:00, Laszlo Ersek wrote:
> On 08/14/19 16:04, Paolo Bonzini wrote:
>> On 14/08/19 15:20, Yao, Jiewen wrote:
- Does this part require a new branch somewhere in the OVMF SEC code?
How do we determine whether the CPU executing SEC is BSP or
hot-plugged AP?
>>> [Jiewen]
dk2-rfc-groups-io ; qemu devel list
>> ; Igor Mammedov ;
>> Chen, Yingwen ; Nakajima, Jun
>> ; Boris Ostrovsky ;
>> Joao Marcal Lemos Martins ; Phillip Goerl
>>
>> Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
>>
>> On 15/08/19 17:00
On Thu, 15 Aug 2019 18:24:53 +0200
Paolo Bonzini wrote:
> On 15/08/19 18:07, Igor Mammedov wrote:
> > Looking at Q35 code and Seabios SMM relocation as example, if I see it
> > right QEMU has:
> > - SMRAM is aliased from DRAM at 0xa
> > - and TSEG steals from the top of low RAM when c
Nakajima, Jun
> ; Boris Ostrovsky ;
> Joao Marcal Lemos Martins ; Phillip Goerl
>
> Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
>
> On 16/08/19 04:46, Yao, Jiewen wrote:
> > Comment below:
> >
> >
> >> -Original Message-
> >>
Yingwen ; Nakajima, Jun
> ; Boris Ostrovsky ;
> Joao Marcal Lemos Martins ; Phillip Goerl
>
> Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
>
> On 15/08/19 17:00, Laszlo Ersek wrote:
> > On 08/14/19 16:04, Paolo Bonzini wrote:
> >> On 14/08/19 15:20,
On Thu, 15 Aug 2019 17:00:16 +0200
Laszlo Ersek wrote:
> On 08/14/19 16:04, Paolo Bonzini wrote:
> > On 14/08/19 15:20, Yao, Jiewen wrote:
> >>> - Does this part require a new branch somewhere in the OVMF SEC code?
> >>> How do we determine whether the CPU executing SEC is BSP or
> >>> hot-pl
On 15/08/19 11:55, Yao, Jiewen wrote:
> Hi Paolo
> I am not sure what do you mean - "You do not need a reset vector ...".
> If so, where is the first instruction of the new CPU in the virtualization
> environment?
> Please help me understand that at first. Then we can continue the discussion.
The
On Wed, 14 Aug 2019 16:04:50 +0200
Paolo Bonzini wrote:
> On 14/08/19 15:20, Yao, Jiewen wrote:
> >> - Does this part require a new branch somewhere in the OVMF SEC code?
> >> How do we determine whether the CPU executing SEC is BSP or
> >> hot-plugged AP?
> > [Jiewen] I think this is blocked
On 08/14/19 16:04, Paolo Bonzini wrote:
> On 14/08/19 15:20, Yao, Jiewen wrote:
>>> - Does this part require a new branch somewhere in the OVMF SEC code?
>>> How do we determine whether the CPU executing SEC is BSP or
>>> hot-plugged AP?
>> [Jiewen] I think this is blocked from hardware perspec
Hi Paolo
I am not sure what do you mean - "You do not need a reset vector ...".
If so, where is the first instruction of the new CPU in the virtualization
environment?
Please help me understand that at first. Then we can continue the discussion.
Thank you
Yao Jiewen
> -Original Message-
On 14/08/19 15:20, Yao, Jiewen wrote:
>> - Does this part require a new branch somewhere in the OVMF SEC code?
>> How do we determine whether the CPU executing SEC is BSP or
>> hot-plugged AP?
> [Jiewen] I think this is blocked from hardware perspective, since the first
> instruction.
> There
My comments below.
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, August 14, 2019 12:09 AM
> To: edk2-devel-groups-io
> Cc: edk2-rfc-groups-io ; qemu devel list
> ; Igor Mammedov ;
> Paolo Bonzini ; Yao, Jiewen
> ; Chen, Yingwen ;
> Nakajima, Jun ;
On 08/13/19 18:09, Laszlo Ersek wrote:
> On 08/13/19 16:16, Laszlo Ersek wrote:
>> (06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMM
>> rebase code.
>>
>> (07) Host CPU: (SMM) Send message to New CPU to Enable SMI.
>
> Aha, so this is the SMM-only register you mention in step
On 08/13/19 16:16, Laszlo Ersek wrote:
> Yingwen and Jiewen suggested the following process.
>
> Legend:
>
> - "New CPU": CPU being hot-added
> - "Host CPU": existing CPU
> - (Flash):code running from flash
> - (SMM): code running from SMRAM
>
> Steps:
>
> (01) New CPU: (Flash) enter res
Hi,
this message is a problem statement, and an initial recommendation for
solving it, from Jiewen, Paolo, Yingwen, and others. I'm cross-posting
the thread starter to the ,
and lists. Please use "Reply All" when
commenting.
In response to the initial posting, I plan to ask a number of question
62 matches
Mail list logo
