security/apparmor/Kconfig | 3 +- security/apparmor/crypto.c | 85 ++++++-------------------------------- 2 files changed, 13 insertions(+), 75 deletions(-)
From: Eric Biggers <ebiggers@google.com>
This user of SHA-256 does not support any other algorithm, so the
crypto_shash abstraction provides no value. Just use the SHA-256
library API instead, which is much simpler and easier to use.
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
This patch is targeting the apparmor tree for 6.16.
security/apparmor/Kconfig | 3 +-
security/apparmor/crypto.c | 85 ++++++--------------------------------
2 files changed, 13 insertions(+), 75 deletions(-)
diff --git a/security/apparmor/Kconfig b/security/apparmor/Kconfig
index 64cc3044a42ce..1e3bd44643dac 100644
--- a/security/apparmor/Kconfig
+++ b/security/apparmor/Kconfig
@@ -57,12 +57,11 @@ config SECURITY_APPARMOR_INTROSPECT_POLICY
cpu is paramount.
config SECURITY_APPARMOR_HASH
bool "Enable introspection of sha256 hashes for loaded profiles"
depends on SECURITY_APPARMOR_INTROSPECT_POLICY
- select CRYPTO
- select CRYPTO_SHA256
+ select CRYPTO_LIB_SHA256
default y
help
This option selects whether introspection of loaded policy
hashes is available to userspace via the apparmor
filesystem. This option provides a light weight means of
diff --git a/security/apparmor/crypto.c b/security/apparmor/crypto.c
index aad486b2fca65..40e17e153f1e5 100644
--- a/security/apparmor/crypto.c
+++ b/security/apparmor/crypto.c
@@ -9,115 +9,54 @@
* Fns to provide a checksum of policy that has been loaded this can be
* compared to userspace policy compiles to check loaded policy is what
* it should be.
*/
-#include <crypto/hash.h>
+#include <crypto/sha2.h>
#include "include/apparmor.h"
#include "include/crypto.h"
-static unsigned int apparmor_hash_size;
-
-static struct crypto_shash *apparmor_tfm;
-
unsigned int aa_hash_size(void)
{
- return apparmor_hash_size;
+ return SHA256_DIGEST_SIZE;
}
char *aa_calc_hash(void *data, size_t len)
{
- SHASH_DESC_ON_STACK(desc, apparmor_tfm);
char *hash;
- int error;
-
- if (!apparmor_tfm)
- return NULL;
- hash = kzalloc(apparmor_hash_size, GFP_KERNEL);
+ hash = kzalloc(SHA256_DIGEST_SIZE, GFP_KERNEL);
if (!hash)
return ERR_PTR(-ENOMEM);
- desc->tfm = apparmor_tfm;
-
- error = crypto_shash_init(desc);
- if (error)
- goto fail;
- error = crypto_shash_update(desc, (u8 *) data, len);
- if (error)
- goto fail;
- error = crypto_shash_final(desc, hash);
- if (error)
- goto fail;
-
+ sha256(data, len, hash);
return hash;
-
-fail:
- kfree(hash);
-
- return ERR_PTR(error);
}
int aa_calc_profile_hash(struct aa_profile *profile, u32 version, void *start,
size_t len)
{
- SHASH_DESC_ON_STACK(desc, apparmor_tfm);
- int error;
+ struct sha256_state state;
__le32 le32_version = cpu_to_le32(version);
if (!aa_g_hash_policy)
return 0;
- if (!apparmor_tfm)
- return 0;
-
- profile->hash = kzalloc(apparmor_hash_size, GFP_KERNEL);
+ profile->hash = kzalloc(SHA256_DIGEST_SIZE, GFP_KERNEL);
if (!profile->hash)
return -ENOMEM;
- desc->tfm = apparmor_tfm;
-
- error = crypto_shash_init(desc);
- if (error)
- goto fail;
- error = crypto_shash_update(desc, (u8 *) &le32_version, 4);
- if (error)
- goto fail;
- error = crypto_shash_update(desc, (u8 *) start, len);
- if (error)
- goto fail;
- error = crypto_shash_final(desc, profile->hash);
- if (error)
- goto fail;
-
+ sha256_init(&state);
+ sha256_update(&state, (u8 *)&le32_version, 4);
+ sha256_update(&state, (u8 *)start, len);
+ sha256_final(&state, profile->hash);
return 0;
-
-fail:
- kfree(profile->hash);
- profile->hash = NULL;
-
- return error;
}
static int __init init_profile_hash(void)
{
- struct crypto_shash *tfm;
-
- if (!apparmor_initialized)
- return 0;
-
- tfm = crypto_alloc_shash("sha256", 0, 0);
- if (IS_ERR(tfm)) {
- int error = PTR_ERR(tfm);
- AA_ERROR("failed to setup profile sha256 hashing: %d\n", error);
- return error;
- }
- apparmor_tfm = tfm;
- apparmor_hash_size = crypto_shash_digestsize(apparmor_tfm);
-
- aa_info_message("AppArmor sha256 policy hashing enabled");
-
+ if (apparmor_initialized)
+ aa_info_message("AppArmor sha256 policy hashing enabled");
return 0;
}
-
late_initcall(init_profile_hash);
base-commit: 33035b665157558254b3c21c3f049fd728e72368
--
2.49.0On 4/28/25 12:04, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> This user of SHA-256 does not support any other algorithm, so the
> crypto_shash abstraction provides no value. Just use the SHA-256
> library API instead, which is much simpler and easier to use.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Acked-by: John Johansen <john.johansen@canonical.com>
> ---
>
> This patch is targeting the apparmor tree for 6.16.
>
> security/apparmor/Kconfig | 3 +-
> security/apparmor/crypto.c | 85 ++++++--------------------------------
> 2 files changed, 13 insertions(+), 75 deletions(-)
>
> diff --git a/security/apparmor/Kconfig b/security/apparmor/Kconfig
> index 64cc3044a42ce..1e3bd44643dac 100644
> --- a/security/apparmor/Kconfig
> +++ b/security/apparmor/Kconfig
> @@ -57,12 +57,11 @@ config SECURITY_APPARMOR_INTROSPECT_POLICY
> cpu is paramount.
>
> config SECURITY_APPARMOR_HASH
> bool "Enable introspection of sha256 hashes for loaded profiles"
> depends on SECURITY_APPARMOR_INTROSPECT_POLICY
> - select CRYPTO
> - select CRYPTO_SHA256
> + select CRYPTO_LIB_SHA256
> default y
> help
> This option selects whether introspection of loaded policy
> hashes is available to userspace via the apparmor
> filesystem. This option provides a light weight means of
> diff --git a/security/apparmor/crypto.c b/security/apparmor/crypto.c
> index aad486b2fca65..40e17e153f1e5 100644
> --- a/security/apparmor/crypto.c
> +++ b/security/apparmor/crypto.c
> @@ -9,115 +9,54 @@
> * Fns to provide a checksum of policy that has been loaded this can be
> * compared to userspace policy compiles to check loaded policy is what
> * it should be.
> */
>
> -#include <crypto/hash.h>
> +#include <crypto/sha2.h>
>
> #include "include/apparmor.h"
> #include "include/crypto.h"
>
> -static unsigned int apparmor_hash_size;
> -
> -static struct crypto_shash *apparmor_tfm;
> -
> unsigned int aa_hash_size(void)
> {
> - return apparmor_hash_size;
> + return SHA256_DIGEST_SIZE;
> }
>
> char *aa_calc_hash(void *data, size_t len)
> {
> - SHASH_DESC_ON_STACK(desc, apparmor_tfm);
> char *hash;
> - int error;
> -
> - if (!apparmor_tfm)
> - return NULL;
>
> - hash = kzalloc(apparmor_hash_size, GFP_KERNEL);
> + hash = kzalloc(SHA256_DIGEST_SIZE, GFP_KERNEL);
> if (!hash)
> return ERR_PTR(-ENOMEM);
>
> - desc->tfm = apparmor_tfm;
> -
> - error = crypto_shash_init(desc);
> - if (error)
> - goto fail;
> - error = crypto_shash_update(desc, (u8 *) data, len);
> - if (error)
> - goto fail;
> - error = crypto_shash_final(desc, hash);
> - if (error)
> - goto fail;
> -
> + sha256(data, len, hash);
> return hash;
> -
> -fail:
> - kfree(hash);
> -
> - return ERR_PTR(error);
> }
>
> int aa_calc_profile_hash(struct aa_profile *profile, u32 version, void *start,
> size_t len)
> {
> - SHASH_DESC_ON_STACK(desc, apparmor_tfm);
> - int error;
> + struct sha256_state state;
> __le32 le32_version = cpu_to_le32(version);
>
> if (!aa_g_hash_policy)
> return 0;
>
> - if (!apparmor_tfm)
> - return 0;
> -
> - profile->hash = kzalloc(apparmor_hash_size, GFP_KERNEL);
> + profile->hash = kzalloc(SHA256_DIGEST_SIZE, GFP_KERNEL);
> if (!profile->hash)
> return -ENOMEM;
>
> - desc->tfm = apparmor_tfm;
> -
> - error = crypto_shash_init(desc);
> - if (error)
> - goto fail;
> - error = crypto_shash_update(desc, (u8 *) &le32_version, 4);
> - if (error)
> - goto fail;
> - error = crypto_shash_update(desc, (u8 *) start, len);
> - if (error)
> - goto fail;
> - error = crypto_shash_final(desc, profile->hash);
> - if (error)
> - goto fail;
> -
> + sha256_init(&state);
> + sha256_update(&state, (u8 *)&le32_version, 4);
> + sha256_update(&state, (u8 *)start, len);
> + sha256_final(&state, profile->hash);
> return 0;
> -
> -fail:
> - kfree(profile->hash);
> - profile->hash = NULL;
> -
> - return error;
> }
>
> static int __init init_profile_hash(void)
> {
> - struct crypto_shash *tfm;
> -
> - if (!apparmor_initialized)
> - return 0;
> -
> - tfm = crypto_alloc_shash("sha256", 0, 0);
> - if (IS_ERR(tfm)) {
> - int error = PTR_ERR(tfm);
> - AA_ERROR("failed to setup profile sha256 hashing: %d\n", error);
> - return error;
> - }
> - apparmor_tfm = tfm;
> - apparmor_hash_size = crypto_shash_digestsize(apparmor_tfm);
> -
> - aa_info_message("AppArmor sha256 policy hashing enabled");
> -
> + if (apparmor_initialized)
> + aa_info_message("AppArmor sha256 policy hashing enabled");
> return 0;
> }
> -
> late_initcall(init_profile_hash);
>
> base-commit: 33035b665157558254b3c21c3f049fd728e72368
On Mon, Apr 28, 2025 at 12:04:30PM -0700, Eric Biggers wrote: > From: Eric Biggers <ebiggers@google.com> > > This user of SHA-256 does not support any other algorithm, so the > crypto_shash abstraction provides no value. Just use the SHA-256 > library API instead, which is much simpler and easier to use. > > Signed-off-by: Eric Biggers <ebiggers@google.com> > --- > > This patch is targeting the apparmor tree for 6.16. > > security/apparmor/Kconfig | 3 +- > security/apparmor/crypto.c | 85 ++++++-------------------------------- > 2 files changed, 13 insertions(+), 75 deletions(-) Any interest in taking this patch through the apparmor or security trees? - Eric
On 5/13/25 21:21, Eric Biggers wrote: > On Mon, Apr 28, 2025 at 12:04:30PM -0700, Eric Biggers wrote: >> From: Eric Biggers <ebiggers@google.com> >> >> This user of SHA-256 does not support any other algorithm, so the >> crypto_shash abstraction provides no value. Just use the SHA-256 >> library API instead, which is much simpler and easier to use. >> >> Signed-off-by: Eric Biggers <ebiggers@google.com> >> --- >> >> This patch is targeting the apparmor tree for 6.16. >> >> security/apparmor/Kconfig | 3 +- >> security/apparmor/crypto.c | 85 ++++++-------------------------------- >> 2 files changed, 13 insertions(+), 75 deletions(-) > > Any interest in taking this patch through the apparmor or security trees? > I can take it through my tree
On Sat, May 17, 2025 at 12:43:30AM -0700, John Johansen wrote: > On 5/13/25 21:21, Eric Biggers wrote: > > On Mon, Apr 28, 2025 at 12:04:30PM -0700, Eric Biggers wrote: > > > From: Eric Biggers <ebiggers@google.com> > > > > > > This user of SHA-256 does not support any other algorithm, so the > > > crypto_shash abstraction provides no value. Just use the SHA-256 > > > library API instead, which is much simpler and easier to use. > > > > > > Signed-off-by: Eric Biggers <ebiggers@google.com> > > > --- > > > > > > This patch is targeting the apparmor tree for 6.16. > > > > > > security/apparmor/Kconfig | 3 +- > > > security/apparmor/crypto.c | 85 ++++++-------------------------------- > > > 2 files changed, 13 insertions(+), 75 deletions(-) > > > > Any interest in taking this patch through the apparmor or security trees? > > > I can take it through my tree Thanks! I notice this isn't in v6.16-rc1. Do you have a pull request planned? - Eric
On 6/12/25 12:11, Eric Biggers wrote: > On Sat, May 17, 2025 at 12:43:30AM -0700, John Johansen wrote: >> On 5/13/25 21:21, Eric Biggers wrote: >>> On Mon, Apr 28, 2025 at 12:04:30PM -0700, Eric Biggers wrote: >>>> From: Eric Biggers <ebiggers@google.com> >>>> >>>> This user of SHA-256 does not support any other algorithm, so the >>>> crypto_shash abstraction provides no value. Just use the SHA-256 >>>> library API instead, which is much simpler and easier to use. >>>> >>>> Signed-off-by: Eric Biggers <ebiggers@google.com> >>>> --- >>>> >>>> This patch is targeting the apparmor tree for 6.16. >>>> >>>> security/apparmor/Kconfig | 3 +- >>>> security/apparmor/crypto.c | 85 ++++++-------------------------------- >>>> 2 files changed, 13 insertions(+), 75 deletions(-) >>> >>> Any interest in taking this patch through the apparmor or security trees? >>> >> I can take it through my tree > > Thanks! I notice this isn't in v6.16-rc1. Do you have a pull request planned? > Hey Eric, sorry I have been sick and didn't get a 6.16 pull request out. I am slowly trying to dig my way out of the backlog, which is several weeks deeo. I might get together a small PR of bug fixes before the 6.17 merge window but the bulk of what is in apparmor-next will be waiting to merge in 6.17 now.
On Sun, Jun 22, 2025 at 02:16:07PM -0700, John Johansen wrote: > On 6/12/25 12:11, Eric Biggers wrote: > > On Sat, May 17, 2025 at 12:43:30AM -0700, John Johansen wrote: > > > On 5/13/25 21:21, Eric Biggers wrote: > > > > On Mon, Apr 28, 2025 at 12:04:30PM -0700, Eric Biggers wrote: > > > > > From: Eric Biggers <ebiggers@google.com> > > > > > > > > > > This user of SHA-256 does not support any other algorithm, so the > > > > > crypto_shash abstraction provides no value. Just use the SHA-256 > > > > > library API instead, which is much simpler and easier to use. > > > > > > > > > > Signed-off-by: Eric Biggers <ebiggers@google.com> > > > > > --- > > > > > > > > > > This patch is targeting the apparmor tree for 6.16. > > > > > > > > > > security/apparmor/Kconfig | 3 +- > > > > > security/apparmor/crypto.c | 85 ++++++-------------------------------- > > > > > 2 files changed, 13 insertions(+), 75 deletions(-) > > > > > > > > Any interest in taking this patch through the apparmor or security trees? > > > > > > > I can take it through my tree > > > > Thanks! I notice this isn't in v6.16-rc1. Do you have a pull request planned? > > > > Hey Eric, > > sorry I have been sick and didn't get a 6.16 pull request out. I am slowly trying > to dig my way out of the backlog, which is several weeks deeo. I might get together > a small PR of bug fixes before the 6.17 merge window but the bulk of what is in > apparmor-next will be waiting to merge in 6.17 now. Hope you're feeling better! Actually, would you mind if instead I took this patch (with your ack) through the libcrypto-next tree for 6.17? Otherwise there will be a silent merge conflict after I apply https://lore.kernel.org/r/20250625070819.1496119-11-ebiggers@kernel.org/ - Eric
On 6/26/25 20:59, Eric Biggers wrote: > On Sun, Jun 22, 2025 at 02:16:07PM -0700, John Johansen wrote: >> On 6/12/25 12:11, Eric Biggers wrote: >>> On Sat, May 17, 2025 at 12:43:30AM -0700, John Johansen wrote: >>>> On 5/13/25 21:21, Eric Biggers wrote: >>>>> On Mon, Apr 28, 2025 at 12:04:30PM -0700, Eric Biggers wrote: >>>>>> From: Eric Biggers <ebiggers@google.com> >>>>>> >>>>>> This user of SHA-256 does not support any other algorithm, so the >>>>>> crypto_shash abstraction provides no value. Just use the SHA-256 >>>>>> library API instead, which is much simpler and easier to use. >>>>>> >>>>>> Signed-off-by: Eric Biggers <ebiggers@google.com> >>>>>> --- >>>>>> >>>>>> This patch is targeting the apparmor tree for 6.16. >>>>>> >>>>>> security/apparmor/Kconfig | 3 +- >>>>>> security/apparmor/crypto.c | 85 ++++++-------------------------------- >>>>>> 2 files changed, 13 insertions(+), 75 deletions(-) >>>>> >>>>> Any interest in taking this patch through the apparmor or security trees? >>>>> >>>> I can take it through my tree >>> >>> Thanks! I notice this isn't in v6.16-rc1. Do you have a pull request planned? >>> >> >> Hey Eric, >> >> sorry I have been sick and didn't get a 6.16 pull request out. I am slowly trying >> to dig my way out of the backlog, which is several weeks deeo. I might get together >> a small PR of bug fixes before the 6.17 merge window but the bulk of what is in >> apparmor-next will be waiting to merge in 6.17 now. > > Hope you're feeling better! Actually, would you mind if instead I took this I lot, though still generally tired/low on energy > patch (with your ack) through the libcrypto-next tree for 6.17? > Otherwise there will be a silent merge conflict after I apply > https://lore.kernel.org/r/20250625070819.1496119-11-ebiggers@kernel.org/ > Avoiding a merge conflict? You have my ACK and blessing I will pull it out of the apparmor tree asap
On Thu, Jun 26, 2025 at 11:14:50PM -0700, John Johansen wrote: > On 6/26/25 20:59, Eric Biggers wrote: > > On Sun, Jun 22, 2025 at 02:16:07PM -0700, John Johansen wrote: > > > On 6/12/25 12:11, Eric Biggers wrote: > > > > On Sat, May 17, 2025 at 12:43:30AM -0700, John Johansen wrote: > > > > > On 5/13/25 21:21, Eric Biggers wrote: > > > > > > On Mon, Apr 28, 2025 at 12:04:30PM -0700, Eric Biggers wrote: > > > > > > > From: Eric Biggers <ebiggers@google.com> > > > > > > > > > > > > > > This user of SHA-256 does not support any other algorithm, so the > > > > > > > crypto_shash abstraction provides no value. Just use the SHA-256 > > > > > > > library API instead, which is much simpler and easier to use. > > > > > > > > > > > > > > Signed-off-by: Eric Biggers <ebiggers@google.com> > > > > > > > --- > > > > > > > > > > > > > > This patch is targeting the apparmor tree for 6.16. > > > > > > > > > > > > > > security/apparmor/Kconfig | 3 +- > > > > > > > security/apparmor/crypto.c | 85 ++++++-------------------------------- > > > > > > > 2 files changed, 13 insertions(+), 75 deletions(-) > > > > > > > > > > > > Any interest in taking this patch through the apparmor or security trees? > > > > > > > > > > > I can take it through my tree > > > > > > > > Thanks! I notice this isn't in v6.16-rc1. Do you have a pull request planned? > > > > > > > > > > Hey Eric, > > > > > > sorry I have been sick and didn't get a 6.16 pull request out. I am slowly trying > > > to dig my way out of the backlog, which is several weeks deeo. I might get together > > > a small PR of bug fixes before the 6.17 merge window but the bulk of what is in > > > apparmor-next will be waiting to merge in 6.17 now. > > > > Hope you're feeling better! Actually, would you mind if instead I took this > I lot, though still generally tired/low on energy > > > patch (with your ack) through the libcrypto-next tree for 6.17? > > Otherwise there will be a silent merge conflict after I apply > > https://lore.kernel.org/r/20250625070819.1496119-11-ebiggers@kernel.org/ > > > Avoiding a merge conflict? You have my ACK and blessing I will pull it out of > the apparmor tree asap Thanks, let me know once you've dropped it. - Eric
On Wed, May 14, 2025 at 12:22 AM Eric Biggers <ebiggers@kernel.org> wrote: > On Mon, Apr 28, 2025 at 12:04:30PM -0700, Eric Biggers wrote: > > From: Eric Biggers <ebiggers@google.com> > > > > This user of SHA-256 does not support any other algorithm, so the > > crypto_shash abstraction provides no value. Just use the SHA-256 > > library API instead, which is much simpler and easier to use. > > > > Signed-off-by: Eric Biggers <ebiggers@google.com> > > --- > > > > This patch is targeting the apparmor tree for 6.16. > > > > security/apparmor/Kconfig | 3 +- > > security/apparmor/crypto.c | 85 ++++++-------------------------------- > > 2 files changed, 13 insertions(+), 75 deletions(-) > > Any interest in taking this patch through the apparmor or security trees? Something like this would need to go through the AppArmor tree. As a FYI, the AppArmor devs are fairly busy at the moment so it may take a bit for them to get around to this. -- paul-moore.com
On 5/14/25 14:57, Paul Moore wrote: > On Wed, May 14, 2025 at 12:22 AM Eric Biggers <ebiggers@kernel.org> wrote: >> On Mon, Apr 28, 2025 at 12:04:30PM -0700, Eric Biggers wrote: >>> From: Eric Biggers <ebiggers@google.com> >>> >>> This user of SHA-256 does not support any other algorithm, so the >>> crypto_shash abstraction provides no value. Just use the SHA-256 >>> library API instead, which is much simpler and easier to use. >>> >>> Signed-off-by: Eric Biggers <ebiggers@google.com> >>> --- >>> >>> This patch is targeting the apparmor tree for 6.16. >>> >>> security/apparmor/Kconfig | 3 +- >>> security/apparmor/crypto.c | 85 ++++++-------------------------------- >>> 2 files changed, 13 insertions(+), 75 deletions(-) >> >> Any interest in taking this patch through the apparmor or security trees? > > Something like this would need to go through the AppArmor tree. As a > FYI, the AppArmor devs are fairly busy at the moment so it may take a > bit for them to get around to this. > I am going to see how much of the backlog I can get through while traveling replies might get batch because I will be mostly off line but hopefully I can deal with most of it this weekend.
© 2016 - 2026 Red Hat, Inc.