On Tue, Nov 14, 2023 at 1:58 PM Stefan Berger <stefanb@xxxxxxxxxxxxx> wrote: > On 11/14/23 13:36, Sush Shringarputale wrote: > > On 11/13/2023 10:59 AM, Stefan Berger wrote: > >> On 10/19/23 14:49, Tushar Sugandhi wrote: > >>> ======================================================================= > >>> | Introduction | > >>> ======================================================================= > >>> This document provides a detailed overview of the proposed Kernel > >>> feature IMA log snapshotting. It describes the motivation behind the > >>> proposal, the problem to be solved, a detailed solution design with > >>> examples, and describes the changes to be made in the clients/services > >>> which are part of remote-attestation system. This is the 2nd version > >>> of the proposal. The first version is present here[1]. > >>> > >>> Table of Contents: > >>> ------------------ > >>> A. Motivation and Background > >>> B. Goals and Non-Goals > >>> B.1 Goals > >>> B.2 Non-Goals > >>> C. Proposed Solution > >>> C.1 Solution Summary > >>> C.2 High-level Work-flow > >>> D. Detailed Design > >>> D.1 Snapshot Aggregate Event > >>> D.2 Snapshot Triggering Mechanism > >>> D.3 Choosing A Persistent Storage Location For Snapshots > >>> D.4 Remote-Attestation Client/Service-side Changes > >>> D.4.a Client-side Changes > >>> D.4.b Service-side Changes > >>> E. Example Walk-through > >>> F. Other Design Considerations > >>> G. References > >>> > >> > >> Userspace applications will have to know > >> a) where are the shard files? > > We describe the file storage location choices in section D.3, but user > > applications will have to query the well-known location described there. > >> b) how do I read the shard files while locking out the producer of the > >> shard files? > >> > >> IMO, this will require a well known config file and a locking method > >> (flock) so that user space applications can work together in this new > >> environment. The lock could be defined in the config file or just be > >> the config file itself. > > The flock is a good idea for co-ordination between UM clients. While > > the Kernel cannot enforce any access in this way, any UM process that > > is planning on triggering the snapshot mechanism should follow that > > protocol. We will ensure we document that as the best-practices in > > the patch series. > > It's more than 'best practices'. You need a well-known config file with > well-known config options in it. > > All clients that were previously just trying to read new bytes from the > IMA log cannot do this anymore in the presence of a log shard producer > but have to also learn that a new log shard has been produced so they > need to figure out the new position in the log where to read from. So > maybe a counter in a config file should indicate to the log readers that > a new log has been produced -- otherwise they would have to monitor all > the log shard files or the log shard file's size. If a counter is needed, I would suggest placing it somewhere other than the config file so that we can enforce limited write access to the config file. Regardless, I imagine there are a few ways one could synchronize various userspace applications such that they see a consistent view of the decomposed log state, and the good news is that the approach described here is opt-in from a userspace perspective. If the userspace does not fully support IMA log snapshotting then it never needs to trigger it and the system behaves as it does today; on the other hand, if the userspace has been updated it can make use of the new functionality to better manage the size of the IMA measurement log. -- paul-moore.com _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
