Re: [PATCH 2/2] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Clear C-bit when SEV is active

[Brijesh Singh <brijesh.singh@amd.com>]

Hi Laszlo,


On 02/27/2018 02:37 PM, Brijesh Singh wrote:
> Hi Laszlo,
> 
> 
> On 2/27/18 11:17 AM, Laszlo Ersek wrote:
>> Hi Brijesh,
>>
>> you provided a lot of information (and it seems like your analysis was
>> advancing in parallel with your email -- I too do that sometimes :) ),
>> so it's not easy for me to write a concise response.
>>
>> * Regarding the C-bit that covers the relocated save state area (esp.
>> considering that the area is not page aligned and/or contains executable
>> code):
>>
>> I think (a) adding any code (under OvmfPkg, or under the core) that sets
>> the C-bit "correctly", and in turn, (b) lacking any code in edk2 that
>> actually *exercises* the "correct" C-bit setting, is counter-productive.
>> Unless the C-bit is actively exercised, we're just adding *dead* code,
>> which is a bad thing -- it's very easy to regress (without anyone
>> noticing), and it leads to developer confusion.
>>
>> On the other hand, I wouldn't want your analysis to be lost (remember: I
>> asked for the explanation because I didn't understand the behavior). So
>> I'm thinking your analysis should be captured in both a commit message,
>> and a large comment *somewhere*. Possibly near the code (wherever it may
>> end up, AmdSevDxe or SmmCpuFeaturesLib) where you manage the C-bit for
>> the *initial* save state map.
>>
>> I mean, wherever you manage the C-bit for the initial save state map
>> (which is required), you can also make a large comment on the *future*
>> location and behavior.
>>
>> IMO it's OK if we don't guarantee the guest with functional access into
>> the relocated save state map -- there is no actual code relying on that!
>> -- as long as we document this gap.
>>
>> Does this suggestion make sense to you?
> 
> I am good with this approach. I will add my analysis detail in commit
> message and also put the similar thing in AmdSevDxe. In future if EDKII
> makes use to SmmSavedArea after the SMBASE relocation then we can
> revisit it.
> 
>>
>> * Regarding mapping all the NonExistent and MMIO GCD entries in the SMM
>> page table as plaintext: I think we should really be on par with
>> AmdSevDxe here. This is code that *will* be exercised, and if we cut
>> corners here, next time we add another MMIO range or device that needs
>> to be accessed from SMM too (for whatever reason), we'll go crazy otherwise.
> 
> Sounds good, I will make the necessary changes and send the update
> patch. thanks for your help.
> 


OK, I have been trying to implement this and its making things much 
harder than we thought. It seems SMM page table is very minimal and does 
not have PTEs for all those MMIO and NonExistent range. So, when we try 
to clear the C-bit on those range then I have no issue clearing the bits 
(it just cause more fault) but later in boot we get ASSERTs. I have seen 
all kind of assertion but the most of time I get below message

SMM exception at access (0x7FC01000)
It is invoked from the instruction before IP(0x7FFCB6EF) in module 
(/disk-part-1/upstream/edk2/Build/Ovmf3264/DEBUG_GCC5/X64/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm/DEBUG/PiSmmCpuDxeSmm.dll)

or Sometime SMM page table overlap assertion etc.

If we just do Flash range then have no issues. Do you want me to dig 
more deep on this or you are okay with my previous approach.


>>
>> * In general, regarding how and when SmmCpuFeaturesLib APIs are hooked
>> into PiSmmCpuDxeSmm: please ask questions -- and ask them to Mike :)
>> OVMF's instance of this lib class is Paolo's work (thanks again for
>> that!), so I always defer to Mike and Paolo whenever this lib class and
>> instance come up. SmmCpuFeaturesInitializeProcessor() looked suitable to
>> me, for implementing the previous bullet, but it's really just my
>> "shopping" for a good pre-existent hook point. If we need something
>> better, let's discuss it with Mike.
>>
>> I'm sorry if the above is a bit too vague; please post some new patches,
>> even if only RFCs :)
> 
> I think your explanation is very clear to me and I am in agreement. Let
> me work on patches.
> 
>>
>> Thanks!
>> Laszlo
>