linux-kernel - Re: [PATCH v6 01/15] lib: Add TLV parser

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]

Message-ID: <b894e43c3bf3c594a87b90ae75141e49fdd577c3.camel@huaweicloud.com>
Date: Tue, 21 Jan 2025 15:29:53 +0100
From: Roberto Sassu <roberto.sassu@...weicloud.com>
To: Thomas Weißschuh <linux@...ssschuh.net>
Cc: zohar@...ux.ibm.com, dmitry.kasatkin@...il.com,
 eric.snowberg@...cle.com,  corbet@....net, mcgrof@...nel.org,
 petr.pavlu@...e.com, samitolvanen@...gle.com,  da.gomez@...sung.com,
 akpm@...ux-foundation.org, paul@...l-moore.com,  jmorris@...ei.org,
 serge@...lyn.com, shuah@...nel.org, mcoquelin.stm32@...il.com, 
 alexandre.torgue@...s.st.com, linux-integrity@...r.kernel.org, 
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, 
 linux-api@...r.kernel.org, linux-modules@...r.kernel.org, 
 linux-security-module@...r.kernel.org, linux-kselftest@...r.kernel.org, 
 wufan@...ux.microsoft.com, pbrobinson@...il.com, zbyszek@...waw.pl,
 hch@....de,  mjg59@...f.ucam.org, pmatilai@...hat.com, jannh@...gle.com,
 dhowells@...hat.com,  jikos@...nel.org, mkoutny@...e.com, ppavlu@...e.com,
 petr.vorel@...il.com,  mzerqung@...inter.de, kgold@...ux.ibm.com, Roberto
 Sassu <roberto.sassu@...wei.com>
Subject: Re: [PATCH v6 01/15] lib: Add TLV parser

On Tue, 2025-01-21 at 15:21 +0100, Thomas Weißschuh wrote:
> On 2025-01-21 14:48:09+0100, Roberto Sassu wrote:
> > On Tue, 2025-01-21 at 14:29 +0100, Thomas Weißschuh wrote:
> > > Hi Robert,
> > > 
> > > On 2024-11-19 11:49:08+0100, Roberto Sassu wrote:
> > > > From: Roberto Sassu <roberto.sassu@...wei.com>
> > > > 
> > > > Add a parser of a generic Type-Length-Value (TLV) format:
> > > > 
> > > > +--------------+--+---------+--------+---------+
> > > > > field1 (u16) | len1 (u32) | value1 (u8 len1) |
> > > > +--------------+------------+------------------+
> > > > >     ...      |    ...     |        ...       |
> > > > +--------------+------------+------------------+
> > > > > fieldN (u16) | lenN (u32) | valueN (u8 lenN) |
> > > > +--------------+------------+------------------+
> > > 
> > > Should mention that its big endian.
> > 
> > Ok.
> > 
> > > > Each adopter can define its own fields. The TLV parser does not need to be
> > > > aware of those, but lets the adopter obtain the data and decide how to
> > > 
> > > "adopter" -> "user".
> > 
> > Ok.
> > 
> > > > continue.
> > > > 
> > > > After processing a TLV entry, call the callback function also with the
> > > > callback data provided by the adopter. The latter can decide how to
> > > > interpret the TLV entry depending on the field ID.
> > > > 
> > > > Nesting TLVs is also possible, the callback function can call tlv_parse()
> > > > to parse the inner structure.
> > > 
> > > Given that we already have the netlink data structures, helpers and
> > > infrastructure, what is the advantage over those?
> > 
> > Sorry, I'm not too familiar on how netlink works, so I might not
> > understand your point.
> 
> Netlink is a TLV format used by the Linux networking subsystem:
> 
> struct nlmsghdr {
>     __u32 nlmsg_len;    /* Length of message including header */
>     __u16 nlmsg_type;   /* Type of message content */
>     __u16 nlmsg_flags;  /* Additional flags */
>     __u32 nlmsg_seq;    /* Sequence number */
>     __u32 nlmsg_pid;    /* Sender port ID */
> };
> 
> https://man.archlinux.org/man/core/man-pages/netlink.7.en
> 
> There are both userspace and in-kernel infrastructures to handle it.
> Looking at it again however it has some unnecessary fields, wasting
> space and uses "host" byteorder which is a problem for an on-disk
> datastructure.
> So maybe not a good alternative after all.
> 
> > I think the benefit of this data structure is the retrocompatibility.
> > If you add new data fields, you don't need to introduce a v2, v3 data
> > format.
> > 
> > New versions of the parser can consume the new information, while the
> > older can still take the ones they are able to understand.
> 
> This is also exactly how netlink is used.

Ok, perfect!

> FYI there were also some review comments inside the patch diff itself.

Ops, thanks! Missed them. Will reply to that email.

Roberto