* Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements [not found] <167380196429.10651.4103075913257868035.stgit@bazille.1015granger.net> @ 2023-02-23 13:05 ` Geert Uytterhoeven 2023-02-23 14:00 ` Chuck Lever III 0 siblings, 1 reply; 14+ messages in thread From: Geert Uytterhoeven @ 2023-02-23 13:05 UTC (permalink / raw) To: Chuck Lever; +Cc: linux-nfs, dhowells, simo, linux-kselftest, linux-m68k 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements 2023-02-23 13:05 ` [PATCH v2 00/41] RPCSEC GSS krb5 enhancements Geert Uytterhoeven @ 2023-02-23 14:00 ` Chuck Lever III 2023-02-23 15:16 ` Geert Uytterhoeven 0 siblings, 1 reply; 14+ messages in thread From: Chuck Lever III @ 2023-02-23 14:00 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Chuck Lever, Linux NFS Mailing List, David Howells, simo, linux-kselftest, linux-m68k > 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements 2023-02-23 14:00 ` Chuck Lever III @ 2023-02-23 15:16 ` Geert Uytterhoeven 2023-02-23 16:18 ` Chuck Lever III 0 siblings, 1 reply; 14+ messages in thread From: Geert Uytterhoeven @ 2023-02-23 15:16 UTC (permalink / raw) To: Chuck Lever III Cc: Chuck Lever, Linux NFS Mailing List, David Howells, simo, linux-kselftest, linux-m68k 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 -- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements 2023-02-23 15:16 ` Geert Uytterhoeven @ 2023-02-23 16:18 ` Chuck Lever III 2023-02-23 16:52 ` Geert Uytterhoeven ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Chuck Lever III @ 2023-02-23 16:18 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Chuck Lever, Linux NFS Mailing List, David Howells, simo, linux-kselftest, linux-m68k > 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements 2023-02-23 16:18 ` Chuck Lever III @ 2023-02-23 16:52 ` Geert Uytterhoeven 2023-02-23 19:32 ` Chuck Lever III 2023-02-27 9:51 ` Geert Uytterhoeven 2023-02-23 17:57 ` Andreas Schwab 2023-02-23 18:28 ` Eero Tamminen 2 siblings, 2 replies; 14+ messages in thread From: Geert Uytterhoeven @ 2023-02-23 16:52 UTC (permalink / raw) To: Chuck Lever III Cc: Chuck Lever, Linux NFS Mailing List, David Howells, simo, linux-kselftest, linux-m68k 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 -- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements 2023-02-23 16:52 ` Geert Uytterhoeven @ 2023-02-23 19:32 ` Chuck Lever III 2023-02-27 9:51 ` Geert Uytterhoeven 1 sibling, 0 replies; 14+ messages in thread From: Chuck Lever III @ 2023-02-23 19:32 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Chuck Lever, Linux NFS Mailing List, David Howells, simo, linux-kselftest, linux-m68k > 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements 2023-02-23 16:52 ` Geert Uytterhoeven 2023-02-23 19:32 ` Chuck Lever III @ 2023-02-27 9:51 ` Geert Uytterhoeven 2023-02-27 15:06 ` Chuck Lever III 1 sibling, 1 reply; 14+ messages in thread From: Geert Uytterhoeven @ 2023-02-27 9:51 UTC (permalink / raw) To: Chuck Lever III Cc: Chuck Lever, Linux NFS Mailing List, David Howells, simo, linux-kselftest, linux-m68k 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 -- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements 2023-02-27 9:51 ` Geert Uytterhoeven @ 2023-02-27 15:06 ` Chuck Lever III 2023-02-27 15:37 ` Geert Uytterhoeven 0 siblings, 1 reply; 14+ messages in thread From: Chuck Lever III @ 2023-02-27 15:06 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Chuck Lever, Linux NFS Mailing List, David Howells, simo, linux-kselftest, linux-m68k > 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements 2023-02-27 15:06 ` Chuck Lever III @ 2023-02-27 15:37 ` Geert Uytterhoeven 0 siblings, 0 replies; 14+ messages in thread From: Geert Uytterhoeven @ 2023-02-27 15:37 UTC (permalink / raw) To: Chuck Lever III Cc: Chuck Lever, Linux NFS Mailing List, David Howells, simo, linux-kselftest, linux-m68k 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 -- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements 2023-02-23 16:18 ` Chuck Lever III 2023-02-23 16:52 ` Geert Uytterhoeven @ 2023-02-23 17:57 ` Andreas Schwab 2023-02-23 18:19 ` Michael Schmitz 2023-02-23 18:28 ` Eero Tamminen 2 siblings, 1 reply; 14+ messages in thread From: Andreas Schwab @ 2023-02-23 17:57 UTC (permalink / raw) To: Chuck Lever III Cc: Geert Uytterhoeven, Chuck Lever, Linux NFS Mailing List, David Howells, simo, linux-kselftest, linux-m68k 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. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements 2023-02-23 17:57 ` Andreas Schwab @ 2023-02-23 18:19 ` Michael Schmitz 2023-02-23 21:46 ` Andreas Schwab 0 siblings, 1 reply; 14+ messages in thread From: Michael Schmitz @ 2023-02-23 18:19 UTC (permalink / raw) To: Andreas Schwab, Chuck Lever III Cc: Geert Uytterhoeven, Chuck Lever, Linux NFS Mailing List, David Howells, simo, linux-kselftest, linux-m68k 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements 2023-02-23 18:19 ` Michael Schmitz @ 2023-02-23 21:46 ` Andreas Schwab 2023-02-23 22:17 ` Michael Schmitz 0 siblings, 1 reply; 14+ messages in thread From: Andreas Schwab @ 2023-02-23 21:46 UTC (permalink / raw) To: Michael Schmitz Cc: Chuck Lever III, Geert Uytterhoeven, Chuck Lever, Linux NFS Mailing List, David Howells, simo, linux-kselftest, linux-m68k 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. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements 2023-02-23 21:46 ` Andreas Schwab @ 2023-02-23 22:17 ` Michael Schmitz 0 siblings, 0 replies; 14+ messages in thread From: Michael Schmitz @ 2023-02-23 22:17 UTC (permalink / raw) To: Andreas Schwab Cc: Chuck Lever III, Geert Uytterhoeven, Chuck Lever, Linux NFS Mailing List, David Howells, simo, linux-kselftest, linux-m68k 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements 2023-02-23 16:18 ` Chuck Lever III 2023-02-23 16:52 ` Geert Uytterhoeven 2023-02-23 17:57 ` Andreas Schwab @ 2023-02-23 18:28 ` Eero Tamminen 2 siblings, 0 replies; 14+ messages in thread From: Eero Tamminen @ 2023-02-23 18:28 UTC (permalink / raw) To: Chuck Lever III; +Cc: linux-kselftest, linux-m68k Hi, On 23.2.2023 18.18, Chuck Lever III wrote: > 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. There are multiple m68k emulators that can run m68k Linux. At least Qemu, WinUAE, Aranym and Hatari. Of those, Qemu, Aranym & Hatari are available directly from Debian: * https://packages.debian.org/bookworm/qemu-system-misc * https://packages.debian.org/bookworm/aranym * https://packages.debian.org/bookworm/hatari Crypto in general is very (too) slow on ancient HW which does not have any crypto instructions or acceleration, so I would avoid emulators that aim for cycle accuracy with old HW (WinUAE & Hatari). Qemu can be used to test also other platforms than m68k, and its usage may be easier to automate for your CI than Aranym, so you could try that (not necessarily starting with m68k). - Eero ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2023-02-27 15:37 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <167380196429.10651.4103075913257868035.stgit@bazille.1015granger.net>
2023-02-23 13:05 ` [PATCH v2 00/41] RPCSEC GSS krb5 enhancements Geert Uytterhoeven
2023-02-23 14:00 ` Chuck Lever III
2023-02-23 15:16 ` Geert Uytterhoeven
2023-02-23 16:18 ` Chuck Lever III
2023-02-23 16:52 ` Geert Uytterhoeven
2023-02-23 19:32 ` Chuck Lever III
2023-02-27 9:51 ` Geert Uytterhoeven
2023-02-27 15:06 ` Chuck Lever III
2023-02-27 15:37 ` Geert Uytterhoeven
2023-02-23 17:57 ` Andreas Schwab
2023-02-23 18:19 ` Michael Schmitz
2023-02-23 21:46 ` Andreas Schwab
2023-02-23 22:17 ` Michael Schmitz
2023-02-23 18:28 ` Eero Tamminen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).