* [dm-devel] [RFC PATCH v1 0/4] keys: introduce key_extract_material helper
@ 2021-07-22 9:17 ` Ahmad Fatoum
0 siblings, 0 replies; 19+ messages in thread
From: Ahmad Fatoum @ 2021-07-22 9:17 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen, James Morris, Serge E. Hallyn,
Alasdair Kergon, Mike Snitzer, dm-devel, Song Liu,
Richard Weinberger
Cc: linux-kernel, linux-raid, linux-security-module, keyrings,
linux-mtd, kernel, linux-integrity
While keys of differing type have a common struct key definition, there is
no common scheme to the payload and key material extraction differs.
For kernel functionality that supports different key types,
this means duplicated code for key material extraction and because key type
is discriminated by a pointer to a global, users need to replicate
reachability checks as well, so builtin code doesn't depend on a key
type symbol offered by a module.
Make this easier by adding a common helper with initial support for
user, logon, encrypted and trusted keys.
This series contains two example of its use: dm-crypt uses it to reduce
boilerplate and ubifs authentication uses it to gain support for trusted
and encrypted keys alongside the already supported logon keys.
Looking forward to your feedback,
Ahmad
---
To: David Howells <dhowells@redhat.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
To: James Morris <jmorris@namei.org>
To: "Serge E. Hallyn" <serge@hallyn.com>
To: Alasdair Kergon <agk@redhat.com>
To: Mike Snitzer <snitzer@redhat.com>
To: dm-devel@redhat.com
To: Song Liu <song@kernel.org>
To: Richard Weinberger <richard@nod.at>
Cc: linux-kernel@vger.kernel.org
Cc: linux-raid@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
Cc: keyrings@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-security-module@vger.kernel.org
Ahmad Fatoum (4):
keys: introduce key_extract_material helper
dm: crypt: use new key_extract_material helper
ubifs: auth: remove never hit key type error check
ubifs: auth: consult encrypted and trusted keys if no logon key was found
Documentation/filesystems/ubifs.rst | 2 +-
drivers/md/dm-crypt.c | 65 ++++--------------------------
fs/ubifs/auth.c | 25 +++++-------
include/linux/key.h | 45 +++++++++++++++++++++-
security/keys/key.c | 40 ++++++++++++++++++-
5 files changed, 107 insertions(+), 70 deletions(-)
base-commit: 2734d6c1b1a089fb593ef6a23d4b70903526fe0c
--
git-series 0.9.1
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC PATCH v1 0/4] keys: introduce key_extract_material helper
@ 2021-07-22 9:17 ` Ahmad Fatoum
0 siblings, 0 replies; 19+ messages in thread
From: Ahmad Fatoum @ 2021-07-22 9:17 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen, James Morris, Serge E. Hallyn,
Alasdair Kergon, Mike Snitzer, dm-devel, Song Liu,
Richard Weinberger
Cc: kernel, linux-kernel, linux-raid, linux-integrity, keyrings,
linux-mtd, linux-security-module
While keys of differing type have a common struct key definition, there is
no common scheme to the payload and key material extraction differs.
For kernel functionality that supports different key types,
this means duplicated code for key material extraction and because key type
is discriminated by a pointer to a global, users need to replicate
reachability checks as well, so builtin code doesn't depend on a key
type symbol offered by a module.
Make this easier by adding a common helper with initial support for
user, logon, encrypted and trusted keys.
This series contains two example of its use: dm-crypt uses it to reduce
boilerplate and ubifs authentication uses it to gain support for trusted
and encrypted keys alongside the already supported logon keys.
Looking forward to your feedback,
Ahmad
---
To: David Howells <dhowells@redhat.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
To: James Morris <jmorris@namei.org>
To: "Serge E. Hallyn" <serge@hallyn.com>
To: Alasdair Kergon <agk@redhat.com>
To: Mike Snitzer <snitzer@redhat.com>
To: dm-devel@redhat.com
To: Song Liu <song@kernel.org>
To: Richard Weinberger <richard@nod.at>
Cc: linux-kernel@vger.kernel.org
Cc: linux-raid@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
Cc: keyrings@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-security-module@vger.kernel.org
Ahmad Fatoum (4):
keys: introduce key_extract_material helper
dm: crypt: use new key_extract_material helper
ubifs: auth: remove never hit key type error check
ubifs: auth: consult encrypted and trusted keys if no logon key was found
Documentation/filesystems/ubifs.rst | 2 +-
drivers/md/dm-crypt.c | 65 ++++--------------------------
fs/ubifs/auth.c | 25 +++++-------
include/linux/key.h | 45 +++++++++++++++++++++-
security/keys/key.c | 40 ++++++++++++++++++-
5 files changed, 107 insertions(+), 70 deletions(-)
base-commit: 2734d6c1b1a089fb593ef6a23d4b70903526fe0c
--
git-series 0.9.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC PATCH v1 1/4] keys: introduce key_extract_material helper
2021-07-22 9:17 ` Ahmad Fatoum
(?)
@ 2021-07-22 9:17 ` Ahmad Fatoum
-1 siblings, 0 replies; 19+ messages in thread
From: Ahmad Fatoum @ 2021-07-22 9:17 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen, James Morris, Serge E. Hallyn,
Alasdair Kergon, Mike Snitzer, dm-devel, Song Liu,
Richard Weinberger
Cc: kernel, Ahmad Fatoum, linux-kernel, linux-raid, keyrings,
linux-mtd, linux-security-module, linux-integrity
While keys of differing type have a common struct key definition, there is
no common scheme to the payload and key material extraction differs.
For kernel functionality that supports different key types,
this means duplicated code for key material extraction and because key type
is discriminated by a pointer to a global, users need to replicate
reachability checks as well, so builtin code doesn't depend on a key
type symbol offered by a module.
Make this easier by adding a common helper with initial support for
user, logon, encrypted and trusted keys. The code is taken from
dm-crypt, which is migrated to use the helper in a later commit.
The implementation must be partially in a header to support configurations
where the key type symbol is defined in a module, but key support in general
is built-in.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
I am not sure whether the chosen header and source file are the best
places for this. This could be made header-only too if that's preferred.
To: David Howells <dhowells@redhat.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
To: James Morris <jmorris@namei.org>
To: "Serge E. Hallyn" <serge@hallyn.com>
To: Alasdair Kergon <agk@redhat.com>
To: Mike Snitzer <snitzer@redhat.com>
To: dm-devel@redhat.com
To: Song Liu <song@kernel.org>
To: Richard Weinberger <richard@nod.at>
Cc: linux-kernel@vger.kernel.org
Cc: linux-raid@vger.kernel.org
Cc: keyrings@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
---
include/linux/key.h | 45 +++++++++++++++++++++++++++++++++++++++++++++
security/keys/key.c | 40 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 85 insertions(+)
diff --git a/include/linux/key.h b/include/linux/key.h
index 7febc4881363..916612f5b313 100644
--- a/include/linux/key.h
+++ b/include/linux/key.h
@@ -20,6 +20,8 @@
#include <linux/assoc_array.h>
#include <linux/refcount.h>
#include <linux/time64.h>
+#include <linux/err.h>
+#include <linux/kconfig.h>
#ifdef __KERNEL__
#include <linux/uidgid.h>
@@ -487,6 +489,48 @@ extern void key_fsuid_changed(struct cred *new_cred);
extern void key_fsgid_changed(struct cred *new_cred);
extern void key_init(void);
+/*
+ * internal use, so key core code need not link against
+ * all supported key types
+ * */
+enum __key_type {
+ KEY_TYPE_UNKNOWN, KEY_TYPE_USER, KEY_TYPE_ENCRYPTED, KEY_TYPE_TRUSTED
+};
+
+const void *__key_extract_material(const struct key *key, enum __key_type type,
+ unsigned int *len);
+
+/**
+ * key_extract_material - Extract decrypted data out of a key
+ * @key: a logon, user, encrypted or trusted key
+ * @len: pointer to variable to store key size into
+ *
+ * Extract decrypted data out of supported key types
+ *
+ * Returns a pointer to the key material if successfull or an error
+ * pointer if key type is not compiled in, the buffer is too
+ * small or the key was revoked.
+ */
+static inline const void *key_extract_material(const struct key *key,
+ unsigned int *len)
+{
+ extern struct key_type key_type_user;
+ extern struct key_type key_type_logon;
+ extern struct key_type key_type_encrypted;
+ extern struct key_type key_type_trusted;
+ enum __key_type type = KEY_TYPE_UNKNOWN;
+ const struct key_type *t = key->type;
+
+ if (t == &key_type_logon || t == &key_type_user)
+ type = KEY_TYPE_USER;
+ else if (IS_REACHABLE(CONFIG_ENCRYPTED_KEYS) && t == &key_type_encrypted)
+ type = KEY_TYPE_ENCRYPTED;
+ else if (IS_REACHABLE(CONFIG_TRUSTED_KEYS) && t == &key_type_trusted)
+ type = KEY_TYPE_TRUSTED;
+
+ return __key_extract_material(key, type, len);
+}
+
#else /* CONFIG_KEYS */
#define key_validate(k) 0
@@ -504,6 +548,7 @@ extern void key_init(void);
#define key_init() do { } while(0)
#define key_free_user_ns(ns) do { } while(0)
#define key_remove_domain(d) do { } while(0)
+#define key_extract_material(k, l) ERR_PTR(-EINVAL)
#endif /* CONFIG_KEYS */
#endif /* __KERNEL__ */
diff --git a/security/keys/key.c b/security/keys/key.c
index c45afdd1dfbb..69cd1cb8c413 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -15,6 +15,9 @@
#include <linux/random.h>
#include <linux/ima.h>
#include <linux/err.h>
+#include <keys/user-type.h>
+#include <keys/encrypted-type.h>
+#include <keys/trusted-type.h>
#include "internal.h"
struct kmem_cache *key_jar;
@@ -1140,6 +1143,43 @@ int generic_key_instantiate(struct key *key, struct key_preparsed_payload *prep)
}
EXPORT_SYMBOL(generic_key_instantiate);
+const void *__key_extract_material(const struct key *key,
+ enum __key_type type, unsigned int *len)
+{
+ const struct encrypted_key_payload *ekp;
+ const struct trusted_key_payload *tkp;
+ const struct user_key_payload *ukp;
+
+ switch (type) {
+ case KEY_TYPE_USER:
+ ukp = user_key_payload_locked(key);
+ if (!ukp)
+ break;
+
+ *len = ukp->datalen;
+ return ukp->data;
+ case KEY_TYPE_ENCRYPTED:
+ ekp = key->payload.data[0];
+ if (!ekp)
+ break;
+
+ *len = ekp->decrypted_datalen;
+ return ekp->decrypted_data;
+ case KEY_TYPE_TRUSTED:
+ tkp = key->payload.data[0];
+ if (!tkp)
+ break;
+
+ *len = tkp->key_len;
+ return tkp->key;
+ default:
+ return ERR_PTR(-EINVAL);
+ }
+
+ return ERR_PTR(-EKEYREVOKED);
+}
+EXPORT_SYMBOL(__key_extract_material);
+
/**
* register_key_type - Register a type of key.
* @ktype: The new key type.
--
git-series 0.9.1
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [dm-devel] [RFC PATCH v1 1/4] keys: introduce key_extract_material helper
@ 2021-07-22 9:17 ` Ahmad Fatoum
0 siblings, 0 replies; 19+ messages in thread
From: Ahmad Fatoum @ 2021-07-22 9:17 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen, James Morris, Serge E. Hallyn,
Alasdair Kergon, Mike Snitzer, dm-devel, Song Liu,
Richard Weinberger
Cc: Ahmad Fatoum, linux-kernel, linux-raid, linux-security-module,
keyrings, linux-mtd, kernel, linux-integrity
While keys of differing type have a common struct key definition, there is
no common scheme to the payload and key material extraction differs.
For kernel functionality that supports different key types,
this means duplicated code for key material extraction and because key type
is discriminated by a pointer to a global, users need to replicate
reachability checks as well, so builtin code doesn't depend on a key
type symbol offered by a module.
Make this easier by adding a common helper with initial support for
user, logon, encrypted and trusted keys. The code is taken from
dm-crypt, which is migrated to use the helper in a later commit.
The implementation must be partially in a header to support configurations
where the key type symbol is defined in a module, but key support in general
is built-in.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
I am not sure whether the chosen header and source file are the best
places for this. This could be made header-only too if that's preferred.
To: David Howells <dhowells@redhat.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
To: James Morris <jmorris@namei.org>
To: "Serge E. Hallyn" <serge@hallyn.com>
To: Alasdair Kergon <agk@redhat.com>
To: Mike Snitzer <snitzer@redhat.com>
To: dm-devel@redhat.com
To: Song Liu <song@kernel.org>
To: Richard Weinberger <richard@nod.at>
Cc: linux-kernel@vger.kernel.org
Cc: linux-raid@vger.kernel.org
Cc: keyrings@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
---
include/linux/key.h | 45 +++++++++++++++++++++++++++++++++++++++++++++
security/keys/key.c | 40 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 85 insertions(+)
diff --git a/include/linux/key.h b/include/linux/key.h
index 7febc4881363..916612f5b313 100644
--- a/include/linux/key.h
+++ b/include/linux/key.h
@@ -20,6 +20,8 @@
#include <linux/assoc_array.h>
#include <linux/refcount.h>
#include <linux/time64.h>
+#include <linux/err.h>
+#include <linux/kconfig.h>
#ifdef __KERNEL__
#include <linux/uidgid.h>
@@ -487,6 +489,48 @@ extern void key_fsuid_changed(struct cred *new_cred);
extern void key_fsgid_changed(struct cred *new_cred);
extern void key_init(void);
+/*
+ * internal use, so key core code need not link against
+ * all supported key types
+ * */
+enum __key_type {
+ KEY_TYPE_UNKNOWN, KEY_TYPE_USER, KEY_TYPE_ENCRYPTED, KEY_TYPE_TRUSTED
+};
+
+const void *__key_extract_material(const struct key *key, enum __key_type type,
+ unsigned int *len);
+
+/**
+ * key_extract_material - Extract decrypted data out of a key
+ * @key: a logon, user, encrypted or trusted key
+ * @len: pointer to variable to store key size into
+ *
+ * Extract decrypted data out of supported key types
+ *
+ * Returns a pointer to the key material if successfull or an error
+ * pointer if key type is not compiled in, the buffer is too
+ * small or the key was revoked.
+ */
+static inline const void *key_extract_material(const struct key *key,
+ unsigned int *len)
+{
+ extern struct key_type key_type_user;
+ extern struct key_type key_type_logon;
+ extern struct key_type key_type_encrypted;
+ extern struct key_type key_type_trusted;
+ enum __key_type type = KEY_TYPE_UNKNOWN;
+ const struct key_type *t = key->type;
+
+ if (t == &key_type_logon || t == &key_type_user)
+ type = KEY_TYPE_USER;
+ else if (IS_REACHABLE(CONFIG_ENCRYPTED_KEYS) && t == &key_type_encrypted)
+ type = KEY_TYPE_ENCRYPTED;
+ else if (IS_REACHABLE(CONFIG_TRUSTED_KEYS) && t == &key_type_trusted)
+ type = KEY_TYPE_TRUSTED;
+
+ return __key_extract_material(key, type, len);
+}
+
#else /* CONFIG_KEYS */
#define key_validate(k) 0
@@ -504,6 +548,7 @@ extern void key_init(void);
#define key_init() do { } while(0)
#define key_free_user_ns(ns) do { } while(0)
#define key_remove_domain(d) do { } while(0)
+#define key_extract_material(k, l) ERR_PTR(-EINVAL)
#endif /* CONFIG_KEYS */
#endif /* __KERNEL__ */
diff --git a/security/keys/key.c b/security/keys/key.c
index c45afdd1dfbb..69cd1cb8c413 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -15,6 +15,9 @@
#include <linux/random.h>
#include <linux/ima.h>
#include <linux/err.h>
+#include <keys/user-type.h>
+#include <keys/encrypted-type.h>
+#include <keys/trusted-type.h>
#include "internal.h"
struct kmem_cache *key_jar;
@@ -1140,6 +1143,43 @@ int generic_key_instantiate(struct key *key, struct key_preparsed_payload *prep)
}
EXPORT_SYMBOL(generic_key_instantiate);
+const void *__key_extract_material(const struct key *key,
+ enum __key_type type, unsigned int *len)
+{
+ const struct encrypted_key_payload *ekp;
+ const struct trusted_key_payload *tkp;
+ const struct user_key_payload *ukp;
+
+ switch (type) {
+ case KEY_TYPE_USER:
+ ukp = user_key_payload_locked(key);
+ if (!ukp)
+ break;
+
+ *len = ukp->datalen;
+ return ukp->data;
+ case KEY_TYPE_ENCRYPTED:
+ ekp = key->payload.data[0];
+ if (!ekp)
+ break;
+
+ *len = ekp->decrypted_datalen;
+ return ekp->decrypted_data;
+ case KEY_TYPE_TRUSTED:
+ tkp = key->payload.data[0];
+ if (!tkp)
+ break;
+
+ *len = tkp->key_len;
+ return tkp->key;
+ default:
+ return ERR_PTR(-EINVAL);
+ }
+
+ return ERR_PTR(-EKEYREVOKED);
+}
+EXPORT_SYMBOL(__key_extract_material);
+
/**
* register_key_type - Register a type of key.
* @ktype: The new key type.
--
git-series 0.9.1
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [RFC PATCH v1 1/4] keys: introduce key_extract_material helper
@ 2021-07-22 9:17 ` Ahmad Fatoum
0 siblings, 0 replies; 19+ messages in thread
From: Ahmad Fatoum @ 2021-07-22 9:17 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen, James Morris, Serge E. Hallyn,
Alasdair Kergon, Mike Snitzer, dm-devel, Song Liu,
Richard Weinberger
Cc: kernel, Ahmad Fatoum, linux-kernel, linux-raid, keyrings,
linux-mtd, linux-security-module, linux-integrity
While keys of differing type have a common struct key definition, there is
no common scheme to the payload and key material extraction differs.
For kernel functionality that supports different key types,
this means duplicated code for key material extraction and because key type
is discriminated by a pointer to a global, users need to replicate
reachability checks as well, so builtin code doesn't depend on a key
type symbol offered by a module.
Make this easier by adding a common helper with initial support for
user, logon, encrypted and trusted keys. The code is taken from
dm-crypt, which is migrated to use the helper in a later commit.
The implementation must be partially in a header to support configurations
where the key type symbol is defined in a module, but key support in general
is built-in.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
I am not sure whether the chosen header and source file are the best
places for this. This could be made header-only too if that's preferred.
To: David Howells <dhowells@redhat.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
To: James Morris <jmorris@namei.org>
To: "Serge E. Hallyn" <serge@hallyn.com>
To: Alasdair Kergon <agk@redhat.com>
To: Mike Snitzer <snitzer@redhat.com>
To: dm-devel@redhat.com
To: Song Liu <song@kernel.org>
To: Richard Weinberger <richard@nod.at>
Cc: linux-kernel@vger.kernel.org
Cc: linux-raid@vger.kernel.org
Cc: keyrings@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
---
include/linux/key.h | 45 +++++++++++++++++++++++++++++++++++++++++++++
security/keys/key.c | 40 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 85 insertions(+)
diff --git a/include/linux/key.h b/include/linux/key.h
index 7febc4881363..916612f5b313 100644
--- a/include/linux/key.h
+++ b/include/linux/key.h
@@ -20,6 +20,8 @@
#include <linux/assoc_array.h>
#include <linux/refcount.h>
#include <linux/time64.h>
+#include <linux/err.h>
+#include <linux/kconfig.h>
#ifdef __KERNEL__
#include <linux/uidgid.h>
@@ -487,6 +489,48 @@ extern void key_fsuid_changed(struct cred *new_cred);
extern void key_fsgid_changed(struct cred *new_cred);
extern void key_init(void);
+/*
+ * internal use, so key core code need not link against
+ * all supported key types
+ * */
+enum __key_type {
+ KEY_TYPE_UNKNOWN, KEY_TYPE_USER, KEY_TYPE_ENCRYPTED, KEY_TYPE_TRUSTED
+};
+
+const void *__key_extract_material(const struct key *key, enum __key_type type,
+ unsigned int *len);
+
+/**
+ * key_extract_material - Extract decrypted data out of a key
+ * @key: a logon, user, encrypted or trusted key
+ * @len: pointer to variable to store key size into
+ *
+ * Extract decrypted data out of supported key types
+ *
+ * Returns a pointer to the key material if successfull or an error
+ * pointer if key type is not compiled in, the buffer is too
+ * small or the key was revoked.
+ */
+static inline const void *key_extract_material(const struct key *key,
+ unsigned int *len)
+{
+ extern struct key_type key_type_user;
+ extern struct key_type key_type_logon;
+ extern struct key_type key_type_encrypted;
+ extern struct key_type key_type_trusted;
+ enum __key_type type = KEY_TYPE_UNKNOWN;
+ const struct key_type *t = key->type;
+
+ if (t == &key_type_logon || t == &key_type_user)
+ type = KEY_TYPE_USER;
+ else if (IS_REACHABLE(CONFIG_ENCRYPTED_KEYS) && t == &key_type_encrypted)
+ type = KEY_TYPE_ENCRYPTED;
+ else if (IS_REACHABLE(CONFIG_TRUSTED_KEYS) && t == &key_type_trusted)
+ type = KEY_TYPE_TRUSTED;
+
+ return __key_extract_material(key, type, len);
+}
+
#else /* CONFIG_KEYS */
#define key_validate(k) 0
@@ -504,6 +548,7 @@ extern void key_init(void);
#define key_init() do { } while(0)
#define key_free_user_ns(ns) do { } while(0)
#define key_remove_domain(d) do { } while(0)
+#define key_extract_material(k, l) ERR_PTR(-EINVAL)
#endif /* CONFIG_KEYS */
#endif /* __KERNEL__ */
diff --git a/security/keys/key.c b/security/keys/key.c
index c45afdd1dfbb..69cd1cb8c413 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -15,6 +15,9 @@
#include <linux/random.h>
#include <linux/ima.h>
#include <linux/err.h>
+#include <keys/user-type.h>
+#include <keys/encrypted-type.h>
+#include <keys/trusted-type.h>
#include "internal.h"
struct kmem_cache *key_jar;
@@ -1140,6 +1143,43 @@ int generic_key_instantiate(struct key *key, struct key_preparsed_payload *prep)
}
EXPORT_SYMBOL(generic_key_instantiate);
+const void *__key_extract_material(const struct key *key,
+ enum __key_type type, unsigned int *len)
+{
+ const struct encrypted_key_payload *ekp;
+ const struct trusted_key_payload *tkp;
+ const struct user_key_payload *ukp;
+
+ switch (type) {
+ case KEY_TYPE_USER:
+ ukp = user_key_payload_locked(key);
+ if (!ukp)
+ break;
+
+ *len = ukp->datalen;
+ return ukp->data;
+ case KEY_TYPE_ENCRYPTED:
+ ekp = key->payload.data[0];
+ if (!ekp)
+ break;
+
+ *len = ekp->decrypted_datalen;
+ return ekp->decrypted_data;
+ case KEY_TYPE_TRUSTED:
+ tkp = key->payload.data[0];
+ if (!tkp)
+ break;
+
+ *len = tkp->key_len;
+ return tkp->key;
+ default:
+ return ERR_PTR(-EINVAL);
+ }
+
+ return ERR_PTR(-EKEYREVOKED);
+}
+EXPORT_SYMBOL(__key_extract_material);
+
/**
* register_key_type - Register a type of key.
* @ktype: The new key type.
--
git-series 0.9.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [RFC PATCH v1 2/4] dm: crypt: use new key_extract_material helper
2021-07-22 9:17 ` Ahmad Fatoum
(?)
@ 2021-07-22 9:18 ` Ahmad Fatoum
-1 siblings, 0 replies; 19+ messages in thread
From: Ahmad Fatoum @ 2021-07-22 9:18 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen, James Morris, Serge E. Hallyn,
Alasdair Kergon, Mike Snitzer, dm-devel, Song Liu,
Richard Weinberger
Cc: kernel, Ahmad Fatoum, linux-kernel, linux-raid, keyrings,
linux-mtd, linux-security-module, linux-integrity
There is a common function now to extract key material out of a few
different key types, which includes all types currently supported by
dm-crypt. Make use of it.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
To: David Howells <dhowells@redhat.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
To: James Morris <jmorris@namei.org>
To: "Serge E. Hallyn" <serge@hallyn.com>
To: Alasdair Kergon <agk@redhat.com>
To: Mike Snitzer <snitzer@redhat.com>
To: dm-devel@redhat.com
To: Song Liu <song@kernel.org>
To: Richard Weinberger <richard@nod.at>
Cc: linux-kernel@vger.kernel.org
Cc: linux-raid@vger.kernel.org
Cc: keyrings@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
---
drivers/md/dm-crypt.c | 65 ++++++--------------------------------------
1 file changed, 9 insertions(+), 56 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 50f4cbd600d5..576d6b7ce231 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -2421,61 +2421,14 @@ static bool contains_whitespace(const char *str)
return false;
}
-static int set_key_user(struct crypt_config *cc, struct key *key)
-{
- const struct user_key_payload *ukp;
-
- ukp = user_key_payload_locked(key);
- if (!ukp)
- return -EKEYREVOKED;
-
- if (cc->key_size != ukp->datalen)
- return -EINVAL;
-
- memcpy(cc->key, ukp->data, cc->key_size);
-
- return 0;
-}
-
-static int set_key_encrypted(struct crypt_config *cc, struct key *key)
-{
- const struct encrypted_key_payload *ekp;
-
- ekp = key->payload.data[0];
- if (!ekp)
- return -EKEYREVOKED;
-
- if (cc->key_size != ekp->decrypted_datalen)
- return -EINVAL;
-
- memcpy(cc->key, ekp->decrypted_data, cc->key_size);
-
- return 0;
-}
-
-static int set_key_trusted(struct crypt_config *cc, struct key *key)
-{
- const struct trusted_key_payload *tkp;
-
- tkp = key->payload.data[0];
- if (!tkp)
- return -EKEYREVOKED;
-
- if (cc->key_size != tkp->key_len)
- return -EINVAL;
-
- memcpy(cc->key, tkp->key, cc->key_size);
-
- return 0;
-}
-
static int crypt_set_keyring_key(struct crypt_config *cc, const char *key_string)
{
char *new_key_string, *key_desc;
int ret;
+ unsigned int len;
struct key_type *type;
struct key *key;
- int (*set_key)(struct crypt_config *cc, struct key *key);
+ const void *key_material;
/*
* Reject key_string with whitespace. dm core currently lacks code for
@@ -2493,18 +2446,14 @@ static int crypt_set_keyring_key(struct crypt_config *cc, const char *key_string
if (!strncmp(key_string, "logon:", key_desc - key_string + 1)) {
type = &key_type_logon;
- set_key = set_key_user;
} else if (!strncmp(key_string, "user:", key_desc - key_string + 1)) {
type = &key_type_user;
- set_key = set_key_user;
} else if (IS_ENABLED(CONFIG_ENCRYPTED_KEYS) &&
!strncmp(key_string, "encrypted:", key_desc - key_string + 1)) {
type = &key_type_encrypted;
- set_key = set_key_encrypted;
} else if (IS_ENABLED(CONFIG_TRUSTED_KEYS) &&
!strncmp(key_string, "trusted:", key_desc - key_string + 1)) {
type = &key_type_trusted;
- set_key = set_key_trusted;
} else {
return -EINVAL;
}
@@ -2521,14 +2470,18 @@ static int crypt_set_keyring_key(struct crypt_config *cc, const char *key_string
down_read(&key->sem);
- ret = set_key(cc, key);
- if (ret < 0) {
+ key_material = key_extract_material(key, &len);
+ if (!IS_ERR(key_material) && len != cc->key_size)
+ key_material = ERR_PTR(-EINVAL);
+ if (IS_ERR(key_material)) {
up_read(&key->sem);
key_put(key);
kfree_sensitive(new_key_string);
- return ret;
+ return PTR_ERR(key_material);
}
+ memcpy(cc->key, key_material, len);
+
up_read(&key->sem);
key_put(key);
--
git-series 0.9.1
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [dm-devel] [RFC PATCH v1 2/4] dm: crypt: use new key_extract_material helper
@ 2021-07-22 9:18 ` Ahmad Fatoum
0 siblings, 0 replies; 19+ messages in thread
From: Ahmad Fatoum @ 2021-07-22 9:18 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen, James Morris, Serge E. Hallyn,
Alasdair Kergon, Mike Snitzer, dm-devel, Song Liu,
Richard Weinberger
Cc: Ahmad Fatoum, linux-kernel, linux-raid, linux-security-module,
keyrings, linux-mtd, kernel, linux-integrity
There is a common function now to extract key material out of a few
different key types, which includes all types currently supported by
dm-crypt. Make use of it.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
To: David Howells <dhowells@redhat.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
To: James Morris <jmorris@namei.org>
To: "Serge E. Hallyn" <serge@hallyn.com>
To: Alasdair Kergon <agk@redhat.com>
To: Mike Snitzer <snitzer@redhat.com>
To: dm-devel@redhat.com
To: Song Liu <song@kernel.org>
To: Richard Weinberger <richard@nod.at>
Cc: linux-kernel@vger.kernel.org
Cc: linux-raid@vger.kernel.org
Cc: keyrings@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
---
drivers/md/dm-crypt.c | 65 ++++++--------------------------------------
1 file changed, 9 insertions(+), 56 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 50f4cbd600d5..576d6b7ce231 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -2421,61 +2421,14 @@ static bool contains_whitespace(const char *str)
return false;
}
-static int set_key_user(struct crypt_config *cc, struct key *key)
-{
- const struct user_key_payload *ukp;
-
- ukp = user_key_payload_locked(key);
- if (!ukp)
- return -EKEYREVOKED;
-
- if (cc->key_size != ukp->datalen)
- return -EINVAL;
-
- memcpy(cc->key, ukp->data, cc->key_size);
-
- return 0;
-}
-
-static int set_key_encrypted(struct crypt_config *cc, struct key *key)
-{
- const struct encrypted_key_payload *ekp;
-
- ekp = key->payload.data[0];
- if (!ekp)
- return -EKEYREVOKED;
-
- if (cc->key_size != ekp->decrypted_datalen)
- return -EINVAL;
-
- memcpy(cc->key, ekp->decrypted_data, cc->key_size);
-
- return 0;
-}
-
-static int set_key_trusted(struct crypt_config *cc, struct key *key)
-{
- const struct trusted_key_payload *tkp;
-
- tkp = key->payload.data[0];
- if (!tkp)
- return -EKEYREVOKED;
-
- if (cc->key_size != tkp->key_len)
- return -EINVAL;
-
- memcpy(cc->key, tkp->key, cc->key_size);
-
- return 0;
-}
-
static int crypt_set_keyring_key(struct crypt_config *cc, const char *key_string)
{
char *new_key_string, *key_desc;
int ret;
+ unsigned int len;
struct key_type *type;
struct key *key;
- int (*set_key)(struct crypt_config *cc, struct key *key);
+ const void *key_material;
/*
* Reject key_string with whitespace. dm core currently lacks code for
@@ -2493,18 +2446,14 @@ static int crypt_set_keyring_key(struct crypt_config *cc, const char *key_string
if (!strncmp(key_string, "logon:", key_desc - key_string + 1)) {
type = &key_type_logon;
- set_key = set_key_user;
} else if (!strncmp(key_string, "user:", key_desc - key_string + 1)) {
type = &key_type_user;
- set_key = set_key_user;
} else if (IS_ENABLED(CONFIG_ENCRYPTED_KEYS) &&
!strncmp(key_string, "encrypted:", key_desc - key_string + 1)) {
type = &key_type_encrypted;
- set_key = set_key_encrypted;
} else if (IS_ENABLED(CONFIG_TRUSTED_KEYS) &&
!strncmp(key_string, "trusted:", key_desc - key_string + 1)) {
type = &key_type_trusted;
- set_key = set_key_trusted;
} else {
return -EINVAL;
}
@@ -2521,14 +2470,18 @@ static int crypt_set_keyring_key(struct crypt_config *cc, const char *key_string
down_read(&key->sem);
- ret = set_key(cc, key);
- if (ret < 0) {
+ key_material = key_extract_material(key, &len);
+ if (!IS_ERR(key_material) && len != cc->key_size)
+ key_material = ERR_PTR(-EINVAL);
+ if (IS_ERR(key_material)) {
up_read(&key->sem);
key_put(key);
kfree_sensitive(new_key_string);
- return ret;
+ return PTR_ERR(key_material);
}
+ memcpy(cc->key, key_material, len);
+
up_read(&key->sem);
key_put(key);
--
git-series 0.9.1
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [RFC PATCH v1 2/4] dm: crypt: use new key_extract_material helper
@ 2021-07-22 9:18 ` Ahmad Fatoum
0 siblings, 0 replies; 19+ messages in thread
From: Ahmad Fatoum @ 2021-07-22 9:18 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen, James Morris, Serge E. Hallyn,
Alasdair Kergon, Mike Snitzer, dm-devel, Song Liu,
Richard Weinberger
Cc: kernel, Ahmad Fatoum, linux-kernel, linux-raid, keyrings,
linux-mtd, linux-security-module, linux-integrity
There is a common function now to extract key material out of a few
different key types, which includes all types currently supported by
dm-crypt. Make use of it.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
To: David Howells <dhowells@redhat.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
To: James Morris <jmorris@namei.org>
To: "Serge E. Hallyn" <serge@hallyn.com>
To: Alasdair Kergon <agk@redhat.com>
To: Mike Snitzer <snitzer@redhat.com>
To: dm-devel@redhat.com
To: Song Liu <song@kernel.org>
To: Richard Weinberger <richard@nod.at>
Cc: linux-kernel@vger.kernel.org
Cc: linux-raid@vger.kernel.org
Cc: keyrings@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
---
drivers/md/dm-crypt.c | 65 ++++++--------------------------------------
1 file changed, 9 insertions(+), 56 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 50f4cbd600d5..576d6b7ce231 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -2421,61 +2421,14 @@ static bool contains_whitespace(const char *str)
return false;
}
-static int set_key_user(struct crypt_config *cc, struct key *key)
-{
- const struct user_key_payload *ukp;
-
- ukp = user_key_payload_locked(key);
- if (!ukp)
- return -EKEYREVOKED;
-
- if (cc->key_size != ukp->datalen)
- return -EINVAL;
-
- memcpy(cc->key, ukp->data, cc->key_size);
-
- return 0;
-}
-
-static int set_key_encrypted(struct crypt_config *cc, struct key *key)
-{
- const struct encrypted_key_payload *ekp;
-
- ekp = key->payload.data[0];
- if (!ekp)
- return -EKEYREVOKED;
-
- if (cc->key_size != ekp->decrypted_datalen)
- return -EINVAL;
-
- memcpy(cc->key, ekp->decrypted_data, cc->key_size);
-
- return 0;
-}
-
-static int set_key_trusted(struct crypt_config *cc, struct key *key)
-{
- const struct trusted_key_payload *tkp;
-
- tkp = key->payload.data[0];
- if (!tkp)
- return -EKEYREVOKED;
-
- if (cc->key_size != tkp->key_len)
- return -EINVAL;
-
- memcpy(cc->key, tkp->key, cc->key_size);
-
- return 0;
-}
-
static int crypt_set_keyring_key(struct crypt_config *cc, const char *key_string)
{
char *new_key_string, *key_desc;
int ret;
+ unsigned int len;
struct key_type *type;
struct key *key;
- int (*set_key)(struct crypt_config *cc, struct key *key);
+ const void *key_material;
/*
* Reject key_string with whitespace. dm core currently lacks code for
@@ -2493,18 +2446,14 @@ static int crypt_set_keyring_key(struct crypt_config *cc, const char *key_string
if (!strncmp(key_string, "logon:", key_desc - key_string + 1)) {
type = &key_type_logon;
- set_key = set_key_user;
} else if (!strncmp(key_string, "user:", key_desc - key_string + 1)) {
type = &key_type_user;
- set_key = set_key_user;
} else if (IS_ENABLED(CONFIG_ENCRYPTED_KEYS) &&
!strncmp(key_string, "encrypted:", key_desc - key_string + 1)) {
type = &key_type_encrypted;
- set_key = set_key_encrypted;
} else if (IS_ENABLED(CONFIG_TRUSTED_KEYS) &&
!strncmp(key_string, "trusted:", key_desc - key_string + 1)) {
type = &key_type_trusted;
- set_key = set_key_trusted;
} else {
return -EINVAL;
}
@@ -2521,14 +2470,18 @@ static int crypt_set_keyring_key(struct crypt_config *cc, const char *key_string
down_read(&key->sem);
- ret = set_key(cc, key);
- if (ret < 0) {
+ key_material = key_extract_material(key, &len);
+ if (!IS_ERR(key_material) && len != cc->key_size)
+ key_material = ERR_PTR(-EINVAL);
+ if (IS_ERR(key_material)) {
up_read(&key->sem);
key_put(key);
kfree_sensitive(new_key_string);
- return ret;
+ return PTR_ERR(key_material);
}
+ memcpy(cc->key, key_material, len);
+
up_read(&key->sem);
key_put(key);
--
git-series 0.9.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [RFC PATCH v1 3/4] ubifs: auth: remove never hit key type error check
2021-07-22 9:17 ` Ahmad Fatoum
(?)
@ 2021-07-22 9:18 ` Ahmad Fatoum
-1 siblings, 0 replies; 19+ messages in thread
From: Ahmad Fatoum @ 2021-07-22 9:18 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen, James Morris, Serge E. Hallyn,
Alasdair Kergon, Mike Snitzer, dm-devel, Song Liu,
Richard Weinberger
Cc: kernel, Ahmad Fatoum, linux-kernel, linux-raid, keyrings,
linux-mtd, linux-security-module, linux-integrity
key_request accepts a key type as its first argument. If it returns a
valid pointer, it should always have this same requested key type.
Indeed other request_key users surveyed such as dm-crypt, ecryptfs
and fscrypt v1 also don't check the key type. Therefore drop the
apparently unneeded check.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
To: David Howells <dhowells@redhat.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
To: James Morris <jmorris@namei.org>
To: "Serge E. Hallyn" <serge@hallyn.com>
To: Alasdair Kergon <agk@redhat.com>
To: Mike Snitzer <snitzer@redhat.com>
To: dm-devel@redhat.com
To: Song Liu <song@kernel.org>
To: Richard Weinberger <richard@nod.at>
Cc: linux-kernel@vger.kernel.org
Cc: linux-raid@vger.kernel.org
Cc: keyrings@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
---
fs/ubifs/auth.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/fs/ubifs/auth.c b/fs/ubifs/auth.c
index e564d5ff8781..6a0b8d858d81 100644
--- a/fs/ubifs/auth.c
+++ b/fs/ubifs/auth.c
@@ -286,12 +286,6 @@ int ubifs_init_authentication(struct ubifs_info *c)
down_read(&keyring_key->sem);
- if (keyring_key->type != &key_type_logon) {
- ubifs_err(c, "key type must be logon");
- err = -ENOKEY;
- goto out;
- }
-
ukp = user_key_payload_locked(keyring_key);
if (!ukp) {
/* key was revoked before we acquired its semaphore */
--
git-series 0.9.1
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [dm-devel] [RFC PATCH v1 3/4] ubifs: auth: remove never hit key type error check
@ 2021-07-22 9:18 ` Ahmad Fatoum
0 siblings, 0 replies; 19+ messages in thread
From: Ahmad Fatoum @ 2021-07-22 9:18 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen, James Morris, Serge E. Hallyn,
Alasdair Kergon, Mike Snitzer, dm-devel, Song Liu,
Richard Weinberger
Cc: Ahmad Fatoum, linux-kernel, linux-raid, linux-security-module,
keyrings, linux-mtd, kernel, linux-integrity
key_request accepts a key type as its first argument. If it returns a
valid pointer, it should always have this same requested key type.
Indeed other request_key users surveyed such as dm-crypt, ecryptfs
and fscrypt v1 also don't check the key type. Therefore drop the
apparently unneeded check.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
To: David Howells <dhowells@redhat.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
To: James Morris <jmorris@namei.org>
To: "Serge E. Hallyn" <serge@hallyn.com>
To: Alasdair Kergon <agk@redhat.com>
To: Mike Snitzer <snitzer@redhat.com>
To: dm-devel@redhat.com
To: Song Liu <song@kernel.org>
To: Richard Weinberger <richard@nod.at>
Cc: linux-kernel@vger.kernel.org
Cc: linux-raid@vger.kernel.org
Cc: keyrings@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
---
fs/ubifs/auth.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/fs/ubifs/auth.c b/fs/ubifs/auth.c
index e564d5ff8781..6a0b8d858d81 100644
--- a/fs/ubifs/auth.c
+++ b/fs/ubifs/auth.c
@@ -286,12 +286,6 @@ int ubifs_init_authentication(struct ubifs_info *c)
down_read(&keyring_key->sem);
- if (keyring_key->type != &key_type_logon) {
- ubifs_err(c, "key type must be logon");
- err = -ENOKEY;
- goto out;
- }
-
ukp = user_key_payload_locked(keyring_key);
if (!ukp) {
/* key was revoked before we acquired its semaphore */
--
git-series 0.9.1
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [RFC PATCH v1 3/4] ubifs: auth: remove never hit key type error check
@ 2021-07-22 9:18 ` Ahmad Fatoum
0 siblings, 0 replies; 19+ messages in thread
From: Ahmad Fatoum @ 2021-07-22 9:18 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen, James Morris, Serge E. Hallyn,
Alasdair Kergon, Mike Snitzer, dm-devel, Song Liu,
Richard Weinberger
Cc: kernel, Ahmad Fatoum, linux-kernel, linux-raid, keyrings,
linux-mtd, linux-security-module, linux-integrity
key_request accepts a key type as its first argument. If it returns a
valid pointer, it should always have this same requested key type.
Indeed other request_key users surveyed such as dm-crypt, ecryptfs
and fscrypt v1 also don't check the key type. Therefore drop the
apparently unneeded check.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
To: David Howells <dhowells@redhat.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
To: James Morris <jmorris@namei.org>
To: "Serge E. Hallyn" <serge@hallyn.com>
To: Alasdair Kergon <agk@redhat.com>
To: Mike Snitzer <snitzer@redhat.com>
To: dm-devel@redhat.com
To: Song Liu <song@kernel.org>
To: Richard Weinberger <richard@nod.at>
Cc: linux-kernel@vger.kernel.org
Cc: linux-raid@vger.kernel.org
Cc: keyrings@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
---
fs/ubifs/auth.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/fs/ubifs/auth.c b/fs/ubifs/auth.c
index e564d5ff8781..6a0b8d858d81 100644
--- a/fs/ubifs/auth.c
+++ b/fs/ubifs/auth.c
@@ -286,12 +286,6 @@ int ubifs_init_authentication(struct ubifs_info *c)
down_read(&keyring_key->sem);
- if (keyring_key->type != &key_type_logon) {
- ubifs_err(c, "key type must be logon");
- err = -ENOKEY;
- goto out;
- }
-
ukp = user_key_payload_locked(keyring_key);
if (!ukp) {
/* key was revoked before we acquired its semaphore */
--
git-series 0.9.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [RFC PATCH v1 4/4] ubifs: auth: consult encrypted and trusted keys if no logon key was found
2021-07-22 9:17 ` Ahmad Fatoum
(?)
@ 2021-07-22 9:18 ` Ahmad Fatoum
-1 siblings, 0 replies; 19+ messages in thread
From: Ahmad Fatoum @ 2021-07-22 9:18 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen, James Morris, Serge E. Hallyn,
Alasdair Kergon, Mike Snitzer, dm-devel, Song Liu,
Richard Weinberger, Jonathan Corbet
Cc: kernel, Ahmad Fatoum, linux-kernel, linux-doc, linux-raid,
keyrings, linux-mtd, linux-security-module, linux-integrity
Currently, UBIFS auth_key can only be a logon key: This is a user key
that's provided to the kernel in plaintext and that then remains within
the kernel. Linux also supports trusted and encrypted keys, which have
stronger guarantees: They are only exposed to userspace in encrypted
form and, in the case of trusted keys, can be directly rooted to a trust
source like a TPM chip.
Add support for auth_key to be either a logon, encrypted or trusted key.
At mount time, the keyring will be searched for a key with the supplied
name in that order.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
To: David Howells <dhowells@redhat.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
To: James Morris <jmorris@namei.org>
To: "Serge E. Hallyn" <serge@hallyn.com>
To: Alasdair Kergon <agk@redhat.com>
To: Mike Snitzer <snitzer@redhat.com>
To: dm-devel@redhat.com
To: Song Liu <song@kernel.org>
To: Richard Weinberger <richard@nod.at>
To: Jonathan Corbet <corbet@lwn.net>
Cc: linux-kernel@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-raid@vger.kernel.org
Cc: keyrings@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
---
Documentation/filesystems/ubifs.rst | 2 +-
fs/ubifs/auth.c | 19 ++++++++++++-------
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/Documentation/filesystems/ubifs.rst b/Documentation/filesystems/ubifs.rst
index e6ee99762534..12d08458b3d7 100644
--- a/Documentation/filesystems/ubifs.rst
+++ b/Documentation/filesystems/ubifs.rst
@@ -101,7 +101,7 @@ compr=zlib override default compressor and set it to "zlib"
auth_key= specify the key used for authenticating the filesystem.
Passing this option makes authentication mandatory.
The passed key must be present in the kernel keyring
- and must be of type 'logon'
+ and must be of type 'logon', 'encrypted' or 'trusted'.
auth_hash_name= The hash algorithm used for authentication. Used for
both hashing and for creating HMACs. Typical values
include "sha256" or "sha512"
diff --git a/fs/ubifs/auth.c b/fs/ubifs/auth.c
index 6a0b8d858d81..af8e9eb58a60 100644
--- a/fs/ubifs/auth.c
+++ b/fs/ubifs/auth.c
@@ -14,6 +14,8 @@
#include <crypto/hash.h>
#include <crypto/algapi.h>
#include <keys/user-type.h>
+#include <keys/trusted-type.h>
+#include <keys/encrypted-type.h>
#include <keys/asymmetric-type.h>
#include "ubifs.h"
@@ -256,9 +258,10 @@ out_destroy:
int ubifs_init_authentication(struct ubifs_info *c)
{
struct key *keyring_key;
- const struct user_key_payload *ukp;
int err;
+ unsigned int len;
char hmac_name[CRYPTO_MAX_ALG_NAME];
+ const void *key_material;
if (!c->auth_hash_name) {
ubifs_err(c, "authentication hash name needed with authentication");
@@ -277,6 +280,10 @@ int ubifs_init_authentication(struct ubifs_info *c)
c->auth_hash_name);
keyring_key = request_key(&key_type_logon, c->auth_key_name, NULL);
+ if (IS_ERR(keyring_key) && IS_REACHABLE(CONFIG_ENCRYPTED_KEYS))
+ keyring_key = request_key(&key_type_encrypted, c->auth_key_name, NULL);
+ if (IS_ERR(keyring_key) && IS_REACHABLE(CONFIG_TRUSTED_KEYS))
+ keyring_key = request_key(&key_type_trusted, c->auth_key_name, NULL);
if (IS_ERR(keyring_key)) {
ubifs_err(c, "Failed to request key: %ld",
@@ -286,12 +293,10 @@ int ubifs_init_authentication(struct ubifs_info *c)
down_read(&keyring_key->sem);
- ukp = user_key_payload_locked(keyring_key);
- if (!ukp) {
- /* key was revoked before we acquired its semaphore */
- err = -EKEYREVOKED;
+ key_material = key_extract_material(keyring_key, &len);
+ err = PTR_ERR_OR_ZERO(key_material);
+ if (err < 0)
goto out;
- }
c->hash_tfm = crypto_alloc_shash(c->auth_hash_name, 0, 0);
if (IS_ERR(c->hash_tfm)) {
@@ -324,7 +329,7 @@ int ubifs_init_authentication(struct ubifs_info *c)
goto out_free_hmac;
}
- err = crypto_shash_setkey(c->hmac_tfm, ukp->data, ukp->datalen);
+ err = crypto_shash_setkey(c->hmac_tfm, key_material, len);
if (err)
goto out_free_hmac;
--
git-series 0.9.1
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [dm-devel] [RFC PATCH v1 4/4] ubifs: auth: consult encrypted and trusted keys if no logon key was found
@ 2021-07-22 9:18 ` Ahmad Fatoum
0 siblings, 0 replies; 19+ messages in thread
From: Ahmad Fatoum @ 2021-07-22 9:18 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen, James Morris, Serge E. Hallyn,
Alasdair Kergon, Mike Snitzer, dm-devel, Song Liu,
Richard Weinberger, Jonathan Corbet
Cc: Ahmad Fatoum, linux-doc, linux-kernel, linux-raid,
linux-security-module, keyrings, linux-mtd, kernel,
linux-integrity
Currently, UBIFS auth_key can only be a logon key: This is a user key
that's provided to the kernel in plaintext and that then remains within
the kernel. Linux also supports trusted and encrypted keys, which have
stronger guarantees: They are only exposed to userspace in encrypted
form and, in the case of trusted keys, can be directly rooted to a trust
source like a TPM chip.
Add support for auth_key to be either a logon, encrypted or trusted key.
At mount time, the keyring will be searched for a key with the supplied
name in that order.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
To: David Howells <dhowells@redhat.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
To: James Morris <jmorris@namei.org>
To: "Serge E. Hallyn" <serge@hallyn.com>
To: Alasdair Kergon <agk@redhat.com>
To: Mike Snitzer <snitzer@redhat.com>
To: dm-devel@redhat.com
To: Song Liu <song@kernel.org>
To: Richard Weinberger <richard@nod.at>
To: Jonathan Corbet <corbet@lwn.net>
Cc: linux-kernel@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-raid@vger.kernel.org
Cc: keyrings@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
---
Documentation/filesystems/ubifs.rst | 2 +-
fs/ubifs/auth.c | 19 ++++++++++++-------
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/Documentation/filesystems/ubifs.rst b/Documentation/filesystems/ubifs.rst
index e6ee99762534..12d08458b3d7 100644
--- a/Documentation/filesystems/ubifs.rst
+++ b/Documentation/filesystems/ubifs.rst
@@ -101,7 +101,7 @@ compr=zlib override default compressor and set it to "zlib"
auth_key= specify the key used for authenticating the filesystem.
Passing this option makes authentication mandatory.
The passed key must be present in the kernel keyring
- and must be of type 'logon'
+ and must be of type 'logon', 'encrypted' or 'trusted'.
auth_hash_name= The hash algorithm used for authentication. Used for
both hashing and for creating HMACs. Typical values
include "sha256" or "sha512"
diff --git a/fs/ubifs/auth.c b/fs/ubifs/auth.c
index 6a0b8d858d81..af8e9eb58a60 100644
--- a/fs/ubifs/auth.c
+++ b/fs/ubifs/auth.c
@@ -14,6 +14,8 @@
#include <crypto/hash.h>
#include <crypto/algapi.h>
#include <keys/user-type.h>
+#include <keys/trusted-type.h>
+#include <keys/encrypted-type.h>
#include <keys/asymmetric-type.h>
#include "ubifs.h"
@@ -256,9 +258,10 @@ out_destroy:
int ubifs_init_authentication(struct ubifs_info *c)
{
struct key *keyring_key;
- const struct user_key_payload *ukp;
int err;
+ unsigned int len;
char hmac_name[CRYPTO_MAX_ALG_NAME];
+ const void *key_material;
if (!c->auth_hash_name) {
ubifs_err(c, "authentication hash name needed with authentication");
@@ -277,6 +280,10 @@ int ubifs_init_authentication(struct ubifs_info *c)
c->auth_hash_name);
keyring_key = request_key(&key_type_logon, c->auth_key_name, NULL);
+ if (IS_ERR(keyring_key) && IS_REACHABLE(CONFIG_ENCRYPTED_KEYS))
+ keyring_key = request_key(&key_type_encrypted, c->auth_key_name, NULL);
+ if (IS_ERR(keyring_key) && IS_REACHABLE(CONFIG_TRUSTED_KEYS))
+ keyring_key = request_key(&key_type_trusted, c->auth_key_name, NULL);
if (IS_ERR(keyring_key)) {
ubifs_err(c, "Failed to request key: %ld",
@@ -286,12 +293,10 @@ int ubifs_init_authentication(struct ubifs_info *c)
down_read(&keyring_key->sem);
- ukp = user_key_payload_locked(keyring_key);
- if (!ukp) {
- /* key was revoked before we acquired its semaphore */
- err = -EKEYREVOKED;
+ key_material = key_extract_material(keyring_key, &len);
+ err = PTR_ERR_OR_ZERO(key_material);
+ if (err < 0)
goto out;
- }
c->hash_tfm = crypto_alloc_shash(c->auth_hash_name, 0, 0);
if (IS_ERR(c->hash_tfm)) {
@@ -324,7 +329,7 @@ int ubifs_init_authentication(struct ubifs_info *c)
goto out_free_hmac;
}
- err = crypto_shash_setkey(c->hmac_tfm, ukp->data, ukp->datalen);
+ err = crypto_shash_setkey(c->hmac_tfm, key_material, len);
if (err)
goto out_free_hmac;
--
git-series 0.9.1
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [RFC PATCH v1 4/4] ubifs: auth: consult encrypted and trusted keys if no logon key was found
@ 2021-07-22 9:18 ` Ahmad Fatoum
0 siblings, 0 replies; 19+ messages in thread
From: Ahmad Fatoum @ 2021-07-22 9:18 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen, James Morris, Serge E. Hallyn,
Alasdair Kergon, Mike Snitzer, dm-devel, Song Liu,
Richard Weinberger, Jonathan Corbet
Cc: kernel, Ahmad Fatoum, linux-kernel, linux-doc, linux-raid,
keyrings, linux-mtd, linux-security-module, linux-integrity
Currently, UBIFS auth_key can only be a logon key: This is a user key
that's provided to the kernel in plaintext and that then remains within
the kernel. Linux also supports trusted and encrypted keys, which have
stronger guarantees: They are only exposed to userspace in encrypted
form and, in the case of trusted keys, can be directly rooted to a trust
source like a TPM chip.
Add support for auth_key to be either a logon, encrypted or trusted key.
At mount time, the keyring will be searched for a key with the supplied
name in that order.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
To: David Howells <dhowells@redhat.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
To: James Morris <jmorris@namei.org>
To: "Serge E. Hallyn" <serge@hallyn.com>
To: Alasdair Kergon <agk@redhat.com>
To: Mike Snitzer <snitzer@redhat.com>
To: dm-devel@redhat.com
To: Song Liu <song@kernel.org>
To: Richard Weinberger <richard@nod.at>
To: Jonathan Corbet <corbet@lwn.net>
Cc: linux-kernel@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-raid@vger.kernel.org
Cc: keyrings@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
---
Documentation/filesystems/ubifs.rst | 2 +-
fs/ubifs/auth.c | 19 ++++++++++++-------
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/Documentation/filesystems/ubifs.rst b/Documentation/filesystems/ubifs.rst
index e6ee99762534..12d08458b3d7 100644
--- a/Documentation/filesystems/ubifs.rst
+++ b/Documentation/filesystems/ubifs.rst
@@ -101,7 +101,7 @@ compr=zlib override default compressor and set it to "zlib"
auth_key= specify the key used for authenticating the filesystem.
Passing this option makes authentication mandatory.
The passed key must be present in the kernel keyring
- and must be of type 'logon'
+ and must be of type 'logon', 'encrypted' or 'trusted'.
auth_hash_name= The hash algorithm used for authentication. Used for
both hashing and for creating HMACs. Typical values
include "sha256" or "sha512"
diff --git a/fs/ubifs/auth.c b/fs/ubifs/auth.c
index 6a0b8d858d81..af8e9eb58a60 100644
--- a/fs/ubifs/auth.c
+++ b/fs/ubifs/auth.c
@@ -14,6 +14,8 @@
#include <crypto/hash.h>
#include <crypto/algapi.h>
#include <keys/user-type.h>
+#include <keys/trusted-type.h>
+#include <keys/encrypted-type.h>
#include <keys/asymmetric-type.h>
#include "ubifs.h"
@@ -256,9 +258,10 @@ out_destroy:
int ubifs_init_authentication(struct ubifs_info *c)
{
struct key *keyring_key;
- const struct user_key_payload *ukp;
int err;
+ unsigned int len;
char hmac_name[CRYPTO_MAX_ALG_NAME];
+ const void *key_material;
if (!c->auth_hash_name) {
ubifs_err(c, "authentication hash name needed with authentication");
@@ -277,6 +280,10 @@ int ubifs_init_authentication(struct ubifs_info *c)
c->auth_hash_name);
keyring_key = request_key(&key_type_logon, c->auth_key_name, NULL);
+ if (IS_ERR(keyring_key) && IS_REACHABLE(CONFIG_ENCRYPTED_KEYS))
+ keyring_key = request_key(&key_type_encrypted, c->auth_key_name, NULL);
+ if (IS_ERR(keyring_key) && IS_REACHABLE(CONFIG_TRUSTED_KEYS))
+ keyring_key = request_key(&key_type_trusted, c->auth_key_name, NULL);
if (IS_ERR(keyring_key)) {
ubifs_err(c, "Failed to request key: %ld",
@@ -286,12 +293,10 @@ int ubifs_init_authentication(struct ubifs_info *c)
down_read(&keyring_key->sem);
- ukp = user_key_payload_locked(keyring_key);
- if (!ukp) {
- /* key was revoked before we acquired its semaphore */
- err = -EKEYREVOKED;
+ key_material = key_extract_material(keyring_key, &len);
+ err = PTR_ERR_OR_ZERO(key_material);
+ if (err < 0)
goto out;
- }
c->hash_tfm = crypto_alloc_shash(c->auth_hash_name, 0, 0);
if (IS_ERR(c->hash_tfm)) {
@@ -324,7 +329,7 @@ int ubifs_init_authentication(struct ubifs_info *c)
goto out_free_hmac;
}
- err = crypto_shash_setkey(c->hmac_tfm, ukp->data, ukp->datalen);
+ err = crypto_shash_setkey(c->hmac_tfm, key_material, len);
if (err)
goto out_free_hmac;
--
git-series 0.9.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [RFC PATCH v1 4/4] ubifs: auth: consult encrypted and trusted keys if no logon key was found
2021-07-22 9:18 ` Ahmad Fatoum
(?)
(?)
@ 2021-07-22 14:45 ` kernel test robot
-1 siblings, 0 replies; 19+ messages in thread
From: kernel test robot @ 2021-07-22 14:45 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 5380 bytes --]
Hi Ahmad,
[FYI, it's a private test report for your RFC patch.]
[auto build test WARNING on 2734d6c1b1a089fb593ef6a23d4b70903526fe0c]
url: https://github.com/0day-ci/linux/commits/Ahmad-Fatoum/keys-introduce-key_extract_material-helper/20210722-172029
base: 2734d6c1b1a089fb593ef6a23d4b70903526fe0c
config: alpha-randconfig-r011-20210722 (attached as .config)
compiler: alpha-linux-gcc (GCC) 10.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/1f09360d0a6ad6d739b7d5195e8c71516d0c3381
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Ahmad-Fatoum/keys-introduce-key_extract_material-helper/20210722-172029
git checkout 1f09360d0a6ad6d739b7d5195e8c71516d0c3381
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-10.3.0 make.cross ARCH=alpha
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
fs/ubifs/auth.c: In function 'ubifs_init_authentication':
>> fs/ubifs/auth.c:285:6: warning: ignoring return value of 'IS_ERR' declared with attribute 'warn_unused_result' [-Wunused-result]
285 | if (IS_ERR(keyring_key) && IS_REACHABLE(CONFIG_TRUSTED_KEYS))
| ^~~~~~~~~~~~~~~~~~~
vim +285 fs/ubifs/auth.c
251
252 /**
253 * ubifs_init_authentication - initialize UBIFS authentication support
254 * @c: UBIFS file-system description object
255 *
256 * This function returns 0 for success or a negative error code otherwise.
257 */
258 int ubifs_init_authentication(struct ubifs_info *c)
259 {
260 struct key *keyring_key;
261 int err;
262 unsigned int len;
263 char hmac_name[CRYPTO_MAX_ALG_NAME];
264 const void *key_material;
265
266 if (!c->auth_hash_name) {
267 ubifs_err(c, "authentication hash name needed with authentication");
268 return -EINVAL;
269 }
270
271 c->auth_hash_algo = match_string(hash_algo_name, HASH_ALGO__LAST,
272 c->auth_hash_name);
273 if ((int)c->auth_hash_algo < 0) {
274 ubifs_err(c, "Unknown hash algo %s specified",
275 c->auth_hash_name);
276 return -EINVAL;
277 }
278
279 snprintf(hmac_name, CRYPTO_MAX_ALG_NAME, "hmac(%s)",
280 c->auth_hash_name);
281
282 keyring_key = request_key(&key_type_logon, c->auth_key_name, NULL);
283 if (IS_ERR(keyring_key) && IS_REACHABLE(CONFIG_ENCRYPTED_KEYS))
284 keyring_key = request_key(&key_type_encrypted, c->auth_key_name, NULL);
> 285 if (IS_ERR(keyring_key) && IS_REACHABLE(CONFIG_TRUSTED_KEYS))
286 keyring_key = request_key(&key_type_trusted, c->auth_key_name, NULL);
287
288 if (IS_ERR(keyring_key)) {
289 ubifs_err(c, "Failed to request key: %ld",
290 PTR_ERR(keyring_key));
291 return PTR_ERR(keyring_key);
292 }
293
294 down_read(&keyring_key->sem);
295
296 key_material = key_extract_material(keyring_key, &len);
297 err = PTR_ERR_OR_ZERO(key_material);
298 if (err < 0)
299 goto out;
300
301 c->hash_tfm = crypto_alloc_shash(c->auth_hash_name, 0, 0);
302 if (IS_ERR(c->hash_tfm)) {
303 err = PTR_ERR(c->hash_tfm);
304 ubifs_err(c, "Can not allocate %s: %d",
305 c->auth_hash_name, err);
306 goto out;
307 }
308
309 c->hash_len = crypto_shash_digestsize(c->hash_tfm);
310 if (c->hash_len > UBIFS_HASH_ARR_SZ) {
311 ubifs_err(c, "hash %s is bigger than maximum allowed hash size (%d > %d)",
312 c->auth_hash_name, c->hash_len, UBIFS_HASH_ARR_SZ);
313 err = -EINVAL;
314 goto out_free_hash;
315 }
316
317 c->hmac_tfm = crypto_alloc_shash(hmac_name, 0, 0);
318 if (IS_ERR(c->hmac_tfm)) {
319 err = PTR_ERR(c->hmac_tfm);
320 ubifs_err(c, "Can not allocate %s: %d", hmac_name, err);
321 goto out_free_hash;
322 }
323
324 c->hmac_desc_len = crypto_shash_digestsize(c->hmac_tfm);
325 if (c->hmac_desc_len > UBIFS_HMAC_ARR_SZ) {
326 ubifs_err(c, "hmac %s is bigger than maximum allowed hmac size (%d > %d)",
327 hmac_name, c->hmac_desc_len, UBIFS_HMAC_ARR_SZ);
328 err = -EINVAL;
329 goto out_free_hmac;
330 }
331
332 err = crypto_shash_setkey(c->hmac_tfm, key_material, len);
333 if (err)
334 goto out_free_hmac;
335
336 c->authenticated = true;
337
338 c->log_hash = ubifs_hash_get_desc(c);
339 if (IS_ERR(c->log_hash)) {
340 err = PTR_ERR(c->log_hash);
341 goto out_free_hmac;
342 }
343
344 err = 0;
345
346 out_free_hmac:
347 if (err)
348 crypto_free_shash(c->hmac_tfm);
349 out_free_hash:
350 if (err)
351 crypto_free_shash(c->hash_tfm);
352 out:
353 up_read(&keyring_key->sem);
354 key_put(keyring_key);
355
356 return err;
357 }
358
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 32997 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH v1 0/4] keys: introduce key_extract_material helper
2021-07-22 9:17 ` Ahmad Fatoum
(?)
@ 2021-08-06 10:53 ` Ahmad Fatoum
-1 siblings, 0 replies; 19+ messages in thread
From: Ahmad Fatoum @ 2021-08-06 10:53 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen, James Morris, Serge E. Hallyn,
Alasdair Kergon, Mike Snitzer, dm-devel, Song Liu,
Richard Weinberger
Cc: linux-kernel, linux-raid, linux-security-module, keyrings,
linux-mtd, kernel, linux-integrity
Hello everyone,
On 22.07.21 11:17, Ahmad Fatoum wrote:
> While keys of differing type have a common struct key definition, there is
> no common scheme to the payload and key material extraction differs.
>
> For kernel functionality that supports different key types,
> this means duplicated code for key material extraction and because key type
> is discriminated by a pointer to a global, users need to replicate
> reachability checks as well, so builtin code doesn't depend on a key
> type symbol offered by a module.
>
> Make this easier by adding a common helper with initial support for
> user, logon, encrypted and trusted keys.
>
> This series contains two example of its use: dm-crypt uses it to reduce
> boilerplate and ubifs authentication uses it to gain support for trusted
> and encrypted keys alongside the already supported logon keys.
>
> Looking forward to your feedback,
@Mike, Aliasdair: Do you think of key_extract_material as an improvement?
Does someone share the opinion that the helper is useful or should I drop
it and just send out the ubifs auth patch seperately?
Cheers,
Ahmad
> Ahmad
>
> ---
> To: David Howells <dhowells@redhat.com>
> To: Jarkko Sakkinen <jarkko@kernel.org>
> To: James Morris <jmorris@namei.org>
> To: "Serge E. Hallyn" <serge@hallyn.com>
> To: Alasdair Kergon <agk@redhat.com>
> To: Mike Snitzer <snitzer@redhat.com>
> To: dm-devel@redhat.com
> To: Song Liu <song@kernel.org>
> To: Richard Weinberger <richard@nod.at>
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-raid@vger.kernel.org
> Cc: linux-integrity@vger.kernel.org
> Cc: keyrings@vger.kernel.org
> Cc: linux-mtd@lists.infradead.org
> Cc: linux-security-module@vger.kernel.org
>
> Ahmad Fatoum (4):
> keys: introduce key_extract_material helper
> dm: crypt: use new key_extract_material helper
> ubifs: auth: remove never hit key type error check
> ubifs: auth: consult encrypted and trusted keys if no logon key was found
>
> Documentation/filesystems/ubifs.rst | 2 +-
> drivers/md/dm-crypt.c | 65 ++++--------------------------
> fs/ubifs/auth.c | 25 +++++-------
> include/linux/key.h | 45 +++++++++++++++++++++-
> security/keys/key.c | 40 ++++++++++++++++++-
> 5 files changed, 107 insertions(+), 70 deletions(-)
>
> base-commit: 2734d6c1b1a089fb593ef6a23d4b70903526fe0c
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dm-devel] [RFC PATCH v1 0/4] keys: introduce key_extract_material helper
@ 2021-08-06 10:53 ` Ahmad Fatoum
0 siblings, 0 replies; 19+ messages in thread
From: Ahmad Fatoum @ 2021-08-06 10:53 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen, James Morris, Serge E. Hallyn,
Alasdair Kergon, Mike Snitzer, dm-devel, Song Liu,
Richard Weinberger
Cc: linux-kernel, linux-raid, linux-security-module, keyrings,
linux-mtd, kernel, linux-integrity
Hello everyone,
On 22.07.21 11:17, Ahmad Fatoum wrote:
> While keys of differing type have a common struct key definition, there is
> no common scheme to the payload and key material extraction differs.
>
> For kernel functionality that supports different key types,
> this means duplicated code for key material extraction and because key type
> is discriminated by a pointer to a global, users need to replicate
> reachability checks as well, so builtin code doesn't depend on a key
> type symbol offered by a module.
>
> Make this easier by adding a common helper with initial support for
> user, logon, encrypted and trusted keys.
>
> This series contains two example of its use: dm-crypt uses it to reduce
> boilerplate and ubifs authentication uses it to gain support for trusted
> and encrypted keys alongside the already supported logon keys.
>
> Looking forward to your feedback,
@Mike, Aliasdair: Do you think of key_extract_material as an improvement?
Does someone share the opinion that the helper is useful or should I drop
it and just send out the ubifs auth patch seperately?
Cheers,
Ahmad
> Ahmad
>
> ---
> To: David Howells <dhowells@redhat.com>
> To: Jarkko Sakkinen <jarkko@kernel.org>
> To: James Morris <jmorris@namei.org>
> To: "Serge E. Hallyn" <serge@hallyn.com>
> To: Alasdair Kergon <agk@redhat.com>
> To: Mike Snitzer <snitzer@redhat.com>
> To: dm-devel@redhat.com
> To: Song Liu <song@kernel.org>
> To: Richard Weinberger <richard@nod.at>
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-raid@vger.kernel.org
> Cc: linux-integrity@vger.kernel.org
> Cc: keyrings@vger.kernel.org
> Cc: linux-mtd@lists.infradead.org
> Cc: linux-security-module@vger.kernel.org
>
> Ahmad Fatoum (4):
> keys: introduce key_extract_material helper
> dm: crypt: use new key_extract_material helper
> ubifs: auth: remove never hit key type error check
> ubifs: auth: consult encrypted and trusted keys if no logon key was found
>
> Documentation/filesystems/ubifs.rst | 2 +-
> drivers/md/dm-crypt.c | 65 ++++--------------------------
> fs/ubifs/auth.c | 25 +++++-------
> include/linux/key.h | 45 +++++++++++++++++++++-
> security/keys/key.c | 40 ++++++++++++++++++-
> 5 files changed, 107 insertions(+), 70 deletions(-)
>
> base-commit: 2734d6c1b1a089fb593ef6a23d4b70903526fe0c
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH v1 0/4] keys: introduce key_extract_material helper
@ 2021-08-06 10:53 ` Ahmad Fatoum
0 siblings, 0 replies; 19+ messages in thread
From: Ahmad Fatoum @ 2021-08-06 10:53 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen, James Morris, Serge E. Hallyn,
Alasdair Kergon, Mike Snitzer, dm-devel, Song Liu,
Richard Weinberger
Cc: linux-kernel, linux-raid, linux-security-module, keyrings,
linux-mtd, kernel, linux-integrity
Hello everyone,
On 22.07.21 11:17, Ahmad Fatoum wrote:
> While keys of differing type have a common struct key definition, there is
> no common scheme to the payload and key material extraction differs.
>
> For kernel functionality that supports different key types,
> this means duplicated code for key material extraction and because key type
> is discriminated by a pointer to a global, users need to replicate
> reachability checks as well, so builtin code doesn't depend on a key
> type symbol offered by a module.
>
> Make this easier by adding a common helper with initial support for
> user, logon, encrypted and trusted keys.
>
> This series contains two example of its use: dm-crypt uses it to reduce
> boilerplate and ubifs authentication uses it to gain support for trusted
> and encrypted keys alongside the already supported logon keys.
>
> Looking forward to your feedback,
@Mike, Aliasdair: Do you think of key_extract_material as an improvement?
Does someone share the opinion that the helper is useful or should I drop
it and just send out the ubifs auth patch seperately?
Cheers,
Ahmad
> Ahmad
>
> ---
> To: David Howells <dhowells@redhat.com>
> To: Jarkko Sakkinen <jarkko@kernel.org>
> To: James Morris <jmorris@namei.org>
> To: "Serge E. Hallyn" <serge@hallyn.com>
> To: Alasdair Kergon <agk@redhat.com>
> To: Mike Snitzer <snitzer@redhat.com>
> To: dm-devel@redhat.com
> To: Song Liu <song@kernel.org>
> To: Richard Weinberger <richard@nod.at>
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-raid@vger.kernel.org
> Cc: linux-integrity@vger.kernel.org
> Cc: keyrings@vger.kernel.org
> Cc: linux-mtd@lists.infradead.org
> Cc: linux-security-module@vger.kernel.org
>
> Ahmad Fatoum (4):
> keys: introduce key_extract_material helper
> dm: crypt: use new key_extract_material helper
> ubifs: auth: remove never hit key type error check
> ubifs: auth: consult encrypted and trusted keys if no logon key was found
>
> Documentation/filesystems/ubifs.rst | 2 +-
> drivers/md/dm-crypt.c | 65 ++++--------------------------
> fs/ubifs/auth.c | 25 +++++-------
> include/linux/key.h | 45 +++++++++++++++++++++-
> security/keys/key.c | 40 ++++++++++++++++++-
> 5 files changed, 107 insertions(+), 70 deletions(-)
>
> base-commit: 2734d6c1b1a089fb593ef6a23d4b70903526fe0c
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 19+ messages in thread