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;
From:   KP Singh <kpsingh@chromium.org>
Date:   Wed, 29 Apr 2020 18:17:47 +0200
To:     Mikko Ylinen <mikko.ylinen@linux.intel.com>
Cc:     KP Singh <kpsingh@chromium.org>,
        open list <linux-kernel@vger.kernel.org>,
        bpf <bpf@vger.kernel.org>,
        Linux Security Module list 
        <linux-security-module@vger.kernel.org>,
        Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        James Morris <jmorris@namei.org>,
        Kees Cook <keescook@chromium.org>,
        Paul Turner <pjt@google.com>, Jann Horn <jannh@google.com>,
        Florent Revest <revest@chromium.org>,
        Brendan Jackman <jackmanb@chromium.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH bpf-next v9 0/8] MAC and Audit policy using eBPF (KRSI)
Message-ID: <20200429161747.GA113900@google.com>
References: <20200329004356.27286-1-kpsingh@chromium.org>
 <0165887d-e9d0-c03e-18b9-72e74a0cbd59@linux.intel.com>
 <CACYkzJ6XyHqr1W=LWV-5Z0txFBtvPCwRY-kczphy+pS7PEitqQ@mail.gmail.com>
 <b5652508-f727-b936-79b5-f8da658395f5@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b5652508-f727-b936-79b5-f8da658395f5@linux.intel.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

So I was able to reproduce the issue and also fix it (will separately
send a patch).

diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
index 9cd4455528e5..1bdd027766d4 100644
--- a/include/linux/lsm_hook_defs.h
+++ b/include/linux/lsm_hook_defs.h
@@ -55,7 +55,7 @@ LSM_HOOK(void, LSM_RET_VOID, bprm_committing_creds, struct linux_binprm *bprm)
 LSM_HOOK(void, LSM_RET_VOID, bprm_committed_creds, struct linux_binprm *bprm)
 LSM_HOOK(int, 0, fs_context_dup, struct fs_context *fc,
         struct fs_context *src_sc)
-LSM_HOOK(int, 0, fs_context_parse_param, struct fs_context *fc,
+LSM_HOOK(int, -ENOPARAM, fs_context_parse_param, struct fs_context *fc,
         struct fs_parameter *param)
 LSM_HOOK(int, 0, sb_alloc_security, struct super_block *sb)
 LSM_HOOK(void, LSM_RET_VOID, sb_free_security, struct super_block *sb)

So what was happening was that:

bpf_lsm hook for fs_context_parse_param was returning 0 which led this
bit of logic to believe the parameter was parsed by the LSM.

int vfs_parse_fs_param(struct fs_context *fc, struct fs_parameter
*param)
{

[...]
        ret = security_fs_context_parse_param(fc, param);
        if (ret != -ENOPARAM)
                /* Param belongs to the LSM or is disallowed by the
                 * LSM; so
                 * don't pass to the FS.
                 */
                return ret;

        if (fc->ops->parse_param) {
                ret = fc->ops->parse_param(fc, param);
                if (ret != -ENOPARAM)
                        return ret;
        }
[...]

This resulted in the fs_context->dev_name being NULL and the following
chain to throw an -EINVAL resulting in unsuccessful mount of the root
file-system:

- do_mount_root -> do_mount -> do_new_mount -> vfs_get_tree ->
-> fc->ops->get_tree -> legacy->get_tree -> fc->fs_type->mount ->
ext4_mount -> mount_bdev -> blkdev_get_by_path -> lookup_bdev

- KP


On 29-Apr 15:45, Mikko Ylinen wrote:
> 
> 
> On 29/04/2020 15:34, KP Singh wrote:
> > Thanks for reporting this! Can you share your Kconfig please?
> 
> This is what I originally started with
> https://raw.githubusercontent.com/clearlinux-pkgs/linux-mainline/master/config
> 
> but I also tried your _LSM_ settings found in this
> https://lore.kernel.org/bpf/20200402040357.GA217889@google.com/
> 
> -- Regards, Mikko