linux-kernel - Re: [PATCH] mm: only enable sys_pkey* when ARCH_HAS

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]

Date:   Fri, 4 Nov 2016 23:44:59 +0000
From:   Mark Rutland <mark.rutland@....com>
To:     Dave Hansen <dave.hansen@...ux.intel.com>
Cc:     linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Russell King <rmk+kernel@...linux.org.uk>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-api@...r.kernel.org, linux-arch@...r.kernel.org,
        linux-mm@...ck.org, torvalds@...ux-foundation.org
Subject: Re: [PATCH] mm: only enable sys_pkey* when ARCH_HAS_PKEYS

On Wed, Nov 02, 2016 at 12:15:50PM -0700, Dave Hansen wrote:
> On 10/31/2016 05:08 PM, Mark Rutland wrote:
> > When an architecture does not select CONFIG_ARCH_HAS_PKEYS, the pkey_alloc
> > syscall will return -ENOSPC for all (otherwise well-formed) requests, as the
> > generic implementation of mm_pkey_alloc() returns -1. The other pkey syscalls
> > perform some work before always failing, in a similar fashion.
> > 
> > This implies the absence of keys, but otherwise functional pkey support. This
> > is odd, since the architecture provides no such support. Instead, it would be
> > preferable to indicate that the syscall is not implemented, since this is
> > effectively the case.
> 
> This makes the behavior of an x86 cpu without pkeys and an arm cpu
> without pkeys differ.  Is that what we want?

My rationale was that we have no idea whether architectures will have pkey
support in future, and if/when they do, we may have to apply additional checks
anyhow. i.e. in cases we'd return -ENOSPC today, we might want to return
another error code.

Returning -ENOSYS retains the current behaviour, and allows us to handle that
ABI issue when we know what architecture support looks like.

Other architectures not using the generic syscalls seem to handle this with
-ENOSYS, e.g. parisc with commit 18088db042dd9ae2, so there's differing
behaviour regardless of arm specifically.

> An application that _wants_ to use protection keys but can't needs to handle
> -ENOSPC anyway.

Sure, and that application *also* has to handle -ENOSYS, given current kernels.

> On an architecture that will never support pkeys, it makes sense to do
> -ENOSYS, but that's not the case for arm, right?

I don't know whether arm or other architectures will have (user-accessible)
pkey-like suport.

Thanks,
Mark.