netdev - Re: [RESEND PATCH 2/2] TCP: pass accepted-TFO indication through getsockopt

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] [day] [month] [year] [list]

Message-ID: <6054b382-40f8-4718-b1ac-63194b37f333@exim.org>
Date: Thu, 17 Apr 2025 11:26:09 +0100
From: jgh@...m.org
To: Kuniyuki Iwashima <kuniyu@...zon.com>
Cc: edumazet@...gle.com, ncardwell@...gle.com, netdev@...r.kernel.org
Subject: Re: [RESEND PATCH 2/2] TCP: pass accepted-TFO indication through
 getsockopt

On 2025/04/16 8:26 PM, Kuniyuki Iwashima wrote:
>> +#define TCPI_OPT_TFO_SEEN	128 /* we accepted a Fast Open option on SYN */
> 
> This is the last bit of tcpi_options.
> 
> We can add another field at the end of the struct if necessary in
> the future, but from the cover letter and commit message, I didn't
> get why this info is needed at per-socket granurality.

An application is operating at socket granularity.  The provision is
so that an application can tell what is going on with each one of
its comms channels independently, rather than (for instance) the
rolled-up information on the entire system that the existing
statistics counter offers.

> Also, This can be retrieved with BPF.

If I understand correctly, BPF is aimed at sysadminss probing
or modifying system operations rather than production use by
an application.  While your point is true, I don't think BPF
is a good fit.
-- 
Cheers,
   Jeremy