linux-kernel - Re: [PATCH v3 5/7] selftests/ima: kexec_file

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 13 Mar 2019 11:14:36 +0100
From:   Petr Vorel <pvorel@...e.cz>
To:     Mimi Zohar <zohar@...ux.ibm.com>, Dave Young <dyoung@...hat.com>
Cc:     linux-integrity@...r.kernel.org, linux-kselftest@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 5/7] selftests/ima: kexec_file_load syscall test

Hi Mimi, Dave,

> > Frankly I did not read and followup much about the testing code changes,
> > not sure if it is doable or not.  The code sharing under testing folder
> > seems not very good.  For example the basic check_root is needed by
> > different parts, but all have its own implementation.  Anyway this is
> > not the duty of this patch set.
> > Also the selftests/lib/ is not a folder for sharing code for different
> > tests, it looks a standalone test instead.
Yes. Thus lib/ folder name is a bit confusing.

> Shuah suggested upstreaming these tests first and defer introducing a
> common set of functions to later.
Make sense.

> > So if split kexec tests to another folder is not doable please just
> > ignore the comment.

> Left in the selftests/ima is a similar test for kernel modules, which
> uses the "common" functions.  So either we wait to move the kexec
> tests or allow them to reach into the ima directory and use the
> ima_common_lib functions.
I guess just load ima_common_lib.sh for now would be good enough.
@Dave: BTW I has starting to work on kselftest common library.
I thought I'd spent some time on it before posting it, but I might even send
the small part I've done so far so we can discuss it.

> > BTW, does CONFIG_KEXEC* is checked?  in case a kernel without KEXEC or
> > KEXEC_FILE compiled in then the tests can just return directly.

> Good point.  Now that there is a common function for reading the
> Kconfig, I'll add that check to both the test_kexec_load.sh and
> test_kexec_file_load.sh tests respectively.

> Mimi


Kind regards,
Petr