On Feb 23, 2023, at 11:52 AM, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
Hi Chuck,
On Thu, Feb 23, 2023 at 5:19 PM Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote:
On Feb 23, 2023, at 10:16 AM, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
On Thu, Feb 23, 2023 at 3:00 PM Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote:
On Feb 23, 2023, at 8:05 AM, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> 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
