[v2,1/1] runtest/cve: Add some existing CVE tests to runtest file

Signed-off-by: Souta Kawahara <souta.kawahara@miraclelinux.com>
---
 runtest/cve | 12 ++++++++++++
 1 file changed, 12 insertions(+)

Pushed, thanks for the quick response.

Hi,

On 21. 06. 23 2:20, Souta Kawahara wrote:
> Signed-off-by: Souta Kawahara <souta.kawahara@miraclelinux.com>
> ---
>   runtest/cve | 12 ++++++++++++
>   1 file changed, 12 insertions(+)
> 
> diff --git a/runtest/cve b/runtest/cve
> index f9a449fe7..bbc552bea 100644
> --- a/runtest/cve
> +++ b/runtest/cve
> @@ -24,6 +24,7 @@ cve-2017-6951 request_key05
>   cve-2017-7308 setsockopt02
>   cve-2017-7472 keyctl04
>   cve-2017-7616 set_mempolicy05
> +cve-2017-8890 accept02
>   cve-2017-10661 timerfd_settime02
>   cve-2017-12192 keyctl07
>   cve-2017-12193 add_key04
> @@ -41,16 +42,19 @@ cve-2017-17805 af_alg02
>   cve-2017-17806 af_alg01
>   cve-2017-17807 request_key04
>   cve-2017-18075 pcrypt_aead01
> +cve-2017-18344 timer_create03
>   cve-2017-1000111 setsockopt07
>   cve-2017-1000112 setsockopt05
>   cve-2017-1000364 stack_clash
>   cve-2017-1000380 snd_timer01
>   cve-2017-1000405 thp04
>   cve-2018-5803 sctp_big_chunk
> +cve-2018-6927 futex_cmp_requeue02
>   cve-2018-7566 snd_seq01
>   cve-2018-8897 ptrace09
>   cve-2018-9568 connect02
>   cve-2018-10124 kill13
> +cve-2018-11508 adjtimex03
>   cve-2018-12896 timer_settime03
>   cve-2018-13405 creat09
>   cve-2018-18445 bpf_prog04
> @@ -66,15 +70,23 @@ cve-2020-14386 sendto03
>   cve-2020-14416 pty03
>   cve-2020-25705 icmp_rate_limit01
>   cve-2020-29373 io_uring02
> +cve-2020-36557 pty06
>   cve-2021-3444 bpf_prog05
>   cve-2021-3609 can_bcm01
> +cve-2021-3653 kvm_svm01
> +cve-2021-3656 kvm_svm02

All kvm_* tests are intended only for baremetal testing and they're 
built only for x86 machines. On any other arch, you'll get errors that 
the test program does not exist. In other words, they don't belong in 
this runfile.

>   cve-2021-4034 execve06
> +cve-2021-4197_1 cgroup_core01
> +cve-2021-4197_2 cgroup_core02
> +cve-2021-4204 bpf_prog06
>   cve-2021-22555 setsockopt08 -i 100
>   cve-2021-26708 vsock01
>   cve-2021-22600 setsockopt09
> +cve-2021-38198 kvm_pagefault01

Also this one.

>   cve-2021-38604 mq_notify03
>   cve-2022-0847 dirtypipe
>   cve-2022-2590 dirtyc0w_shmem
> +cve-2022-23222 bpf_prog07
>   # Tests below may cause kernel memory leak
>   cve-2020-25704 perf_event_open03
>   cve-2022-0185 fsconfig03

Martin Doucha <mdoucha@suse.cz> wrote:


> >   cve-2021-3444 bpf_prog05
> >   cve-2021-3609 can_bcm01
> > +cve-2021-3653 kvm_svm01
> > +cve-2021-3656 kvm_svm02
>
> All kvm_* tests are intended only for baremetal testing and they're
> built only for x86 machines. On any other arch, you'll get errors that
> the test program does not exist. In other words, they don't belong in
> this runfile.
>

Thanks for the info. I look a while why can't build them
as fake programs and only exit with TCONF on non-x86,
but seems it has some platform-dependent assembly language
and the linker rule unsupport that.

Okay, I will make an additional patch to kick out them.

On 21. 06. 23 13:52, Li Wang wrote:
> Thanks for the info. I look a while why can't build them
> as fake programs and only exit with TCONF on non-x86,
> but seems it has some platform-dependent assembly language
> and the linker rule unsupport that.

The KVM Makefile is complicated because we build a raw machine code 
binary which will be executed in the VM and then link it inside the test 
program as a data blob. Adding extra conditions to skip the blob 
compilation and safely TCONF in the test programs would make everything 
even more complicated so it's not worth the effort at this point because 
the KVM test coverage is still quite small.

Hi!
> > Thanks for the info. I look a while why can't build them
> > as fake programs and only exit with TCONF on non-x86,
> > but seems it has some platform-dependent assembly language
> > and the linker rule unsupport that.
> 
> The KVM Makefile is complicated because we build a raw machine code 
> binary which will be executed in the VM and then link it inside the test 
> program as a data blob. Adding extra conditions to skip the blob 
> compilation and safely TCONF in the test programs would make everything 
> even more complicated so it's not worth the effort at this point because 
> the KVM test coverage is still quite small.

I guess that proper solution could be implemented in the new generation
LTP executor. For instance if these tests have arch tag in tst_test set
to x86_64 the executor can read the metadata and wouldn't even attempt
to run these tests.

The whole point of the metadata parsing is to make the test execution
more flexible, since the runtest file based approach does not scale and
was outdated even ten years ago...