linux-kernel - Re: [PATCH linux-next] mm/madvise: allow KSM hints for process

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <54b67d6b-f600-1b9b-3d3f-e91b13d04c91@redhat.com>
Date:   Fri, 1 Jul 2022 14:39:24 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Michal Hocko <mhocko@...e.com>
Cc:     cgel.zte@...il.com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, vbabka@...e.cz, minchan@...nel.org,
        oleksandr@...hat.com, xu xin <xu.xin16@....com.cn>,
        Jann Horn <jannh@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH linux-next] mm/madvise: allow KSM hints for
 process_madvise

> I am not sure about exact details of the KSM implementation but if that
> is not a desirable behavior then it should be handled on the KSM level.
> The very sam thing can easily happen in a multithreaded (or in general
> multi-process with shared mm) environment as well.

I don't quite get what you mean.

>  
>>>> Further, if an app explicitly decides to disable KSM one some region, we
>>>> should not overwrite that.
>>>
>>> Well, the interface is rather spartan. You cannot really tell "disable
>>> KSM on some reqion". You can only tell "KSM can be applied to this
>>> region" and later change your mind. Maybe this is what you had in
>>> mind though.
>>
>> That's what I meant. The hugepage interface has different semantics and
>> you get three possible states:
>>
>> 1: yes please: MADV_HUGEPAGE
>> 2: don't care -- don't set anything
>> 3. please no: MADV_NOHUGEPAGE
>>
>> Currently for KSM we only have 1 and 2 internally I think (single
>> flag), because it didn't matter in the past ebcause there was no
>> force-enablement. One could convert it into all 3 states, changing the
>> semantics of MADV_UNMERGEABLE slightly from
>>
>>
>> 1: yes please: MADV_MERGEABLE
>> 2: don't care: MADV_UNMERGEABLE
>>
>> to
>>
>> 1: yes please: MADV_MERGEABLE
>> 2: don't care -- don't set anything
>> 3. please no: MADV_UNMERGEABLE
> 
> Are you saying that any remote handling of the KSM has to deal with a
> pre-existing semantic as well? Are we aware of any existing application
> that really uses MADV_UNMERGEABLE in a hope to disable KSM for any of
> its sensitive memory ranges? My understanding is that this is simply a
> on/off knob and a remote way to do the same is in line with the existing
> API.

"its sensitive memory ranges" that's exactly what I am concerned of.
There should be a toggle, and existing applciations will not be using it.

> 
> To be completely honest I do not really buy an argument that this might
> break something much more than the original application can do already.

How can you get a shared zeropage in a private mapping after a previous
write if not via KSM?

> Unless I am missing the ptrace check puts the bar rather high. Adversary
> with this level of access to the target application has already broken
> it. Or am I missing something?

I don't see what you mean.

-- 
Thanks,

David / dhildenb