Re: [Question] Testing environment regarding SMM driver

[poxyran <poxyrantab@gmail.com>]

Thanks Laszlo and Andrew for the answers, from what I can see, is not
possible to do what I meant but your answers gave me some ideas. Thanks
a lot.

BR,

poxyran


On 9/21/2018 4:05 PM, Laszlo Ersek wrote:
> On 09/21/18 20:15, poxyran wrote:
>> Hello again,
>>
>> my question is: is it possible to create a SMM driver that
>> installs/register a SMI handler (in order to call it from a usermode app
>> in the OS) and test it in the UEFI Shell or do I need to setup up a
>> dedicated machine with the SMM stack as described in official EDK II
>> documentation [1]?
>>
>> [1]
>>
>> https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt
> These questions are not "either/or", they are orthogonal.
>
> Normally, any pre-existent platform firmware will keep you, as a 3rd
> party UEFI developer, *out* of SMM. Doing otherwise would be a huge
> security hole. However, if you own the platform in question (meaning you
> can build and install the firmware to the platform), then you should be
> able to use whatever the SMM infrastructure has to offer. It does not
> matter whether you do this on a physical UEFI development platform, or
> in OVMF + QEMU/KVM. As long as you get sufficient access to the platform
> itself. I hope this answers Q1.
>
> Regarding the wiki article. I wrote that article mainly for developers
> with a Windows desktop background. That's why I recommend to set up a
> separate, headless Linux server. Because, running Linux as the host OS,
> you get to run OVMF on QEMU not just with software emulation (TCG) but
> with hardware virtualization (KVM). And the latter makes for a world of
> difference. If you work at a Windows shop, you can run virtualization
> clients (management tools) on your Windows desktop, and with them,
> connect to the Linux server for managing / running your firmware.
>
> If you already work on a Linux laptop, you should be able to run OVMF on
> QEMU/KVM using nothing but your laptop. In such cases, the libvirt
> client and server components, and QEMU, and the host kernel (KVM), and
> OVMF, build up the "virt stack" on a single machine.
>
> Whether you can do the *exact* things you want to do, within OVMF, I
> can't tell. I don't know what you mean to do. A good part of the edk2
> SMM stack is built into OVMF with SMM_REQUIRE, but (due to QEMU/KVM
> being a virtual platform), at least *some* artifacts of physical
> hardware will be necessarily missing. (Such as SMRR, movable LAPIC base,
> etc.) OVMF also does not include/provide a number of standardized SMM
> abstractions, such as EFI_PEI_SMM_COMMUNICATION_PPI. (That's by choice,
> BTW.)
>
> I vaguely recall that Ray used OVMF as a testbed for some SMM driver he
> was developing at some point. I think Ray was using Q35 because of that
> (i.e. SMM), and his use case also included CSM, and that's why he wrote
> commit db27e9f3d8f0 ("OvmfPkg/LegacyRegion: Support legacy region
> manipulation of Q35", 2016-03-15). But I could be totally imagining things.
>
> If you run
>
>   git log --reverse --grep=SMM -- OvmfPkg
>
> you'll get a good amount of documentation about OVMF's SMM support. The
> first large series was 8786ba4fe722..5e04f4b7e1a4, but things didn't
> stop with that, of course. The OvmfPkg/README file has some notes on SMM
> too.
>
> I think you should be able to imitate the variable driver split, for
> your use case. You can write a runtime DXE driver that exposes a custom
> protocol. You can write a UEFI app (to be started from the UEFI shell)
> that locates and calls this protocol. In the implementation of the new
> runtime protocol, you can use EFI_SMM_COMMUNICATION_PROTOCOL to send
> message buffers into SMM. (Actually you could do this directly in your
> UEFI app too.) I expect you should be able to write a DXE_SMM_DRIVER
> driver too that registered a hook for the message sent. I don't recall
> all the details off-hand, but it's very well specified in the Platform
> Init spec. I hope this helps with Q2.
>
> Thanks
> Laszlo