Jan Kiszka wrote: > Jamie Lokier wrote: >> Jan Kiszka wrote: >>> While IO_MEM_ROMD marks an I/O memory region as "read/execute from RAM, >>> but write to I/O handler", there is no flag indicating that an I/O >>> region which is fully managed by I/O handlers can still be hosting >>> executable code. One use case for this are flash device models that >>> switch to I/O mode during reprogramming. Not all reprogramming states >>> modify to read data, thus practically allow to continue execution. >>> Moreover, we need to avoid switching the modes too frequently for >>> performance reasons which requires fetching opcodes while still in I/O >>> device mode. >> I like this change. >> >> Does "fetching opcodes while still in I/O device mode" fetch opcodes >> from the RAM backing, or via the I/O read handlers? > > Via the latter. This is most "correct" in that broken guests that jump > to the ROM while it's in some critical write cycle will properly crash. > >> If the latter, I'm wondering how KVM would cope with that. > > I think it won't work without extending KVM to fetch - as a last resort > - also from I/O devices. Or we give up the "correctness" and keep the > RAM-base KVM slot for IO_MEM_EXEC regions. That should be solvable in a > transparent way in kvm_set_phys_mem.
Which, of course, would break CFI reads etc. for KVM guest. So this feature actually requires additional support by KVM to fetch code from I/O devices. Jan
signature.asc
Description: OpenPGP digital signature
