Re: [edk2-discuss] Load Option passing. Either bugs or my confusion.

[Laszlo Ersek]

On 04/17/20 05:22, Hou Qiming wrote:
> I'm glad we can reach a consensus that ramfb needs sanity checks. And well,
> I'm probably at fault with the hijacking.
> 
> Your QEMU/TCG in QEMU/TCG example also made me realize a deeper problem,
> though: your setting still can't escape the host display / physical GPU
> issue. The middle display layers be bochs or whatever, but as long as the
> framebuffer content and resolution values are propagated, and the end
> result is displayed at all on the host, the host GPU attack surface remains
> exposed to the L2 guest, and checks are needed. Everything shown on the
> screen involves the display driver - GPU stack, GTK or SDL or tty, you
> can't avoid that. ramfb-kvmgt just happened to be the shortest pipeline
> where every stage neglected the checks, which exposed this problem.

Good point.

> Blaming
> this on ramfb is unfair since in your scenario the checks are better done
> in the display subsystems.
> 
> TL;DR You made me realize right now, it's a very real risk that an AARCH64
> Windows guest could exploit a x64 host's display driver by specifying a
> crafted framebuffer with overflowing resolution. I don't want to break it,
> but I'd prefer a broken state over an insecure state.
> 
> I'm not quite sure what this thread is. But I think with the scope this
> discussion is going, maybe it's more of a bug than a regression.

All display devices (frontends) emulated by QEMU have to set bounds for
the permissible resolutions, for the guest. And those limits must never
break the capabilities of the display backends. So this is not a new
problem. How is it handled with other frontends? Like bochs-display, for
example -- I assume bochs-display too is purely virtual, i.e. the
resolution is fully controller (between bounds) by the guest. How is the
guest currently prevented from setting a bochs-display resolution that
"breaks SDL" (whatever that means)?

I'm inclined to agree that we're just seeing two sides of the same bug
-- the first state was too lax, and the current state is too strict.

Thanks
Laszlo