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
| ||
|
Message-ID: <53481.1697600240@cvs.openbsd.org> Date: Tue, 17 Oct 2023 21:37:20 -0600 From: "Theo de Raadt" <deraadt@...nbsd.org> To: Jeff Xu <jeffxu@...gle.com> cc: Linus Torvalds <torvalds@...ux-foundation.org>, jeffxu@...omium.org, akpm@...ux-foundation.org, keescook@...omium.org, sroettger@...gle.com, jorgelo@...omium.org, groeck@...omium.org, linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org, linux-mm@...ck.org, jannh@...gle.com, surenb@...gle.com, alex.sierra@....com, apopple@...dia.com, aneesh.kumar@...ux.ibm.com, axelrasmussen@...gle.com, ben@...adent.org.uk, catalin.marinas@....com, david@...hat.com, dwmw@...zon.co.uk, ying.huang@...el.com, hughd@...gle.com, joey.gouly@....com, corbet@....net, wangkefeng.wang@...wei.com, Liam.Howlett@...cle.com, lstoakes@...il.com, willy@...radead.org, mawupeng1@...wei.com, linmiaohe@...wei.com, namit@...are.com, peterx@...hat.com, peterz@...radead.org, ryan.roberts@....com, shr@...kernel.io, vbabka@...e.cz, xiujianfeng@...wei.com, yu.ma@...el.com, zhangpeng362@...wei.com, dave.hansen@...el.com, luto@...nel.org, linux-hardening@...r.kernel.org Subject: Re: [RFC PATCH v1 0/8] Introduce mseal() syscall Jeff Xu <jeffxu@...gle.com> wrote: > In linux cases, I think, eventually, mseal() will have a bigger scope than > BSD's mimmutable(). I don't believe that, considering noone needed this behaviour from the VM system in the last 4 decades. > VMA's metadata(vm_area_struct) contains a lot > of control info, depending on application's needs, mseal() can be > expanded to seal individual control info. > For example, in madvice(2) case: > As Jann point out in [1] and I quote: > "you'd probably also want to block destructive madvise() operations > that can effectively alter region contents by discarding pages and > such, ..." Then prohibit madvise(MADV_FREE) on all non-writeable mappings that are immutable. Just include this in the set of behaviours. Or make it the default. Don't make it an option that a program needs to set on pages! Noone is going to call it. Most programs don't know the addresses of the *REGIONS* they would want to do this for. Does your program know where libc's text segment starts and ends? No your program does not know these addresses, so the parts of the 'system' which do know this needs to do it (which would be ld.so or the libc init constructors). If madvise(MADV_FREE) is so dangerous.. say you have a program that would call through abort(), but you know a zero there can make the abort not abort but return, then is it bad to let the attacker do: madvise(&abort, pagesize, MADV_FREE) If that is bad, then block it in a smart way! Don't make a programmer of an application figure out how to do this. That results in a defense methodology where a handful of programs self-protect, but everything else is unprotected or unprotectable. That is shortsighted. > Another example: if an application wants to keep a memory always > present in RAM, for whatever the reason, it can call seal the mlock(). Please explain the attack surface. > I think I explained the logic of using bitmasks in the mseal() > interface clearly with the example of madvice() and mlock(). It is clear as mud.
Powered by blists - more mailing lists