[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9d149d61-239c-67ac-0647-b59a12264299@gmail.com>
Date: Tue, 9 Apr 2024 18:17:05 +0100
From: Edward Cree <ecree.xilinx@...il.com>
To: Harishankar Vishwanathan <harishankar.vishwanathan@...il.com>,
Edward Cree <ecree@....com>
Cc: ast@...nel.org, harishankar.vishwanathan@...gers.edu, paul@...valent.com,
Matan Shachnai <m.shachnai@...gers.edu>,
Srinivas Narayana <srinivas.narayana@...gers.edu>,
Santosh Nagarakatte <santosh.nagarakatte@...gers.edu>,
Daniel Borkmann <daniel@...earbox.net>,
John Fastabend <john.fastabend@...il.com>,
Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau
<martin.lau@...ux.dev>, Eduard Zingerman <eddyz87@...il.com>,
Song Liu <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>,
KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...gle.com>,
Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
"David S. Miller" <davem@...emloft.net>, bpf@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 bpf-next] bpf: Fix latent unsoundness in and/or/xor
value tracking
On 04/04/2024 03:40, Harishankar Vishwanathan wrote:
> [...]
> Given the above, please advise if we should backport this patch to older
> kernels (and whether I should use the fixes tag).
I don't feel too strongly about it, and if you or Shung-Hsi still
think, on reflection, that backporting is desirable, then go ahead
and keep the Fixes: tag.
But maybe tweak the description so someone doesn't see "latent
unsoundness" and think they need to CVE and rush this patch out as
a security thing; it's more like hardening. *shrug*
>> Commit message could also make clearer that the new code considers whether
>> the *output* ubounds cross sign, rather than looking at the input bounds
>> as the previous code did. At first I was confused as to why XOR didn't
>> need special handling (since -ve xor -ve is +ve).
>
> Sounds good regarding making it clearer within the context of what the
> existing code does. However, I wanted to clarify that XOR does indeed use
> the same handling as all the other operations. Could you elaborate on what
> you mean?
Just that if you XOR two negative numbers you get a positive number,
which isn't true for AND or OR; and my confused little brain thought
that fact was relevant, which it isn't.
-e
Powered by blists - more mailing lists