> > Is there any check anywhere that prevents a malicious guest to keep > writing host data and write past the vram area? I think the dst checks in > ati_2d_do_blt inherited from ati_2d_blt would probably catch that but is > there anything we can check here to prevent getting there? Like stopping > host data after the dst region ends and then ignoring further HOST_DATA > register writes which is probably what the real chip does too. Also what > happens if a guest just writes HOST_DATA without starting a blit first. Do > we end up here with nonsense values or is that prevented somewhere. I > think we need to check somewhere if there's an ongoing host data blt > before trying to use that data. Maybe it's there already somewhere but > I've missed it. >
I did a deeper investigation on this and you're right the hardware seems to set an "active" flag for the blit. When the blit isn't active HOST_DATA writes are ignored. This will be addressed in v9. Writing beyond VRAM I believe was already handled by a comparison of the current row against the dst height and as you said eventually the dst checks in ati_2d_do_blt. But the active flag also makes sure these sorts of writes are ignored when a blit isn't in progress, which wasn't the case before. But I did learn something new while looking into early writes to host_data_last and how that affects engine state. I learned that the accumulator is actually 256-bits flushed every 128-bits. It initially looked like an early end of the blit was just drawing garbage or uninitialized memory to the framebuffer but by chance I tried out some wider blits and noticed a repeating pattern at 256-bits. If ended early it just cycles through whatever is in the accumulator to finish off the blit! So that change will also be in v9.
