Hi Laszlo, On Thu, Aug 4, 2022 at 3:17 PM Laszlo Ersek <lersek@xxxxxxxxxx> wrote: > > On 08/04/22 14:47, Jason A. Donenfeld wrote: > > On Thu, Aug 4, 2022 at 2:11 PM Jason A. Donenfeld <Jason@xxxxxxxxx> wrote: > >> > >> Hi Laszlo, > >> > >> On Thu, Aug 04, 2022 at 01:31:36PM +0200, Laszlo Ersek wrote: > >>> None of the existing info passing methods seem early enough, generic > >>> enough, and secure enough (at the same time)... > >> > >> Can you look at the v2 patch? It seems to work on every configuration I > >> throw at it. Keep in mind that setup_data is only used very, very early. > >> I can think of a few other places to put it too, looking at the x86 > >> memory map, that will survive long enough. > >> > >> I think this might actually be a straightforwardly solvable problem if > >> you think about it more basically. > > > > And just to put things in perspective here... We only need like 48 > > bytes or something at some easy fixed address. That's not much. That's > > *got* to be a fairly tractable problem. If v2 has issues, I can't see > > why there wouldn't be a different easy place to put a meger 48 bytes > > of stuff that then is allowed to be wiped out after early boot. > > I've looked at v2. It still relies on passing information from QEMU to > the guest kernel through guest RAM such that the whole firmware > execution takes place in-between, without the firmware knowing anything > about that particular area -- effectively treating it as free system > RAM. Such exceptions are time bombs. > > We *have* used hard-coded addresses, sometimes they are unavoidable, but > then they are open-coded in both QEMU and the firmware, and some early > part of the firmware takes care to either move the data to a "safe" > place, or to cover it in-place with a kind of reservation that prevents > other parts of the firmware from trampling over it. I've debugged > mistakes (memory corruption) when such reservation was forgotten; it's > not fun. > > In short, I have nothing against the QEMU patch, but then the current > OvmfPkg maintainers should accept a patch for the firmware too, for > protecting the area from later firmware components, as early as possible. What you say mostly makes sense. Though, I was wondering if there's some unused space (maybe a historical low address) that nothing touches because it's always been considered reserved. Some kind of ancient video data region, for example. We only need 48 bytes after all... My hope was that somebody with a lot of deep x86 knowledge would be able to smell their way to something that's always good like that. (Alternatively, there's my real_addr thing from v2.) Jason
