mbox series

[v2,00/41] RPCSEC GSS krb5 enhancements

Message ID 167380196429.10651.4103075913257868035.stgit@bazille.1015granger.net (mailing list archive)
Headers show
Series RPCSEC GSS krb5 enhancements | expand

Message

Chuck Lever Jan. 15, 2023, 5:20 p.m. UTC
The purpose of this series is to improve/harden the security
provided by the Linux kernel's RPCSEC GSS Kerberos 5 mechanism.
There are lots of clean-ups in this series, but the pertinent
feature is the addition of a clean deprecation path for the DES-
and SHA1-based encryption types in accordance with Internet BCPs.

This series disables DES-based enctypes by default, provides a
mechanism for disabling SHA1-based enctypes, and introduces two
modern enctypes that do not use deprecated crypto algorithms.

Not only does that improve security for Kerberos 5 users, but it
also prepares SunRPC for eventually switching to a shared common
kernel Kerberos 5 implementation, which surely will not implement
any deprecated encryption types (in particular, DES-based ones).

Today, MIT supports both of the newly-introduced enctypes, but
Heimdal does not appear to. Thus distributions can enable and
disable kernel enctype support to match the set of enctypes
supported in their user space Kerberos libraries.

Scott has been kicking the tires -- we've found no regressions with
the current SHA1-based enctypes, while the new ones are disabled by
default until we have an opportunity for interop testing. The KUnit
tests for the new enctypes pass and this implementation successfully
interoperates with itself using these enctypes. Therefore I believe
it to be safe to merge.

When this series gets merged, the Linux NFS community should select
and announce a date-certain for removal of SunRPC's DES-based
enctype code.

---

Changes since v1:
- Addressed Simo's NAK on "SUNRPC: Improve Kerberos confounder generation"
- Added Cc: linux-kselftest@ for review of the KUnit-related patches


Chuck Lever (41):
      SUNRPC: Add header ifdefs to linux/sunrpc/gss_krb5.h
      SUNRPC: Remove .blocksize field from struct gss_krb5_enctype
      SUNRPC: Remove .conflen field from struct gss_krb5_enctype
      SUNRPC: Improve Kerberos confounder generation
      SUNRPC: Obscure Kerberos session key
      SUNRPC: Refactor set-up for aux_cipher
      SUNRPC: Obscure Kerberos encryption keys
      SUNRPC: Obscure Kerberos signing keys
      SUNRPC: Obscure Kerberos integrity keys
      SUNRPC: Refactor the GSS-API Per Message calls in the Kerberos mechanism
      SUNRPC: Remove another switch on ctx->enctype
      SUNRPC: Add /proc/net/rpc/gss_krb5_enctypes file
      NFSD: Replace /proc/fs/nfsd/supported_krb5_enctypes with a symlink
      SUNRPC: Replace KRB5_SUPPORTED_ENCTYPES macro
      SUNRPC: Enable rpcsec_gss_krb5.ko to be built without CRYPTO_DES
      SUNRPC: Remove ->encrypt and ->decrypt methods from struct gss_krb5_enctype
      SUNRPC: Rename .encrypt_v2 and .decrypt_v2 methods
      SUNRPC: Hoist KDF into struct gss_krb5_enctype
      SUNRPC: Clean up cipher set up for v1 encryption types
      SUNRPC: Parametrize the key length passed to context_v2_alloc_cipher()
      SUNRPC: Add new subkey length fields
      SUNRPC: Refactor CBC with CTS into helpers
      SUNRPC: Add gk5e definitions for RFC 8009 encryption types
      SUNRPC: Add KDF-HMAC-SHA2
      SUNRPC: Add RFC 8009 encryption and decryption functions
      SUNRPC: Advertise support for RFC 8009 encryption types
      SUNRPC: Support the Camellia enctypes
      SUNRPC: Add KDF_FEEDBACK_CMAC
      SUNRPC: Advertise support for the Camellia encryption types
      SUNRPC: Move remaining internal definitions to gss_krb5_internal.h
      SUNRPC: Add KUnit tests for rpcsec_krb5.ko
      SUNRPC: Export get_gss_krb5_enctype()
      SUNRPC: Add KUnit tests RFC 3961 Key Derivation
      SUNRPC: Add Kunit tests for RFC 3962-defined encryption/decryption
      SUNRPC: Add KDF KUnit tests for the RFC 6803 encryption types
      SUNRPC: Add checksum KUnit tests for the RFC 6803 encryption types
      SUNRPC: Add encryption KUnit tests for the RFC 6803 encryption types
      SUNRPC: Add KDF-HMAC-SHA2 Kunit tests
      SUNRPC: Add RFC 8009 checksum KUnit tests
      SUNRPC: Add RFC 8009 encryption KUnit tests
      SUNRPC: Add encryption self-tests


 fs/nfsd/nfsctl.c                         |   74 +-
 include/linux/sunrpc/gss_krb5.h          |  196 +--
 include/linux/sunrpc/gss_krb5_enctypes.h |   41 -
 net/sunrpc/.kunitconfig                  |   30 +
 net/sunrpc/Kconfig                       |   96 +-
 net/sunrpc/auth_gss/Makefile             |    2 +
 net/sunrpc/auth_gss/auth_gss.c           |   17 +
 net/sunrpc/auth_gss/gss_krb5_crypto.c    |  656 +++++--
 net/sunrpc/auth_gss/gss_krb5_internal.h  |  232 +++
 net/sunrpc/auth_gss/gss_krb5_keys.c      |  416 ++++-
 net/sunrpc/auth_gss/gss_krb5_mech.c      |  730 +++++---
 net/sunrpc/auth_gss/gss_krb5_seal.c      |  122 +-
 net/sunrpc/auth_gss/gss_krb5_seqnum.c    |    2 +
 net/sunrpc/auth_gss/gss_krb5_test.c      | 2040 ++++++++++++++++++++++
 net/sunrpc/auth_gss/gss_krb5_unseal.c    |   63 +-
 net/sunrpc/auth_gss/gss_krb5_wrap.c      |  124 +-
 net/sunrpc/auth_gss/svcauth_gss.c        |   65 +
 17 files changed, 4001 insertions(+), 905 deletions(-)
 delete mode 100644 include/linux/sunrpc/gss_krb5_enctypes.h
 create mode 100644 net/sunrpc/.kunitconfig
 create mode 100644 net/sunrpc/auth_gss/gss_krb5_internal.h
 create mode 100644 net/sunrpc/auth_gss/gss_krb5_test.c

--
Chuck Lever

Comments

Simo Sorce Jan. 18, 2023, 4:02 p.m. UTC | #1
On Sun, 2023-01-15 at 12:20 -0500, Chuck Lever wrote:
> The purpose of this series is to improve/harden the security
> provided by the Linux kernel's RPCSEC GSS Kerberos 5 mechanism.
> There are lots of clean-ups in this series, but the pertinent
> feature is the addition of a clean deprecation path for the DES-
> and SHA1-based encryption types in accordance with Internet BCPs.
> 
> This series disables DES-based enctypes by default, provides a
> mechanism for disabling SHA1-based enctypes, and introduces two
> modern enctypes that do not use deprecated crypto algorithms.
> 
> Not only does that improve security for Kerberos 5 users, but it
> also prepares SunRPC for eventually switching to a shared common
> kernel Kerberos 5 implementation, which surely will not implement
> any deprecated encryption types (in particular, DES-based ones).
> 
> Today, MIT supports both of the newly-introduced enctypes, but
> Heimdal does not appear to. Thus distributions can enable and
> disable kernel enctype support to match the set of enctypes
> supported in their user space Kerberos libraries.
> 
> Scott has been kicking the tires -- we've found no regressions with
> the current SHA1-based enctypes, while the new ones are disabled by
> default until we have an opportunity for interop testing. The KUnit
> tests for the new enctypes pass and this implementation successfully
> interoperates with itself using these enctypes. Therefore I believe
> it to be safe to merge.
> 
> When this series gets merged, the Linux NFS community should select
> and announce a date-certain for removal of SunRPC's DES-based
> enctype code.
> 
> ---
> 
> Changes since v1:
> - Addressed Simo's NAK on "SUNRPC: Improve Kerberos confounder generation"
> - Added Cc: linux-kselftest@ for review of the KUnit-related patches
> 
> 
> Chuck Lever (41):
>       SUNRPC: Add header ifdefs to linux/sunrpc/gss_krb5.h
>       SUNRPC: Remove .blocksize field from struct gss_krb5_enctype
>       SUNRPC: Remove .conflen field from struct gss_krb5_enctype
>       SUNRPC: Improve Kerberos confounder generation
>       SUNRPC: Obscure Kerberos session key
>       SUNRPC: Refactor set-up for aux_cipher
>       SUNRPC: Obscure Kerberos encryption keys
>       SUNRPC: Obscure Kerberos signing keys
>       SUNRPC: Obscure Kerberos integrity keys
>       SUNRPC: Refactor the GSS-API Per Message calls in the Kerberos mechanism
>       SUNRPC: Remove another switch on ctx->enctype
>       SUNRPC: Add /proc/net/rpc/gss_krb5_enctypes file
>       NFSD: Replace /proc/fs/nfsd/supported_krb5_enctypes with a symlink
>       SUNRPC: Replace KRB5_SUPPORTED_ENCTYPES macro
>       SUNRPC: Enable rpcsec_gss_krb5.ko to be built without CRYPTO_DES
>       SUNRPC: Remove ->encrypt and ->decrypt methods from struct gss_krb5_enctype
>       SUNRPC: Rename .encrypt_v2 and .decrypt_v2 methods
>       SUNRPC: Hoist KDF into struct gss_krb5_enctype
>       SUNRPC: Clean up cipher set up for v1 encryption types
>       SUNRPC: Parametrize the key length passed to context_v2_alloc_cipher()
>       SUNRPC: Add new subkey length fields
>       SUNRPC: Refactor CBC with CTS into helpers
>       SUNRPC: Add gk5e definitions for RFC 8009 encryption types
>       SUNRPC: Add KDF-HMAC-SHA2
>       SUNRPC: Add RFC 8009 encryption and decryption functions
>       SUNRPC: Advertise support for RFC 8009 encryption types
>       SUNRPC: Support the Camellia enctypes
>       SUNRPC: Add KDF_FEEDBACK_CMAC
>       SUNRPC: Advertise support for the Camellia encryption types
>       SUNRPC: Move remaining internal definitions to gss_krb5_internal.h
>       SUNRPC: Add KUnit tests for rpcsec_krb5.ko
>       SUNRPC: Export get_gss_krb5_enctype()
>       SUNRPC: Add KUnit tests RFC 3961 Key Derivation
>       SUNRPC: Add Kunit tests for RFC 3962-defined encryption/decryption
>       SUNRPC: Add KDF KUnit tests for the RFC 6803 encryption types
>       SUNRPC: Add checksum KUnit tests for the RFC 6803 encryption types
>       SUNRPC: Add encryption KUnit tests for the RFC 6803 encryption types
>       SUNRPC: Add KDF-HMAC-SHA2 Kunit tests
>       SUNRPC: Add RFC 8009 checksum KUnit tests
>       SUNRPC: Add RFC 8009 encryption KUnit tests
>       SUNRPC: Add encryption self-tests
> 
> 
>  fs/nfsd/nfsctl.c                         |   74 +-
>  include/linux/sunrpc/gss_krb5.h          |  196 +--
>  include/linux/sunrpc/gss_krb5_enctypes.h |   41 -
>  net/sunrpc/.kunitconfig                  |   30 +
>  net/sunrpc/Kconfig                       |   96 +-
>  net/sunrpc/auth_gss/Makefile             |    2 +
>  net/sunrpc/auth_gss/auth_gss.c           |   17 +
>  net/sunrpc/auth_gss/gss_krb5_crypto.c    |  656 +++++--
>  net/sunrpc/auth_gss/gss_krb5_internal.h  |  232 +++
>  net/sunrpc/auth_gss/gss_krb5_keys.c      |  416 ++++-
>  net/sunrpc/auth_gss/gss_krb5_mech.c      |  730 +++++---
>  net/sunrpc/auth_gss/gss_krb5_seal.c      |  122 +-
>  net/sunrpc/auth_gss/gss_krb5_seqnum.c    |    2 +
>  net/sunrpc/auth_gss/gss_krb5_test.c      | 2040 ++++++++++++++++++++++
>  net/sunrpc/auth_gss/gss_krb5_unseal.c    |   63 +-
>  net/sunrpc/auth_gss/gss_krb5_wrap.c      |  124 +-
>  net/sunrpc/auth_gss/svcauth_gss.c        |   65 +
>  17 files changed, 4001 insertions(+), 905 deletions(-)
>  delete mode 100644 include/linux/sunrpc/gss_krb5_enctypes.h
>  create mode 100644 net/sunrpc/.kunitconfig
>  create mode 100644 net/sunrpc/auth_gss/gss_krb5_internal.h
>  create mode 100644 net/sunrpc/auth_gss/gss_krb5_test.c
> 
> --
> Chuck Lever

I reviewed the whole patchset (except the Camellia related commits):
Reviewed-by: Simo Sorce <simo@redhat.com>

