netdev - Re: [RFC PATCH v1 0/1] net: mctp: MCTP VDM extension

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

Message-ID: <00357b1aff6d9be445f070172feb969639274a21.camel@codeconstruct.com.au>
Date:   Sat, 29 Apr 2023 07:18:32 +0800
From:   Jeremy Kerr <jk@...econstruct.com.au>
To:     "Richert, Krzysztof" <krzysztof.richert@...el.com>,
        matt@...econstruct.com.au
Cc:     davem@...emloft.net, kuba@...nel.org, netdev@...r.kernel.org
Subject: Re: [RFC PATCH v1 0/1] net: mctp: MCTP VDM extension

Hi Krzysztof,

> Not sure if I follow you, please let me ask additional questions.
>  
> > 
> >  A) we keep the DSP0236 specified behaviour in the kernel; allowing a
> >     bind on a PCI/IANA vendor type, but not the subtype
> > 
> >  B) we add a "vendor mark" field to the sockaddr_mctp_vendor_ext; an
> >     arbitrary u32. Sockets can specify a vendor mark value during bind()
> >     so that they receive packets with a specific mark. This allows us
> >     to reject duplicate bind()s on the same mark value.
> but such "vendor mark" is not actually PCI/IANA ? Or maybe by 
> "vendor mark" you think about u32 which is always just after 
> PCI/IANA in received packet? 

No, it's not part of the on-the-wire data of the packet at all, and not
specified by any standard; it's system-internal. The PCI/IANA vendor IDs
still appear in the packet as per DSP0236, the mark functionality just
covers the subtype use-case.

The mark is just an arbitrary u32 (or whatever type we choose) that gets
set on the skb when the packet is routed for local input.

Vendors using a subtype mechanism would have a little BPF code that
applies a mark to the packet, by looking at whatever subtype format that
vendor packet uses (from your case: a u8 that appears in the second
byte). The mark value does not need to match the subtype value; the mark
just needs to be unique against the vendor-id for that specific system.

Then, the userspace program implementing that subtype protocol would
bind() with:

 - the MCTP type 0x7e/0x7f;
 - the PCI/IANA value specific to that vendor
 - the mark set to the value set above (ie, defined by what the BPF
   sets)

... and hence only receive packets for that specific vendor id and
subtype.

Would that work?

Cheers,

Jeremy