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: <fdb140d04c2f5ccc7cf453e75bbbb3d7e8716a16.camel@codeconstruct.com.au>
Date: Thu, 04 May 2023 16:10:44 +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,

> > 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?
> Thanks, I think I got it.
> Yes, it seems it would work.

OK, super!

> Unfortunately have no experience if it comes
> to BPF code, but I assume if there are several processes which want to
> consume VDM then on of them (or maybe dedicated one) should install proper
> BPF handler for an incoming packet, right ?

Yes, exactly. I'm not super familiar with BPF either, but I'm happy to
work with you on getting the infrastructure going for this.

In general, we would need the vendor mark field on the skb, the mark as
a member of the sockaddr, and some glue code to allow BPF to set the skb
mark.

> It's out of the topic but maybe you know how the BPF usually is distribute.
> In case when kernel itself would parse VDM for all vendors there are no
> worries, but in BPF case, if I understand correctly, vendor must provide
> BPF code which actually support marks for all VDMs across all vendors, 
> correct ?

No, it would only need to apply the mark needed for that vendor+subtype
combination. I was imagining a design where the bind()-ing process
provides the BPF code itself, just for its own subtype. The specific u32
for the mark value could either be predefined by the vendor, or could be
probed at runtime.

[we would need some facility to prevent mark collision; I suspect we'll
want to require unique (mark, vendor) values on bind()]

Cheers,


Jeremy