On 08/04/22 15:16, Laszlo Ersek wrote: > On 08/04/22 14:47, Jason A. Donenfeld wrote: >> On Thu, Aug 4, 2022 at 2:11 PM Jason A. Donenfeld <ja...@zx2c4.com> 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.
Reference: https://github.com/tianocore/edk2/commit/ad43bc6b2e > > 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. > > Laszlo >