Simo.
Chuck Lever III Jan. 18, 2023, 5:16 p.m. UTC | #2
> On Jan 18, 2023, at 11:02 AM, Simo Sorce <simo@redhat.com> wrote:
> 
> On Sun, 2023-01-15 at 12:20 -0500, Chuck Lever wrote:
>> The purpose of this series is to improve/harden the security
>> provided by the Linux kernel's RPCSEC GSS Kerberos 5 mechanism.
>> There are lots of clean-ups in this series, but the pertinent
>> feature is the addition of a clean deprecation path for the DES-
>> and SHA1-based encryption types in accordance with Internet BCPs.
>> 
>> This series disables DES-based enctypes by default, provides a
>> mechanism for disabling SHA1-based enctypes, and introduces two
>> modern enctypes that do not use deprecated crypto algorithms.
>> 
>> Not only does that improve security for Kerberos 5 users, but it
>> also prepares SunRPC for eventually switching to a shared common
>> kernel Kerberos 5 implementation, which surely will not implement
>> any deprecated encryption types (in particular, DES-based ones).
>> 
>> Today, MIT supports both of the newly-introduced enctypes, but
>> Heimdal does not appear to. Thus distributions can enable and
>> disable kernel enctype support to match the set of enctypes
>> supported in their user space Kerberos libraries.
>> 
>> Scott has been kicking the tires -- we've found no regressions with
>> the current SHA1-based enctypes, while the new ones are disabled by
>> default until we have an opportunity for interop testing. The KUnit
>> tests for the new enctypes pass and this implementation successfully
>> interoperates with itself using these enctypes. Therefore I believe
>> it to be safe to merge.
>> 
>> When this series gets merged, the Linux NFS community should select
>> and announce a date-certain for removal of SunRPC's DES-based
>> enctype code.
>> 
>> ---
>> 
>> Changes since v1:
>> - Addressed Simo's NAK on "SUNRPC: Improve Kerberos confounder generation"
>> - Added Cc: linux-kselftest@ for review of the KUnit-related patches
>> 
>> 
>> Chuck Lever (41):
>>      SUNRPC: Add header ifdefs to linux/sunrpc/gss_krb5.h
>>      SUNRPC: Remove .blocksize field from struct gss_krb5_enctype
>>      SUNRPC: Remove .conflen field from struct gss_krb5_enctype
>>      SUNRPC: Improve Kerberos confounder generation
>>      SUNRPC: Obscure Kerberos session key
>>      SUNRPC: Refactor set-up for aux_cipher
>>      SUNRPC: Obscure Kerberos encryption keys
>>      SUNRPC: Obscure Kerberos signing keys
>>      SUNRPC: Obscure Kerberos integrity keys
>>      SUNRPC: Refactor the GSS-API Per Message calls in the Kerberos mechanism
>>      SUNRPC: Remove another switch on ctx->enctype
>>      SUNRPC: Add /proc/net/rpc/gss_krb5_enctypes file
>>      NFSD: Replace /proc/fs/nfsd/supported_krb5_enctypes with a symlink
>>      SUNRPC: Replace KRB5_SUPPORTED_ENCTYPES macro
>>      SUNRPC: Enable rpcsec_gss_krb5.ko to be built without CRYPTO_DES
>>      SUNRPC: Remove ->encrypt and ->decrypt methods from struct gss_krb5_enctype
>>      SUNRPC: Rename .encrypt_v2 and .decrypt_v2 methods
>>      SUNRPC: Hoist KDF into struct gss_krb5_enctype
>>      SUNRPC: Clean up cipher set up for v1 encryption types
>>      SUNRPC: Parametrize the key length passed to context_v2_alloc_cipher()
>>      SUNRPC: Add new subkey length fields
>>      SUNRPC: Refactor CBC with CTS into helpers
>>      SUNRPC: Add gk5e definitions for RFC 8009 encryption types
>>      SUNRPC: Add KDF-HMAC-SHA2
>>      SUNRPC: Add RFC 8009 encryption and decryption functions
>>      SUNRPC: Advertise support for RFC 8009 encryption types
>>      SUNRPC: Support the Camellia enctypes
>>      SUNRPC: Add KDF_FEEDBACK_CMAC
>>      SUNRPC: Advertise support for the Camellia encryption types
>>      SUNRPC: Move remaining internal definitions to gss_krb5_internal.h
>>      SUNRPC: Add KUnit tests for rpcsec_krb5.ko
>>      SUNRPC: Export get_gss_krb5_enctype()
>>      SUNRPC: Add KUnit tests RFC 3961 Key Derivation
>>      SUNRPC: Add Kunit tests for RFC 3962-defined encryption/decryption
>>      SUNRPC: Add KDF KUnit tests for the RFC 6803 encryption types
>>      SUNRPC: Add checksum KUnit tests for the RFC 6803 encryption types
>>      SUNRPC: Add encryption KUnit tests for the RFC 6803 encryption types
>>      SUNRPC: Add KDF-HMAC-SHA2 Kunit tests
>>      SUNRPC: Add RFC 8009 checksum KUnit tests
>>      SUNRPC: Add RFC 8009 encryption KUnit tests
>>      SUNRPC: Add encryption self-tests
>> 
>> 
>> fs/nfsd/nfsctl.c                         |   74 +-
>> include/linux/sunrpc/gss_krb5.h          |  196 +--
>> include/linux/sunrpc/gss_krb5_enctypes.h |   41 -
>> net/sunrpc/.kunitconfig                  |   30 +
>> net/sunrpc/Kconfig                       |   96 +-
>> net/sunrpc/auth_gss/Makefile             |    2 +
>> net/sunrpc/auth_gss/auth_gss.c           |   17 +
>> net/sunrpc/auth_gss/gss_krb5_crypto.c    |  656 +++++--
>> net/sunrpc/auth_gss/gss_krb5_internal.h  |  232 +++
>> net/sunrpc/auth_gss/gss_krb5_keys.c      |  416 ++++-
>> net/sunrpc/auth_gss/gss_krb5_mech.c      |  730 +++++---
>> net/sunrpc/auth_gss/gss_krb5_seal.c      |  122 +-
>> net/sunrpc/auth_gss/gss_krb5_seqnum.c    |    2 +
>> net/sunrpc/auth_gss/gss_krb5_test.c      | 2040 ++++++++++++++++++++++
>> net/sunrpc/auth_gss/gss_krb5_unseal.c    |   63 +-
>> net/sunrpc/auth_gss/gss_krb5_wrap.c      |  124 +-
>> net/sunrpc/auth_gss/svcauth_gss.c        |   65 +
>> 17 files changed, 4001 insertions(+), 905 deletions(-)
>> delete mode 100644 include/linux/sunrpc/gss_krb5_enctypes.h
>> create mode 100644 net/sunrpc/.kunitconfig
>> create mode 100644 net/sunrpc/auth_gss/gss_krb5_internal.h
>> create mode 100644 net/sunrpc/auth_gss/gss_krb5_test.c
>> 
>> --
>> Chuck Lever
> 
> I reviewed the whole patchset (except the Camellia related commits):
> Reviewed-by: Simo Sorce <simo@redhat.com>

Thank you!

I've applied this series to nfsd-next. Comments and testing are
still welcome.


--
Chuck Lever
Geert Uytterhoeven Feb. 23, 2023, 1:05 p.m. UTC | #3
Hi Chuck,

On Sun, 15 Jan 2023, Chuck Lever wrote:
> The purpose of this series is to improve/harden the security
> provided by the Linux kernel's RPCSEC GSS Kerberos 5 mechanism.
> There are lots of clean-ups in this series, but the pertinent
> feature is the addition of a clean deprecation path for the DES-
> and SHA1-based encryption types in accordance with Internet BCPs.
>
> This series disables DES-based enctypes by default, provides a
> mechanism for disabling SHA1-based enctypes, and introduces two
> modern enctypes that do not use deprecated crypto algorithms.
>
> Not only does that improve security for Kerberos 5 users, but it
> also prepares SunRPC for eventually switching to a shared common
> kernel Kerberos 5 implementation, which surely will not implement
> any deprecated encryption types (in particular, DES-based ones).
>
> Today, MIT supports both of the newly-introduced enctypes, but
> Heimdal does not appear to. Thus distributions can enable and
> disable kernel enctype support to match the set of enctypes
> supported in their user space Kerberos libraries.
>
> Scott has been kicking the tires -- we've found no regressions with
> the current SHA1-based enctypes, while the new ones are disabled by
> default until we have an opportunity for interop testing. The KUnit
> tests for the new enctypes pass and this implementation successfully
> interoperates with itself using these enctypes. Therefore I believe
> it to be safe to merge.
>
> When this series gets merged, the Linux NFS community should select
> and announce a date-certain for removal of SunRPC's DES-based
> enctype code.

As this is now upstream, I gave it a try on m68k (on the ARAnyM
emulator), using a config based on atari_defconfig:

     KTAP version 1
     # Subtest: RFC 3961 tests
     1..3
         KTAP version 1
         # Subtest: RFC 3961 n-fold
         ok 1 64-fold("012345")
         ok 2 56-fold("password")
         ok 3 64-fold("Rough Consensus, and Running Code")
         ok 4 168-fold("password")
         ok 5 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY")
         ok 6 168-fold("Q")
         ok 7 168-fold("ba")
         ok 8 64-fold("kerberos")
         ok 9 128-fold("kerberos")
         ok 10 168-fold("kerberos")
         ok 11 256-fold("kerberos")
     # RFC 3961 n-fold: pass:11 fail:0 skip:0 total:11
     ok 1 RFC 3961 n-fold
         KTAP version 1
         # Subtest: RFC 3961 key derivation
     # RFC 3961 key derivation: ASSERTION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:52
     Expected gk5e != ((void *)0), but
         gk5e == 00000000
         ((void *)0) == 00000000
         not ok 1 des3-hmac-sha1 key derivation case 1
     # RFC 3961 key derivation: ASSERTION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:52
     Expected gk5e != ((void *)0), but
         gk5e == 00000000
         ((void *)0) == 00000000
         not ok 2 des3-hmac-sha1 key derivation case 2
     # RFC 3961 key derivation: ASSERTION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:52
     Expected gk5e != ((void *)0), but
         gk5e == 00000000
         ((void *)0) == 00000000
         not ok 3 des3-hmac-sha1 key derivation case 3
     # RFC 3961 key derivation: ASSERTION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:52
     Expected gk5e != ((void *)0), but
         gk5e == 00000000
         ((void *)0) == 00000000
         not ok 4 des3-hmac-sha1 key derivation case 4
     # RFC 3961 key derivation: ASSERTION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:52
     Expected gk5e != ((void *)0), but
         gk5e == 00000000
         ((void *)0) == 00000000
         not ok 5 des3-hmac-sha1 key derivation case 5
     # RFC 3961 key derivation: ASSERTION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:52
     Expected gk5e != ((void *)0), but
         gk5e == 00000000
         ((void *)0) == 00000000
         not ok 6 des3-hmac-sha1 key derivation case 6
     # RFC 3961 key derivation: ASSERTION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:52
     Expected gk5e != ((void *)0), but
         gk5e == 00000000
         ((void *)0) == 00000000
         not ok 7 des3-hmac-sha1 key derivation case 7
     # RFC 3961 key derivation: ASSERTION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:52
     Expected gk5e != ((void *)0), but
         gk5e == 00000000
         ((void *)0) == 00000000
         not ok 8 des3-hmac-sha1 key derivation case 8
     # RFC 3961 key derivation: ASSERTION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:52
     Expected gk5e != ((void *)0), but
         gk5e == 00000000
         ((void *)0) == 00000000
         not ok 9 des3-hmac-sha1 key derivation case 9
     # RFC 3961 key derivation: pass:0 fail:9 skip:0 total:9
     not ok 2 RFC 3961 key derivation
*** CHK ***   FORMAT=2
Current process id is 794
BAD KERNEL TRAP: 00000000
Modules linked in: gss_krb5_test rpcsec_gss_krb5 auth_rpcgss oid_registry kunit
PC: [<1188975a>] rfc6803_suite+0x2/0xffffc688 [gss_krb5_test]
SR: 2200  SP: 93025120  a2: 01b6f700
d0: 00000002    d1: 00000010    d2: 00000014    d3: 01aebcc4
d4: 01aebc44    d5: 00000009    a0: 11889754    a1: 01aebc44
Process insmod (pid: 794, task=c42c6bea)
Frame format=2 instr addr=1188975a
Stack from 01aebbd8:
         11963860 00000000 01aebc44 00000000 00000005 00000001 00000000 00000000
         11889e5c 11889e34 11889be8 119644d8 1196356e 00000001 00000009 00000000
         00000000 0000000b 01aebcfc 00000001 00000000 00000001 00000002 00000000
         00000000 00000000 00000000 00657333 2d686d61 632d7368 6131206b 65792064
         65726976 6174696f 6e206361 73652039 00000000 484e4f4c 4f475922 29000000
         00000801 000c729c 005b9c58 00000000 00040cc0 00040cc0 00000000 00000000
Call Trace: [<11963860>] kunit_run_tests+0x2f2/0x3d2 [kunit]
  [<119644d8>] kunit_debugfs_create_suite+0x0/0x54 [kunit]
  [<1196356e>] kunit_run_tests+0x0/0x3d2 [kunit]
  [<000c729c>] get_page_from_freelist+0x176/0x48a
  [<00040cc0>] __finish_swait+0x1a/0x1c
  [<00040cc0>] __finish_swait+0x1a/0x1c
  [<00040cc0>] __finish_swait+0x1a/0x1c
  [<000c7126>] get_page_from_freelist+0x0/0x48a
  [<00009752>] ssincosnan+0x10/0x26
  [<000c6f00>] __putback_isolated_page+0x62/0x7c
  [<119639e2>] __kunit_test_suites_init+0xa2/0xfa [kunit]
  [<000405ea>] __wake_up+0x0/0x1c
  [<00037774>] blocking_notifier_call_chain+0x0/0x46
  [<11963a5a>] kunit_module_notify+0x20/0x34 [kunit]
  [<00037404>] notifier_call_chain+0x34/0x48
  [<0004e3b4>] module_put+0x0/0x50
  [<000377a0>] blocking_notifier_call_chain+0x2c/0x46
  [<0004ebd4>] do_init_module+0xd6/0x1a2
  [<0036ec50>] memset+0x0/0x8c
  [<00005b94>] flush_icache_range+0x0/0x30
  [<0005009c>] load_module+0x1304/0x1368
  [<0000eb60>] zer_rm2+0x1c/0x24
  [<0036ed04>] __generic_copy_from_user+0x0/0x40
  [<00010000>] EXPTBL+0x1c8/0x400
  [<0036ec50>] memset+0x0/0x8c
  [<003762ac>] __cond_resched+0x0/0x46
  [<000501d4>] sys_init_module+0xd4/0xda
  [<0000eb60>] zer_rm2+0x1c/0x24
  [<0000536e>] buserr_c+0xc6/0x49a
  [<00002962>] syscall+0x8/0xc
  [<0000eb60>] zer_rm2+0x1c/0x24
  [<0000eb60>] zer_rm2+0x1c/0x24
  [<00010000>] EXPTBL+0x1c8/0x400
  [<0018c00b>] nfs_direct_write_schedule_iovec+0xe3/0x1d6

Code: 646b 1188 42f6 0000 0000 0000 0000 5246 <4320> 3638 3033 2073 7569 7465 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Disabling lock debugging due to kernel taint

All of gss_krb5_test, rpcsec_gss_krb5, auth_rpcgss, oid_registry, and
kunit are modular.

Thanks!

Gr{oetje,eeting}s,

 						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
 							    -- Linus Torvalds
