On Thu, 5 Sep 2019 15:08:31 +0200 Laszlo Ersek <ler...@redhat.com> wrote:
> On 09/04/19 11:52, Igor Mammedov wrote: > > > it could be stolen RAM + black hole like TSEG, assuming fw can live > > without RAM(0x30000+128K) range > > (in this case fwcfg interface would only work for locking down the range) > > > > or > > > > we can actually have a dedicated SMRAM (like in my earlier RFC), > > in this case FW can use RAM(0x30000+128K) when SMRAM isn't mapped into RAM > > address space > > (in this case fwcfg would be used to temporarily map SMRAM into normal RAM > > and unmap/lock > > after SMI relocation handler was initialized). > > > > If possible I'd prefer a simpler TSEG like variant. > > I think TSEG-like behavior is between these two. That is, I believe we > should have explicit open/close/lock operations. And, when the range is > closed (meaning, closed+unlocked, or closed+locked), then the black hole > should take effect for code that's not running in SMM. > > Put differently, its like the second choice, except the range never > appears as normal RAM. "When SMRAM isn't mapped into RAM address space", > then the address range shows "nothing" (black hole). I guess we at point where patch is better then words, I'll send one as reply here shortly. I've just implemented subset of above (opened, closed+locked). > Regarding "fw can live without RAM(0x30000+128K) range" -- do you mean > whether the firmware could use another RAM area for fw_cfg DMA? > > If that's the question, then I wouldn't worry about it. I'd remove the > 0x30000+128K range from the memory map, so the fw_cfg stuff (or anything > else) would never allocate memory from the range. It's much more > concerning to me however how the SMM infrastructure would deal with a > hole in the memory map right there. I didn't mean fwcfg in this context, what I meant if firmware were able to avoid using RAM(0x30000+128K) range (since it becomes unusable after locking). Looks like you just answered it here
