* [PATCH] KEYS: user: Align the payload buffer
@ 2019-02-20 13:32 David Howells
2019-02-20 13:52 ` David Laight
0 siblings, 1 reply; 5+ messages in thread
From: David Howells @ 2019-02-20 13:32 UTC (permalink / raw)
To: jmorris
Cc: Aaro Koskinen, stable, Eric Biggers, Aaro Koskinen, keyrings,
linux-security-module, linux-kernel
From: Eric Biggers <ebiggers@google.com>
Align the payload of "user" and "logon" keys so that users of the
keyrings service can access it as a struct that requires more than
2-byte alignment. fscrypt currently does this which results in the read
of fscrypt_key::size being misaligned as it needs 4-byte alignment.
Align to __alignof__(u64) rather than __alignof__(long) since in the
future it's conceivable that people would use structs beginning with
u64, which on some platforms would require more than 'long' alignment.
Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Fixes: 2aa349f6e37c ("[PATCH] Keys: Export user-defined keyring operations")
Fixes: 88bd6ccdcdd6 ("ext4 crypto: add encryption key management facilities")
Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: David Howells <dhowells@redhat.com>
---
include/keys/user-type.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/keys/user-type.h b/include/keys/user-type.h
index e098cbe27db5..12babe991594 100644
--- a/include/keys/user-type.h
+++ b/include/keys/user-type.h
@@ -31,7 +31,7 @@
struct user_key_payload {
struct rcu_head rcu; /* RCU destructor */
unsigned short datalen; /* length of this data */
- char data[0]; /* actual data */
+ char data[0] __aligned(__alignof__(u64)); /* actual data */
};
extern struct key_type key_type_user;
^ permalink raw reply related [flat|nested] 5+ messages in thread* RE: [PATCH] KEYS: user: Align the payload buffer
2019-02-20 13:32 [PATCH] KEYS: user: Align the payload buffer David Howells
@ 2019-02-20 13:52 ` David Laight
2019-02-20 14:09 ` David Howells
0 siblings, 1 reply; 5+ messages in thread
From: David Laight @ 2019-02-20 13:52 UTC (permalink / raw)
To: 'David Howells', jmorris@namei.org
Cc: Aaro Koskinen, stable@vger.kernel.org, Eric Biggers,
Aaro Koskinen, keyrings@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
From: David Howells
> Sent: 20 February 2019 13:32
>
> From: Eric Biggers <ebiggers@google.com>
>
> Align the payload of "user" and "logon" keys so that users of the
> keyrings service can access it as a struct that requires more than
> 2-byte alignment. fscrypt currently does this which results in the read
> of fscrypt_key::size being misaligned as it needs 4-byte alignment.
>
> Align to __alignof__(u64) rather than __alignof__(long) since in the
> future it's conceivable that people would use structs beginning with
> u64, which on some platforms would require more than 'long' alignment.
...
> include/keys/user-type.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/keys/user-type.h b/include/keys/user-type.h
> index e098cbe27db5..12babe991594 100644
> --- a/include/keys/user-type.h
> +++ b/include/keys/user-type.h
> @@ -31,7 +31,7 @@
> struct user_key_payload {
> struct rcu_head rcu; /* RCU destructor */
> unsigned short datalen; /* length of this data */
> - char data[0]; /* actual data */
> + char data[0] __aligned(__alignof__(u64)); /* actual data */
> };
I'd make the 'datalen' field 'unsigned int' at the same time.
It will use some of the hole you've made and generate better
code on most arches.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] KEYS: user: Align the payload buffer
2019-02-20 13:52 ` David Laight
@ 2019-02-20 14:09 ` David Howells
2019-02-20 20:50 ` James Morris
0 siblings, 1 reply; 5+ messages in thread
From: David Howells @ 2019-02-20 14:09 UTC (permalink / raw)
To: David Laight
Cc: dhowells, jmorris@namei.org, Aaro Koskinen,
stable@vger.kernel.org, Eric Biggers, keyrings@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
David Laight <David.Laight@ACULAB.COM> wrote:
> I'd make the 'datalen' field 'unsigned int' at the same time.
> It will use some of the hole you've made and generate better
> code on most arches.
Most arches? I though most, if not all, arches had a load-word instruction.
Do you want to send me a patch for that? I'd rather not alter this patch at
this point. I can pass the additional patch to James for the next merge
window.
David
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] KEYS: user: Align the payload buffer
2019-02-20 14:09 ` David Howells
@ 2019-02-20 20:50 ` James Morris
2019-02-20 21:37 ` David Howells
0 siblings, 1 reply; 5+ messages in thread
From: James Morris @ 2019-02-20 20:50 UTC (permalink / raw)
To: David Howells
Cc: David Laight, Aaro Koskinen, stable@vger.kernel.org, Eric Biggers,
keyrings@vger.kernel.org, linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
On Wed, 20 Feb 2019, David Howells wrote:
> David Laight <David.Laight@ACULAB.COM> wrote:
>
> > I'd make the 'datalen' field 'unsigned int' at the same time.
> > It will use some of the hole you've made and generate better
> > code on most arches.
>
> Most arches? I though most, if not all, arches had a load-word instruction.
>
> Do you want to send me a patch for that? I'd rather not alter this patch at
> this point. I can pass the additional patch to James for the next merge
> window.
Should this first one go into -rc?
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-02-20 21:37 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-02-20 13:32 [PATCH] KEYS: user: Align the payload buffer David Howells
2019-02-20 13:52 ` David Laight
2019-02-20 14:09 ` David Howells
2019-02-20 20:50 ` James Morris
2019-02-20 21:37 ` David Howells
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox