All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Cc: Kees Cook <keescook@chromium.org>,
	David Ahern <dsahern@kernel.org>,
	davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com,
	pabeni@redhat.com, linux-hardening@vger.kernel.org
Subject: Re: [PATCH net-next v2] netlink: split up copies in the ack construction
Date: Wed, 16 Nov 2022 17:05:26 -0800	[thread overview]
Message-ID: <20221116170526.752c304b@kernel.org> (raw)
In-Reply-To: <1e97660d-32ff-c0cc-951b-5beda6283571@embeddedor.com>

On Wed, 16 Nov 2022 18:55:36 -0600 Gustavo A. R. Silva wrote:
> > @@ -56,7 +55,6 @@ struct nlmsghdr {
> >   	__u16		nlmsg_flags;
> >   	__u32		nlmsg_seq;
> >   	__u32		nlmsg_pid;
> > -	__u8		nlmsg_data[];
> >   };  
> 
> This seems to be a sensible change. In general, it's not a good idea
> to have variable length objects (flex-array members) in structures used
> as headers, and that we know will ultimately be followed by more objects
> when embedded inside other structures.

Meaning we should go back to zero-length arrays instead?
Will this not bring back out-of-bound warnings that Kees 
has been fixing?

Is there something in the standard that makes flexible array
at the end of an embedded struct a problem?
Or it's just unlikely compiler people will budge?

AFAICT this is just one of 3 such structs which iproute2 build hits.

  reply	other threads:[~2022-11-17  1:05 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-27 21:25 [PATCH net-next v2] netlink: split up copies in the ack construction Jakub Kicinski
2022-10-31  9:20 ` patchwork-bot+netdevbpf
2022-11-14  2:39 ` David Ahern
2022-11-14 17:06   ` Jakub Kicinski
2022-11-16 22:53     ` Kees Cook
2022-11-16 22:56       ` Kees Cook
2022-11-17  0:27         ` Kees Cook
2022-11-17  0:55           ` Gustavo A. R. Silva
2022-11-17  1:05             ` Jakub Kicinski [this message]
2022-11-17  1:20               ` Gustavo A. R. Silva
2022-11-17  6:13                 ` Jakub Kicinski
2022-11-17 16:25                   ` Stephen Hemminger
2022-11-17 20:36                     ` Jakub Kicinski
2022-11-17 22:35                       ` Kees Cook
2022-11-18  0:28                         ` Jakub Kicinski
2022-11-18  3:27                           ` Kees Cook
2022-11-18 15:59                           ` David Ahern
2022-11-18  2:37                       ` Stephen Hemminger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221116170526.752c304b@kernel.org \
    --to=kuba@kernel.org \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=gustavo@embeddedor.com \
    --cc=keescook@chromium.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.