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, 23 Jun 2014 15:00:46 -0700 From: Andy Lutomirski <luto@...capital.net> To: Dave Hansen <dave.hansen@...el.com> Cc: "H. Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Qiaowei Ren <qiaowei.ren@...el.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...hat.com> Subject: Re: [PATCH v6 08/10] x86, mpx: add prctl commands PR_MPX_REGISTER, PR_MPX_UNREGISTER On Jun 23, 2014 1:09 PM, "Dave Hansen" <dave.hansen@...el.com> wrote: > > On 06/23/2014 01:00 PM, Andy Lutomirski wrote: > > On 06/18/2014 02:44 AM, Qiaowei Ren wrote: > >> > This patch adds the PR_MPX_REGISTER and PR_MPX_UNREGISTER prctl() > >> > commands. These commands can be used to register and unregister MPX > >> > related resource on the x86 platform. > >> > > >> > The base of the bounds directory is set into mm_struct during > >> > PR_MPX_REGISTER command execution. This member can be used to > >> > check whether one application is mpx enabled. > > The register and unregister operations seem to be almost the same thing. > > How about just PR_SYNC_MPX? > > That wouldn't support a usage model where userspace wanted to keep using > MPX, but wanted the kernel to butt out and not try to free unused bounds > tables. That's not super-important, but it does lose some level of > flexibility. > Hmm. How about PR_SET/GET_MPX_BOUNDS_TABLE, to update the kernel's copy. No fpu magic needed. This has an added benefit: CRIU will need updating for MPX, and they'll appreciate having the required interface already exist. (They'll want a way to allocate "MPX" memory, too, but that's probably somewhat less important, and it won't result in duplicated functionality.) > FWIW, I think it would also be handy to support a PR_MPX_DISABLE prctl > too. That way, a wrapper program could set a flag that any children > could notice if they try a PR_MPX_REGISTER. That way we could > software-disable MPX in cases in a process tree where it was not wanted. Seccomp can do this :) --Andy -- 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/
Powered by blists - more mailing lists