August 2022 - Linux-kselftest-mirror

[PATCH v2] selftests/net: Refactor xfrm_fill_key() to use array of structs

by Gautam Menghani

A TODO in net/ipsec.c asks to refactor the code in xfrm_fill_key() to use set/map to avoid manually comparing each algorithm with the "name" parameter passed to the function as an argument. This patch refactors the code to create an array of structs where each struct contains the algorithm name and its corresponding key length. Signed-off-by: Gautam Menghani <gautammenghani201(a)gmail.com> --- changes in v2: 1. Fix the compilation warnings for struct and variable declaration tools/testing/selftests/net/ipsec.c | 108 +++++++++++++--------------- 1 file changed, 49 insertions(+), 59 deletions(-) diff --git a/tools/testing/selftests/net/ipsec.c b/tools/testing/selftests/net/ipsec.c index cc10c10c5ed9..4a0eeb5b71d2 100644 --- a/tools/testing/selftests/net/ipsec.c +++ b/tools/testing/selftests/net/ipsec.c @@ -58,6 +58,8 @@ #define VETH_FMT "ktst-%d" #define VETH_LEN 12 +#define XFRM_ALGO_NR_KEYS 29 + static int nsfd_parent = -1; static int nsfd_childa = -1; static int nsfd_childb = -1; @@ -75,6 +77,46 @@ const unsigned int ping_timeout = 300; const unsigned int ping_count = 100; const unsigned int ping_success = 80; +struct xfrm_key_entry { + char algo_name[35]; + int key_len; +}; + +struct xfrm_key_entry xfrm_key_entries[XFRM_ALGO_NR_KEYS]; + +static void init_xfrm_algo_keys(void) +{ + xfrm_key_entries[0] = (struct xfrm_key_entry) {"digest_null", 0}; + xfrm_key_entries[1] = (struct xfrm_key_entry) {"ecb(cipher_null)", 0}; + xfrm_key_entries[2] = (struct xfrm_key_entry) {"cbc(des)", 64}; + xfrm_key_entries[3] = (struct xfrm_key_entry) {"hmac(md5)", 128}; + xfrm_key_entries[4] = (struct xfrm_key_entry) {"cmac(aes)", 128}; + xfrm_key_entries[5] = (struct xfrm_key_entry) {"xcbc(aes)", 128}; + xfrm_key_entries[6] = (struct xfrm_key_entry) {"cbc(cast5)", 128}; + xfrm_key_entries[7] = (struct xfrm_key_entry) {"cbc(serpent)", 128}; + xfrm_key_entries[8] = (struct xfrm_key_entry) {"hmac(sha1)", 160}; + xfrm_key_entries[9] = (struct xfrm_key_entry) {"hmac(rmd160)", 160}; + xfrm_key_entries[10] = (struct xfrm_key_entry) {"cbc(des3_ede)", 192}; + xfrm_key_entries[11] = (struct xfrm_key_entry) {"hmac(sha256)", 256}; + xfrm_key_entries[12] = (struct xfrm_key_entry) {"cbc(aes)", 256}; + xfrm_key_entries[13] = (struct xfrm_key_entry) {"cbc(camellia)", 256}; + xfrm_key_entries[14] = (struct xfrm_key_entry) {"cbc(twofish)", 256}; + xfrm_key_entries[15] = (struct xfrm_key_entry) {"rfc3686(ctr(aes))", 288}; + xfrm_key_entries[16] = (struct xfrm_key_entry) {"hmac(sha384)", 384}; + xfrm_key_entries[17] = (struct xfrm_key_entry) {"cbc(blowfish)", 448}; + xfrm_key_entries[18] = (struct xfrm_key_entry) {"hmac(sha512)", 512}; + xfrm_key_entries[19] = (struct xfrm_key_entry) {"rfc4106(gcm(aes))-128", 160}; + xfrm_key_entries[20] = (struct xfrm_key_entry) {"rfc4543(gcm(aes))-128", 160}; + xfrm_key_entries[21] = (struct xfrm_key_entry) {"rfc4309(ccm(aes))-128", 152}; + xfrm_key_entries[22] = (struct xfrm_key_entry) {"rfc4106(gcm(aes))-192", 224}; + xfrm_key_entries[23] = (struct xfrm_key_entry) {"rfc4543(gcm(aes))-192", 224}; + xfrm_key_entries[24] = (struct xfrm_key_entry) {"rfc4309(ccm(aes))-192", 216}; + xfrm_key_entries[25] = (struct xfrm_key_entry) {"rfc4106(gcm(aes))-256", 288}; + xfrm_key_entries[26] = (struct xfrm_key_entry) {"rfc4543(gcm(aes))-256", 288}; + xfrm_key_entries[27] = (struct xfrm_key_entry) {"rfc4309(ccm(aes))-256", 280}; + xfrm_key_entries[28] = (struct xfrm_key_entry) {"rfc7539(chacha20,poly1305)-128", 0}; +} + static void randomize_buffer(void *buf, size_t buflen) { int *p = (int *)buf; @@ -767,65 +809,12 @@ static int do_ping(int cmd_fd, char *buf, size_t buf_len, struct in_addr from, static int xfrm_fill_key(char *name, char *buf, size_t buf_len, unsigned int *key_len) { - /* TODO: use set/map instead */ - if (strncmp(name, "digest_null", ALGO_LEN) == 0) - *key_len = 0; - else if (strncmp(name, "ecb(cipher_null)", ALGO_LEN) == 0) - *key_len = 0; - else if (strncmp(name, "cbc(des)", ALGO_LEN) == 0) - *key_len = 64; - else if (strncmp(name, "hmac(md5)", ALGO_LEN) == 0) - *key_len = 128; - else if (strncmp(name, "cmac(aes)", ALGO_LEN) == 0) - *key_len = 128; - else if (strncmp(name, "xcbc(aes)", ALGO_LEN) == 0) - *key_len = 128; - else if (strncmp(name, "cbc(cast5)", ALGO_LEN) == 0) - *key_len = 128; - else if (strncmp(name, "cbc(serpent)", ALGO_LEN) == 0) - *key_len = 128; - else if (strncmp(name, "hmac(sha1)", ALGO_LEN) == 0) - *key_len = 160; - else if (strncmp(name, "hmac(rmd160)", ALGO_LEN) == 0) - *key_len = 160; - else if (strncmp(name, "cbc(des3_ede)", ALGO_LEN) == 0) - *key_len = 192; - else if (strncmp(name, "hmac(sha256)", ALGO_LEN) == 0) - *key_len = 256; - else if (strncmp(name, "cbc(aes)", ALGO_LEN) == 0) - *key_len = 256; - else if (strncmp(name, "cbc(camellia)", ALGO_LEN) == 0) - *key_len = 256; - else if (strncmp(name, "cbc(twofish)", ALGO_LEN) == 0) - *key_len = 256; - else if (strncmp(name, "rfc3686(ctr(aes))", ALGO_LEN) == 0) - *key_len = 288; - else if (strncmp(name, "hmac(sha384)", ALGO_LEN) == 0) - *key_len = 384; - else if (strncmp(name, "cbc(blowfish)", ALGO_LEN) == 0) - *key_len = 448; - else if (strncmp(name, "hmac(sha512)", ALGO_LEN) == 0) - *key_len = 512; - else if (strncmp(name, "rfc4106(gcm(aes))-128", ALGO_LEN) == 0) - *key_len = 160; - else if (strncmp(name, "rfc4543(gcm(aes))-128", ALGO_LEN) == 0) - *key_len = 160; - else if (strncmp(name, "rfc4309(ccm(aes))-128", ALGO_LEN) == 0) - *key_len = 152; - else if (strncmp(name, "rfc4106(gcm(aes))-192", ALGO_LEN) == 0) - *key_len = 224; - else if (strncmp(name, "rfc4543(gcm(aes))-192", ALGO_LEN) == 0) - *key_len = 224; - else if (strncmp(name, "rfc4309(ccm(aes))-192", ALGO_LEN) == 0) - *key_len = 216; - else if (strncmp(name, "rfc4106(gcm(aes))-256", ALGO_LEN) == 0) - *key_len = 288; - else if (strncmp(name, "rfc4543(gcm(aes))-256", ALGO_LEN) == 0) - *key_len = 288; - else if (strncmp(name, "rfc4309(ccm(aes))-256", ALGO_LEN) == 0) - *key_len = 280; - else if (strncmp(name, "rfc7539(chacha20,poly1305)-128", ALGO_LEN) == 0) - *key_len = 0; + int i; + + for (i = 0; i < XFRM_ALGO_NR_KEYS; i++) { + if (strncmp(name, xfrm_key_entries[i].algo_name, ALGO_LEN) == 0) + *key_len = xfrm_key_entries[i].key_len; + } if (*key_len > buf_len) { printk("Can't pack a key - too big for buffer"); @@ -2305,6 +2294,7 @@ int main(int argc, char **argv) } } + init_xfrm_algo_keys(); srand(time(NULL)); page_size = sysconf(_SC_PAGESIZE); if (page_size < 1) -- 2.34.1

