On Thu, Jan 5, 2023 at 5:02 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > None of what you ask for is for any kind of real security, it's all > just crazy "but I want to feel the warm and fuzzies and take shortcuts > elsewhere, and push my pain onto other people". Actually, let me maybe soften that a bit and say that it's "convenience features". It might make some things more _convenient_ to do, exactly because it might allow other parts to do short-cuts. But because it's a convenience-feature, it had also better either be (a) really easy and clear to do in the kernel and (b) have sufficiently *wide* convenience so that it doesn't end up being one of those "corner case things we have to maintain forever and nobody uses". And I think VM_DROPPABLE matches (a), and would be fine if it had some other non-made-up use (although honestly, we should solve the 32-bit problem first - ignoring it isn't fine for anything that is supposed to be widely useful). We *have* talked about features kind of like it before, for people doing basically caches in user space that they can re-create on demand and are ok with just going away under memory pressure. But those people almost invariably want dropped pages to cause a SIGSEGV or SIGBUS, not to come back as zeroes. So you were insulting when you said kernel people don't care about security issues. And I'm just telling you that's not true, but it *is* 100% true that kernel people are often really fed up with security people who have their blinders on, focus on some small thing, and think nothing else ever matters. So yes, the way to get something like VM_DROPPABLE accepted is to remove the blinders, and have it be something more widely useful, and not be a "for made up bad code". Side note: making the 32-bit issue go away is likely trivial. We can make 'vm_flags' be 64-bit, and a patch for that has been floating around for over a decade: https://lore.kernel.org/all/20110412151116.B50D.A69D9226@xxxxxxxxxxxxxx/ but there was enough push-back on that patch that I didn't want to take it, and some of the arguments for it were not that convincing (at the time). But see commit ca16d140af91 ("mm: don't access vm_flags as 'int'"), which happened as a result, and which I (obviously very naively) believed would be a way to get the conversion to happen in a more controlled manner. Sadly, it never actually took off, and we have very few "vm_flags_t" users in the kernel, and a lot of "unsigned long flags". We even started out with a "__nocast" annotation to try to make sparse trigger on people who didn't use vm_flags_t properly. That was removed due to it just never happening. But converting things to vm_flags_t with a coccinelle script (hand-wave: look for variables of of "unsigned long" that use the VM_xyz constants), and then just making vm_flags_t be a "u64" instead sounds like a way forward. But again: this is all about new flags like VM_DROPPABLE not being some corner-case that nobody is expected to use other than some special code that is relegated to 64-bit only because it is *so* special. Linus
