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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171219083122.q7ycxg2dfspgzw7z@lt-gp.iram.es>
Date:   Tue, 19 Dec 2017 09:31:22 +0100
From:   Gabriel Paubert <paubert@...m.es>
To:     Ram Pai <linuxram@...ibm.com>
Cc:     Dave Hansen <dave.hansen@...el.com>, linux-arch@...r.kernel.org,
        corbet@....net, arnd@...db.de, linux-doc@...r.kernel.org,
        x86@...nel.org, linux-kernel@...r.kernel.org, mhocko@...nel.org,
        linux-mm@...ck.org, mingo@...hat.com, paulus@...ba.org,
        ebiederm@...ssion.com, linux-kselftest@...r.kernel.org,
        bauerman@...ux.vnet.ibm.com, akpm@...ux-foundation.org,
        khandual@...ux.vnet.ibm.com, linuxppc-dev@...ts.ozlabs.org,
        aneesh.kumar@...ux.vnet.ibm.com
Subject: Re: [PATCH v9 29/51] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys:
 Add sysfs interface

On Mon, Dec 18, 2017 at 03:15:51PM -0800, Ram Pai wrote:
> On Mon, Dec 18, 2017 at 02:28:14PM -0800, Dave Hansen wrote:
> > On 12/18/2017 02:18 PM, Ram Pai wrote:
> > > b) minimum number of keys available to the application.
> > > 	if libraries consumes a few, they could provide a library
> > > 	interface to the application informing the number available to
> > > 	the application.  The library interface can leverage (b) to
> > > 	provide the information.
> > 
> > OK, let's see a real user of this including a few libraries.  Then we'll
> > put it in the kernel.
> > 
> > > c) types of disable-rights supported by keys.
> > > 	Helps the application to determine the types of disable-features
> > > 	available. This is helpful, otherwise the app has to 
> > > 	make pkey_alloc() call with the corresponding parameter set
> > > 	and see if it suceeds or fails. Painful from an application
> > > 	point of view, in my opinion.
> > 
> > Again, let's see a real-world use of this.  How does it look?  How does
> > an app "fall back" if it can't set a restriction the way it wants to?
> > 
> > Are we *sure* that such an interface makes sense?  For instance, will it
> > be possible for some keys to be execute-disable while other are only
> > write-disable?
> 
> Can it be on x86?
> 
> its not possible on ppc. the keys can *all* be  the-same-attributes-disable all the
> time.
> 
> However you are right. Its conceivable that some arch could provide a
> feature where it can be x-attribute-disable for key 'a' and
> y-attribute-disable for key 'b'.  But than its a bit of a headache
> for an application to consume such a feature.
> 
> Ben: I recall you requesting this feature.  Thoughts?
> 
> > 
> > > I think on x86 you look for some hardware registers to determine
> > > which hardware features are enabled by the kernel.
> > 
> > No, we use CPUID.  It's a part of the ISA that's designed for
> > enumerating CPU and (sometimes) OS support for CPU features.
> > 
> > > We do not have generic support for something like that on ppc.  The
> > > kernel looks at the device tree to determine what hardware features
> > > are available. But does not have mechanism to tell the hardware to
> > > track which of its features are currently enabled/used by the
> > > kernel; atleast not for the memory-key feature.
> > 
> > Bummer.  You're missing out.
> > 
> > But, you could still do this with a syscall.  "Hey, kernel, do you
> > support this feature?"
> 
> or do powerpc specific sysfs interface.
> or a debugfs interface.

getauxval(3) ?

With AT_HWCAP or HWCAP2 as parameter already gives information about
features supported by the hardware and the kernel.

Taking one bit to expose the availability of protection keys to
applications does not look impossible.

Do I miss something obvious?

	Gabriel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