From: Eric Biggers <[email protected]>
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 <[email protected]>
Fixes: 2aa349f6e37c ("[PATCH] Keys: Export user-defined keyring operations")
Fixes: 88bd6ccdcdd6 ("ext4 crypto: add encryption key management facilities")
Cc: [email protected]
Signed-off-by: Eric Biggers <[email protected]>
Tested-by: Aaro Koskinen <[email protected]>
Signed-off-by: David Howells <[email protected]>
---
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;
From: David Howells
> Sent: 20 February 2019 13:32
>
> From: Eric Biggers <[email protected]>
>
> 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)
David Laight <[email protected]> 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
On Wed, 20 Feb 2019, David Howells wrote:
> David Laight <[email protected]> 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
<[email protected]>
James Morris <[email protected]> wrote:
> Should this first one go into -rc?
Yes please.
David