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]
Message-ID: <20190313101436.GB25643@dell5510>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