[net-next,0/2] MCTP sockaddr padding check/initialisation fixup

Message

Eugene Syromiatnikov Nov. 1, 2021, 5:54 p.m. UTC

Hello.

Padding/reserved fields necessitate appropriate checks in order to be usable
in the future.

Eugene Syromiatnikov (2):
  mctp: handle the struct sockaddr_mctp padding fields
  mctp: handle the struct sockaddr_mctp_ext padding field

 net/mctp/af_mctp.c | 24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

Comments

Jeremy Kerr Nov. 2, 2021, 1:57 a.m. UTC | #1

Hi Eugene,

> Padding/reserved fields necessitate appropriate checks in order to be
> usable in the future.

We don't have a foreseeable need for extra fields here; so this is a bit
hypothetical at the moment. However, I guess there may be something that
comes up in future - was there something you have in mind?

The requirements for the padding bytes to be zero on sendmsg() will
break the ABI for applications that are using the interface on 5.15;
there's a small, contained set of those at the moment though, so I'm OK
to handle the updates if this patch is accepted, but we'd need to make a
call on that soon.

Setting the pad bytes to zero on recvmsg() is a good plan though, I'm
happy for that change to go in regardless.

Cheers,


Jeremy

Eugene Syromiatnikov Nov. 2, 2021, 8:50 a.m. UTC | #2

On Tue, Nov 02, 2021 at 09:57:34AM +0800, Jeremy Kerr wrote:
> Hi Eugene,
> 
> > Padding/reserved fields necessitate appropriate checks in order to be
> > usable in the future.
> 
> We don't have a foreseeable need for extra fields here; so this is a bit
> hypothetical at the moment. However, I guess there may be something that
> comes up in future - was there something you have in mind?

Not really, but reality suggests that many interfaces tend to extend
over time (including socket addresses, see flags in sockaddr_vm
as an example), so future-proofing padding allows extending into it
with minimal implementation complication, comparing to other approaches.

> The requirements for the padding bytes to be zero on sendmsg() will
> break the ABI for applications that are using the interface on 5.15;
> there's a small, contained set of those at the moment though, so I'm OK
> to handle the updates if this patch is accepted, but we'd need to make a
> call on that soon.

Yeah, I regret I have not caught it earlier.

> Setting the pad bytes to zero on recvmsg() is a good plan though, I'm
> happy for that change to go in regardless.

I can split it out in case there is hesitance with regards to applying padding
checks.