Chuck Lever III Feb. 23, 2023, 2 p.m. UTC | #4
> On Feb 23, 2023, at 8:05 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> 
> 	Hi Chuck,
> 
> On Sun, 15 Jan 2023, Chuck Lever wrote:
>> The purpose of this series is to improve/harden the security
>> provided by the Linux kernel's RPCSEC GSS Kerberos 5 mechanism.
>> There are lots of clean-ups in this series, but the pertinent
>> feature is the addition of a clean deprecation path for the DES-
>> and SHA1-based encryption types in accordance with Internet BCPs.
>> 
>> This series disables DES-based enctypes by default, provides a
>> mechanism for disabling SHA1-based enctypes, and introduces two
>> modern enctypes that do not use deprecated crypto algorithms.
>> 
>> Not only does that improve security for Kerberos 5 users, but it
>> also prepares SunRPC for eventually switching to a shared common
>> kernel Kerberos 5 implementation, which surely will not implement
>> any deprecated encryption types (in particular, DES-based ones).
>> 
>> Today, MIT supports both of the newly-introduced enctypes, but
>> Heimdal does not appear to. Thus distributions can enable and
>> disable kernel enctype support to match the set of enctypes
>> supported in their user space Kerberos libraries.
>> 
>> Scott has been kicking the tires -- we've found no regressions with
>> the current SHA1-based enctypes, while the new ones are disabled by
>> default until we have an opportunity for interop testing. The KUnit
>> tests for the new enctypes pass and this implementation successfully
>> interoperates with itself using these enctypes. Therefore I believe
>> it to be safe to merge.
>> 
>> When this series gets merged, the Linux NFS community should select
>> and announce a date-certain for removal of SunRPC's DES-based
>> enctype code.
> 
> As this is now upstream, I gave it a try on m68k (on the ARAnyM
> emulator), using a config based on atari_defconfig:
> 
>    KTAP version 1
>    # Subtest: RFC 3961 tests
>    1..3
>        KTAP version 1
>        # Subtest: RFC 3961 n-fold
>        ok 1 64-fold("012345")
>        ok 2 56-fold("password")
>        ok 3 64-fold("Rough Consensus, and Running Code")
>        ok 4 168-fold("password")
>        ok 5 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY")
>        ok 6 168-fold("Q")
>        ok 7 168-fold("ba")
>        ok 8 64-fold("kerberos")
>        ok 9 128-fold("kerberos")
>        ok 10 168-fold("kerberos")
>        ok 11 256-fold("kerberos")
>    # RFC 3961 n-fold: pass:11 fail:0 skip:0 total:11
>    ok 1 RFC 3961 n-fold
>        KTAP version 1
>        # Subtest: RFC 3961 key derivation
>    # RFC 3961 key derivation: ASSERTION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:52
>    Expected gk5e != ((void *)0), but
>        gk5e == 00000000
>        ((void *)0) == 00000000
>        not ok 1 des3-hmac-sha1 key derivation case 1

Geert, thanks for testing GSS on m68k.

This assertion failure means that support for the encryption types
specified in RFC 3961 is not built into your kernel.

The new Kunit tests don't work unless everything is built in --
there's a net/sunrpc/.kunitconfig that provides the supported
build configuration for running them. I typically use a command
line similar to this:

./tools/testing/kunit/kunit.py run --raw_output=all --kunitconfig ./net/sunrpc/.kunitconfig


I'm not sure what's crashing at rfc6803_suite+0x2, but I suspect
it's a similar issue.


>    # RFC 3961 key derivation: ASSERTION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:52
>    Expected gk5e != ((void *)0), but
>        gk5e == 00000000
>        ((void *)0) == 00000000
>        not ok 2 des3-hmac-sha1 key derivation case 2
>    # RFC 3961 key derivation: ASSERTION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:52
>    Expected gk5e != ((void *)0), but
>        gk5e == 00000000
>        ((void *)0) == 00000000
>        not ok 3 des3-hmac-sha1 key derivation case 3
>    # RFC 3961 key derivation: ASSERTION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:52
>    Expected gk5e != ((void *)0), but
>        gk5e == 00000000
>        ((void *)0) == 00000000
>        not ok 4 des3-hmac-sha1 key derivation case 4
>    # RFC 3961 key derivation: ASSERTION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:52
>    Expected gk5e != ((void *)0), but
>        gk5e == 00000000
>        ((void *)0) == 00000000
>        not ok 5 des3-hmac-sha1 key derivation case 5
>    # RFC 3961 key derivation: ASSERTION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:52
>    Expected gk5e != ((void *)0), but
>        gk5e == 00000000
>        ((void *)0) == 00000000
>        not ok 6 des3-hmac-sha1 key derivation case 6
>    # RFC 3961 key derivation: ASSERTION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:52
>    Expected gk5e != ((void *)0), but
>        gk5e == 00000000
>        ((void *)0) == 00000000
>        not ok 7 des3-hmac-sha1 key derivation case 7
>    # RFC 3961 key derivation: ASSERTION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:52
>    Expected gk5e != ((void *)0), but
>        gk5e == 00000000
>        ((void *)0) == 00000000
>        not ok 8 des3-hmac-sha1 key derivation case 8
>    # RFC 3961 key derivation: ASSERTION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:52
>    Expected gk5e != ((void *)0), but
>        gk5e == 00000000
>        ((void *)0) == 00000000
>        not ok 9 des3-hmac-sha1 key derivation case 9
>    # RFC 3961 key derivation: pass:0 fail:9 skip:0 total:9
>    not ok 2 RFC 3961 key derivation
> *** CHK ***   FORMAT=2
> Current process id is 794
> BAD KERNEL TRAP: 00000000
> Modules linked in: gss_krb5_test rpcsec_gss_krb5 auth_rpcgss oid_registry kunit
> PC: [<1188975a>] rfc6803_suite+0x2/0xffffc688 [gss_krb5_test]
> SR: 2200  SP: 93025120  a2: 01b6f700
> d0: 00000002    d1: 00000010    d2: 00000014    d3: 01aebcc4
> d4: 01aebc44    d5: 00000009    a0: 11889754    a1: 01aebc44
> Process insmod (pid: 794, task=c42c6bea)
> Frame format=2 instr addr=1188975a
> Stack from 01aebbd8:
>        11963860 00000000 01aebc44 00000000 00000005 00000001 00000000 00000000
>        11889e5c 11889e34 11889be8 119644d8 1196356e 00000001 00000009 00000000
>        00000000 0000000b 01aebcfc 00000001 00000000 00000001 00000002 00000000
>        00000000 00000000 00000000 00657333 2d686d61 632d7368 6131206b 65792064
>        65726976 6174696f 6e206361 73652039 00000000 484e4f4c 4f475922 29000000
>        00000801 000c729c 005b9c58 00000000 00040cc0 00040cc0 00000000 00000000
> Call Trace: [<11963860>] kunit_run_tests+0x2f2/0x3d2 [kunit]
> [<119644d8>] kunit_debugfs_create_suite+0x0/0x54 [kunit]
> [<1196356e>] kunit_run_tests+0x0/0x3d2 [kunit]
> [<000c729c>] get_page_from_freelist+0x176/0x48a
> [<00040cc0>] __finish_swait+0x1a/0x1c
> [<00040cc0>] __finish_swait+0x1a/0x1c
> [<00040cc0>] __finish_swait+0x1a/0x1c
> [<000c7126>] get_page_from_freelist+0x0/0x48a
> [<00009752>] ssincosnan+0x10/0x26
> [<000c6f00>] __putback_isolated_page+0x62/0x7c
> [<119639e2>] __kunit_test_suites_init+0xa2/0xfa [kunit]
> [<000405ea>] __wake_up+0x0/0x1c
> [<00037774>] blocking_notifier_call_chain+0x0/0x46
> [<11963a5a>] kunit_module_notify+0x20/0x34 [kunit]
> [<00037404>] notifier_call_chain+0x34/0x48
> [<0004e3b4>] module_put+0x0/0x50
> [<000377a0>] blocking_notifier_call_chain+0x2c/0x46
> [<0004ebd4>] do_init_module+0xd6/0x1a2
> [<0036ec50>] memset+0x0/0x8c
> [<00005b94>] flush_icache_range+0x0/0x30
> [<0005009c>] load_module+0x1304/0x1368
> [<0000eb60>] zer_rm2+0x1c/0x24
> [<0036ed04>] __generic_copy_from_user+0x0/0x40
> [<00010000>] EXPTBL+0x1c8/0x400
> [<0036ec50>] memset+0x0/0x8c
> [<003762ac>] __cond_resched+0x0/0x46
> [<000501d4>] sys_init_module+0xd4/0xda
> [<0000eb60>] zer_rm2+0x1c/0x24
> [<0000536e>] buserr_c+0xc6/0x49a
> [<00002962>] syscall+0x8/0xc
> [<0000eb60>] zer_rm2+0x1c/0x24
> [<0000eb60>] zer_rm2+0x1c/0x24
> [<00010000>] EXPTBL+0x1c8/0x400
> [<0018c00b>] nfs_direct_write_schedule_iovec+0xe3/0x1d6
> 
> Code: 646b 1188 42f6 0000 0000 0000 0000 5246 <4320> 3638 3033 2073 7569 7465 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
> Disabling lock debugging due to kernel taint
> 
> All of gss_krb5_test, rpcsec_gss_krb5, auth_rpcgss, oid_registry, and
> kunit are modular.
> 
> Thanks!
> 
> Gr{oetje,eeting}s,
> 
> 						Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> 							    -- Linus Torvalds

--
Chuck Lever
Geert Uytterhoeven Feb. 23, 2023, 3:16 p.m. UTC | #5
Hi Chuck,

On Thu, Feb 23, 2023 at 3:00 PM Chuck Lever III <chuck.lever@oracle.com> wrote:
> > On Feb 23, 2023, at 8:05 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Sun, 15 Jan 2023, Chuck Lever wrote:
> >> The purpose of this series is to improve/harden the security
> >> provided by the Linux kernel's RPCSEC GSS Kerberos 5 mechanism.
> >> There are lots of clean-ups in this series, but the pertinent
> >> feature is the addition of a clean deprecation path for the DES-
> >> and SHA1-based encryption types in accordance with Internet BCPs.
> >>
> >> This series disables DES-based enctypes by default, provides a
> >> mechanism for disabling SHA1-based enctypes, and introduces two
> >> modern enctypes that do not use deprecated crypto algorithms.
> >>
> >> Not only does that improve security for Kerberos 5 users, but it
> >> also prepares SunRPC for eventually switching to a shared common
> >> kernel Kerberos 5 implementation, which surely will not implement
> >> any deprecated encryption types (in particular, DES-based ones).
> >>
> >> Today, MIT supports both of the newly-introduced enctypes, but
> >> Heimdal does not appear to. Thus distributions can enable and
> >> disable kernel enctype support to match the set of enctypes
> >> supported in their user space Kerberos libraries.
> >>
> >> Scott has been kicking the tires -- we've found no regressions with
> >> the current SHA1-based enctypes, while the new ones are disabled by
> >> default until we have an opportunity for interop testing. The KUnit
> >> tests for the new enctypes pass and this implementation successfully
> >> interoperates with itself using these enctypes. Therefore I believe
> >> it to be safe to merge.
> >>
> >> When this series gets merged, the Linux NFS community should select
> >> and announce a date-certain for removal of SunRPC's DES-based
> >> enctype code.
> >
> > As this is now upstream, I gave it a try on m68k (on the ARAnyM
> > emulator), using a config based on atari_defconfig:
> >
> >    KTAP version 1
> >    # Subtest: RFC 3961 tests
> >    1..3
> >        KTAP version 1
> >        # Subtest: RFC 3961 n-fold
> >        ok 1 64-fold("012345")
> >        ok 2 56-fold("password")
> >        ok 3 64-fold("Rough Consensus, and Running Code")
> >        ok 4 168-fold("password")
> >        ok 5 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY")
> >        ok 6 168-fold("Q")
> >        ok 7 168-fold("ba")
> >        ok 8 64-fold("kerberos")
> >        ok 9 128-fold("kerberos")
> >        ok 10 168-fold("kerberos")
> >        ok 11 256-fold("kerberos")
> >    # RFC 3961 n-fold: pass:11 fail:0 skip:0 total:11
> >    ok 1 RFC 3961 n-fold
> >        KTAP version 1
> >        # Subtest: RFC 3961 key derivation
> >    # RFC 3961 key derivation: ASSERTION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:52
> >    Expected gk5e != ((void *)0), but
> >        gk5e == 00000000
> >        ((void *)0) == 00000000
> >        not ok 1 des3-hmac-sha1 key derivation case 1
>
> Geert, thanks for testing GSS on m68k.
>
> This assertion failure means that support for the encryption types
> specified in RFC 3961 is not built into your kernel.
>
> The new Kunit tests don't work unless everything is built in --
>
> there's a net/sunrpc/.kunitconfig that provides the supported
> build configuration for running them. I typically use a command
> line similar to this:
>
> ./tools/testing/kunit/kunit.py run --raw_output=all --kunitconfig ./net/sunrpc/.kunitconfig

Aren't modular crypto algorithms auto-loaded when needed?

In general, it's a good idea to make the tests test only functionality
that is available, either through "depends on" in Kconfig, or "#if
IS_ENABLED(...)".  Of course that does not preclude providing a
.kunitconfig to enable and test everything.

Note that net/sunrpc/.kunitconfig has

    CONFIG_RPCSEC_GSS_KRB5_KUNIT_TEST=y

which needs KUNIT_ALL_TESTS=y, else it will still be modular.

First, I tried getting my modular setup working.
After enabling:
    CONFIG_RPCSEC_GSS_KRB5_ENCTYPES_DES=y
    CONFIG_RPCSEC_GSS_KRB5_ENCTYPES_CAMELLIA=y
    CONFIG_RPCSEC_GSS_KRB5_ENCTYPES_AES_SHA2=y
(the former is marked deprecated!)
and loading all needed crypto modules (cfr. the .kunitconfig), I got:

    KTAP version 1
    # Subtest: RFC 3961 tests
    1..3
        KTAP version 1
        # Subtest: RFC 3961 n-fold
        ok 1 64-fold("012345")
        ok 2 56-fold("password")
        ok 3 64-fold("Rough Consensus, and Running Code")
        ok 4 168-fold("password")
        ok 5 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY")
        ok 6 168-fold("Q")
        ok 7 168-fold("ba")
        ok 8 64-fold("kerberos")
        ok 9 128-fold("kerberos")
        ok 10 168-fold("kerberos")
        ok 11 256-fold("kerberos")
    # RFC 3961 n-fold: pass:11 fail:0 skip:0 total:11
    ok 1 RFC 3961 n-fold
        KTAP version 1
        # Subtest: RFC 3961 key derivation
    # RFC 3961 key derivation: ASSERTION FAILED at
