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
| ||
|
Date: Mon, 26 Mar 2018 19:27:18 -0700 From: Ram Pai <linuxram@...ibm.com> To: Dave Hansen <dave.hansen@...ux.intel.com> Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org, tglx@...utronix.de, dave.hansen@...el.com, mpe@...erman.id.au, mingo@...nel.org, akpm@...ux-foundation.org, shuah@...nel.org Subject: Re: [PATCH 1/9] x86, pkeys: do not special case protection key 0 On Fri, Mar 23, 2018 at 11:09:05AM -0700, Dave Hansen wrote: > > From: Dave Hansen <dave.hansen@...ux.intel.com> > > mm_pkey_is_allocated() treats pkey 0 as unallocated. That is > inconsistent with the manpages, and also inconsistent with > mm->context.pkey_allocation_map. Stop special casing it and only > disallow values that are actually bad (< 0). > > The end-user visible effect of this is that you can now use > mprotect_pkey() to set pkey=0. > > This is a bit nicer than what Ram proposed because it is simpler > and removes special-casing for pkey 0. On the other hand, it does > allow applciations to pkey_free() pkey-0, but that's just a silly > thing to do, so we are not going to protect against it. The more I think about this, the more I feel we are opening up a can of worms. I am ok with a bad application, shooting itself in its feet. But I am worried about all the bug reports and support requests we will encounter when applications inadvertently shoot themselves and blame it on the kernel. a warning in dmesg logs indicating a free-of-pkey-0 can help deflect the blame from the kernel. RP
Powered by blists - more mailing lists