[Qemu-devel] fw_cfg DMA security

[Qemu-devel] fw_cfg DMA security

[Jordan Justen]

Back when I was looking at fw_cfg support for -kernel in OVMF, I noted
that it took a while to read the kernel. We improved the perf
substantially by using a 'rep insb' instruction, which I think kvm
special cases to minimize VM traps.

Nevertheless, I thought that it would be good to implement a DMA
interface to fw_cfg. It's great to see that Marc made that happen.

One complication I thought of was that it might be tricky to deal with
the implications of allowing this DMA to specify any old address to
fill with fw_cfg data.

So, for example, since Red Hat is working on SMM. Would a DMA to SMRAM
be protected?

I haven't watched the fw_cfg DMA discussion too closely, but has this
been thought about?

One idea I had was that near the end of the firmware boot, the
firmware could trigger fw_cfg in QEMU to stop supporting DMA until a
reset.

-Jordan

Re: [Qemu-devel] fw_cfg DMA security

[Gerd Hoffmann]

  Hi,

> One complication I thought of was that it might be tricky to deal with
> the implications of allowing this DMA to specify any old address to
> fill with fw_cfg data.
> 
> So, for example, since Red Hat is working on SMM. Would a DMA to SMRAM
> be protected?
> 
> I haven't watched the fw_cfg DMA discussion too closely, but has this
> been thought about?

Yes.  That problem isn't new and it isn't specific to fw_cfg.  You also
don't want grant dma access to smram/tseg to your ide/sata/scsi
controller or NIC.

> One idea I had was that near the end of the firmware boot, the
> firmware could trigger fw_cfg in QEMU to stop supporting DMA until a
> reset.

Should not be needed.  We have address spaces in qemu, and the
smram/tseg regions are explicitly excluded (when enabled) from dma-able
memory.

mark: when writing a fw_cfg_dma tests it is a good idea to add a
testcase for this, so make sure this works as intended and to avoid
security-sensitive regressions.

cheers,
  Gerd

Re: [Qemu-devel] fw_cfg DMA security

[Paolo Bonzini]

On 23/10/2015 08:56, Gerd Hoffmann wrote:
>> > 
>> > So, for example, since Red Hat is working on SMM. Would a DMA to SMRAM
>> > be protected?
>> > 
>> > I haven't watched the fw_cfg DMA discussion too closely, but has this
>> > been thought about?
> Yes.  That problem isn't new and it isn't specific to fw_cfg.  You also
> don't want grant dma access to smram/tseg to your ide/sata/scsi
> controller or NIC.
> 
> > One idea I had was that near the end of the firmware boot, the
> > firmware could trigger fw_cfg in QEMU to stop supporting DMA until a
> > reset.
> 
> Should not be needed.  We have address spaces in qemu, and the
> smram/tseg regions are explicitly excluded (when enabled) from dma-able
> memory.

Exactly.  SMRAM/TSEG is only added to CPU address spaces: for TCG, it's
enabled specifically when the processor enters SMM and disabled upon
RSM; for KVM, it's added to hypervisor address space 1, which is only
looked up for processors that are in SMM.

Paolo

Re: [Qemu-devel] fw_cfg DMA security

[Marc Marí]

On Fri, 23 Oct 2015 08:56:26 +0200
Gerd Hoffmann <kraxel@redhat.com> wrote:

>   Hi,
> 
> > One complication I thought of was that it might be tricky to deal
> > with the implications of allowing this DMA to specify any old
> > address to fill with fw_cfg data.
> > 
> > So, for example, since Red Hat is working on SMM. Would a DMA to
> > SMRAM be protected?
> > 
> > I haven't watched the fw_cfg DMA discussion too closely, but has
> > this been thought about?
> 
> Yes.  That problem isn't new and it isn't specific to fw_cfg.  You
> also don't want grant dma access to smram/tseg to your ide/sata/scsi
> controller or NIC.
> 
> > One idea I had was that near the end of the firmware boot, the
> > firmware could trigger fw_cfg in QEMU to stop supporting DMA until a
> > reset.
> 
> Should not be needed.  We have address spaces in qemu, and the
> smram/tseg regions are explicitly excluded (when enabled) from
> dma-able memory.
> 
> mark: when writing a fw_cfg_dma tests it is a good idea to add a
> testcase for this, so make sure this works as intended and to avoid
> security-sensitive regressions.

Noted, thanks

Marc

> cheers,
>   Gerd
> 
>