net/sunrpc/auth_gss/gss_krb5_test.c:62
    Expected err == 0, but
        err == -22 (0xffffffffffffffea)
        not ok 1 des3-hmac-sha1 key derivation case 1
    # RFC 3961 key derivation: ASSERTION FAILED at
net/sunrpc/auth_gss/gss_krb5_test.c:62
    Expected err == 0, but
        err == -22 (0xffffffffffffffea)
        not ok 2 des3-hmac-sha1 key derivation case 2
    # RFC 3961 key derivation: ASSERTION FAILED at
net/sunrpc/auth_gss/gss_krb5_test.c:62
    Expected err == 0, but
        err == -22 (0xffffffffffffffea)
        not ok 3 des3-hmac-sha1 key derivation case 3
    # RFC 3961 key derivation: ASSERTION FAILED at
net/sunrpc/auth_gss/gss_krb5_test.c:62
    Expected err == 0, but
        err == -22 (0xffffffffffffffea)
        not ok 4 des3-hmac-sha1 key derivation case 4
    # RFC 3961 key derivation: ASSERTION FAILED at
net/sunrpc/auth_gss/gss_krb5_test.c:62
    Expected err == 0, but
        err == -22 (0xffffffffffffffea)
        not ok 5 des3-hmac-sha1 key derivation case 5
    # RFC 3961 key derivation: ASSERTION FAILED at
net/sunrpc/auth_gss/gss_krb5_test.c:62
    Expected err == 0, but
        err == -22 (0xffffffffffffffea)
        not ok 6 des3-hmac-sha1 key derivation case 6
    # RFC 3961 key derivation: ASSERTION FAILED at
net/sunrpc/auth_gss/gss_krb5_test.c:62
    Expected err == 0, but
        err == -22 (0xffffffffffffffea)
        not ok 7 des3-hmac-sha1 key derivation case 7
    # RFC 3961 key derivation: ASSERTION FAILED at
net/sunrpc/auth_gss/gss_krb5_test.c:62
    Expected err == 0, but
        err == -22 (0xffffffffffffffea)
        not ok 8 des3-hmac-sha1 key derivation case 8
    # RFC 3961 key derivation: ASSERTION FAILED at
net/sunrpc/auth_gss/gss_krb5_test.c:62
    Expected err == 0, but
        err == -22 (0xffffffffffffffea)
        not ok 9 des3-hmac-sha1 key derivation case 9
    # RFC 3961 key derivation: pass:0 fail:9 skip:0 total:9
    not ok 2 RFC 3961 key derivation
*** CHK ***   FORMAT=2
Current process id is 785
BAD KERNEL TRAP: 00000000
Modules linked in: gss_krb5_test kunit rpcsec_gss_krb5 auth_rpcgss
oid_registry camellia_generic sha512_generic sha1_generic md5 cmac
hmac ecb cts cbc
PC: [<1187775a>] rfc6803_suite+0x2/0xffffc688 [gss_krb5_test]
SR: 2200  SP: efc1339e  a2: 01b4e610
d0: 00000002    d1: 00000010    d2: 00000014    d3: 01b57cc4
d4: 01b57c44    d5: 00000009    a0: 11877754    a1: 01b57c44
Process insmod (pid: 785, task=52ae00a3)
Frame format=2 instr addr=1187775a
Stack from 01b57bd8:
        11869860 00000000 01b57c44 00000000 00000005 00000001 00000000 00000000
        11877e5c 11877e34 11877be8 1186a4d8 1186956e 00000001 00000009 00000000
        00000000 0000000b 01b57cfc 00000001 00000000 00000001 00000002 00000000
        00000000 00000000 00000000 00657333 2d686d61 632d7368 6131206b 65792064
        65726976 6174696f 6e206361 73652039 00000000 484e4f4c 4f475922 29000000
        00000801 000c729c 005d6074 00000000 00040cc0 00040cc0 00000000 00000000
Call Trace: [<11869860>] kunit_run_tests+0x2f2/0x3d2 [kunit]

I.e. -EINVAL later, so something is still missing.

Second, with net/sunrpc/.kunitconfig, and just
CONFIG_RPCSEC_GSS_KRB5_KUNIT_TEST still modular, the tests
succeed, but there is still a crash:

    KTAP version 1
    # Subtest: RFC 3961 tests
    1..3
        KTAP version 1
        # Subtest: RFC 3961 n-fold
        ok 1 64-fold("012345")
        ok 2 56-fold("password")
        ok 3 64-fold("Rough Consensus, and Running Code")
        ok 4 168-fold("password")
        ok 5 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY")
        ok 6 168-fold("Q")
        ok 7 168-fold("ba")
        ok 8 64-fold("kerberos")
        ok 9 128-fold("kerberos")
        ok 10 168-fold("kerberos")
        ok 11 256-fold("kerberos")
    # RFC 3961 n-fold: pass:11 fail:0 skip:0 total:11
    ok 1 RFC 3961 n-fold
        KTAP version 1
        # Subtest: RFC 3961 key derivation
        ok 1 des3-hmac-sha1 key derivation case 1
        ok 2 des3-hmac-sha1 key derivation case 2
        ok 3 des3-hmac-sha1 key derivation case 3
        ok 4 des3-hmac-sha1 key derivation case 4
        ok 5 des3-hmac-sha1 key derivation case 5
        ok 6 des3-hmac-sha1 key derivation case 6
        ok 7 des3-hmac-sha1 key derivation case 7
        ok 8 des3-hmac-sha1 key derivation case 8
        ok 9 des3-hmac-sha1 key derivation case 9
    # RFC 3961 key derivation: pass:9 fail:0 skip:0 total:9
    ok 2 RFC 3961 key derivation
*** CHK ***   FORMAT=2
Current process id is 716
BAD KERNEL TRAP: 00000000
Modules linked in: gss_krb5_test
PC: [<1197575a>] rfc6803_suite+0x2/0xffffc688 [gss_krb5_test]
SR: 2200  SP: acd229e8  a2: 01ae20a0
d0: 00000002    d1: 00000010    d2: 00000014    d3: 01ae1cc4
d4: 01ae1c44    d5: 00000000    a0: 11975754    a1: 01ae1c44
Process insmod (pid: 716, task=962b0746)
Frame format=2 instr addr=1197575a
Stack from 01ae1bd8:
        001f3158 00000000 01ae1c44 00000000 00000005 00000001 00000000 00000000
        11975e5c 11975e34 11975be8 001f415c 001f2e66 00000001 00000000 00000000
        00000009 00000014 01ae1cfc 00000002 00000000 00000000 00000002 00000000
        00000000 00000000 00000000 00657333 2d686d61 632d7368 6131206b 65792064
        65726976 6174696f 6e206361 73652039 00000000 484e4f4c 4f475922 29000000
        00000801 000c729c 005db3c4 00000000 00040cc0 00040cc0 00000000 00000000
Call Trace: [<001f3158>] kunit_run_tests+0x2f2/0x3d2

Third, with net/sunrpc/.kunitconfig, and
CONFIG_RPCSEC_GSS_KRB5_KUNIT_TEST=y:

    KTAP version 1
    # Subtest: RFC 3961 tests
    1..2
        KTAP version 1
        # Subtest: RFC 3961 n-fold
        ok 1 64-fold("012345")
        ok 2 56-fold("password")
        ok 3 64-fold("Rough Consensus, and Running Code")
        ok 4 168-fold("password")
        ok 5 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY")
        ok 6 168-fold("Q")
        ok 7 168-fold("ba")
        ok 8 64-fold("kerberos")
        ok 9 128-fold("kerberos")
        ok 10 168-fold("kerberos")
        ok 11 256-fold("kerberos")
    # RFC 3961 n-fold: pass:11 fail:0 skip:0 total:11
    ok 1 RFC 3961 n-fold
        KTAP version 1
        # Subtest: RFC 3961 key derivation
        ok 1 des3-hmac-sha1 key derivation case 1
        ok 2 des3-hmac-sha1 key derivation case 2
        ok 3 des3-hmac-sha1 key derivation case 3
        ok 4 des3-hmac-sha1 key derivation case 4
        ok 5 des3-hmac-sha1 key derivation case 5
        ok 6 des3-hmac-sha1 key derivation case 6
        ok 7 des3-hmac-sha1 key derivation case 7
        ok 8 des3-hmac-sha1 key derivation case 8
        ok 9 des3-hmac-sha1 key derivation case 9
    # RFC 3961 key derivation: pass:9 fail:0 skip:0 total:9
    ok 2 RFC 3961 key derivation
# RFC 3961 tests: pass:2 fail:0 skip:0 total:2
# Totals: pass:20 fail:0 skip:0 total:20
ok 31 RFC 3961 tests
    KTAP version 1
    # Subtest: RFC 3962 suite
    1..2
        KTAP version 1
        # Subtest: RFC 3962 encryption
        ok 1 Encrypt with aes128-cts-hmac-sha1-96 case 1
        ok 2 Encrypt with aes128-cts-hmac-sha1-96 case 2
        ok 3 Encrypt with aes128-cts-hmac-sha1-96 case 3
        ok 4 Encrypt with aes128-cts-hmac-sha1-96 case 4
        ok 5 Encrypt with aes128-cts-hmac-sha1-96 case 5
        ok 6 Encrypt with aes128-cts-hmac-sha1-96 case 6
    # RFC 3962 encryption: pass:6 fail:0 skip:0 total:6
    ok 1 RFC 3962 encryption
Unable to handle kernel access at virtual address af06da84
Oops: 00000000
Modules linked in:
PC: [<20746573>] 0x20746573
SR: 2204  SP: 05ef00e4  a2: 010195d0
d0: 00000002    d1: 00000010    d2: 00000006    d3: 0101bdf8
d4: 0101bd78    d5: 00000000    a0: 20746573    a1: 0101bd78
Process swapper (pid: 1, task=b63809d5)
Frame format=7 eff addr=20746573 ssw=0546 faddr=20746573
wb 1 stat/addr/data: 0000 00000000 00000000
wb 2 stat/addr/data: 0000 00000000 00000000
wb 3 stat/addr/data: 0000 20746573 00000000
push data: 00000000 00000000 00000000 00000000
Stack from 0101bd0c:
        001f64b0 00000000 0101bd78 0000001f 00000023 01015480 000359ba 0000209c
        00000000 005890c0 0053aafc 001f7c88 001f61be 00000001 00000000 00000000
        00000006 00000006 0101be30 00000001 00000000 00000000 00000001 00000000
        00000000 00000000 00000000 006e6372 79707420 77697468 20616573 3132382d
        6374732d 686d6163 2d736861 312d3936 20636173 65203600 4f475922 29000000
        00000801 000c886c 006003b4 00000000 00040cc0 00040cc0 00000000 00000000
Call Trace: [<001f64b0>] kunit_run_tests+0x2f2/0x3d2
 [<000359ba>] parse_args+0x0/0x202
 [<0000209c>] do_one_initcall+0x0/0x184
 [<001f7c88>] kunit_debugfs_create_suite+0x0/0x54
 [<001f61be>] kunit_run_tests+0x0/0x3d2
 [<000c886c>] get_page_from_freelist+0x176/0x48a
 [<00040cc0>] __finish_swait+0x1a/0x1c
 [<00040cc0>] __finish_swait+0x1a/0x1c
 [<00040cc0>] __finish_swait+0x1a/0x1c
 [<0000209c>] do_one_initcall+0x0/0x184
 [<000c86f6>] get_page_from_freelist+0x0/0x48a
 [<000c8500>] prepare_alloc_pages.isra.0+0x12/0x84
 [<001f6632>] __kunit_test_suites_init+0xa2/0xfa
 [<003a160c>] _printk+0x0/0x18
 [<001f7b9e>] kunit_run_all_tests+0xd0/0x1a6
 [<0039a0c0>] strcpy+0x0/0x1c
 [<00564602>] kernel_init_freeable+0x152/0x190
 [<000359ba>] parse_args+0x0/0x202
 [<003a6e76>] kernel_init+0x0/0xec
 [<003a6e8a>] kernel_init+0x14/0xec
 [<003a6e76>] kernel_init+0x0/0xec
 [<000028d4>] ret_from_kernel_thread+0xc/0x14

I.e. a slightly different crash.
As the difference between the two crashes is modular vs. builtin,
this looks like an out-of-bound access in the test.

Gr{oetje,eeting}s,

                        Geert
