linux-kernel - Re: [RFC v2 0/7] mm/damon: extend for page faults reporting based access monitoring

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251207045257.47035-1-sj@kernel.org>
Date: Sat,  6 Dec 2025 20:52:56 -0800
From: SeongJae Park <sj@...nel.org>
To: SeongJae Park <sj@...nel.org>
Cc: "Liam R. Howlett" <Liam.Howlett@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Hildenbrand <david@...hat.com>,
	Jann Horn <jannh@...gle.com>,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	Michal Hocko <mhocko@...e.com>,
	Mike Rapoport <rppt@...nel.org>,
	Pedro Falcato <pfalcato@...e.de>,
	Suren Baghdasaryan <surenb@...gle.com>,
	Vlastimil Babka <vbabka@...e.cz>,
	damon@...ts.linux.dev,
	kernel-team@...a.com,
	linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [RFC v2 0/7] mm/damon: extend for page faults reporting based access monitoring

On Sun, 27 Jul 2025 13:18:06 -0700 SeongJae Park <sj@...nel.org> wrote:

> TL; DR: Extend DAMON interface between core and operation sets for
> operation set driven report-based monitoring such as per-CPU and
> write-only access monitoring.  Further introduce an example physical
> address space monitoring operation set that uses page faults as the
> source of the information.
[...]
> Core Layer Changes for Reporting-based Monitoring
> -------------------------------------------------
> 
> Optimize such possible duplicated efforts, by updating DAMON core layer
> to support real time access reporting.  The updated interface allows
> operations set implementations to report (or, push) their information to
> the core layer, on their preferred schedule.  DAMON core layer will
> handle the reports by managing meta data and updating the final
> monitoring results (DAMON regions) accordingly.
> 
> Also add another operations set callback to determine if a given access
> report is eligible to be used for a given operations set.  For example,
> if the operations set implementation is for monitoring only specific CPU
> or writes, the operations set could ask the core layer to ignore
> reported accesses that were made by other CPUs, or were made for reads.
> 
> paddr_fault: Page Faults-based Physical Address Space Access Monitoring
> -----------------------------------------------------------------------
> 
> Using the core layer changes, implement a new DAMON operation set,
> namely paddr_fault.  It is the same as the page table Accessed bits
> based physical address space monitoring, but uses page faults as the
> source of the access information.
> 
> Specifically, it installs PAGE_NONE protection to access sampling pages
> on damon_operations->prepare_access_checks() callback.  Then, it
> captures the following access to the page in the page fault handling
> context, and directly reports the findings to DAMON, using
> damon_report_access().

I was going in this direction because obviously the protection installing is
obviously what operation set layer should do.  But, damon_report_access()
handling is on the core layer.  For followup extension for
per-CPUs/threads/read/write monitoring, we need to filtr in/out the page fault
information, but that's not only for page fault but general access check
sampling results.  And therefore it makes more sense to be done in core layer.

Also this approach is unnecessarily increasing the number of operation set.  It
is also restricting such advanced monitoring to specific operation set.

So I changed my mind to add a control data structure on the core layer.  It
will let API callers specify what access check primitives (or, sources) should
be used, and what access information should be filtered in/out.


Thanks,
SJ

[...]