From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 02F2BCA9ECB for ; Thu, 31 Oct 2019 18:40:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CE63C2086D for ; Thu, 31 Oct 2019 18:40:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="ToKg4wox" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729347AbfJaSki (ORCPT ); Thu, 31 Oct 2019 14:40:38 -0400 Received: from mail-pl1-f194.google.com ([209.85.214.194]:41081 "EHLO mail-pl1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729251AbfJaSki (ORCPT ); Thu, 31 Oct 2019 14:40:38 -0400 Received: by mail-pl1-f194.google.com with SMTP id t10so3073459plr.8 for ; Thu, 31 Oct 2019 11:40:37 -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=4ZF1W1bG/Rl8CChrQFOeusHspeNIEyvicA7XRZyNais=; b=ToKg4woxb646iL0UBTpW7kOzBulVyPZE8eDKGJRbGidQmuB1kSZuXXGKQrlmhVqoG/ 6mqlKlPwwHbv30/kmrxykMo2JifdPmff3G7Vcjm5igE3zt+aH+NuABmoc8V6qYyGdAUo 73/woDqeWba6Ad8QQ0T/3wSFBcBSEsb+D3la0= 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=4ZF1W1bG/Rl8CChrQFOeusHspeNIEyvicA7XRZyNais=; b=H2mukumumc5Tpi9UygdEOPyGsnfPAtBiCDMnKB3nrmc+ZCmD6Ro13ARHzgcopQqeZ0 7W5zS1b49vlxPPfwU5o0fl3Z1UVLqpjPBDOb3d0zsa+rNhd5KGEqi3wtEc9769lKmzgv mrIRkF5CNOfkJjw4ReJMtEXqZnAEKMcxKW8lkJTLNYas0iyTO27Ivl1DnhXYjhmHDl5t WL8I4IAKyklvvzT/RyHMsGoIiMvilJhzCV+uwd/nwZgqZJGnQ/nf6/BBDBwdytc4sc/b nBPDA41PmCeLhEnnNCYyejylPdWBRpFwkIPnhaQ3a9LquCVIPuqpsABqxASINq5I3fYb QH9w== X-Gm-Message-State: APjAAAXwIKpMi7VPnm7DqrkFpHsaW7FLnOwRiM9oWrua7Qgwc7yTyfER Lwr0JUZI7iRakvc1m8X8ZNGcSA== X-Google-Smtp-Source: APXvYqzTiXUhiopZUISbbRLvil8rhHffcEWWEBYAGxeX2kHSa42od+2QUV+X5ZsC/43T4hltLWmqWA== X-Received: by 2002:a17:902:326:: with SMTP id 35mr8047584pld.248.1572547237564; Thu, 31 Oct 2019 11:40:37 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id j14sm3913682pfi.168.2019.10.31.11.40.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 31 Oct 2019 11:40:36 -0700 (PDT) Date: Thu, 31 Oct 2019 11:40:35 -0700 From: Kees Cook To: Brendan Higgins Cc: Iurii Zaikin , Luis Chamberlain , Alan Maguire , Matthias Maennich , shuah , John Johansen , jmorris@namei.org, serge@hallyn.com, David Gow , Theodore Ts'o , Linux Kernel Mailing List , linux-security-module@vger.kernel.org, KUnit Development , "open list:KERNEL SELFTEST FRAMEWORK" , Mike Salvatore Subject: Re: [PATCH linux-kselftest/test v1] apparmor: add AppArmor KUnit tests for policy unpack Message-ID: <201910311136.BBC4C70B@keescook> References: <20191018001816.94460-1-brendanhiggins@google.com> <20191018122949.GD11244@42.do-not-panic.com> <20191024101529.GK11244@42.do-not-panic.com> <201910301205.74EC2A226D@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kselftest-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org On Thu, Oct 31, 2019 at 02:33:32AM -0700, Brendan Higgins wrote: > 2) One of the layers in your program is too think, and you should > introduce a new layer with a new public interface that you can test > through. > > I think the second point here is problematic with how C is written in > the kernel. We don't really have any concept of public vs. private > inside the kernel outside of static vs. not static, which is much more > restricted. I don't find "2" to be a convincing argument (as you hint a bit at in the next paragraph)_. There are lots of things code is depending on (especially given the kernel's coding style guides about breaking up large functions into little ones), that you want to test to make sure is working correctly that has no public exposure, and you want to test those helper's corner cases which might be hard to (currently) reach via the higher level public APIs. -- Kees Cook