Chuck Lever III Feb. 23, 2023, 4:18 p.m. UTC | #6
> On Feb 23, 2023, at 10:16 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> 
> Hi Chuck,
> 
> On Thu, Feb 23, 2023 at 3:00 PM Chuck Lever III <chuck.lever@oracle.com> wrote:
>>> On Feb 23, 2023, at 8:05 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>> On Sun, 15 Jan 2023, Chuck Lever wrote:
>>>> The purpose of this series is to improve/harden the security
>>>> provided by the Linux kernel's RPCSEC GSS Kerberos 5 mechanism.
>>>> There are lots of clean-ups in this series, but the pertinent
>>>> feature is the addition of a clean deprecation path for the DES-
>>>> and SHA1-based encryption types in accordance with Internet BCPs.
>>>> 
>>>> This series disables DES-based enctypes by default, provides a
>>>> mechanism for disabling SHA1-based enctypes, and introduces two
>>>> modern enctypes that do not use deprecated crypto algorithms.
>>>> 
>>>> Not only does that improve security for Kerberos 5 users, but it
>>>> also prepares SunRPC for eventually switching to a shared common
>>>> kernel Kerberos 5 implementation, which surely will not implement
>>>> any deprecated encryption types (in particular, DES-based ones).
>>>> 
>>>> Today, MIT supports both of the newly-introduced enctypes, but
>>>> Heimdal does not appear to. Thus distributions can enable and
>>>> disable kernel enctype support to match the set of enctypes
>>>> supported in their user space Kerberos libraries.
>>>> 
>>>> Scott has been kicking the tires -- we've found no regressions with
>>>> the current SHA1-based enctypes, while the new ones are disabled by
>>>> default until we have an opportunity for interop testing. The KUnit
>>>> tests for the new enctypes pass and this implementation successfully
>>>> interoperates with itself using these enctypes. Therefore I believe
>>>> it to be safe to merge.
>>>> 
>>>> When this series gets merged, the Linux NFS community should select
>>>> and announce a date-certain for removal of SunRPC's DES-based
>>>> enctype code.
>>> 
>>> As this is now upstream, I gave it a try on m68k (on the ARAnyM
>>> emulator), using a config based on atari_defconfig:
>>> 
>>>   KTAP version 1
>>>   # Subtest: RFC 3961 tests
>>>   1..3
>>>       KTAP version 1
>>>       # Subtest: RFC 3961 n-fold
>>>       ok 1 64-fold("012345")
>>>       ok 2 56-fold("password")
>>>       ok 3 64-fold("Rough Consensus, and Running Code")
>>>       ok 4 168-fold("password")
>>>       ok 5 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY")
>>>       ok 6 168-fold("Q")
>>>       ok 7 168-fold("ba")
>>>       ok 8 64-fold("kerberos")
>>>       ok 9 128-fold("kerberos")
>>>       ok 10 168-fold("kerberos")
>>>       ok 11 256-fold("kerberos")
>>>   # RFC 3961 n-fold: pass:11 fail:0 skip:0 total:11
>>>   ok 1 RFC 3961 n-fold
>>>       KTAP version 1
>>>       # Subtest: RFC 3961 key derivation
>>>   # RFC 3961 key derivation: ASSERTION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:52
>>>   Expected gk5e != ((void *)0), but
>>>       gk5e == 00000000
>>>       ((void *)0) == 00000000
>>>       not ok 1 des3-hmac-sha1 key derivation case 1
>> 
>> Geert, thanks for testing GSS on m68k.
>> 
>> This assertion failure means that support for the encryption types
>> specified in RFC 3961 is not built into your kernel.
>> 
>> The new Kunit tests don't work unless everything is built in --
>> 
>> there's a net/sunrpc/.kunitconfig that provides the supported
>> build configuration for running them. I typically use a command
>> line similar to this:
>> 
>> ./tools/testing/kunit/kunit.py run --raw_output=all --kunitconfig ./net/sunrpc/.kunitconfig
> 
> Aren't modular crypto algorithms auto-loaded when needed?

The ciphers and digests are handled via the kernel's crypto
manager. They will indeed get auto-loaded by SunRPC's GSS on
demand, but of course, the set of algorithms used by GSS
has to be enabled by Kconfig options first.

SunRPC GSS has a set of Kerberos encryption types that make
use of individual ciphers and digests. Those have never been
modularized, and they are each enabled by Kconfig options,
as explained below.


> In general, it's a good idea to make the tests test only functionality
> that is available, either through "depends on" in Kconfig, or "#if
> IS_ENABLED(...)".

An earlier version of this patch set did just that. It became
quite a mess. That's why I chose the .kunitconfig approach.


> Of course that does not preclude providing a
> .kunitconfig to enable and test everything.

The suite should test every Kerberos encryption type that
SunRPC GSS has support for. There's no reason to disable a
particular encryption type when running the unit tests...
unless I'm missing something?


> Note that net/sunrpc/.kunitconfig has
> 
>    CONFIG_RPCSEC_GSS_KRB5_KUNIT_TEST=y
> 
> which needs KUNIT_ALL_TESTS=y, else it will still be modular.
> 
> First, I tried getting my modular setup working.
> After enabling:
>    CONFIG_RPCSEC_GSS_KRB5_ENCTYPES_DES=y

And CONFIG_RPCSEC_GSS_KRB5_ENCTYPES_AES_SHA1=y ??


>    CONFIG_RPCSEC_GSS_KRB5_ENCTYPES_CAMELLIA=y
>    CONFIG_RPCSEC_GSS_KRB5_ENCTYPES_AES_SHA2=y
> (the former is marked deprecated!)

Yes, that's one of the main points of my patches. ENCTYPES_DES
gates support for several Kerberos encryption types that we
want to remove from the kernel eventually.

AES_SHA1 is another set of encryption types that still has legs,
but will need to be deprecated because it uses SHA1, which is
scheduled for deprecation.

CAMELLIA is apparently not widely supported, so it can be
disabled separately.

AES_SHA2 is shiny and new. Some distributions might choose to
keep it disabled until it's had more road testing. But these
are the encryption types that are to replace both DES and
AES_SHA1.


> and loading all needed crypto modules (cfr. the .kunitconfig), I got:
> 
>    KTAP version 1
>    # Subtest: RFC 3961 tests
>    1..3
>        KTAP version 1
>        # Subtest: RFC 3961 n-fold
>        ok 1 64-fold("012345")
>        ok 2 56-fold("password")
>        ok 3 64-fold("Rough Consensus, and Running Code")
>        ok 4 168-fold("password")
>        ok 5 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY")
>        ok 6 168-fold("Q")
>        ok 7 168-fold("ba")
>        ok 8 64-fold("kerberos")
>        ok 9 128-fold("kerberos")
>        ok 10 168-fold("kerberos")
>        ok 11 256-fold("kerberos")
>    # RFC 3961 n-fold: pass:11 fail:0 skip:0 total:11
>    ok 1 RFC 3961 n-fold
>        KTAP version 1
>        # Subtest: RFC 3961 key derivation
>    # RFC 3961 key derivation: ASSERTION FAILED at
> net/sunrpc/auth_gss/gss_krb5_test.c:62
>    Expected err == 0, but
>        err == -22 (0xffffffffffffffea)
>        not ok 1 des3-hmac-sha1 key derivation case 1

This assertion means the RFC 3961 KDF function is not
available -- it was not enabled via Kconfig.


>    # RFC 3961 key derivation: ASSERTION FAILED at
> net/sunrpc/auth_gss/gss_krb5_test.c:62
>    Expected err == 0, but
>        err == -22 (0xffffffffffffffea)
>        not ok 2 des3-hmac-sha1 key derivation case 2
>    # RFC 3961 key derivation: ASSERTION FAILED at
> net/sunrpc/auth_gss/gss_krb5_test.c:62
>    Expected err == 0, but
>        err == -22 (0xffffffffffffffea)
>        not ok 3 des3-hmac-sha1 key derivation case 3
>    # RFC 3961 key derivation: ASSERTION FAILED at
> net/sunrpc/auth_gss/gss_krb5_test.c:62
>    Expected err == 0, but
>        err == -22 (0xffffffffffffffea)
>        not ok 4 des3-hmac-sha1 key derivation case 4
>    # RFC 3961 key derivation: ASSERTION FAILED at
> net/sunrpc/auth_gss/gss_krb5_test.c:62
>    Expected err == 0, but
>        err == -22 (0xffffffffffffffea)
>        not ok 5 des3-hmac-sha1 key derivation case 5
>    # RFC 3961 key derivation: ASSERTION FAILED at
> net/sunrpc/auth_gss/gss_krb5_test.c:62
>    Expected err == 0, but
>        err == -22 (0xffffffffffffffea)
>        not ok 6 des3-hmac-sha1 key derivation case 6
>    # RFC 3961 key derivation: ASSERTION FAILED at
> net/sunrpc/auth_gss/gss_krb5_test.c:62
>    Expected err == 0, but
>        err == -22 (0xffffffffffffffea)
>        not ok 7 des3-hmac-sha1 key derivation case 7
>    # RFC 3961 key derivation: ASSERTION FAILED at
> net/sunrpc/auth_gss/gss_krb5_test.c:62
>    Expected err == 0, but
>        err == -22 (0xffffffffffffffea)
>        not ok 8 des3-hmac-sha1 key derivation case 8
>    # RFC 3961 key derivation: ASSERTION FAILED at
> net/sunrpc/auth_gss/gss_krb5_test.c:62
>    Expected err == 0, but
>        err == -22 (0xffffffffffffffea)
>        not ok 9 des3-hmac-sha1 key derivation case 9
>    # RFC 3961 key derivation: pass:0 fail:9 skip:0 total:9
>    not ok 2 RFC 3961 key derivation
> *** CHK ***   FORMAT=2
> Current process id is 785
> BAD KERNEL TRAP: 00000000
> Modules linked in: gss_krb5_test kunit rpcsec_gss_krb5 auth_rpcgss
> oid_registry camellia_generic sha512_generic sha1_generic md5 cmac
> hmac ecb cts cbc
> PC: [<1187775a>] rfc6803_suite+0x2/0xffffc688 [gss_krb5_test]

Assuming that "PC:" on m68k is the same as "RIP:" on x86...
this does not make sense. rfc6803_suite is not a function.

1416 static struct kunit_suite rfc6803_suite = {
1417         .name                   = "RFC 6803 suite",
1418         .test_cases             = rfc6803_test_cases,
1419 };     


> SR: 2200  SP: efc1339e  a2: 01b4e610
> d0: 00000002    d1: 00000010    d2: 00000014    d3: 01b57cc4
> d4: 01b57c44    d5: 00000009    a0: 11877754    a1: 01b57c44
> Process insmod (pid: 785, task=52ae00a3)
> Frame format=2 instr addr=1187775a
> Stack from 01b57bd8:
>        11869860 00000000 01b57c44 00000000 00000005 00000001 00000000 00000000
>        11877e5c 11877e34 11877be8 1186a4d8 1186956e 00000001 00000009 00000000
>        00000000 0000000b 01b57cfc 00000001 00000000 00000001 00000002 00000000
>        00000000 00000000 00000000 00657333 2d686d61 632d7368 6131206b 65792064
>        65726976 6174696f 6e206361 73652039 00000000 484e4f4c 4f475922 29000000
>        00000801 000c729c 005d6074 00000000 00040cc0 00040cc0 00000000 00000000
> Call Trace: [<11869860>] kunit_run_tests+0x2f2/0x3d2 [kunit]
> 
> I.e. -EINVAL later, so something is still missing.
> 
> Second, with net/sunrpc/.kunitconfig, and just
> CONFIG_RPCSEC_GSS_KRB5_KUNIT_TEST still modular, the tests
> succeed, but there is still a crash:
> 
>    KTAP version 1
>    # Subtest: RFC 3961 tests
>    1..3
>        KTAP version 1
>        # Subtest: RFC 3961 n-fold
>        ok 1 64-fold("012345")
>        ok 2 56-fold("password")
>        ok 3 64-fold("Rough Consensus, and Running Code")
>        ok 4 168-fold("password")
>        ok 5 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY")
>        ok 6 168-fold("Q")
>        ok 7 168-fold("ba")
>        ok 8 64-fold("kerberos")
>        ok 9 128-fold("kerberos")
>        ok 10 168-fold("kerberos")
>        ok 11 256-fold("kerberos")
>    # RFC 3961 n-fold: pass:11 fail:0 skip:0 total:11
>    ok 1 RFC 3961 n-fold
>        KTAP version 1
>        # Subtest: RFC 3961 key derivation
>        ok 1 des3-hmac-sha1 key derivation case 1
>        ok 2 des3-hmac-sha1 key derivation case 2
>        ok 3 des3-hmac-sha1 key derivation case 3
>        ok 4 des3-hmac-sha1 key derivation case 4
>        ok 5 des3-hmac-sha1 key derivation case 5
>        ok 6 des3-hmac-sha1 key derivation case 6
>        ok 7 des3-hmac-sha1 key derivation case 7
>        ok 8 des3-hmac-sha1 key derivation case 8
>        ok 9 des3-hmac-sha1 key derivation case 9
>    # RFC 3961 key derivation: pass:9 fail:0 skip:0 total:9
>    ok 2 RFC 3961 key derivation
> *** CHK ***   FORMAT=2
> Current process id is 716
> BAD KERNEL TRAP: 00000000
> Modules linked in: gss_krb5_test
> PC: [<1197575a>] rfc6803_suite+0x2/0xffffc688 [gss_krb5_test]
> SR: 2200  SP: acd229e8  a2: 01ae20a0
> d0: 00000002    d1: 00000010    d2: 00000014    d3: 01ae1cc4
> d4: 01ae1c44    d5: 00000000    a0: 11975754    a1: 01ae1c44
> Process insmod (pid: 716, task=962b0746)
> Frame format=2 instr addr=1197575a
> Stack from 01ae1bd8:
>        001f3158 00000000 01ae1c44 00000000 00000005 00000001 00000000 00000000
>        11975e5c 11975e34 11975be8 001f415c 001f2e66 00000001 00000000 00000000
>        00000009 00000014 01ae1cfc 00000002 00000000 00000000 00000002 00000000
>        00000000 00000000 00000000 00657333 2d686d61 632d7368 6131206b 65792064
>        65726976 6174696f 6e206361 73652039 00000000 484e4f4c 4f475922 29000000
>        00000801 000c729c 005db3c4 00000000 00040cc0 00040cc0 00000000 00000000
> Call Trace: [<001f3158>] kunit_run_tests+0x2f2/0x3d2
> 
> Third, with net/sunrpc/.kunitconfig, and
> CONFIG_RPCSEC_GSS_KRB5_KUNIT_TEST=y:
> 
>    KTAP version 1
>    # Subtest: RFC 3961 tests
>    1..2
>        KTAP version 1
>        # Subtest: RFC 3961 n-fold
>        ok 1 64-fold("012345")
>        ok 2 56-fold("password")
>        ok 3 64-fold("Rough Consensus, and Running Code")
>        ok 4 168-fold("password")
>        ok 5 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY")
>        ok 6 168-fold("Q")
>        ok 7 168-fold("ba")
>        ok 8 64-fold("kerberos")
>        ok 9 128-fold("kerberos")
>        ok 10 168-fold("kerberos")
>        ok 11 256-fold("kerberos")
>    # RFC 3961 n-fold: pass:11 fail:0 skip:0 total:11
>    ok 1 RFC 3961 n-fold
>        KTAP version 1
>        # Subtest: RFC 3961 key derivation
>        ok 1 des3-hmac-sha1 key derivation case 1
>        ok 2 des3-hmac-sha1 key derivation case 2
>        ok 3 des3-hmac-sha1 key derivation case 3
>        ok 4 des3-hmac-sha1 key derivation case 4
>        ok 5 des3-hmac-sha1 key derivation case 5
>        ok 6 des3-hmac-sha1 key derivation case 6
>        ok 7 des3-hmac-sha1 key derivation case 7
>        ok 8 des3-hmac-sha1 key derivation case 8
>        ok 9 des3-hmac-sha1 key derivation case 9
>    # RFC 3961 key derivation: pass:9 fail:0 skip:0 total:9
>    ok 2 RFC 3961 key derivation
> # RFC 3961 tests: pass:2 fail:0 skip:0 total:2
> # Totals: pass:20 fail:0 skip:0 total:20
> ok 31 RFC 3961 tests
>    KTAP version 1
>    # Subtest: RFC 3962 suite
>    1..2
>        KTAP version 1
>        # Subtest: RFC 3962 encryption
>        ok 1 Encrypt with aes128-cts-hmac-sha1-96 case 1
>        ok 2 Encrypt with aes128-cts-hmac-sha1-96 case 2
>        ok 3 Encrypt with aes128-cts-hmac-sha1-96 case 3
>        ok 4 Encrypt with aes128-cts-hmac-sha1-96 case 4
>        ok 5 Encrypt with aes128-cts-hmac-sha1-96 case 5
>        ok 6 Encrypt with aes128-cts-hmac-sha1-96 case 6
>    # RFC 3962 encryption: pass:6 fail:0 skip:0 total:6
>    ok 1 RFC 3962 encryption
> Unable to handle kernel access at virtual address af06da84
> Oops: 00000000
> Modules linked in:
> PC: [<20746573>] 0x20746573
> SR: 2204  SP: 05ef00e4  a2: 010195d0
> d0: 00000002    d1: 00000010    d2: 00000006    d3: 0101bdf8
> d4: 0101bd78    d5: 00000000    a0: 20746573    a1: 0101bd78
> Process swapper (pid: 1, task=b63809d5)
> Frame format=7 eff addr=20746573 ssw=0546 faddr=20746573
> wb 1 stat/addr/data: 0000 00000000 00000000
> wb 2 stat/addr/data: 0000 00000000 00000000
> wb 3 stat/addr/data: 0000 20746573 00000000
> push data: 00000000 00000000 00000000 00000000
> Stack from 0101bd0c:
>        001f64b0 00000000 0101bd78 0000001f 00000023 01015480 000359ba 0000209c
>        00000000 005890c0 0053aafc 001f7c88 001f61be 00000001 00000000 00000000
>        00000006 00000006 0101be30 00000001 00000000 00000000 00000001 00000000
>        00000000 00000000 00000000 006e6372 79707420 77697468 20616573 3132382d
>        6374732d 686d6163 2d736861 312d3936 20636173 65203600 4f475922 29000000
>        00000801 000c886c 006003b4 00000000 00040cc0 00040cc0 00000000 00000000
> Call Trace: [<001f64b0>] kunit_run_tests+0x2f2/0x3d2
> [<000359ba>] parse_args+0x0/0x202
> [<0000209c>] do_one_initcall+0x0/0x184
> [<001f7c88>] kunit_debugfs_create_suite+0x0/0x54
> [<001f61be>] kunit_run_tests+0x0/0x3d2
> [<000c886c>] get_page_from_freelist+0x176/0x48a
> [<00040cc0>] __finish_swait+0x1a/0x1c
> [<00040cc0>] __finish_swait+0x1a/0x1c
> [<00040cc0>] __finish_swait+0x1a/0x1c
> [<0000209c>] do_one_initcall+0x0/0x184
> [<000c86f6>] get_page_from_freelist+0x0/0x48a
> [<000c8500>] prepare_alloc_pages.isra.0+0x12/0x84
> [<001f6632>] __kunit_test_suites_init+0xa2/0xfa
> [<003a160c>] _printk+0x0/0x18
> [<001f7b9e>] kunit_run_all_tests+0xd0/0x1a6
> [<0039a0c0>] strcpy+0x0/0x1c
> [<00564602>] kernel_init_freeable+0x152/0x190
> [<000359ba>] parse_args+0x0/0x202
> [<003a6e76>] kernel_init+0x0/0xec
> [<003a6e8a>] kernel_init+0x14/0xec
> [<003a6e76>] kernel_init+0x0/0xec
> [<000028d4>] ret_from_kernel_thread+0xc/0x14
> 
> I.e. a slightly different crash.
> As the difference between the two crashes is modular vs. builtin,
> this looks like an out-of-bound access in the test.

