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 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 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 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
On Sat, 24 Aug 2019 01:48:09 +
"Yao, Jiewen" wrote:
> I give my thought.
> Paolo may add more.
Here are some ideas I have on the topic.
>
> > -Original Message-
> > From: Kinney, Michael D
> > Sent: Friday, August 23, 2019 11:25 PM
> > To: Yao, Jiewen ; Paolo Bonzini
> > ; Laszlo Er
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
I give my thought.
Paolo may add more.
> -Original Message-
> From: Kinney, Michael D
> Sent: Friday, August 23, 2019 11:25 PM
> To: Yao, Jiewen ; Paolo Bonzini
> ; Laszlo Ersek ;
> r...@edk2.groups.io; Kinney, Michael D
> Cc: Alex Williamson ; de...@edk2.groups.io;
> qemu devel list ; Ig
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.
For this OVMF use case, is any CPU init required
before the first SMI?
From Paolo's list of steps ar
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
Thank you Mike!
That is good reference on the real hardware behavior. (Glad it is public.)
For threat model, the unique part in virtual environment is temp RAM.
The temp RAM in real platform is per CPU cache, while the temp RAM in virtual
platform is global memory.
That brings one more potential
Paolo,
I find the following links related to the discussions here
along with one example feature called GENPROTRANGE.
https://csrc.nist.gov/CSRC/media/Presentations/The-Whole-is-Greater/images-media/day1_trusted-computing_200-250.pdf
https://cansecwest.com/slides/2017/CSW2017_Cuauhtemoc-Rene_CPU_
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
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.
Can we add a chipset feature to prevent DMA to 64KB range fr
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
Laszlo,
I believe all the code for the AP startup vector
is already in edk2.
It is a combination of the reset vector code in
UefiCpuPkg/ResetVecor/Vtf0 and an IA32/X64 specific
feature in the GenFv tool. It sets up a 4KB aligned
location near 4GB which can be used to start an AP
using INIT-SIPI-
Paolo,
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 SMBASE register to
be updated from the current
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
Paolo,
It makes sense to match real HW. That puts us back to
the reset vector and handling the initial SMI at
3000:8000. That is all workable from a FW implementation
perspective. It look like the only issue left is DMA.
DMA protection of memory ranges is a chipset feature.
For the current QEM
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
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 interacting with the hot plug controller.
>
> Can th
36 matches
Mail list logo
