netdev - Re: [RFC net-next v1] tools: ynl: Add an strace rendering mode to ynl-gen

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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Thu, 15 Jun 2023 20:00:36 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Donald Hunter <donald.hunter@...il.com>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>, Eric
 Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
 donald.hunter@...hat.com
Subject: Re: [RFC net-next v1] tools: ynl: Add an strace rendering mode to
 ynl-gen

On Thu, 15 Jun 2023 16:13:36 +0100 Donald Hunter wrote:
> Add --mode strace to ynl-gen-c.py to generate source files for strace
> that teach it to understand how to decode genetlink messages defined
> in the spec. I successfully used this to add openvswitch message
> decoding to strace as I described in:
> 
> https://donaldh.wtf/2023/06/teaching-strace-new-tricks/
> 
> It successfully generated ovs_datapath and ovs_vport but ovs_flow
> needed manual fixes to fix code ordering and forward declarations.
> 
> Limitations:
> 
> - Uses a crude mechanism to try and emit functions in the right order
>   which fails for ovs_flow

What's the dependency? I pushed some stuff recently to try to order
types more intelligently but for normal C netlink it still won't deal
with cycles :(

Actually I think that you're using raw family info rather than the
codegen-focused structs, maybe that's why?

> - Outputs all strace sources to stdout or a single file
> - Does not use the right semantic strace decoders for e.g. IP or MAC
>   addresses because there is no schema information to say what the
>   domain type is.

The interpretation depends on another attribute or we expose things 
as binary with no machine-readable indication if its IP addr or MAC etc?

> This seems like a useful tool to have as part of the ynl suite since
> it lowers the cost of getting good strace support for new netlink
> families. But I realise that the generated format is dependent on an
> out of tree project. If there is interest in having this in-tree then
> I can clean it up and address some of the limitations before
> submission.

I think it's fine, we'll have to cross this bridge sooner or later.
I suspect we'll need to split ynl-gen-c once again (like the
tools/net/ynl/lib/nlspec.py, maybe we need another layer for code 
generators? nlcodegen or some such?) before we add codegen for more
languages. I'm not sure you actually need that yet, maybe the strace
generator needs just nlspec.py and it can be a separate script?