Why not run the test suite just as I suggested?

Since I cannot reproduce this crash and do not have an m68k
platform available to me, I will need you to continue to
pursue the issue. I'll help as much as I can.

I would very much like to see successful test results on
non-x86 platforms.

--
Chuck Lever
Geert Uytterhoeven Feb. 23, 2023, 4:52 p.m. UTC | #7
Hi Chuck,

On Thu, Feb 23, 2023 at 5:19 PM Chuck Lever III <chuck.lever@oracle.com> wrote:
> > On Feb 23, 2023, at 10:16 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Thu, Feb 23, 2023 at 3:00 PM Chuck Lever III <chuck.lever@oracle.com> wrote:
> >>> On Feb 23, 2023, at 8:05 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >>> On Sun, 15 Jan 2023, Chuck Lever wrote:
> >>>> The purpose of this series is to improve/harden the security
> >>>> provided by the Linux kernel's RPCSEC GSS Kerberos 5 mechanism.
> >>>> There are lots of clean-ups in this series, but the pertinent
> >>>> feature is the addition of a clean deprecation path for the DES-
> >>>> and SHA1-based encryption types in accordance with Internet BCPs.
> >>>>
> >>>> This series disables DES-based enctypes by default, provides a
> >>>> mechanism for disabling SHA1-based enctypes, and introduces two
> >>>> modern enctypes that do not use deprecated crypto algorithms.
> >>>>
> >>>> Not only does that improve security for Kerberos 5 users, but it
> >>>> also prepares SunRPC for eventually switching to a shared common
> >>>> kernel Kerberos 5 implementation, which surely will not implement
> >>>> any deprecated encryption types (in particular, DES-based ones).
> >>>>
> >>>> Today, MIT supports both of the newly-introduced enctypes, but
> >>>> Heimdal does not appear to. Thus distributions can enable and
> >>>> disable kernel enctype support to match the set of enctypes
> >>>> supported in their user space Kerberos libraries.
> >>>>
> >>>> Scott has been kicking the tires -- we've found no regressions with
> >>>> the current SHA1-based enctypes, while the new ones are disabled by
> >>>> default until we have an opportunity for interop testing. The KUnit
> >>>> tests for the new enctypes pass and this implementation successfully
> >>>> interoperates with itself using these enctypes. Therefore I believe
> >>>> it to be safe to merge.
> >>>>
> >>>> When this series gets merged, the Linux NFS community should select
> >>>> and announce a date-certain for removal of SunRPC's DES-based
> >>>> enctype code.
> >>>
> >>> As this is now upstream, I gave it a try on m68k (on the ARAnyM
> >>> emulator), using a config based on atari_defconfig:
> >>>
> >>>   KTAP version 1
> >>>   # Subtest: RFC 3961 tests
> >>>   1..3
> >>>       KTAP version 1
> >>>       # Subtest: RFC 3961 n-fold
> >>>       ok 1 64-fold("012345")
> >>>       ok 2 56-fold("password")
> >>>       ok 3 64-fold("Rough Consensus, and Running Code")
> >>>       ok 4 168-fold("password")
> >>>       ok 5 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY")
> >>>       ok 6 168-fold("Q")
> >>>       ok 7 168-fold("ba")
> >>>       ok 8 64-fold("kerberos")
> >>>       ok 9 128-fold("kerberos")
> >>>       ok 10 168-fold("kerberos")
> >>>       ok 11 256-fold("kerberos")
> >>>   # RFC 3961 n-fold: pass:11 fail:0 skip:0 total:11
> >>>   ok 1 RFC 3961 n-fold
> >>>       KTAP version 1
> >>>       # Subtest: RFC 3961 key derivation
> >>>   # RFC 3961 key derivation: ASSERTION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:52
> >>>   Expected gk5e != ((void *)0), but
> >>>       gk5e == 00000000
> >>>       ((void *)0) == 00000000
> >>>       not ok 1 des3-hmac-sha1 key derivation case 1
> >>
> >> Geert, thanks for testing GSS on m68k.
> >>
> >> This assertion failure means that support for the encryption types
> >> specified in RFC 3961 is not built into your kernel.
> >>
> >> The new Kunit tests don't work unless everything is built in --
> >>
> >> there's a net/sunrpc/.kunitconfig that provides the supported
> >> build configuration for running them. I typically use a command
> >> line similar to this:
> >>
> >> ./tools/testing/kunit/kunit.py run --raw_output=all --kunitconfig ./net/sunrpc/.kunitconfig
> >
> > Aren't modular crypto algorithms auto-loaded when needed?
>
> The ciphers and digests are handled via the kernel's crypto
> manager. They will indeed get auto-loaded by SunRPC's GSS on
> demand, but of course, the set of algorithms used by GSS
> has to be enabled by Kconfig options first.
>
> SunRPC GSS has a set of Kerberos encryption types that make
> use of individual ciphers and digests. Those have never been
> modularized, and they are each enabled by Kconfig options,
> as explained below.
>
>
> > In general, it's a good idea to make the tests test only functionality
> > that is available, either through "depends on" in Kconfig, or "#if
> > IS_ENABLED(...)".
>
> An earlier version of this patch set did just that. It became
> quite a mess. That's why I chose the .kunitconfig approach.
>
>
> > Of course that does not preclude providing a
> > .kunitconfig to enable and test everything.
>
> The suite should test every Kerberos encryption type that
> SunRPC GSS has support for. There's no reason to disable a
> particular encryption type when running the unit tests...
> unless I'm missing something?

That depends: do you want to test everything, or do you want to test
(only) the functionality you enabled for your product?
I tend to enable all modular tests, so I can use insmod to run any
relevant test when needed.  If a test suddenly needs something that
is not enabled, you can not run the test without enabling extra
functionality (which you may not want to enable).

> > Note that net/sunrpc/.kunitconfig has
> >
> >    CONFIG_RPCSEC_GSS_KRB5_KUNIT_TEST=y
> >
> > which needs KUNIT_ALL_TESTS=y, else it will still be modular.
> >
> > First, I tried getting my modular setup working.
> > After enabling:
> >    CONFIG_RPCSEC_GSS_KRB5_ENCTYPES_DES=y
>
> And CONFIG_RPCSEC_GSS_KRB5_ENCTYPES_AES_SHA1=y ??

Sure, I had that enabled, thanks to "default y".

> > Third, with net/sunrpc/.kunitconfig, and
> > CONFIG_RPCSEC_GSS_KRB5_KUNIT_TEST=y:

[...]

> > Unable to handle kernel access at virtual address af06da84

> > I.e. a slightly different crash.
> > As the difference between the two crashes is modular vs. builtin,
> > this looks like an out-of-bound access in the test.
>
> Why not run the test suite just as I suggested?

I don't think I can use tools/testing/kunit/kunit.py to run the tests
when cross-compiling my kernel?

My third case (adding options from net/sunrpc/.kunitconfig, and
setting CONFIG_RPCSEC_GSS_KRB5_KUNIT_TEST=y) should be equivalent to
that, right?

> Since I cannot reproduce this crash and do not have an m68k
> platform available to me, I will need you to continue to
> pursue the issue. I'll help as much as I can.
>
> I would very much like to see successful test results on
> non-x86 platforms.

Thanks, I'll give it a try on some other platforms, later...

Gr{oetje,eeting}s,

                        Geert
Andreas Schwab Feb. 23, 2023, 5:57 p.m. UTC | #8
On Feb 23 2023, Chuck Lever III wrote:

> Assuming that "PC:" on m68k is the same as "RIP:" on x86...
> this does not make sense. rfc6803_suite is not a function.

That can mean that something has overwritten the return PC.
Michael Schmitz Feb. 23, 2023, 6:19 p.m. UTC | #9
Hi Andreas,

On 24/02/23 06:57, Andreas Schwab wrote:
> On Feb 23 2023, Chuck Lever III wrote:
>
>> Assuming that "PC:" on m68k is the same as "RIP:" on x86...
>> this does not make sense. rfc6803_suite is not a function.
> That can mean that something has overwritten the return PC.
>
Wouldn't you expect a format error in that case?

Cheers,

     Michael
