On Wed, 2025-12-17 at 17:01 +0100, Roberto Sassu wrote: > On Wed, 2025-12-17 at 10:26 -0500, Mimi Zohar wrote: > > Hi Roberto, > > > > Thank you! Everything is working as designed. > > > > - Only public functions require kernel-doc comments, but other functions > > would > > benefit having a comment. > > > > - As I mentioned in response to Steven's patch, "After trimming the > > measurement > > list, existing verifiers, which walk the IMA measurement list, will > > obviously > > fail to match the PCRs. Breaking existing userspace applications is a > > problem > > and, unfortunately, requires yet another Kconfig option. It needs to be at > > least mentioned here in the patch description." > > Hi Mimi > > sure. > > > On Fri, 2025-12-12 at 18:19 +0100, Roberto Sassu wrote: > > > From: Roberto Sassu <[email protected]> > > > > > > Introduce the ability of staging the entire (or a portion of the) IMA > > > measurement list for deletion. Staging means moving the current content of > > > the measurement list to a separate location, and allowing users to read > > > and > > > delete it. This causes the measurement list to be atomically truncated > > > before new measurements can be added. > > > > This last sentence is the crux of your of your proposal. > > -> "quickly be atomically ... so ..." > > Ok. > > > I must be missing something. With the ability of trimming N records, it's > > unclear to me the benefit of staging the measurement list and requiring a > > separate deletion. The measurement list can be read before trimming without > > loosing any measurements. Like now, the entire measurement list could be > > moved > > to a staging area. Instead of freeing all of the records, only N records > > would > > be freed. Afterwards the remaining staged measurements (N+1) could be > > restored > > to the head of the measurement list. > > My hope is to avoid trimming based on N in the kernel, but rather offer > the same functionality on a user space service that simply gets all the > measurements it can from the kernel (with the stage all approach), and > exposes the desired measurements to requesting applications (based on N > or based on a PCR value, as Microsoft requested).
Agreed, the measurement list needs to be copied to userspace and saved. How userspace applications will access it needs to be defined and documented. I thought Microsoft backed away from trimming the measurement list based on a PCR value. At least basing it on a PCR value, is not implemented in the kernel. > > I think it was already mentioned earlier in the discussion. By reading > and trimming at two different times, there is a race window where two > separate remote attestation agents determine N on the current > measurements list and attempt to trim one after another with the same > N, but the latter attempts to do it on an already trimmed measurements > list. They could take the write lock for the read too to avoid that. Yes, I saw the problem in v1, when the second request wasn't rejected but was synchronized by a mutex. That should have been fixed in v2 with your locking changes. > > The stage all approach is not susceptible to this race window, because > it does not require a prior read before the operation. I'm not convinced of that, as any application with cap sysadmin can initiate a trim or trim & delete. At least at the moment, there's no way of limiting the trim/delete to a given application. Perhaps it could be limited based on SELinux labels. -- thanks, Mimi
