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

[David Hildenbrand]

> 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