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

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

Message-ID: <61b1f1f0c9aab58551e98ba396deba56e77f1f89.camel@codeconstruct.com.au>
Date:   Thu, 27 Apr 2023 14:08:08 +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,

> >  - could we turn this into a non-vendor-specific (length, data) match
> >    instead? If the length is zero, this falls back to exactly as
> >    specified in DSP0236.
> No problem, for me sounds good. I will prepare solution based on the 
> non-vendor data as offset/length/data instead of sub-code.

OK, neat.

We may need to work out when the subtype length gets set - either if:

 (a) it is part of the sockaddr,

 or

 (b) it is defined when vendor-specific addressing is enabled via the
 MCTP_OPT_VENDOR_EXT sockopt (ie, we would make the length part of the
 setsockopt argument).

The (a) approach may have issues when we're processing incoming packets:
we'll need to have advance knowledge of the length before we can extract
the sockaddr.

This is fine for a "responder" model, where there's a bind() call to
provide the sockopt (and hence subtype length) in the receiving socket.

However, this may be tricky for recvfrom(), where there is no prior
length value available. We could extract this from the earlier
(outgoing) message, but that's getting a bit hacky at that point.

> I think offset is also required to know from which byte to start
> parsing data.

Are there cases where the subtype does not immediately follow the
PCIe/IANA type? If not, we could just require that...

> > Also, do we really need 8 bytes of type for this? Is some vendor
> > planning to support more than 4.3 billion MCTP subtypes? :)
> Intel uses only one byte and those are static values. Behind 8 bytes 
> was idea that maybe someone uses dynamic generated values (e.g SHA).
> For me it's hard to guess what maximum size it should be to not
> kill performance and make it useful.
> If you have advise I would appreciate.

I don't think there'll be much impact on performance here, but we do
need to ensure we don't hit the maximum size of a sockaddr. It would
also be nice to keep things down to a reasonable size in general - I
don't think there will be much need for more than 16 bits of subtype, or
32 if we're being super conservative.

(and we can probably reduce the length down to just a u8 too).

> > This is also under the assumption that we want to be able to support
> > both extended addressing *and* vendor addressing at the same time. I
> > don't think there's any reason not to, but any thoughts on that?
> Actually it's our main use case when extending addressing and vendor
> addressing are use in the same time.

OK, good to know.

I assume this is for PECI - have you considered just standardising that
as a top-level MCTP type value? :D

Cheers,

Jeremy