* [Qemu-devel] fw_cfg DMA security
@ 2015-10-23 6:27 Jordan Justen
2015-10-23 6:56 ` Gerd Hoffmann
0 siblings, 1 reply; 4+ messages in thread
From: Jordan Justen @ 2015-10-23 6:27 UTC (permalink / raw)
To: markmb, qemu-devel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] fw_cfg DMA security
2015-10-23 6:27 [Qemu-devel] fw_cfg DMA security Jordan Justen
@ 2015-10-23 6:56 ` Gerd Hoffmann
2015-10-23 7:29 ` Paolo Bonzini
2015-10-23 9:49 ` Marc Marí
0 siblings, 2 replies; 4+ messages in thread
From: Gerd Hoffmann @ 2015-10-23 6:56 UTC (permalink / raw)
To: Jordan Justen; +Cc: markmb, qemu-devel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] fw_cfg DMA security
2015-10-23 6:56 ` Gerd Hoffmann
@ 2015-10-23 7:29 ` Paolo Bonzini
2015-10-23 9:49 ` Marc Marí
1 sibling, 0 replies; 4+ messages in thread
From: Paolo Bonzini @ 2015-10-23 7:29 UTC (permalink / raw)
To: Gerd Hoffmann, Jordan Justen; +Cc: markmb, qemu-devel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] fw_cfg DMA security
2015-10-23 6:56 ` Gerd Hoffmann
2015-10-23 7:29 ` Paolo Bonzini
@ 2015-10-23 9:49 ` Marc Marí
1 sibling, 0 replies; 4+ messages in thread
From: Marc Marí @ 2015-10-23 9:49 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: Jordan Justen, qemu-devel
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
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-10-23 9:50 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-23 6:27 [Qemu-devel] fw_cfg DMA security Jordan Justen
2015-10-23 6:56 ` Gerd Hoffmann
2015-10-23 7:29 ` Paolo Bonzini
2015-10-23 9:49 ` Marc Marí
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.