All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [doc, runtest] [was: Re:  [PATCH] cve: add CVE-2025-38236 test]
Date: Mon, 18 Aug 2025 08:08:19 +0200	[thread overview]
Message-ID: <20250818060819.GA133791@pevik> (raw)
In-Reply-To: <aJsu4qw72EZiKnSP@yuki.lan>

Hi Cyril, all,

> Hi!
> > This problem happen on all runtest files, fixing just one does not fix the
> > problem.

> Well we can do that for any runtest file that has clear definition of
> which tests belongs there. For CVE it's crystal clear, tests that have
> cve tag should be there. For the rest of the runtest files, it's not so
> much. Maybe for syscalls we may be able to do so.

> The main thing is that we have to start somewhere got eventually get
> there. I just quickly looked at the cve runtest file and figured out
> that we have to add tests variants somewhere into the metadata. I.e.
> quite a few of the CVE tests have command line options in the runtest
> file which has to be stored somewhere else.

Thanks for analysis. I put your investigation into an issue:

https://github.com/linux-test-project/ltp/issues/1253

> > Sure, it'd be possible to generate runtest/cve from metadata. Do we really want
> > to implement it? (I can create a ticket). I guess we would use C and ujson to
> > not require json-c or python3 for building LTP.

> Or we can hook it up directly into the metadata parser, instead of
> parsing the resulting JSON we can act on the data while they are in the
> memory. Matching some tags and writing a test name into a file could be
> easily done.

> > I would be more interested to have section "CVE reproducers" in Statistics page [1].
> > While the same tool could be used to do both goals, when only doc page
> > implemented, it could be easily done in python3 (doc/conf.py already parses
> > ltp.json).

> > When we are at Statistics page, also generating list of reproducers (based on
> > kernel fixes) would be also nice. Because this was implemented in the previous
> > asciidoctor implementation. How about having these lists Statistics, where are
> > other tables already (and linking each test to "Test Catalog")?

> > Also I find "Statistics" name confusing. It says nothing about the content. I
> > wonder if people curiously click on the page or just ignore the page (if they
> > don't like math :)). Maybe "Kernel coverage" or something like that would be
> > more informative.

> I would put the list of reproducers and list of CVE reproducers into a
> separate page that would be have "reproducers" in the name.

https://github.com/linux-test-project/ltp/issues/1254

> And statistics is probably okayish name, since coverage may mislead
> people even more. For example we have a lot of tests for a write()
> syscall yet coverage for all the possible write handlers in kernel is
> very poor and not likely to improve.

Fair enough.

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2025-08-18  6:08 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-12  8:45 [LTP] [PATCH] cve: add CVE-2025-38236 test Andrea Cervesato
2025-08-12  9:43 ` Wei Gao via ltp
2025-08-12 10:57   ` Andrea Cervesato via ltp
2025-08-12 11:09     ` Petr Vorel
2025-08-12 10:12 ` Petr Vorel
2025-08-12 11:09   ` Cyril Hrubis
2025-08-12 11:45     ` [LTP] [doc, runtest] [was: Re: [PATCH] cve: add CVE-2025-38236 test] Petr Vorel
2025-08-12 12:09       ` Cyril Hrubis
2025-08-18  6:08         ` Petr Vorel [this message]
2025-08-12 10:51 ` [LTP] [PATCH] cve: add CVE-2025-38236 test Petr Vorel
2025-08-12 10:55   ` Andrea Cervesato via ltp
2025-08-12 11:14     ` Cyril Hrubis
2025-08-12 11:17       ` Andrea Cervesato via ltp
2025-08-12 11:50       ` Petr Vorel
2025-08-12 11:25     ` Petr Vorel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250818060819.GA133791@pevik \
    --to=pvorel@suse.cz \
    --cc=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.