Messages in this thread | | | Date | Wed, 16 Aug 2023 08:12:56 -0700 | From | Dan Williams <> | Subject | Re: [PATCH v2 2/5] tsm: Introduce a shared ABI for attestation reports |
| |
Tom Lendacky wrote: > > +static ssize_t privlevel_store(struct device *dev, > > + struct device_attribute *attr, const char *buf, > > + size_t len) > > +{ > > + unsigned int val; > > + int rc; > > + > > + rc = kstrtouint(buf, 0, &val); > > + if (rc) > > + return rc; > > + > > + guard(rwsem_write)(&tsm_rwsem); > > + if (tsm_report.desc.privlevel == val) > > + return len; > > + tsm_report.desc.privlevel = val; > > + tsm_report.write_generation++; > > So I'm wondering if this use of write_generation helps or not. Since it > isn't incremented if the levels are the same, that might present race > conditions. > > What if user A requests vmpl 2 and privlevel is already 2, then > write_generation is not incremented. But before user A can read back the > generation value user B can request vmpl 3 and cause write_generation to > be incremented. > > This may not be a problem for VMPL, since that can be checked in the > returned attestation report, but it could be for the report format. If the > extended format is requested but changed to default, then the additional > certs might not be returned and the guest may think there aren't any...? > > Maybe incrementing the write_generation no matter what is best.
True, and good eye. If write_generation does not always increment once per write there is no way to assume the state of the parameters. Will fix.
| |