3 years

3
3
0 0

[PATCH v5 0/5] userfaultfd: add /dev/userfaultfd for fine grained access control

by Axel Rasmussen

This series is based on torvalds/master. The series is split up like so: - Patch 1 is a simple fixup which we should take in any case (even by itself). - Patches 2-5 add the feature, configurable selftest support, and docs. Why not ...? ============ - Why not /proc/[pid]/userfaultfd? Two main points (additional discussion [1]): - /proc/[pid]/* files are all owned by the user/group of the process, and they don't really support chmod/chown. So, without extending procfs it doesn't solve the problem this series is trying to solve. - The main argument *for* this was to support creating UFFDs for remote processes. But, that use case clearly calls for CAP_SYS_PTRACE, so to support this we could just use the UFFD syscall as-is. - Why not use a syscall? Access to syscalls is generally controlled by capabilities. We don't have a capability which is used for userfaultfd access without also granting more / other permissions as well, and adding a new capability was rejected [2]. - It's possible a LSM could be used to control access instead, but I have some concerns. I don't think this approach would be as easy to use, particularly if we were to try to solve this with something heavyweight like SELinux. Maybe we could pursue adding a new LSM specifically for this user case, but it may be too narrow of a case to justify that. Changelog ========= v4->v5: - Call userfaultfd_syscall_allowed() directly in the syscall, so we don't have to plumb a flag into new_userfaultfd(). [Nadav] - Refactored run_vmtests.sh to loop over UFFD test mods. [Nadav] - Reworded cover letter. - Picked up some Acked-by's. v3->v4: - Picked up an Acked-by on 5/5. - Updated cover letter to cover "why not ...". - Refactored userfaultfd_allowed() into userfaultfd_syscall_allowed(). [Peter] - Removed obsolete comment from a previous version. [Peter] - Refactored userfaultfd_open() in selftest. [Peter] - Reworded admin-guide documentation. [Mike, Peter] - Squashed 2 commits adding /dev/userfaultfd to selftest and making selftest configurable. [Peter] - Added "syscall" test modifier (the default behavior) to selftest. [Peter] v2->v3: - Rebased onto linux-next/akpm-base, in order to be based on top of the run_vmtests.sh refactor which was merged previously. - Picked up some Reviewed-by's. - Fixed ioctl definition (_IO instead of _IOWR), and stopped using compat_ptr_ioctl since it is unneeded for ioctls which don't take a pointer. - Removed the "handle_kernel_faults" bool, simplifying the code. The result is logically equivalent, but simpler. - Fixed userfaultfd selftest so it returns KSFT_SKIP appropriately. - Reworded documentation per Shuah's feedback on v2. - Improved example usage for userfaultfd selftest. v1->v2: - Add documentation update. - Test *both* userfaultfd(2) and /dev/userfaultfd via the selftest. [1]: https://patchwork.kernel.org/project/linux-mm/cover/20220719195628.3415852-… [2]: https://lore.kernel.org/lkml/686276b9-4530-2045-6bd8-170e5943abe4@schaufler… Axel Rasmussen (5): selftests: vm: add hugetlb_shared userfaultfd test to run_vmtests.sh userfaultfd: add /dev/userfaultfd for fine grained access control userfaultfd: selftests: modify selftest to use /dev/userfaultfd userfaultfd: update documentation to describe /dev/userfaultfd selftests: vm: add /dev/userfaultfd test cases to run_vmtests.sh Documentation/admin-guide/mm/userfaultfd.rst | 41 ++++++++++- Documentation/admin-guide/sysctl/vm.rst | 3 + fs/userfaultfd.c | 73 +++++++++++++++----- include/uapi/linux/userfaultfd.h | 4 ++ tools/testing/selftests/vm/run_vmtests.sh | 15 ++-- tools/testing/selftests/vm/userfaultfd.c | 69 +++++++++++++++--- 6 files changed, 172 insertions(+), 33 deletions(-) -- 2.37.1.559.g78731f0fdb-goog

3 years

2
9
0 0

[PATCH][next] selftests/bpf: Fix spelling mistake "succesful" -> "successful"

by Colin Ian King

There is a spelling mistake in an ASSERT_OK literal string. Fix it. Signed-off-by: Colin Ian King <colin.i.king(a)gmail.com> --- tools/testing/selftests/bpf/prog_tests/kfunc_call.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/bpf/prog_tests/kfunc_call.c b/tools/testing/selftests/bpf/prog_tests/kfunc_call.c index 351fafa006fb..eede7c304f86 100644 --- a/tools/testing/selftests/bpf/prog_tests/kfunc_call.c +++ b/tools/testing/selftests/bpf/prog_tests/kfunc_call.c @@ -109,7 +109,7 @@ static void test_destructive(void) { __u64 save_caps = 0; - ASSERT_OK(test_destructive_open_and_load(), "succesful_load"); + ASSERT_OK(test_destructive_open_and_load(), "successful_load"); if (!ASSERT_OK(cap_disable_effective(1ULL << CAP_SYS_BOOT, &save_caps), "drop_caps")) return; -- 2.37.1

3 years

3
2
0 0

[net-next 0/6] net: support QUIC crypto

by Adel Abouchaev

QUIC requires end to end encryption of the data. The application usually prepares the data in clear text, encrypts and calls send() which implies multiple copies of the data before the packets hit the networking stack. Similar to kTLS, QUIC kernel offload of cryptography reduces the memory pressure by reducing the number of copies. The scope of kernel support is limited to the symmetric cryptography, leaving the handshake to the user space library. For QUIC in particular, the application packets that require symmetric cryptography are the 1RTT packets with short headers. Kernel will encrypt the application packets on transmission and decrypt on receive. This series implements Tx only, because in QUIC server applications Tx outweighs Rx by orders of magnitude. Supporting the combination of QUIC and GSO requires the application to correctly place the data and the kernel to correctly slice it. The encryption process appends an arbitrary number of bytes (tag) to the end of the message to authenticate it. The GSO value should include this overhead, the offload would then subtract the tag size to parse the input on Tx before chunking and encrypting it. With the kernel cryptography, the buffer copy operation is conjoined with the encryption operation. The memory bandwidth is reduced by 5-8%. When devices supporting QUIC encryption in hardware come to the market, we will be able to free further 7% of CPU utilization which is used today for crypto operations. *** BLURB HERE *** Adel Abouchaev (6): Documentation on QUIC kernel Tx crypto. Define QUIC specific constants, control and data plane structures Add UDP ULP operations, initialization and handling prototype functions. Implement QUIC offload functions Add flow counters and Tx processing error counter Add self tests for ULP operations, flow setup and crypto tests Documentation/networking/index.rst | 1 + Documentation/networking/quic.rst | 186 ++++ include/net/inet_sock.h | 2 + include/net/netns/mib.h | 3 + include/net/quic.h | 63 ++ include/net/snmp.h | 6 + include/net/udp.h | 33 + include/uapi/linux/quic.h | 61 + include/uapi/linux/snmp.h | 9 + include/uapi/linux/udp.h | 4 + net/Kconfig | 1 + net/Makefile | 1 + net/ipv4/Makefile | 3 +- net/ipv4/udp.c | 15 + net/ipv4/udp_ulp.c | 192 ++++ net/quic/Kconfig | 16 + net/quic/Makefile | 8 + net/quic/quic_main.c | 1417 ++++++++++++++++++++++++ net/quic/quic_proc.c | 45 + tools/testing/selftests/net/.gitignore | 3 +- tools/testing/selftests/net/Makefile | 3 +- tools/testing/selftests/net/quic.c | 1153 +++++++++++++++++++ tools/testing/selftests/net/quic.sh | 46 + 23 files changed, 3268 insertions(+), 3 deletions(-) create mode 100644 Documentation/networking/quic.rst create mode 100644 include/net/quic.h create mode 100644 include/uapi/linux/quic.h create mode 100644 net/ipv4/udp_ulp.c create mode 100644 net/quic/Kconfig create mode 100644 net/quic/Makefile create mode 100644 net/quic/quic_main.c create mode 100644 net/quic/quic_proc.c create mode 100644 tools/testing/selftests/net/quic.c create mode 100755 tools/testing/selftests/net/quic.sh -- 2.30.2

3 years

2
8
0 0

[PATCH] selftests/dma: Add a .gitignore file containing name of executable

by Gautam Menghani

The dma tests in kselftests are missing a .gitignore file, which leads to the dma_map_benchmark executable file showing up in "git status". This patch adds a .gitignore file containing the executable name. Signed-off-by: Gautam Menghani <gautammenghani201(a)gmail.com> --- tools/testing/selftests/dma/.gitignore | 1 + 1 file changed, 1 insertion(+) create mode 100644 tools/testing/selftests/dma/.gitignore diff --git a/tools/testing/selftests/dma/.gitignore b/tools/testing/selftests/dma/.gitignore new file mode 100644 index 000000000000..668e2f8be2f7 --- /dev/null +++ b/tools/testing/selftests/dma/.gitignore @@ -0,0 +1 @@ +dma_map_benchmark -- 2.34.1

3 years

1
1
0 0

lkft kselftest for next-20220817

by lkft＠linaro.org

## Build * kernel: 6.0.0-rc1 * git: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next * git branch: master * git commit: 95d10484d66e54d5c01e36389e9318221fb8f60b * git describe: next-20220817 * test details: https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20220817 ## Test Regressions (compared to next-20220816) No test regressions found. ## Metric Regressions (compared to next-20220816) No metric regressions found. Tested-by: Linux Kernel Functional Testing <lkft(a)linaro.org> ## Test Fixes (compared to next-20220816) No test fixes found. ## Metric Fixes (compared to next-20220816) No metric fixes found. ## Test result summary total: 0, pass: 0, fail: 0, skip: 0, xfail: 0 ## Build Summary ## Test suites summary -- Linaro LKFT https://lkft.linaro.org

3 years

1
0
0 0

<> Business Traffic Plans <>

by Shameka

Hello Tired of keep looking for quality business traffic? your search is over, we provide the best business traffic available on the market check our deals and offers here https://basedbusinesstraffic.co/ Unsubscribe: https://mgdots.co/unsubscribe/

3 years

1
0
0 0

[PATCH v11 0/9] bpf: Add kfuncs for PKCS#7 signature verification

by Roberto Sassu

One of the desirable features in security is the ability to restrict import of data to a given system based on data authenticity. If data import can be restricted, it would be possible to enforce a system-wide policy based on the signing keys the system owner trusts. This feature is widely used in the kernel. For example, if the restriction is enabled, kernel modules can be plugged in only if they are signed with a key whose public part is in the primary or secondary keyring. For eBPF, it can be useful as well. For example, it might be useful to authenticate data an eBPF program makes security decisions on. After a discussion in the eBPF mailing list, it was decided that the stated goal should be accomplished by introducing four new kfuncs: bpf_lookup_user_key() and bpf_lookup_system_key(), for retrieving a keyring with keys trusted for signature verification, respectively from its serial and from a pre-determined ID; bpf_key_put(), to release the reference obtained with the former two kfuncs, bpf_verify_pkcs7_signature(), for verifying PKCS#7 signatures. Other than the key serial, bpf_lookup_user_key() also accepts key lookup flags, that influence the behavior of the lookup. bpf_lookup_system_key() accepts pre-determined IDs defined in include/linux/verification.h. bpf_key_put() accepts the new bpf_key structure, introduced to tell whether the other structure member, a key pointer, is valid or not. The reason is that verify_pkcs7_signature() also accepts invalid pointers, set with the pre-determined ID, to select a system-defined keyring. key_put() must be called only for valid key pointers. Since the two key lookup functions allocate memory and one increments a key reference count, they must be used in conjunction with bpf_key_put(). The latter must be called only if the lookup functions returned a non-NULL pointer. The verifier denies the execution of eBPF programs that don't respect this rule. The two key lookup functions should be used in alternative, depending on the use case. While bpf_lookup_user_key() provides great flexibility, it seems suboptimal in terms of security guarantees, as even if the eBPF program is assumed to be trusted, the serial used to obtain the key pointer might come from untrusted user space not choosing one that the system administrator approves to enforce a mandatory policy. bpf_lookup_system_key() instead provides much stronger guarantees, especially if the pre-determined ID is not passed by user space but is hardcoded in the eBPF program, and that program is signed. In this case, bpf_verify_pkcs7_signature() will always perform signature verification with a key that the system administrator approves, i.e. the primary, secondary or platform keyring. Nevertheless, key permission checks need to be done accurately. Since bpf_lookup_user_key() cannot determine how a key will be used by other kfuncs, it has to defer the permission check to the actual kfunc using the key. It does it by calling lookup_user_key() with KEY_DEFER_PERM_CHECK as needed permission. Later, bpf_verify_pkcs7_signature(), if called, completes the permission check by calling key_validate(). It does not need to call key_task_permission() with permission KEY_NEED_SEARCH, as it is already done elsewhere by the key subsystem. Future kfuncs using the bpf_key structure need to implement the proper checks as well. Finally, the last kfunc, bpf_verify_pkcs7_signature(), accepts the data and signature to verify as eBPF dynamic pointers, to minimize the number of kfunc parameters, and the keyring with keys for signature verification as a bpf_key structure, returned by one of the two key lookup functions. bpf_lookup_user_key() and bpf_verify_pkcs7_signature() can be called only from sleepable programs, because of memory allocation and crypto operations. For example, the lsm.s/bpf attach point is suitable, fexit/array_map_update_elem is not. The correctness of implementation of the new kfuncs and of their usage is checked with the introduced tests. The patch set includes a patch from another author (dependency) for sake of completeness. It is organized as follows. Patch 1 from KP Singh allows kfuncs to be used by LSM programs. Patch 2 allows dynamic pointers to be used as kfunc parameters. Patch 3 exports bpf_dynptr_get_size(), to obtain the real size of data carried by a dynamic pointer. Patch 4 makes available for new eBPF kfuncs some key-related definitions. Patch 5 introduces the bpf_lookup_*_key() and bpf_key_put() kfuncs. Patch 6 introduces the bpf_verify_pkcs7_signature() kfunc. Finally, patches 7-9 introduce the tests. Changelog v10: - Introduce key_lookup_flags_check() and system_keyring_id_check() inline functions to check parameters (suggested by KP) - Fix descriptions and comment of key-related kfuncs (suggested by KP) - Register kfunc set only once (suggested by Alexei) - Move needed kernel options to the architecture-independent configuration for testing v9: - Drop patch to introduce KF_SLEEPABLE kfunc flag (already merged) - Rename valid_ptr member of bpf_key to has_ref (suggested by Daniel) - Check dynamic pointers in kfunc definition with bpf_dynptr_kern struct definition instead of string, to detect structure renames (suggested by Daniel) - Explicitly say that we permit initialized dynamic pointers in kfunc definition (suggested by Daniel) - Remove noinline __weak from kfuncs definition (reported by Daniel) - Simplify key lookup flags check in bpf_lookup_user_key() (suggested by Daniel) - Explain the reason for deferring key permission check (suggested by Daniel) - Allocate memory with GFP_ATOMIC in bpf_lookup_system_key(), and remove KF_SLEEPABLE kfunc flag from kfunc declaration (suggested by Daniel) - Define only one kfunc set and remove the loop for registration (suggested by Alexei) v8: - Define the new bpf_key structure to carry the key pointer and whether that pointer is valid or not (suggested by Daniel) - Drop patch to mark a kfunc parameter with the __maybe_null suffix - Improve documentation of kfuncs - Introduce bpf_lookup_system_key() to obtain a key pointer suitable for verify_pkcs7_signature() (suggested by Daniel) - Use the new kfunc registration API - Drop patch to test the __maybe_null suffix - Add tests for bpf_lookup_system_key() v7: - Add support for using dynamic and NULL pointers in kfunc (suggested by Alexei) - Add new kfunc-related tests v6: - Switch back to key lookup helpers + signature verification (until v5), and defer permission check from bpf_lookup_user_key() to bpf_verify_pkcs7_signature() - Add additional key lookup test to illustrate the usage of the KEY_LOOKUP_CREATE flag and validate the flags (suggested by Daniel) - Make description of flags of bpf_lookup_user_key() more user-friendly (suggested by Daniel) - Fix validation of flags parameter in bpf_lookup_user_key() (reported by Daniel) - Rename bpf_verify_pkcs7_signature() keyring-related parameters to user_keyring and system_keyring to make their purpose more clear - Accept keyring-related parameters of bpf_verify_pkcs7_signature() as alternatives (suggested by KP) - Replace unsigned long type with u64 in helper declaration (suggested by Daniel) - Extend the bpf_verify_pkcs7_signature() test by calling the helper without data, by ensuring that the helper enforces the keyring-related parameters as alternatives, by ensuring that the helper rejects inaccessible and expired keyrings, and by checking all system keyrings - Move bpf_lookup_user_key() and bpf_key_put() usage tests to ref_tracking.c (suggested by John) - Call bpf_lookup_user_key() and bpf_key_put() only in sleepable programs v5: - Move KEY_LOOKUP_ to include/linux/key.h for validation of bpf_verify_pkcs7_signature() parameter - Remove bpf_lookup_user_key() and bpf_key_put() helpers, and the corresponding tests - Replace struct key parameter of bpf_verify_pkcs7_signature() with the keyring serial and lookup flags - Call lookup_user_key() and key_put() in bpf_verify_pkcs7_signature() code, to ensure that the retrieved key is used according to the permission requested at lookup time - Clarified keyring precedence in the description of bpf_verify_pkcs7_signature() (suggested by John) - Remove newline in the second argument of ASSERT_ - Fix helper prototype regular expression in bpf_doc.py v4: - Remove bpf_request_key_by_id(), don't return an invalid pointer that other helpers can use - Pass the keyring ID (without ULONG_MAX, suggested by Alexei) to bpf_verify_pkcs7_signature() - Introduce bpf_lookup_user_key() and bpf_key_put() helpers (suggested by Alexei) - Add lookup_key_norelease test, to ensure that the verifier blocks eBPF programs which don't decrement the key reference count - Parse raw PKCS#7 signature instead of module-style signature in the verify_pkcs7_signature test (suggested by Alexei) - Parse kernel module in user space and pass raw PKCS#7 signature to the eBPF program for signature verification v3: - Rename bpf_verify_signature() back to bpf_verify_pkcs7_signature() to avoid managing different parameters for each signature verification function in one helper (suggested by Daniel) - Use dynamic pointers and export bpf_dynptr_get_size() (suggested by Alexei) - Introduce bpf_request_key_by_id() to give more flexibility to the caller of bpf_verify_pkcs7_signature() to retrieve the appropriate keyring (suggested by Alexei) - Fix test by reordering the gcc command line, always compile sign-file - Improve helper support check mechanism in the test v2: - Rename bpf_verify_pkcs7_signature() to a more generic bpf_verify_signature() and pass the signature type (suggested by KP) - Move the helper and prototype declaration under #ifdef so that user space can probe for support for the helper (suggested by Daniel) - Describe better the keyring types (suggested by Daniel) - Include linux/bpf.h instead of vmlinux.h to avoid implicit or redeclaration - Make the test selfcontained (suggested by Alexei) v1: - Don't define new map flag but introduce simple wrapper of verify_pkcs7_signature() (suggested by Alexei and KP) KP Singh (1): bpf: Allow kfuncs to be used in LSM programs Roberto Sassu (8): btf: Handle dynamic pointer parameter in kfuncs bpf: Export bpf_dynptr_get_size() KEYS: Move KEY_LOOKUP_ to include/linux/key.h bpf: Add bpf_lookup_*_key() and bpf_key_put() kfuncs bpf: Add bpf_verify_pkcs7_signature() kfunc selftests/bpf: Add verifier tests for bpf_lookup_*_key() and bpf_key_put() selftests/bpf: Add additional tests for bpf_lookup_*_key() selftests/bpf: Add test for bpf_verify_pkcs7_signature() kfunc include/linux/bpf.h | 7 + include/linux/bpf_verifier.h | 3 + include/linux/key.h | 11 + include/linux/verification.h | 8 + kernel/bpf/btf.c | 23 + kernel/bpf/helpers.c | 2 +- kernel/bpf/verifier.c | 4 +- kernel/trace/bpf_trace.c | 180 ++++++++ security/keys/internal.h | 2 - tools/testing/selftests/bpf/Makefile | 14 +- tools/testing/selftests/bpf/config | 6 + tools/testing/selftests/bpf/config.x86_64 | 5 - .../selftests/bpf/prog_tests/lookup_key.c | 112 +++++ .../bpf/prog_tests/verify_pkcs7_sig.c | 399 ++++++++++++++++++ .../selftests/bpf/progs/test_lookup_key.c | 46 ++ .../bpf/progs/test_verify_pkcs7_sig.c | 100 +++++ tools/testing/selftests/bpf/test_verifier.c | 3 +- .../selftests/bpf/verifier/ref_tracking.c | 139 ++++++ .../testing/selftests/bpf/verify_sig_setup.sh | 104 +++++ 19 files changed, 1154 insertions(+), 14 deletions(-) create mode 100644 tools/testing/selftests/bpf/prog_tests/lookup_key.c create mode 100644 tools/testing/selftests/bpf/prog_tests/verify_pkcs7_sig.c create mode 100644 tools/testing/selftests/bpf/progs/test_lookup_key.c create mode 100644 tools/testing/selftests/bpf/progs/test_verify_pkcs7_sig.c create mode 100755 tools/testing/selftests/bpf/verify_sig_setup.sh -- 2.25.1

3 years

3
15
0 0

[PATCH nf 0/2] testing: selftests: nft_flowtable.sh: unbreak test script

by Florian Westphal

nft_flowtable.sh fails most of the time since 2738d9d963bd1f0 ("netfilter: flowtable: move dst_check to packet path"). Arguably the test scripts way of detecting 'offloaded' vs 'offload failed' was always flaky/broken. These patches fix this up: 1. first patch moves to random netns names so we don't trip over existing 'ns1' name (too generic...). 2. second patch reworks the 'offload appears to be non-working' by means of packet counters. Because counters are only incremented when a packet is handled by the classic forward path, check that the counter is lower than a given threshold (25% of file size). Florian Westphal (2): testing: selftests: nft_flowtable.sh: use random netns names testing: selftests: nft_flowtable.sh: rework test to detect offload failure .../selftests/netfilter/nft_flowtable.sh | 377 ++++++++++-------- 1 file changed, 207 insertions(+), 170 deletions(-) -- 2.35.1

3 years

1
2
0 0

lkft kselftest for next-20220816

by lkft＠linaro.org

## Build * kernel: 6.0.0-rc1 * git: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next * git branch: master * git commit: e1084bacab44f570691c0fdaa1259acf93ed0098 * git describe: next-20220816 * test details: https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20220816 ## Test Regressions (compared to next-20220815) No test regressions found. ## Metric Regressions (compared to next-20220815) No metric regressions found. Tested-by: Linux Kernel Functional Testing <lkft(a)linaro.org> ## Test Fixes (compared to next-20220815) No test fixes found. ## Metric Fixes (compared to next-20220815) No metric fixes found. ## Test result summary total: 0, pass: 0, fail: 0, skip: 0, xfail: 0 ## Build Summary ## Test suites summary -- Linaro LKFT https://lkft.linaro.org

3 years

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror August 2022