Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp963156ybh; Tue, 21 Jul 2020 12:12:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy5P35cTjevtvOUeAFBFyw8zmbmppiseDusCsD/78USh3v1V0S45upHz5pmL9bzKv5ShT13 X-Received: by 2002:a50:9f08:: with SMTP id b8mr24892894edf.388.1595358728703; Tue, 21 Jul 2020 12:12:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595358728; cv=none; d=google.com; s=arc-20160816; b=UoJkrY+Nrsz4aDiQM7jYNXZY55DFlYPr/ivldGl1KStez2GBZZXV8xY7x2q9vddrFt p3gZ3YX6YVt4cPOllDXuetsqYct5f0+o38bUY1InmO4Bikzua9jJmaRY5I+S7aRpxu95 vNRm4WWwljEU6Bsn6bmjM0oR10+JLUT6K3+QCBxnbsaDRuckd8VHU0IJJkN0KF9nXlZ/ kpDQ0TDWE+eGohHEHiOUXV5XCNLcdM3cFdaXgS41uevTgUFyChkzvXJMufgIShwZ6uEy hfRY6wSJ8CUltbeGIrHKIjUd0MFhGmjVS/gVmV8ncZ7RRTNVl07sPkaf/Vq9FMXDe9n8 zOjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=NAFt6C2lnvpS45jVhw23Ap3Sp8296UwbtX9tobHLa1g=; b=voIalNZGbuY74CHsfbrA5I3fuNSw8q+pu0HHjLMinknkAFAV0IwLZnaXGFJnft0CV1 TQPxxd327cvheJTd3b5ZLzSwUB62fr2HyVvAeW+zGI8J26P8PK3Hgmz5Go2kSxk70Vuy XaSfqY8uGIbApOVVv8TQQ6TkE4Ge2VAOCn6Yligf9mCehiPuizAkW9PwrZWVof29AYQa xDw4X+5bemoMfGNDLasaI8CFeJGI7E0jm8WofOJ3kr6hT2+qxO/prF5Gy9xBvdrU6khb 6lGP6QgrKc5MDmZstedn7+r4TDteP0dThYAAx7RyeTcj6AfATFFq0A3QAX1rvD0drwn7 cbnQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=icFK+j1Q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p14si13204437edm.364.2020.07.21.12.11.45; Tue, 21 Jul 2020 12:12:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=icFK+j1Q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730324AbgGUTJh (ORCPT + 99 others); Tue, 21 Jul 2020 15:09:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41698 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730300AbgGUTJd (ORCPT ); Tue, 21 Jul 2020 15:09:33 -0400 Received: from mail-pj1-x1042.google.com (mail-pj1-x1042.google.com [IPv6:2607:f8b0:4864:20::1042]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3CA11C0619DA for ; Tue, 21 Jul 2020 12:09:33 -0700 (PDT) Received: by mail-pj1-x1042.google.com with SMTP id f16so2142882pjt.0 for ; Tue, 21 Jul 2020 12:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=NAFt6C2lnvpS45jVhw23Ap3Sp8296UwbtX9tobHLa1g=; b=icFK+j1QmdrfPm1agUfJealBTpwFHPXzo+8S/+STX6KNUWATkXlIlCEWGl2IAB0Kaw 81hUL9l2hd6YXn1feWWISzSrw+hQRCIGKNVJbWKr7A8mt5ntyHbZ7HqDqAM0G+A1AosL C4oIXZNzgs1qwn+vlMLHBWHD7jiCUNtg/I8HA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=NAFt6C2lnvpS45jVhw23Ap3Sp8296UwbtX9tobHLa1g=; b=ir3Pvek4+f9B41gWGV/eHzBc56mVaT8nuZvK3D9lL4TB1wvfP/WZGKmh70XaHzjD0A fxtA6Q15l66R6DZHCtAcfbcZdMf+e8fO+xTDyDirKEWbfrTEohdNxY8UhlH1smL4F3Oh Jy/oIpWF4UaXkWrds27zP+dMgKQT/1sdgr0m4ndO+nl14C91kq6EBir8q7ztHsvSyejk L/lZD7v4oxneYnyhsdIAe3APlyQEdePYviIrav+ESgLwtbn3tLeKsyectNdZ47JeoOfA I+7bBJK5UEfOhz1xvVT7akAPwju/1iJBUIlbdEfMhc8LNW+NkR2QJt64ByHQyvg8wOwo s0Ng== X-Gm-Message-State: AOAM530kcSagiK59gLflJZdsycaMZa49bmJkOk0UlghlQDDXGa4RAtXh SSLLxU6dwEkmANJ9lNdX0CGfYLvMUR0= X-Received: by 2002:a17:902:7612:: with SMTP id k18mr22356298pll.187.1595358572696; Tue, 21 Jul 2020 12:09:32 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id c139sm20745411pfb.65.2020.07.21.12.09.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Jul 2020 12:09:31 -0700 (PDT) Date: Tue, 21 Jul 2020 12:09:30 -0700 From: Kees Cook To: Vitor Massaru Iha Cc: kunit-dev@googlegroups.com, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, brendanhiggins@google.com, davidgow@google.com, skhan@linuxfoundation.org, linux-kernel-mentees@lists.linuxfoundation.org Subject: Re: [PATCH v3] lib: Convert test_user_copy to KUnit test Message-ID: <202007211207.5BAA9D8D@keescook> References: <20200721174654.72132-1-vitor@massaru.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200721174654.72132-1-vitor@massaru.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 21, 2020 at 02:46:54PM -0300, Vitor Massaru Iha wrote: > This adds the conversion of the runtime tests of test_user_copy fuctions, > from `lib/test_user_copy.c`to KUnit tests. > > Signed-off-by: Vitor Massaru Iha > --- > v2: > * splitted patch in 3: > - Allows to install and load modules in root filesystem; > - Provides an userspace memory context when tests are compiled > as module; > - Convert test_user_copy to KUnit test; > * removed entry for CONFIG_TEST_USER_COPY; > * replaced pr_warn to KUNIT_EXPECT_FALSE_MSG in test macro to > decrease the diff; > v3: > * rebased with last kunit branch > * Please apply this commit from kunit-fixes: > 3f37d14b8a3152441f36b6bc74000996679f0998 > And these from patchwork: > https://patchwork.kernel.org/patch/11676331/ > https://patchwork.kernel.org/patch/11676335/ > --- > lib/Kconfig.debug | 28 ++++++++------ > lib/Makefile | 2 +- > lib/{test_user_copy.c => user_copy_kunit.c} | 42 +++++++++------------ > 3 files changed, 35 insertions(+), 37 deletions(-) > rename lib/{test_user_copy.c => user_copy_kunit.c} (91%) > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index 9ad9210d70a1..f699a3624ae7 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -2078,18 +2078,6 @@ config TEST_VMALLOC > > If unsure, say N. > > -config TEST_USER_COPY > - tristate "Test user/kernel boundary protections" > - depends on m > - help > - This builds the "test_user_copy" module that runs sanity checks > - on the copy_to/from_user infrastructure, making sure basic > - user/kernel boundary testing is working. If it fails to load, > - a regression has been detected in the user/kernel memory boundary > - protections. > - > - If unsure, say N. > - > config TEST_BPF > tristate "Test BPF filter functionality" > depends on m && NET > @@ -2154,6 +2142,22 @@ config SYSCTL_KUNIT_TEST > > If unsure, say N. > > +config USER_COPY_KUNIT > + tristate "KUnit Test for user/kernel boundary protections" > + depends on KUNIT > + depends on m > + help > + This builds the "user_copy_kunit" module that runs sanity checks > + on the copy_to/from_user infrastructure, making sure basic > + user/kernel boundary testing is working. If it fails to load, > + a regression has been detected in the user/kernel memory boundary > + protections. > + > + For more information on KUnit and unit tests in general please refer > + to the KUnit documentation in Documentation/dev-tools/kunit/. > + > + If unsure, say N. > + > config LIST_KUNIT_TEST > tristate "KUnit Test for Kernel Linked-list structures" if !KUNIT_ALL_TESTS > depends on KUNIT > diff --git a/lib/Makefile b/lib/Makefile > index b1c42c10073b..8c145f85accc 100644 > --- a/lib/Makefile > +++ b/lib/Makefile > @@ -78,7 +78,6 @@ obj-$(CONFIG_TEST_VMALLOC) += test_vmalloc.o > obj-$(CONFIG_TEST_OVERFLOW) += test_overflow.o > obj-$(CONFIG_TEST_RHASHTABLE) += test_rhashtable.o > obj-$(CONFIG_TEST_SORT) += test_sort.o > -obj-$(CONFIG_TEST_USER_COPY) += test_user_copy.o > obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_keys.o > obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_key_base.o > obj-$(CONFIG_TEST_PRINTF) += test_printf.o > @@ -318,3 +317,4 @@ obj-$(CONFIG_OBJAGG) += objagg.o > # KUnit tests > obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o > obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o > +obj-$(CONFIG_USER_COPY_KUNIT) += user_copy_kunit.o > diff --git a/lib/test_user_copy.c b/lib/user_copy_kunit.c > similarity index 91% > rename from lib/test_user_copy.c > rename to lib/user_copy_kunit.c > index 5ff04d8fe971..a10ddd15b4cd 100644 > --- a/lib/test_user_copy.c > +++ b/lib/user_copy_kunit.c > @@ -16,6 +16,7 @@ > #include > #include > #include > +#include > > /* > * Several 32-bit architectures support 64-bit {get,put}_user() calls. > @@ -35,7 +36,7 @@ > ({ \ > int cond = (condition); \ > if (cond) \ > - pr_warn("[%d] " msg "\n", __LINE__, ##__VA_ARGS__); \ > + KUNIT_EXPECT_FALSE_MSG(test, cond, msg, ##__VA_ARGS__); \ I'm surprised any of this compiles with both a macro and arg named "test". :) Can you change the arg to something with more clarity? "context" or "kunit" seems better. > cond; \ > }) > > @@ -44,7 +45,7 @@ static bool is_zeroed(void *from, size_t size) > return memchr_inv(from, 0x0, size) == NULL; > } > > -static int test_check_nonzero_user(char *kmem, char __user *umem, size_t size) > +static int test_check_nonzero_user(struct kunit *test, char *kmem, char __user *umem, size_t size) > { > int ret = 0; > size_t start, end, i, zero_start, zero_end; > @@ -102,7 +103,7 @@ static int test_check_nonzero_user(char *kmem, char __user *umem, size_t size) > return ret; > } > > -static int test_copy_struct_from_user(char *kmem, char __user *umem, > +static int test_copy_struct_from_user(struct kunit *test, char *kmem, char __user *umem, > size_t size) > { > int ret = 0; > @@ -177,7 +178,7 @@ static int test_copy_struct_from_user(char *kmem, char __user *umem, > return ret; > } > > -static int __init test_user_copy_init(void) > +static void user_copy_test(struct kunit *test) > { > int ret = 0; > char *kmem; > @@ -192,16 +193,14 @@ static int __init test_user_copy_init(void) > #endif > > kmem = kmalloc(PAGE_SIZE * 2, GFP_KERNEL); > - if (!kmem) > - return -ENOMEM; > + KUNIT_EXPECT_FALSE_MSG(test, kmem == NULL, "kmalloc failed"); This would need to be an ASSERT, yes? > > user_addr = vm_mmap(NULL, 0, PAGE_SIZE * 2, > PROT_READ | PROT_WRITE | PROT_EXEC, > MAP_ANONYMOUS | MAP_PRIVATE, 0); > if (user_addr >= (unsigned long)(TASK_SIZE)) { > - pr_warn("Failed to allocate user memory\n"); > kfree(kmem); > - return -ENOMEM; > + KUNIT_FAIL(test, "Failed to allocate user memory"); > } Why FAIL instead of ASSERT? > > usermem = (char __user *)user_addr; > @@ -245,9 +244,9 @@ static int __init test_user_copy_init(void) > #undef test_legit > > /* Test usage of check_nonzero_user(). */ > - ret |= test_check_nonzero_user(kmem, usermem, 2 * PAGE_SIZE); > + ret |= test_check_nonzero_user(test, kmem, usermem, 2 * PAGE_SIZE); > /* Test usage of copy_struct_from_user(). */ > - ret |= test_copy_struct_from_user(kmem, usermem, 2 * PAGE_SIZE); > + ret |= test_copy_struct_from_user(test, kmem, usermem, 2 * PAGE_SIZE); > > /* > * Invalid usage: none of these copies should succeed. > @@ -309,23 +308,18 @@ static int __init test_user_copy_init(void) > > vm_munmap(user_addr, PAGE_SIZE * 2); > kfree(kmem); > - > - if (ret == 0) { > - pr_info("tests passed.\n"); > - return 0; > - } > - > - return -EINVAL; Does KUnit provide a end-of-test summary now? > } > > -module_init(test_user_copy_init); > - > -static void __exit test_user_copy_exit(void) > -{ > - pr_info("unloaded.\n"); > -} > +static struct kunit_case user_copy_test_cases[] = { > + KUNIT_CASE(user_copy_test), > + {} > +}; > > -module_exit(test_user_copy_exit); > +static struct kunit_suite user_copy_test_suite = { > + .name = "user_copy", > + .test_cases = user_copy_test_cases, > +}; > > +kunit_test_suites(&user_copy_test_suite); > MODULE_AUTHOR("Kees Cook "); > MODULE_LICENSE("GPL"); > > base-commit: d43c7fb05765152d4d4a39a8ef957c4ea14d8847 > -- > 2.26.2 > Otherwise, yes, looking good. -- Kees Cook