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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <FA6429E0-C480-47AA-AAF0-95E615D8265B@amacapital.net>
Date:   Fri, 26 Oct 2018 15:12:17 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     Daniel Micay <danielmicay@...il.com>
Cc:     Dave Hansen <dave.hansen@...el.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        kernel list <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H . Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Will Deacon <will.deacon@....com>,
        Andy Lutomirski <luto@...nel.org>, jroedel@...e.de
Subject: Re: [PATCH 1/2] x86/pkeys: copy pkey state at fork()



> On Oct 26, 2018, at 2:39 PM, Daniel Micay <danielmicay@...il.com> wrote:
> 
> I ended up working around this with a pthread_atfork handler disabling
> my usage of the feature in the child process for the time being. I
> don't have an easy way to detect if the bug is present within a
> library so

Can you not just make sure that the fix is backported to all relevant kernels?

I suppose we could add a new flag for pkey_get() or something.

> I'm going to need a kernel version check with a table of
> kernel releases fixing the problem for each stable branch.

That won’t work right on district kernels. Please don’t go there.

> 
> It would be helpful if there was a new cpuinfo flag to check if the
> MPK state is preserved on fork in addition to the existing ospke flag.
> The problem will fade away over time but in my experience there are a
> lot of people using distributions with kernels not incorporating all
> of the stable fixes. I expect other people will run into the problem
> once hardware with MPK is more widely available and other people try
> to use it for various things like moving GC or assorted security
> features. Someone will end up running software adopting it on an older
> kernel with the problem.
> 
> The clobbering issue I found with MAP_FIXED_NOREPLACE isn't quite
> as annoying because it was easy to make a runtime test usable in a library
> to see if the feature works properly.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