Received-SPF: pass (google.com: domain of linux-kernel+bounces-137391-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Subject: Re: [PATCH v2 bpf-next] bpf: Fix latent unsoundness in and/or/xor
 value tracking
To: Harishankar Vishwanathan <harishankar.vishwanathan@gmail.com>,
 Edward Cree <ecree@amd.com>
Cc: ast@kernel.org, harishankar.vishwanathan@rutgers.edu, paul@isovalent.com,
 Matan Shachnai <m.shachnai@rutgers.edu>,
 Srinivas Narayana <srinivas.narayana@rutgers.edu>,
 Santosh Nagarakatte <santosh.nagarakatte@rutgers.edu>,
 Daniel Borkmann <daniel@iogearbox.net>,
 John Fastabend <john.fastabend@gmail.com>,
 Andrii Nakryiko <andrii@kernel.org>, Martin KaFai Lau
 <martin.lau@linux.dev>, Eduard Zingerman <eddyz87@gmail.com>,
 Song Liu <song@kernel.org>, Yonghong Song <yonghong.song@linux.dev>,
 KP Singh <kpsingh@kernel.org>, Stanislav Fomichev <sdf@google.com>,
 Hao Luo <haoluo@google.com>, Jiri Olsa <jolsa@kernel.org>,
 "David S. Miller" <davem@davemloft.net>, bpf@vger.kernel.org,
 linux-kernel@vger.kernel.org
References: <20240402212039.51815-1-harishankar.vishwanathan@gmail.com>
 <77f5c5ed-881e-c9a8-cfdb-200c322fb55d@amd.com>
 <CAM=Ch04xd5u75UFeQwVrzP7=A5KPAw3x7_drqQHK3C-43T4T2w@mail.gmail.com>
From: Edward Cree <ecree.xilinx@gmail.com>
Message-ID: <9d149d61-239c-67ac-0647-b59a12264299@gmail.com>
Date: Tue, 9 Apr 2024 18:17:05 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.14.0
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <CAM=Ch04xd5u75UFeQwVrzP7=A5KPAw3x7_drqQHK3C-43T4T2w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 7bit

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