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.
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
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
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
&
On 16/08/19 04:46, Yao, Jiewen wrote:
> Comment below:
>
>
>> -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: e
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
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
tforms plan to do,
if anything.
Paolo
> Mike
>
>> -Original Message-
>> From: r...@edk2.groups.io [mailto:r...@edk2.groups.io] On
>> Behalf Of Yao, Jiewen
>> Sent: Sunday, August 18, 2019 4:01 PM
>> To: Paolo Bonzini
>> Cc: Alex Williamson ; Laszlo
>
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
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
>
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 t
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
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
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
On 20/09/19 11:28, Laszlo Ersek wrote:
>> On QEMU side, we can drop black-hole approach and allocate
>> dedicated SMRAM region, which explicitly gets mapped into
>> RAM address space and after SMI hanlder initialization, gets
>> unmapped (locked). So that SMRAM would be accessible only
>> from
On 07/11/19 12:55, Daniel P. Berrangé wrote:
>> Yes, I would make SMM use a cryptographic pseudo-random number generator
>> and seed it from virtio-rng from DXE, way before the OS starts and can
>> "attack" it.
>>
>> Once you've gotten a seed, you can create a CSPRNG with a stream cipher
>>
On 07/11/19 12:52, Daniel P. Berrangé wrote:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bb5530e4082446aac3a3d69780cd4dbfa4520013
>
> Is it practical to provide a jitter entropy source for EDK2
> too ?
The hard part is not collecting jitter (though the
On 07/11/19 11:25, Ard Biesheuvel wrote:
>> This looks problematic on QEMU. Entropy is a valuable resource, and
>> whatever resource SMM drivers depend on, should not be possible for e.g.
>> a 3rd party UEFI driver (or even for the runtime OS) to exhaust.
>> Therefore, it's not *only* the case
On 07/11/19 14:27, Laszlo Ersek wrote:
> The VirtioRngDxe driver is a UEFI driver that follows the UEFI driver
> model. Meaning (in this context), it is connected to the virtio-rng
> device in the BDS phase, by platform BDS code.
>
> Put differently, the non-privileged driver that's the source of
ch in time for the next
> stable tag (edk2-stable202008).
For what it's worth "correct" means that I don't see anything that could
break and in fact I find it good policy hygienic not to allow recursive
interrupts.
v1 is okay for me too, so:
Reviewed-by: Paolo Bonzini
Paolo
-
On 16/06/20 20:42, Laszlo Ersek wrote:
> (Hmmm... maybe the hypervisor *has* to queue the timer interrupts,
> otherwise some of them would simply be lost, and the guest would lose
> track of time.)
Yes, there are various kinds of coalescing of interrupts that
hypervisors perform to help the guest
On 09/06/21 16:28, James Bottomley wrote:
That would cut across the ApEntrypoint and the guidedStructureEnd.
However, nothing says anything in the reset vector guided structure has
to be data ... so it could equally well be code. That means we can do
guid based entries that contain the 32 bit
Hi Tobin,
as mentioned in the reply to the QEMU patches posted by Tobin, I think the
firmware helper approach is very good, but there are some disadvantages in the
idea of auxiliary vCPUs. These are especially true in the VMM, where it's much
nicer to have a separate VM that goes through a
On 23/02/21 18:06, Laszlo Ersek wrote:
On 02/23/21 08:45, Paolo Bonzini wrote:
On 22/02/21 15:53, Laszlo Ersek wrote:
+
+ if (mCpuHotEjectData != NULL) {
+ CPU_HOT_EJECT_HANDLER Handler;
+
+ Handler = mCpuHotEjectData->Handler;
This patch looks otherwise OK to me, but:
In patch v8
On 22/02/21 15:53, Laszlo Ersek wrote:
+
+ if (mCpuHotEjectData != NULL) {
+CPU_HOT_EJECT_HANDLER Handler;
+
+Handler = mCpuHotEjectData->Handler;
This patch looks otherwise OK to me, but:
In patch v8 08/10, we have a ReleaseMemoryFence(). (For now, it is only
expressed as a
On 04/03/21 21:45, Laszlo Ersek wrote:
On 03/04/21 10:21, Paolo Bonzini wrote:
Hi Tobin,
as mentioned in the reply to the QEMU patches posted by Tobin, I
think the firmware helper approach is very good, but there are some
disadvantages in the idea of auxiliary vCPUs. These are especially
true
On 15/04/21 01:34, Erdem Aktas wrote:
We do not want to generate different binaries for AMD, Intel, Intel
with TDX, AMD with SEV/SNP etc
My question is why the user would want a single binary for VMs with and
without TDX/SNP. I know there is attestation, but why would you even
want the
On Tue, Oct 31, 2023 at 10:16 AM Attar, AbdulLateef (Abdul Lateef)
wrote:
>
> [Public]
>
> +Laszlo, +Gerd, +Paolo
> PR: https://github.com/tianocore/edk2/pull/4982
I left a comment in the PR.
The patch is only correct if this code is only ever used on 64-bit
processors. Note that KVM uses the
On 2/22/24 16:44, Tom Lendacky wrote:
On 2/22/24 05:24, Gerd Hoffmann wrote:
Hi,
+ if (Cr4.Bits.LA57) {
+ if (PhysBits > 48) {
+ /*
+ * Some Intel CPUs support 5-level paging, have more than 48
+ * phys-bits but support only 4-level EPT, which effectively
+
On Thu, Feb 22, 2024 at 5:13 PM Paolo Bonzini wrote:
> Also, to clarify the hardware behavior, if hCR4.LA57=0 and host
> PhysAddrSize==52, then will guest physical addresses above 2^48
>
> 1) cause a reserved #PF in the guest, or
>
> 2) cause a non-present NPF exit in the
messages sent to this group.
View/Reply Online (#116224): https://edk2.groups.io/g/devel/message/116224
Mute This Topic: https://groups.io/mt/104642317/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
On Fri, Mar 1, 2024 at 10:27 AM Michael Brown wrote:
> > My version is attached, feel free to reuse it (either entirely or
> > partially) for a hypothetical v2. Apologies to you and Mike K for the
> > confusion!
>
> I much prefer this version of the patch, because the explanations are
> easier to
One fix is needed in the code.
On Thu, Feb 29, 2024 at 2:04 PM Ray Ni wrote:
> + //
> + // Save the "Interrupted TPL" (TPL that was interrupted).
> + //
> + mInterruptedTplMask |= (UINTN)(1 << gEfiCurrentTpl);
> +}
>}
> + //
> + // Clear interrupted TPL
42317/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
From 23c4f60cf79f29ab5eff55a02c72bb504804d02a Mon Sep 17 00:00:00 2001
From: Paolo Bonzini
Date: Thu, 29 Feb 2024 23:54:50 +0100
Subject: [PATCH 1/
Il ven 1 mar 2024, 12:10 Michael Brown ha scritto:
> It feels as though this should be able to be cleanly modelled with a
> single global state array
>
>BOOLEAN mSavedInterruptState[TPL_HIGH_LEVEL]
>
Pretty much, yes. But you only have to write it when the interrupts are
already disabled,
signaled on the next timer tick" (in the description of gBS->SetTimer)
Paolo
> Thanks,
>
> Mike
>
> > -Original Message-
> > From: Michael Brown
> > Sent: Thursday, February 29, 2024 5:23 AM
> > To: devel@edk2.groups.io; Ni, Ray
> &
On 2/29/24 20:22, Michael Brown wrote:
The design of NestedInterruptTplLib is that each nested interrupt must increase
the TPL, but if I understand correctly there is a hole here:
//
// Call RestoreTPL() to allow event notifications to be
// dispatched. This will implicitly re-enable
On 2/29/24 14:02, Ray Ni wrote:
In the end, it will lower the TPL to TPL_APPLICATION with interrupt enabled.
However, it's possible that another timer interrupt happens just in the end
of RestoreTPL() function when TPL is TPL_APPLICATION.
How do non-OVMF platforms solve the issue? Do they
On 2/29/24 20:16, Kinney, Michael D wrote:
-Original Message-
From: Paolo Bonzini
Sent: Thursday, February 29, 2024 11:04 AM
To: Ni, Ray ; devel@edk2.groups.io
Cc: Kinney, Michael D ; Liming Gao
; Laszlo Ersek ; Michael
Brown
Subject: Re: [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack
On Mon, Mar 4, 2024 at 6:24 PM Tom Lendacky wrote:
>
> On 3/4/24 07:09, Gerd Hoffmann wrote:
> >Hi,
> >
> >>> 23:16 GuestPhysAddrSize Maximum guest physical address size in bits.
> >>> This number applies only to guests using
> >>> nested
> >>>
40 matches
Mail list logo