Chuck Lever III Feb. 23, 2023, 7:32 p.m. UTC | #10
> On Feb 23, 2023, at 11:52 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> 
> Hi Chuck,
> 
> On Thu, Feb 23, 2023 at 5:19 PM Chuck Lever III <chuck.lever@oracle.com> wrote:
>>> On Feb 23, 2023, at 10:16 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>> On Thu, Feb 23, 2023 at 3:00 PM Chuck Lever III <chuck.lever@oracle.com> wrote:
>>>>> On Feb 23, 2023, at 8:05 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>>>> On Sun, 15 Jan 2023, Chuck Lever wrote:
>>>>>> The purpose of this series is to improve/harden the security
>>>>>> provided by the Linux kernel's RPCSEC GSS Kerberos 5 mechanism.
>>>>>> There are lots of clean-ups in this series, but the pertinent
>>>>>> feature is the addition of a clean deprecation path for the DES-
>>>>>> and SHA1-based encryption types in accordance with Internet BCPs.
>>>>>> 
>>>>>> This series disables DES-based enctypes by default, provides a
>>>>>> mechanism for disabling SHA1-based enctypes, and introduces two
>>>>>> modern enctypes that do not use deprecated crypto algorithms.
>>>>>> 
>>>>>> Not only does that improve security for Kerberos 5 users, but it
>>>>>> also prepares SunRPC for eventually switching to a shared common
>>>>>> kernel Kerberos 5 implementation, which surely will not implement
>>>>>> any deprecated encryption types (in particular, DES-based ones).
>>>>>> 
>>>>>> Today, MIT supports both of the newly-introduced enctypes, but
>>>>>> Heimdal does not appear to. Thus distributions can enable and
>>>>>> disable kernel enctype support to match the set of enctypes
>>>>>> supported in their user space Kerberos libraries.
>>>>>> 
>>>>>> Scott has been kicking the tires -- we've found no regressions with
>>>>>> the current SHA1-based enctypes, while the new ones are disabled by
>>>>>> default until we have an opportunity for interop testing. The KUnit
>>>>>> tests for the new enctypes pass and this implementation successfully
>>>>>> interoperates with itself using these enctypes. Therefore I believe
>>>>>> it to be safe to merge.
>>>>>> 
>>>>>> When this series gets merged, the Linux NFS community should select
>>>>>> and announce a date-certain for removal of SunRPC's DES-based
>>>>>> enctype code.
>>>>> 
>>>>> As this is now upstream, I gave it a try on m68k (on the ARAnyM
>>>>> emulator), using a config based on atari_defconfig:
>>>>> 
>>>>>  KTAP version 1
>>>>>  # Subtest: RFC 3961 tests
>>>>>  1..3
>>>>>      KTAP version 1
>>>>>      # Subtest: RFC 3961 n-fold
>>>>>      ok 1 64-fold("012345")
>>>>>      ok 2 56-fold("password")
>>>>>      ok 3 64-fold("Rough Consensus, and Running Code")
>>>>>      ok 4 168-fold("password")
>>>>>      ok 5 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY")
>>>>>      ok 6 168-fold("Q")
>>>>>      ok 7 168-fold("ba")
>>>>>      ok 8 64-fold("kerberos")
>>>>>      ok 9 128-fold("kerberos")
>>>>>      ok 10 168-fold("kerberos")
>>>>>      ok 11 256-fold("kerberos")
>>>>>  # RFC 3961 n-fold: pass:11 fail:0 skip:0 total:11
>>>>>  ok 1 RFC 3961 n-fold
>>>>>      KTAP version 1
>>>>>      # Subtest: RFC 3961 key derivation
>>>>>  # RFC 3961 key derivation: ASSERTION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:52
>>>>>  Expected gk5e != ((void *)0), but
>>>>>      gk5e == 00000000
>>>>>      ((void *)0) == 00000000
>>>>>      not ok 1 des3-hmac-sha1 key derivation case 1
>>>> 
>>>> Geert, thanks for testing GSS on m68k.
>>>> 
>>>> This assertion failure means that support for the encryption types
>>>> specified in RFC 3961 is not built into your kernel.
>>>> 
>>>> The new Kunit tests don't work unless everything is built in --
>>>> 
>>>> there's a net/sunrpc/.kunitconfig that provides the supported
>>>> build configuration for running them. I typically use a command
>>>> line similar to this:
>>>> 
>>>> ./tools/testing/kunit/kunit.py run --raw_output=all --kunitconfig ./net/sunrpc/.kunitconfig
>>> 
>>> Aren't modular crypto algorithms auto-loaded when needed?
>> 
>> The ciphers and digests are handled via the kernel's crypto
>> manager. They will indeed get auto-loaded by SunRPC's GSS on
>> demand, but of course, the set of algorithms used by GSS
>> has to be enabled by Kconfig options first.
>> 
>> SunRPC GSS has a set of Kerberos encryption types that make
>> use of individual ciphers and digests. Those have never been
>> modularized, and they are each enabled by Kconfig options,
>> as explained below.
>> 
>> 
>>> In general, it's a good idea to make the tests test only functionality
>>> that is available, either through "depends on" in Kconfig, or "#if
>>> IS_ENABLED(...)".
>> 
>> An earlier version of this patch set did just that. It became
>> quite a mess. That's why I chose the .kunitconfig approach.
>> 
>> 
>>> Of course that does not preclude providing a
>>> .kunitconfig to enable and test everything.
>> 
>> The suite should test every Kerberos encryption type that
>> SunRPC GSS has support for. There's no reason to disable a
>> particular encryption type when running the unit tests...
>> unless I'm missing something?
> 
> That depends: do you want to test everything, or do you want to test
> (only) the functionality you enabled for your product?

Each Kunit test is supposed to test one thing in particular.
These tests each test a feature of the GSS Kerberos
encryption type implementation.

So... they are really not for the purpose of configuration or
integration testing. I didn't have distributors in mind for
running these tests. They are instead targeted to kernel
developers and platform maintainers.


> I tend to enable all modular tests, so I can use insmod to run any
> relevant test when needed.  If a test suddenly needs something that
> is not enabled, you can not run the test without enabling extra
> functionality (which you may not want to enable).

I wouldn't expect these tests to be run as part of a product
CI suite. They are most valuable when making changes to the
SunRPC GSS code, or crypto code that GSS depends on.

"Did I just break this code?"


>>> Note that net/sunrpc/.kunitconfig has
>>> 
>>>   CONFIG_RPCSEC_GSS_KRB5_KUNIT_TEST=y
>>> 
>>> which needs KUNIT_ALL_TESTS=y, else it will still be modular.
>>> 
>>> First, I tried getting my modular setup working.
>>> After enabling:
>>>   CONFIG_RPCSEC_GSS_KRB5_ENCTYPES_DES=y
>> 
>> And CONFIG_RPCSEC_GSS_KRB5_ENCTYPES_AES_SHA1=y ??
> 
> Sure, I had that enabled, thanks to "default y".
> 
>>> Third, with net/sunrpc/.kunitconfig, and
>>> CONFIG_RPCSEC_GSS_KRB5_KUNIT_TEST=y:
> 
> [...]
> 
>>> Unable to handle kernel access at virtual address af06da84
> 
>>> I.e. a slightly different crash.
>>> As the difference between the two crashes is modular vs. builtin,
>>> this looks like an out-of-bound access in the test.
>> 
>> Why not run the test suite just as I suggested?
> 
> I don't think I can use tools/testing/kunit/kunit.py to run the tests
> when cross-compiling my kernel?

You should be able to... that tool runs under UML and
compiles what it needs to run the tests.


> My third case (adding options from net/sunrpc/.kunitconfig, and
> setting CONFIG_RPCSEC_GSS_KRB5_KUNIT_TEST=y) should be equivalent to
> that, right?
> 
>> Since I cannot reproduce this crash and do not have an m68k
>> platform available to me, I will need you to continue to
>> pursue the issue. I'll help as much as I can.
>> 
>> I would very much like to see successful test results on
>> non-x86 platforms.
> 
> Thanks, I'll give it a try on some other platforms, later...


--
Chuck Lever
Andreas Schwab Feb. 23, 2023, 9:46 p.m. UTC | #11
On Feb 24 2023, Michael Schmitz wrote:

> Hi Andreas,
>
> On 24/02/23 06:57, Andreas Schwab wrote:
>> On Feb 23 2023, Chuck Lever III wrote:
>>
>>> Assuming that "PC:" on m68k is the same as "RIP:" on x86...
>>> this does not make sense. rfc6803_suite is not a function.
>> That can mean that something has overwritten the return PC.
>>
> Wouldn't you expect a format error in that case?

What format error do you mean?  There was a chk exception, presumably
because the first word of rfc6803_suite happens to match the encoding of
the chk insn.
Michael Schmitz Feb. 23, 2023, 10:17 p.m. UTC | #12
Hi Andreas,

On 24/02/23 10:46, Andreas Schwab wrote:
> On Feb 24 2023, Michael Schmitz wrote:
>
>> Hi Andreas,
>>
>> On 24/02/23 06:57, Andreas Schwab wrote:
>>> On Feb 23 2023, Chuck Lever III wrote:
>>>
>>>> Assuming that "PC:" on m68k is the same as "RIP:" on x86...
>>>> this does not make sense. rfc6803_suite is not a function.
>>> That can mean that something has overwritten the return PC.
>>>
>> Wouldn't you expect a format error in that case?
> What format error do you mean?  There was a chk exception, presumably
> because the first word of rfc6803_suite happens to match the encoding of
> the chk insn.

I got confused by 'return PC' and thought the exception had happened on 
a return instruction (but even that would be unlikely - only rte can 
generate a format error ...).

Your explanation is more likely to be correct. Would that Geert had 
copied the code snipped from the log.

Cheers,

     Michael
Geert Uytterhoeven Feb. 27, 2023, 9:51 a.m. UTC | #13
Hi Chuck,

On Thu, Feb 23, 2023 at 5:52 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Feb 23, 2023 at 5:19 PM Chuck Lever III <chuck.lever@oracle.com> wrote:
> > > On Feb 23, 2023, at 10:16 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
 > > Unable to handle kernel access at virtual address af06da84
>
> > > I.e. a slightly different crash.
> > > As the difference between the two crashes is modular vs. builtin,
> > > this looks like an out-of-bound access in the test.

Just ran it on physical arm32 and arm64 (Renesas APE6EVM and
Salvator-XS), and the test crashes there, too.

> > Why not run the test suite just as I suggested?

kunit_kernel.ConfigError: m68k is not a valid arch, options are
['alpha', 'arm', 'arm64', 'i386', 'powerpc', 'riscv', 's390', 'sparc',
'x86_64']

Will look into adding m68k support ;-)

But the issue can easily be reproduced using
".../tools/testing/kunit/kunit.py run --arch=arm
--cross_compile=arm-linux-gnueabihf- --raw_output=all --kunitconfig
./net/sunrpc/.kunitconfig" on current upstream[1]:

KTAP version 1
1..5
    KTAP version 1
    # Subtest: RFC 3961 tests
    1..2
        KTAP version 1
        # Subtest: RFC 3961 n-fold
        ok 1 64-fold("012345")
        ok 2 56-fold("password")
        ok 3 64-fold("Rough Consensus, and Running Code")
        ok 4 168-fold("password")
        ok 5 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY")
        ok 6 168-fold("Q")
        ok 7 168-fold("ba")
        ok 8 64-fold("kerberos")
        ok 9 128-fold("kerberos")
        ok 10 168-fold("kerberos")
        ok 11 256-fold("kerberos")
    # RFC 3961 n-fold: pass:11 fail:0 skip:0 total:11
    ok 1 RFC 3961 n-fold
        KTAP version 1
        # Subtest: RFC 3961 key derivation
        ok 1 des3-hmac-sha1 key derivation case 1
        ok 2 des3-hmac-sha1 key derivation case 2
        ok 3 des3-hmac-sha1 key derivation case 3
        ok 4 des3-hmac-sha1 key derivation case 4
        ok 5 des3-hmac-sha1 key derivation case 5
        ok 6 des3-hmac-sha1 key derivation case 6
        ok 7 des3-hmac-sha1 key derivation case 7
        ok 8 des3-hmac-sha1 key derivation case 8
        ok 9 des3-hmac-sha1 key derivation case 9
    # RFC 3961 key derivation: pass:9 fail:0 skip:0 total:9
    ok 2 RFC 3961 key derivation
# RFC 3961 tests: pass:2 fail:0 skip:0 total:2
# Totals: pass:20 fail:0 skip:0 total:20
ok 1 RFC 3961 tests
    KTAP version 1
    # Subtest: RFC 3962 suite
    1..2
        KTAP version 1
        # Subtest: RFC 3962 encryption
        ok 1 Encrypt with aes128-cts-hmac-sha1-96 case 1
        ok 2 Encrypt with aes128-cts-hmac-sha1-96 case 2
        ok 3 Encrypt with aes128-cts-hmac-sha1-96 case 3
        ok 4 Encrypt with aes128-cts-hmac-sha1-96 case 4
        ok 5 Encrypt with aes128-cts-hmac-sha1-96 case 5
        ok 6 Encrypt with aes128-cts-hmac-sha1-96 case 6
    # RFC 3962 encryption: pass:6 fail:0 skip:0 total:6
    ok 1 RFC 3962 encryption
