linux-kernel - Re: [PATCH 07/12] mm: Pass the 4-bit protection key in via PROT

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]

Date:	Fri, 4 Sep 2015 13:18:30 -0700
From:	Dave Hansen <dave@...1.net>
To:	Florian Weimer <fw@...eb.enyo.de>
Cc:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH 07/12] mm: Pass the 4-bit protection key in via PROT_ bits
 to syscalls

On 09/04/2015 01:13 PM, Florian Weimer wrote:
...
>>>> >>>  #define PROT_WRITE	0x2		/* page can be written */
>>>> >>>  #define PROT_EXEC	0x4		/* page can be executed */
>>>> >>>  #define PROT_SEM	0x8		/* page may be used for atomic ops */
>>>> >>> +#define PROT_PKEY0	0x10		/* protection key value (bit 0) */
>>>> >>> +#define PROT_PKEY1	0x20		/* protection key value (bit 1) */
>>>> >>> +#define PROT_PKEY2	0x40		/* protection key value (bit 2) */
>>>> >>> +#define PROT_PKEY3	0x80		/* protection key value (bit 3) */
>>> >> 
>>> >> Thats leaking deep Intelisms into asm-generic which makes me very
>>> >> uncomfortable. Whether we need to reserve some bits for "arch specific"
>>> >> is one question, what we do with them ought not to be leaking out.
>>> >> 
>>> >> To start with trying to port code people will want to do
>>> >> 
>>> >> #define PROT_PKEY0	0
>>> >> #define PROT_PKEY1	0
>> >
>> > Yeah, I feel pretty uncomfortable with it as well.  I really don't
>> > expect these to live like this in asm-generic when I submit this.
>> >
>> > Powerpc and ia64 have _something_ resembling protection keys, so the
>> > concept isn't entirely x86 or Intel-specific.  My hope would be that we
>> > do this in a way that other architectures can use.
> It will also be very painful to add additional bits.  We went through
> this with the CPU affinity mask, and it still hurts it.  Please use a
> more sensible interface from the start. :)

Any suggestions?

Are you thinking that we want a completely separate syscall and
completely avoid using the PROT_* bits?
--
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/