Linux Test Project
 help / color / mirror / Atom feed
From: Richard Palethorpe <rpalethorpe@suse.de>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 2/2] bpf: Check truncation on 32bit div/mod by zero
Date: Tue, 27 Apr 2021 10:50:39 +0100	[thread overview]
Message-ID: <87k0oot5sg.fsf@suse.de> (raw)
In-Reply-To: <YIfZqZ29H2AN1vqh@pevik>

Hello Petr,

Petr Vorel <pvorel@suse.cz> writes:

> Hi Richard,
>
>> Add a test which checks for a number of issues surrounding division by
>> zero.
>
>> +++ b/testcases/kernel/syscalls/bpf/bpf_prog05.c
> ...
>> +/*\
>> + * [Description]
>> + *
>> + * Compare the effects of 32-bit div/mod by zero with the "expected"
> FYI this causes docparser error:
>
> /usr/src/ltp/docparse/testinfo.pl metadata.json
> , or ] expected while parsing array, at character offset 70801 (before "expected"",\n     "b...") at /usr/src/ltp/docparse/testinfo.pl line 423
>
> Because we don't escap double quotes (among other issues previously reported,
> e.g. tabs), it produces invalid json:

bah, maybe we should just base64 encode doc strings in the JSON?

>
>    "doc": [
>      "[Description]",
>      "",
>      "Compare the effects of 32-bit div/mod by zero with the "expected"",
>      "behaviour.",
>      "",
>
> But I tested it on various OS and the code compiles and runs ok.
>
> I also looked at the code (very interesting), but with my minimal bpf knowledge
> I'm not the one who should review it.
>
>> + * behaviour.
>> + *
>> + * The commit "bpf: fix subprog verifier bypass by div/mod by 0
>> + * exception", changed div/mod by zero from exiting the current
>> + * program to setting the destination register to zero (div) or
>> + * leaving it untouched (mod).
>> + *
>> + * This solved one verfier bug which allowed dodgy pointer values, but
>                       ^
>                       verifier

+1

>
>> + * it turned out that the source register was being 32-bit truncated
>> + * when it should not be. Also the destination register for mod was
>> + * not being truncated when it should be.
>> + *
>> + * So then we have the following two fixes:
>> + * "bpf: Fix 32 bit src register truncation on div/mod"
>> + * "bpf: Fix truncation handling for mod32 dst reg wrt zero"
> - * "bpf: Fix 32 bit src register truncation on div/mod"
> - * "bpf: Fix truncation handling for mod32 dst reg wrt zero"
> (making it list)

+1
>
>> + *
>> + * Testing for all of these issues is a problem. Not least because
>> + * division by zero is undefined, so in theory any result is
>> + * acceptable so long as the verifier and runtime behaviour
>> + * match.
>> + *
>> + * However to keep things simple we just check if the source and
>> + * destination register runtime values match the current upstream
>> + * behaviour at the time of writing.
>> + *
>> + * If the test fails you may have one or more of the above patches
>> + * missing. In this case it is possible that you are not vulnerable
>> + * depending on what other backports and fixes have been applied. If
>> + * upstream changes the behaviour of division by zero, then the test
>> + * will need updating.
>> +\*/
> @metan: remove this before merge.
>
>
> Kind regards,
> Petr


-- 
Thank you,
Richard.

  reply	other threads:[~2021-04-27  9:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-26 12:01 [LTP] [PATCH 1/2] lapi/bpf: Add /= and %= Richard Palethorpe
2021-04-26 12:01 ` [LTP] [PATCH 2/2] bpf: Check truncation on 32bit div/mod by zero Richard Palethorpe
2021-04-27  9:30   ` Petr Vorel
2021-04-27  9:50     ` Richard Palethorpe [this message]
2021-04-27 10:54       ` Cyril Hrubis
2021-04-27 10:58     ` Cyril Hrubis
2021-04-27 12:03       ` Petr Vorel
2021-04-27  9:54   ` Cyril Hrubis
2021-04-27 11:25     ` Richard Palethorpe

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=87k0oot5sg.fsf@suse.de \
    --to=rpalethorpe@suse.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox