linux-kernel - Re: [RFC PATCH v2 7/9] mm/damon/core: set damos_filter default allowance behavior based on installed filters

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: <20250228044845.37918-1-sj@kernel.org>
Date: Thu, 27 Feb 2025 20:48:45 -0800
From: SeongJae Park <sj@...nel.org>
To: SeongJae Park <sj@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	damon@...ts.linux.dev,
	kernel-team@...a.com,
	linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [RFC PATCH v2 7/9] mm/damon/core: set damos_filter default allowance behavior based on installed filters

On Wed, 26 Feb 2025 21:50:54 -0800 SeongJae Park <sj@...nel.org> wrote:

> On Wed, 26 Feb 2025 17:57:52 -0800 SeongJae Park <sj@...nel.org> wrote:
> 
> > Decide whether to allow or reject by default on core and opertions layer
> > handled filters evaluation stages.  It is decided as the opposite of the
> > last installed filter's behavior.  If there is no filter at all, allow
> > by default.  If there is any operations layer handled filters, core
> > layer's filtering stage sets allowing as the default behavior regardless
> > of the last filter of core layer-handling ones, since the last filter of
> > core layer handled filters in the case is not really the last filter of
> > the entire filtering stage.
> 
> This is not sufficient enough.  Even with this change, core-handled allow
> filters after core-handled reject filters are still meaningless.
> 
> If a region is matched to a core layer handled filter, the allow/reject
> decision should be respected while ignoring all remaining filters, regardless
> of on what layer those are handled.  It works in the way for reect filters,
> since core layer-rejected regions are not passed to the ops layer at all.  In
> case of allow filter, however, the region is passed to ops layer without the
> information about whether it has passed to the ops layer because it was
> allowed, or just not matched to any filter.  Hence, all ops filters can be
> applied to the region.
> 
> We can implement this missing part by storing the core layer filtering stage
> decision somewhere and let ops filter filtering stage repsect it.  Changes like
> attached diff at the end of this mail may work.  I will add such changes to
> next version of this patch series.

I now realize this is not a missing part of this improvement patch series, but
a sole fix for the allow filter behavior.  The current behavior is not matching
with the documented one, and this change will fix it.  I will post a patch for
this fix separately from this patch series.


Thanks,
SJ

[...]