Paolo Bonzini <pbonz...@redhat.com> writes: > On 31/01/19 10:37, Markus Armbruster wrote: >>> >>>> Hmm, why is it okay to treat all pfl->cmd values the same when >>>> secure=on? >>> But doesn't matter. You just don't want MMIO mode to be active outside >>> SMM: all that non-SMM code want to do with the flash is read and execute >>> it, as far as they're concerned it's just ROM and the command mode is >>> nonexistent. >> Out of curiosity: what effect does secure=on have when the device is >> read-only (pflash_t member ro non-zero)? > > Non-SMM code cannot execute commands. This means two things: > > First, in addition to writes, there are nondestructive commands such as > read device id. Those are also inaccessible to non-SMM if secure=on. > Again, for non-SMM code it looks like your old ROM. This is not > important but... > > ... CFI commands, even commands that are nondestructive or writes that > fail because of readonly-ness, consist of multiple writes to the flash > device. If non-SMM code could issue a partial command, the SMM flash > driver would likely end up confused. Therefore it's probably a good > idea to make all parallel flash devices have secure=on even if the > content of the flash cannot be damaged, and that's why I never > considered anything but -global to configure the property.
Makes sense now, thanks!
