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:   Fri, 8 Dec 2023 09:06:30 +0100 (CET)
From:   Miroslav Benes <mbenes@...e.cz>
To:     Joe Lawrence <joe.lawrence@...hat.com>
cc:     Marcos Paulo de Souza <mpdesouza@...e.com>,
        Shuah Khan <shuah@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        Heiko Carstens <hca@...ux.ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        Sven Schnelle <svens@...ux.ibm.com>,
        Josh Poimboeuf <jpoimboe@...nel.org>,
        Jiri Kosina <jikos@...nel.org>, Petr Mladek <pmladek@...e.com>,
        linux-kselftest@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org,
        live-patching@...r.kernel.org
Subject: Re: [PATCH v3 2/3] livepatch: Move tests from lib/livepatch to
 selftests/livepatch

> > My idea is to abandon this way completely, take the selftests and build 
> > and run them on the system right away.
> > 
> > Both should be doable, hopefully, if we wire it all correctly... and 
> > document it.
> > 
> I can't think of why it shouldn't continue to work, even in a future
> where newer livepatching selftests support older kernels.  (We would
> just have newer selftests sources backported to test older kernel sources.)
> 
> Are there any test cases which truly need to be build on-the-fly?  Aside
> from testing different toolchain pieces?

https://github.com/SUSE/qa_test_klp is what we would like to migrate to 
selftests to have just one place for all tests.

There is basically just one live patch template and one supporting kernel 
module template which is livepatched. The final result is driven by a set 
of macros and function parameters. In some cases more modules are compiled 
as parts of a test in a loop.

However, I do not think there is anything which truly needs to be built 
on-the-fly in the end. Everything can be worked around. Templates may be 
abandoned and we would have a live patch and a module(s) per test. Some 
tests are probably not worth it and may be removed. So it is a question of 
convenience and maintainability. When we, for example, simplified API and 
klp_register_patch() was removed, only one place needed to be amended. 
Also, the current state in lib/livepatch/ could be simplified with the 
proposed infrastructure as some files could be merged together.

Miroslav

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