linux-kernel - Re: [PATCH 4/4] add ksm kernel shared memory driver.

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]

Date:	Tue, 31 Mar 2009 10:54:57 -0500
From:	Anthony Liguori <anthony@...emonkey.ws>
To:	Andrea Arcangeli <aarcange@...hat.com>
CC:	Izik Eidus <ieidus@...hat.com>, linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org, linux-mm@...ck.org, avi@...hat.com,
	chrisw@...hat.com, riel@...hat.com, jeremy@...p.org,
	mtosatti@...hat.com, hugh@...itas.com, corbet@....net,
	yaniv@...hat.com, dmonakhov@...nvz.org
Subject: Re: [PATCH 4/4] add ksm kernel shared memory driver.

Andrea Arcangeli wrote:
> On Tue, Mar 31, 2009 at 10:09:24AM -0500, Anthony Liguori wrote:
>   
>> I don't think the registering of ram should be done via sysfs.  That would 
>> be a pretty bad interface IMHO.  But I do think the functionality that 
>> ksmctl provides along with the security issues I mentioned earlier really 
>> suggest that there ought to be a separate API for control vs. registration 
>> and that control API would make a lot of sense as a sysfs API.
>>
>> If you wanted to explore alternative APIs for registration, madvise() seems 
>> like the obvious candidate to me.
>>
>> madvise(start, size, MADV_SHARABLE) seems like a pretty obvious API to me.
>>     
>
> madvise to me would sound appropriate, only if ksm would be always-in,
> which is not the case as it won't even be built if it's configured to
> N.
>   

You can still disable ksm and simply return ENOSYS for the MADV_ flag.  
You could even keep it as a module if you liked by separating the 
madvise bits from the ksm bits.  The madvise() bits could just provide 
the tracking infrastructure for determine which vmas were currently 
marked as sharable.

You could then have ksm as loadable module that consumed that interface 
to then perform scanning.

> Besides madvise is sus covered syscall, and this is linux specific detail.
>   

A number of MADV_ flags are Linux specific (like MADV_DOFORK/MADV_DONTFORK).

Regards,

Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/