Stephen Checkoway <stephen.checko...@oberlin.edu> writes: >> On Feb 19, 2019, at 10:28, Markus Armbruster <arm...@redhat.com> wrote: >> >> My terminology might be confused... >> >> Let me backtrack a bit an explain my use case. On physical PCs, the >> single flash chip is commonly configured to have a read-only part and a >> read/write part. The read-only part holds UEFI code, and the read-write >> part holds its persistent state. >> >> Since our virtual flash chips lack this feature, our virtual PCs have >> *two* of them: one configured read-only, and one configured read/write. >> Cleaning that up would be nice. >> >> The comment "It does not implement software data protection as found in >> many real chips" in both pflash_cfi0*.c might be referring to this >> missing feature. > > I understand now, thank you for explaining. I noticed the comments about > software data protection in the code, but I didn't investigate. > >>From a quick look at <https://www.cypress.com/file/195291/download> Table 27 >>on page 8, I see there are at least 4 different protection modes. I think the >>most common one (based on my reading of a handful of data sheets for flash >>chips) is the high voltage one. Essentially, there are sector groups that can >>be locked/unlocked using high voltage. It seems easy enough to model this by >>configuring sectors as locked and refusing to erase or program them. > > Software command locking would probably involve implementing a few additional > commands. > > I'm not sure what the others are. > > Which locking method do you need?
László, Philippe, what would you prefer to work with in OVMF?