8<--- cut here ---
Unable to handle kernel paging request at virtual address 73657420 when execute
[73657420] *pgd=00000000
Internal error: Oops: 80000005 [#1] ARM
CPU: 0 PID: 1 Comm: swapper Tainted: G                 N
6.2.0-12486-g85f341272fa9 #1
Hardware name: Generic DT based system
PC is at 0x73657420
LR is at kunit_run_tests+0x3cc/0x5e8
pc : [<73657420>]    lr : [<c02d0e54>]    psr: 20000053
sp : f0809cc8  ip : f0809e54  fp : 00000006
r10: c069dc30  r9 : c069dd84  r8 : f0809e54
r7 : 00000000  r6 : 00000006  r5 : c08a8504  r4 : c08a82d0
r3 : 73657420  r2 : 00000002  r1 : f0809e54  r0 : 00000000
Flags: nzCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment none
Control: 10c53c7d  Table: 40004059  DAC: 00000051
Register r0 information: NULL pointer
Register r1 information: 2-page vmalloc region starting at 0xf0808000
allocated at kernel_clone+0x94/0x2fc
Register r2 information: non-paged memory
Register r3 information: non-paged memory
Register r4 information: non-slab/vmalloc memory
Register r5 information: non-slab/vmalloc memory
Register r6 information: non-paged memory
Register r7 information: NULL pointer
Register r8 information: 2-page vmalloc region starting at 0xf0808000
allocated at kernel_clone+0x94/0x2fc
Register r9 information: non-slab/vmalloc memory
Register r10 information: non-slab/vmalloc memory
Register r11 information: non-paged memory
Register r12 information: 2-page vmalloc region starting at 0xf0808000
allocated at kernel_clone+0x94/0x2fc
Process swapper (pid: 1, stack limit = 0x(ptrval))
Stack: (0xf0809cc8 to 0xf080a000)
9cc0:                   c06b6154 f0809d54 00000006 c01443d8 00000000 00000000
9ce0: 00000000 00000000 c088a8c0 c069dd1c c069dd38 c0698d6c 00000000 00000001
9d00: 00000000 00000000 00000001 00000000 00000000 00000000 00000000 00000000
9d20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9d40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9d60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9d80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9da0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9dc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9de0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9e00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9e20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9e40: 00000000 00000000 00000000 00000000 00000000 72636e00 20747079 68746977
9e60: 73656120 2d383231 2d737463 63616d68 6168732d 36392d31 73616320 00362065
9e80: 2259474f 00000029 800000d3 3ffff049 0000000c 00313601 0000004a 00000000
9ea0: c0894480 ff7583a2 00000004 ffffffff 00000000 c069e520 00000000 c072185c
9ec0: c072183c c0141eac f0809f1c c031fd5c 0251f4a2 ff7583a2 c0727f10 c08d932c
9ee0: c0727f14 00000002 00000005 c0804205 00000000 c072183c c0700510 c02d1160
9f00: c0cf534e c050f460 f0809f1c 00000005 c0727f10 c0cf5340 00000000 00000001
9f20: c072185c c02d2e94 c0c01100 c0727f24 c0727f10 c08d9318 c072185c c0806cd0
9f40: c0728750 c0cf5340 c06b9808 c06b73e0 c072185c c072183c c0700510 c07015f4
9f60: 00000007 00000007 00000000 c0700510 00000002 0000005d c0c5c000 c0804200
9f80: c0515dd8 00000000 00000000 00000000 00000000 00000000 00000000 c0515df0
9fa0: 00000000 c0515dd8 00000000 c0100148 00000000 00000000 00000000 00000000
9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
 kunit_run_tests from __kunit_test_suites_init+0xc0/0x1a8
 __kunit_test_suites_init from kunit_run_all_tests+0x24c/0x41c
 kunit_run_all_tests from kernel_init_freeable+0x20c/0x258
 kernel_init_freeable from kernel_init+0x18/0x144
 kernel_init from ret_from_fork+0x14/0x2c
Exception stack(0xf0809fb0 to 0xf0809ff8)
9fa0:                                     00000000 00000000 00000000 00000000
9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
Code: bad PC value
---[ end trace 0000000000000000 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

[1] 85f341272fa9 = f3a2439f20d91893 ("Merge tag 'rproc-v6.3' of
    git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux") +
    a cherry-pick of a fix for a regression on my arm64 platforms)

Gr{oetje,eeting}s,

                        Geert
Chuck Lever III Feb. 27, 2023, 3:06 p.m. UTC | #14
> On Feb 27, 2023, at 4:51 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> 
> Hi Chuck,
> 
> On Thu, Feb 23, 2023 at 5:52 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> On Thu, Feb 23, 2023 at 5:19 PM Chuck Lever III <chuck.lever@oracle.com> wrote:
>>>> On Feb 23, 2023, at 10:16 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>> Unable to handle kernel access at virtual address af06da84
>> 
>>>> I.e. a slightly different crash.
>>>> As the difference between the two crashes is modular vs. builtin,
>>>> this looks like an out-of-bound access in the test.
> 
> Just ran it on physical arm32 and arm64 (Renesas APE6EVM and
> Salvator-XS), and the test crashes there, too.
> 
>>> Why not run the test suite just as I suggested?
> 
> kunit_kernel.ConfigError: m68k is not a valid arch, options are
> ['alpha', 'arm', 'arm64', 'i386', 'powerpc', 'riscv', 's390', 'sparc',
> 'x86_64']
> 
> Will look into adding m68k support ;-)
> 
> But the issue can easily be reproduced using
> ".../tools/testing/kunit/kunit.py run --arch=arm
> --cross_compile=arm-linux-gnueabihf- --raw_output=all --kunitconfig
> ./net/sunrpc/.kunitconfig" on current upstream[1]:
> 
> KTAP version 1
> 1..5
>    KTAP version 1
>    # Subtest: RFC 3961 tests
>    1..2
>        KTAP version 1
>        # Subtest: RFC 3961 n-fold
>        ok 1 64-fold("012345")
>        ok 2 56-fold("password")
>        ok 3 64-fold("Rough Consensus, and Running Code")
>        ok 4 168-fold("password")
>        ok 5 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY")
>        ok 6 168-fold("Q")
>        ok 7 168-fold("ba")
>        ok 8 64-fold("kerberos")
>        ok 9 128-fold("kerberos")
>        ok 10 168-fold("kerberos")
>        ok 11 256-fold("kerberos")
>    # RFC 3961 n-fold: pass:11 fail:0 skip:0 total:11
>    ok 1 RFC 3961 n-fold
>        KTAP version 1
>        # Subtest: RFC 3961 key derivation
>        ok 1 des3-hmac-sha1 key derivation case 1
>        ok 2 des3-hmac-sha1 key derivation case 2
>        ok 3 des3-hmac-sha1 key derivation case 3
>        ok 4 des3-hmac-sha1 key derivation case 4
>        ok 5 des3-hmac-sha1 key derivation case 5
>        ok 6 des3-hmac-sha1 key derivation case 6
>        ok 7 des3-hmac-sha1 key derivation case 7
>        ok 8 des3-hmac-sha1 key derivation case 8
>        ok 9 des3-hmac-sha1 key derivation case 9
>    # RFC 3961 key derivation: pass:9 fail:0 skip:0 total:9
>    ok 2 RFC 3961 key derivation
> # RFC 3961 tests: pass:2 fail:0 skip:0 total:2
> # Totals: pass:20 fail:0 skip:0 total:20
> ok 1 RFC 3961 tests
>    KTAP version 1
>    # Subtest: RFC 3962 suite
>    1..2
>        KTAP version 1
>        # Subtest: RFC 3962 encryption
>        ok 1 Encrypt with aes128-cts-hmac-sha1-96 case 1
>        ok 2 Encrypt with aes128-cts-hmac-sha1-96 case 2
>        ok 3 Encrypt with aes128-cts-hmac-sha1-96 case 3
>        ok 4 Encrypt with aes128-cts-hmac-sha1-96 case 4
>        ok 5 Encrypt with aes128-cts-hmac-sha1-96 case 5
>        ok 6 Encrypt with aes128-cts-hmac-sha1-96 case 6
>    # RFC 3962 encryption: pass:6 fail:0 skip:0 total:6
>    ok 1 RFC 3962 encryption
> 8<--- cut here ---
> Unable to handle kernel paging request at virtual address 73657420 when execute
> [73657420] *pgd=00000000
> Internal error: Oops: 80000005 [#1] ARM
> CPU: 0 PID: 1 Comm: swapper Tainted: G                 N
> 6.2.0-12486-g85f341272fa9 #1
> Hardware name: Generic DT based system
> PC is at 0x73657420
> LR is at kunit_run_tests+0x3cc/0x5e8
> pc : [<73657420>]    lr : [<c02d0e54>]    psr: 20000053
> sp : f0809cc8  ip : f0809e54  fp : 00000006
> r10: c069dc30  r9 : c069dd84  r8 : f0809e54
> r7 : 00000000  r6 : 00000006  r5 : c08a8504  r4 : c08a82d0
> r3 : 73657420  r2 : 00000002  r1 : f0809e54  r0 : 00000000
> Flags: nzCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment none
> Control: 10c53c7d  Table: 40004059  DAC: 00000051
> Register r0 information: NULL pointer
> Register r1 information: 2-page vmalloc region starting at 0xf0808000
> allocated at kernel_clone+0x94/0x2fc
> Register r2 information: non-paged memory
> Register r3 information: non-paged memory
> Register r4 information: non-slab/vmalloc memory
> Register r5 information: non-slab/vmalloc memory
> Register r6 information: non-paged memory
> Register r7 information: NULL pointer
> Register r8 information: 2-page vmalloc region starting at 0xf0808000
> allocated at kernel_clone+0x94/0x2fc
> Register r9 information: non-slab/vmalloc memory
> Register r10 information: non-slab/vmalloc memory
> Register r11 information: non-paged memory
> Register r12 information: 2-page vmalloc region starting at 0xf0808000
> allocated at kernel_clone+0x94/0x2fc
> Process swapper (pid: 1, stack limit = 0x(ptrval))
> Stack: (0xf0809cc8 to 0xf080a000)
> 9cc0:                   c06b6154 f0809d54 00000006 c01443d8 00000000 00000000
> 9ce0: 00000000 00000000 c088a8c0 c069dd1c c069dd38 c0698d6c 00000000 00000001
> 9d00: 00000000 00000000 00000001 00000000 00000000 00000000 00000000 00000000
> 9d20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 9d40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 9d60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 9d80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 9da0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 9dc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 9de0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 9e00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 9e20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 9e40: 00000000 00000000 00000000 00000000 00000000 72636e00 20747079 68746977
> 9e60: 73656120 2d383231 2d737463 63616d68 6168732d 36392d31 73616320 00362065
> 9e80: 2259474f 00000029 800000d3 3ffff049 0000000c 00313601 0000004a 00000000
> 9ea0: c0894480 ff7583a2 00000004 ffffffff 00000000 c069e520 00000000 c072185c
> 9ec0: c072183c c0141eac f0809f1c c031fd5c 0251f4a2 ff7583a2 c0727f10 c08d932c
> 9ee0: c0727f14 00000002 00000005 c0804205 00000000 c072183c c0700510 c02d1160
> 9f00: c0cf534e c050f460 f0809f1c 00000005 c0727f10 c0cf5340 00000000 00000001
> 9f20: c072185c c02d2e94 c0c01100 c0727f24 c0727f10 c08d9318 c072185c c0806cd0
> 9f40: c0728750 c0cf5340 c06b9808 c06b73e0 c072185c c072183c c0700510 c07015f4
> 9f60: 00000007 00000007 00000000 c0700510 00000002 0000005d c0c5c000 c0804200
> 9f80: c0515dd8 00000000 00000000 00000000 00000000 00000000 00000000 c0515df0
> 9fa0: 00000000 c0515dd8 00000000 c0100148 00000000 00000000 00000000 00000000
> 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> kunit_run_tests from __kunit_test_suites_init+0xc0/0x1a8
> __kunit_test_suites_init from kunit_run_all_tests+0x24c/0x41c
> kunit_run_all_tests from kernel_init_freeable+0x20c/0x258
> kernel_init_freeable from kernel_init+0x18/0x144
> kernel_init from ret_from_fork+0x14/0x2c
> Exception stack(0xf0809fb0 to 0xf0809ff8)
> 9fa0:                                     00000000 00000000 00000000 00000000
> 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> Code: bad PC value
> ---[ end trace 0000000000000000 ]---
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> 
> [1] 85f341272fa9 = f3a2439f20d91893 ("Merge tag 'rproc-v6.3' of
>    git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux") +
>    a cherry-pick of a fix for a regression on my arm64 platforms)

I'm still not able to reproduce:

[cel@bazille odd-releases]$ tools/testing/kunit/kunit.py run --arch=arm
--cross_compile=arm-linux-gnueabihf- --raw_output=all --kunitconfig
./net/sunrpc/.kunitconfig
[10:04:14] Configuring KUnit Kernel ...
Generating .config ...
Populating config with:
$ make ARCH=arm O=.kunit olddefconfig
[10:04:18] Building KUnit Kernel ...
Populating config with:
$ make ARCH=arm O=.kunit olddefconfig
Building with:
$ make ARCH=arm O=.kunit --jobs=4
ERROR:root:gcc: error: unrecognized argument in option ‘-mabi=aapcs-linux’
gcc: note: valid arguments to ‘-mabi=’ are: ms sysv
gcc: error: unrecognized argument in option ‘-mabi=aapcs-linux’
gcc: note: valid arguments to ‘-mabi=’ are: ms sysv
gcc: error: unrecognized command-line option ‘-mlittle-endian’
gcc: error: unrecognized command-line option ‘-mlittle-endian’
gcc: error: unrecognized command-line option ‘-mtp=cp15’
gcc: error: unrecognized command-line option ‘-mtp=cp15’
gcc: error: unrecognized command-line option ‘-mfpu=vfp’
make[2]: *** [../scripts/Makefile.build:252: scripts/mod/empty.o] Error 1
make[2]: *** Waiting for unfinished jobs....
gcc: error: unrecognized command-line option ‘-mfpu=vfp’
make[2]: *** [../scripts/Makefile.build:114: scripts/mod/devicetable-offsets.s] Error 1
make[1]: *** [/home/cel/src/linux/odd-releases/Makefile:1297: prepare0] Error 2
make: *** [Makefile:242: __sub-make] Error 2

-bash: --cross_compile=arm-linux-gnueabihf-: command not found
-bash: ./net/sunrpc/.kunitconfig: Permission denied
[cel@bazille odd-releases]$ gcc --version
gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[cel@bazille odd-releases]$

What am I missing?


--
Chuck Lever
Geert Uytterhoeven Feb. 27, 2023, 3:37 p.m. UTC | #15
Hi Chuck,

On Mon, Feb 27, 2023 at 4:06 PM Chuck Lever III <chuck.lever@oracle.com> wrote:
> > On Feb 27, 2023, at 4:51 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Thu, Feb 23, 2023 at 5:52 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >> On Thu, Feb 23, 2023 at 5:19 PM Chuck Lever III <chuck.lever@oracle.com> wrote:
> >>>> On Feb 23, 2023, at 10:16 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >>> Unable to handle kernel access at virtual address af06da84
> >>
> >>>> I.e. a slightly different crash.
> >>>> As the difference between the two crashes is modular vs. builtin,
> >>>> this looks like an out-of-bound access in the test.
> >
> > Just ran it on physical arm32 and arm64 (Renesas APE6EVM and
> > Salvator-XS), and the test crashes there, too.
> >
> >>> Why not run the test suite just as I suggested?
> >
> > kunit_kernel.ConfigError: m68k is not a valid arch, options are
> > ['alpha', 'arm', 'arm64', 'i386', 'powerpc', 'riscv', 's390', 'sparc',
> > 'x86_64']
> >
> > Will look into adding m68k support ;-)
> >
> > But the issue can easily be reproduced using
> > ".../tools/testing/kunit/kunit.py run --arch=arm
> > --cross_compile=arm-linux-gnueabihf- --raw_output=all --kunitconfig
> > ./net/sunrpc/.kunitconfig" on current upstream[1]:

> I'm still not able to reproduce:
>
> [cel@bazille odd-releases]$ tools/testing/kunit/kunit.py run --arch=arm
> --cross_compile=arm-linux-gnueabihf- --raw_output=all --kunitconfig
> ./net/sunrpc/.kunitconfig
> [10:04:14] Configuring KUnit Kernel ...
> Generating .config ...
> Populating config with:
> $ make ARCH=arm O=.kunit olddefconfig
> [10:04:18] Building KUnit Kernel ...
> Populating config with:
> $ make ARCH=arm O=.kunit olddefconfig
> Building with:
> $ make ARCH=arm O=.kunit --jobs=4
> ERROR:root:gcc: error: unrecognized argument in option ‘-mabi=aapcs-linux’
> gcc: note: valid arguments to ‘-mabi=’ are: ms sysv
> gcc: error: unrecognized argument in option ‘-mabi=aapcs-linux’
> gcc: note: valid arguments to ‘-mabi=’ are: ms sysv
> gcc: error: unrecognized command-line option ‘-mlittle-endian’
> gcc: error: unrecognized command-line option ‘-mlittle-endian’
> gcc: error: unrecognized command-line option ‘-mtp=cp15’
> gcc: error: unrecognized command-line option ‘-mtp=cp15’
> gcc: error: unrecognized command-line option ‘-mfpu=vfp’
> make[2]: *** [../scripts/Makefile.build:252: scripts/mod/empty.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
> gcc: error: unrecognized command-line option ‘-mfpu=vfp’
> make[2]: *** [../scripts/Makefile.build:114: scripts/mod/devicetable-offsets.s] Error 1
> make[1]: *** [/home/cel/src/linux/odd-releases/Makefile:1297: prepare0] Error 2
> make: *** [Makefile:242: __sub-make] Error 2
>
> -bash: --cross_compile=arm-linux-gnueabihf-: command not found
> -bash: ./net/sunrpc/.kunitconfig: Permission denied
> [cel@bazille odd-releases]$ gcc --version
> gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
> Copyright (C) 2022 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> [cel@bazille odd-releases]$
>
> What am I missing?

Please run that as a single command, not split across 3 lines.

Gr{oetje,eeting}s,

                        Geert