linux-kernel - Re: [PATCH v2 bpf-next] bpf: Fix latent unsoundness in and/or/xor value tracking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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