| Message ID | 20210818060533.3569517-57-keescook@chromium.org (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | Introduce strict memcpy() bounds checking | expand |
| Context | Check | Description |
|---|---|---|
| netdev/cover_letter | success | Link |
| netdev/fixes_present | success | Link |
| netdev/patch_count | fail | Series longer than 15 patches |
| netdev/tree_selection | success | Guessed tree name to be net-next |
| netdev/subject_prefix | success | Link |
| netdev/cc_maintainers | warning | 2 maintainers not CCed: ndesaulniers@google.com nathan@kernel.org |
| netdev/source_inline | success | Was 0 now: 0 |
| netdev/verify_signedoff | success | Link |
| netdev/module_param | success | Was 0 now: 0 |
| netdev/build_32bit | success | Errors and warnings before: 101 this patch: 101 |
| netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
| netdev/verify_fixes | success | Link |
| netdev/checkpatch | warning | CHECK: Alignment should match open parenthesis |
| netdev/build_allmodconfig_warn | success | Errors and warnings before: 101 this patch: 101 |
| netdev/header_inline | success | Link |
On Tue, Aug 17, 2021 at 11:05:26PM -0700, Kees Cook wrote: > In preparation for FORTIFY_SOURCE performing compile-time and run-time > field bounds checking for memset(), avoid intentionally writing across > neighboring fields. > > Add struct_group() to mark region of struct mlx5_ib_mr that should be > initialized to zero. > > Cc: Leon Romanovsky <leon@kernel.org> > Cc: Doug Ledford <dledford@redhat.com> > Cc: Jason Gunthorpe <jgg@ziepe.ca> > Cc: linux-rdma@vger.kernel.org > Signed-off-by: Kees Cook <keescook@chromium.org> > --- > drivers/infiniband/hw/mlx5/mlx5_ib.h | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h b/drivers/infiniband/hw/mlx5/mlx5_ib.h > index bf20a388eabe..f63bf204a7a1 100644 > --- a/drivers/infiniband/hw/mlx5/mlx5_ib.h > +++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h > @@ -644,6 +644,7 @@ struct mlx5_ib_mr { > struct ib_umem *umem; > > /* This is zero'd when the MR is allocated */ > + struct_group(cleared, > union { > /* Used only while the MR is in the cache */ > struct { > @@ -691,12 +692,13 @@ struct mlx5_ib_mr { > bool is_odp_implicit; > }; > }; > + ); > }; > > /* Zero the fields in the mr that are variant depending on usage */ > static inline void mlx5_clear_mr(struct mlx5_ib_mr *mr) > { > - memset(mr->out, 0, sizeof(*mr) - offsetof(struct mlx5_ib_mr, out)); > + memset(&mr->cleared, 0, sizeof(mr->cleared)); > } Why not use the memset_after(mr->umem) here? Jason
On Thu, Aug 19, 2021 at 09:27:16AM -0300, Jason Gunthorpe wrote: > On Tue, Aug 17, 2021 at 11:05:26PM -0700, Kees Cook wrote: > > In preparation for FORTIFY_SOURCE performing compile-time and run-time > > field bounds checking for memset(), avoid intentionally writing across > > neighboring fields. > > > > Add struct_group() to mark region of struct mlx5_ib_mr that should be > > initialized to zero. > > > > Cc: Leon Romanovsky <leon@kernel.org> > > Cc: Doug Ledford <dledford@redhat.com> > > Cc: Jason Gunthorpe <jgg@ziepe.ca> > > Cc: linux-rdma@vger.kernel.org > > Signed-off-by: Kees Cook <keescook@chromium.org> > > --- > > drivers/infiniband/hw/mlx5/mlx5_ib.h | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h b/drivers/infiniband/hw/mlx5/mlx5_ib.h > > index bf20a388eabe..f63bf204a7a1 100644 > > --- a/drivers/infiniband/hw/mlx5/mlx5_ib.h > > +++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h > > @@ -644,6 +644,7 @@ struct mlx5_ib_mr { > > struct ib_umem *umem; > > > > /* This is zero'd when the MR is allocated */ > > + struct_group(cleared, > > union { > > /* Used only while the MR is in the cache */ > > struct { > > @@ -691,12 +692,13 @@ struct mlx5_ib_mr { > > bool is_odp_implicit; > > }; > > }; > > + ); > > }; > > > > /* Zero the fields in the mr that are variant depending on usage */ > > static inline void mlx5_clear_mr(struct mlx5_ib_mr *mr) > > { > > - memset(mr->out, 0, sizeof(*mr) - offsetof(struct mlx5_ib_mr, out)); > > + memset(&mr->cleared, 0, sizeof(mr->cleared)); > > } > > Why not use the memset_after(mr->umem) here? I can certainly do that instead. In this series I've tended to opt for groupings so the position of future struct member additions are explicitly chosen. (i.e. reducing the chance that a zeroing of the new member be a surprise.) -Kees
On Thu, Aug 19, 2021 at 09:19:08AM -0700, Kees Cook wrote: > On Thu, Aug 19, 2021 at 09:27:16AM -0300, Jason Gunthorpe wrote: > > On Tue, Aug 17, 2021 at 11:05:26PM -0700, Kees Cook wrote: > > > In preparation for FORTIFY_SOURCE performing compile-time and run-time > > > field bounds checking for memset(), avoid intentionally writing across > > > neighboring fields. > > > > > > Add struct_group() to mark region of struct mlx5_ib_mr that should be > > > initialized to zero. > > > > > > Cc: Leon Romanovsky <leon@kernel.org> > > > Cc: Doug Ledford <dledford@redhat.com> > > > Cc: Jason Gunthorpe <jgg@ziepe.ca> > > > Cc: linux-rdma@vger.kernel.org > > > Signed-off-by: Kees Cook <keescook@chromium.org> > > > drivers/infiniband/hw/mlx5/mlx5_ib.h | 4 +++- > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h b/drivers/infiniband/hw/mlx5/mlx5_ib.h > > > index bf20a388eabe..f63bf204a7a1 100644 > > > +++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h > > > @@ -644,6 +644,7 @@ struct mlx5_ib_mr { > > > struct ib_umem *umem; > > > > > > /* This is zero'd when the MR is allocated */ > > > + struct_group(cleared, > > > union { > > > /* Used only while the MR is in the cache */ > > > struct { > > > @@ -691,12 +692,13 @@ struct mlx5_ib_mr { > > > bool is_odp_implicit; > > > }; > > > }; > > > + ); > > > }; > > > > > > /* Zero the fields in the mr that are variant depending on usage */ > > > static inline void mlx5_clear_mr(struct mlx5_ib_mr *mr) > > > { > > > - memset(mr->out, 0, sizeof(*mr) - offsetof(struct mlx5_ib_mr, out)); > > > + memset(&mr->cleared, 0, sizeof(mr->cleared)); > > > } > > > > Why not use the memset_after(mr->umem) here? > > I can certainly do that instead. In this series I've tended to opt > for groupings so the position of future struct member additions are > explicitly chosen. (i.e. reducing the chance that a zeroing of the new > member be a surprise.) I saw the earlier RDMA patches where using other memset techniques though? Were there flex arrays or something that made groups infeasible? Jason
On Thu, Aug 19, 2021 at 01:47:57PM -0300, Jason Gunthorpe wrote: > On Thu, Aug 19, 2021 at 09:19:08AM -0700, Kees Cook wrote: > > On Thu, Aug 19, 2021 at 09:27:16AM -0300, Jason Gunthorpe wrote: > > > On Tue, Aug 17, 2021 at 11:05:26PM -0700, Kees Cook wrote: > > > > In preparation for FORTIFY_SOURCE performing compile-time and run-time > > > > field bounds checking for memset(), avoid intentionally writing across > > > > neighboring fields. > > > > > > > > Add struct_group() to mark region of struct mlx5_ib_mr that should be > > > > initialized to zero. > > > > > > > > Cc: Leon Romanovsky <leon@kernel.org> > > > > Cc: Doug Ledford <dledford@redhat.com> > > > > Cc: Jason Gunthorpe <jgg@ziepe.ca> > > > > Cc: linux-rdma@vger.kernel.org > > > > Signed-off-by: Kees Cook <keescook@chromium.org> > > > > drivers/infiniband/hw/mlx5/mlx5_ib.h | 4 +++- > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h b/drivers/infiniband/hw/mlx5/mlx5_ib.h > > > > index bf20a388eabe..f63bf204a7a1 100644 > > > > +++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h > > > > @@ -644,6 +644,7 @@ struct mlx5_ib_mr { > > > > struct ib_umem *umem; > > > > > > > > /* This is zero'd when the MR is allocated */ > > > > + struct_group(cleared, > > > > union { > > > > /* Used only while the MR is in the cache */ > > > > struct { > > > > @@ -691,12 +692,13 @@ struct mlx5_ib_mr { > > > > bool is_odp_implicit; > > > > }; > > > > }; > > > > + ); > > > > }; > > > > > > > > /* Zero the fields in the mr that are variant depending on usage */ > > > > static inline void mlx5_clear_mr(struct mlx5_ib_mr *mr) > > > > { > > > > - memset(mr->out, 0, sizeof(*mr) - offsetof(struct mlx5_ib_mr, out)); > > > > + memset(&mr->cleared, 0, sizeof(mr->cleared)); > > > > } > > > > > > Why not use the memset_after(mr->umem) here? > > > > I can certainly do that instead. In this series I've tended to opt > > for groupings so the position of future struct member additions are > > explicitly chosen. (i.e. reducing the chance that a zeroing of the new > > member be a surprise.) > > I saw the earlier RDMA patches where using other memset techniques > though? Were there flex arrays or something that made groups infeasible? Which do you mean? When doing the conversions I tended to opt for struct_group() since it provides more robust "intentionality". Strictly speaking, the new memset helpers are doing field-spanning writes, but the "clear to the end" pattern was so common it made sense to add the helpers, as they're a bit less disruptive. It's totally up to you! :)
On Thu, Aug 19, 2021 at 11:14:37AM -0700, Kees Cook wrote: > Which do you mean? When doing the conversions I tended to opt for > struct_group() since it provides more robust "intentionality". Strictly > speaking, the new memset helpers are doing field-spanning writes, but the > "clear to the end" pattern was so common it made sense to add the helpers, > as they're a bit less disruptive. It's totally up to you! :) Well, of the patches you cc'd to me only this one used the struct group.. Jason
On Fri, Aug 20, 2021 at 09:34:00AM -0300, Jason Gunthorpe wrote: > On Thu, Aug 19, 2021 at 11:14:37AM -0700, Kees Cook wrote: > > > Which do you mean? When doing the conversions I tended to opt for > > struct_group() since it provides more robust "intentionality". Strictly > > speaking, the new memset helpers are doing field-spanning writes, but the > > "clear to the end" pattern was so common it made sense to add the helpers, > > as they're a bit less disruptive. It's totally up to you! :) > > Well, of the patches you cc'd to me only this one used the struct > group.. Understood. I've adjusted this for v3. Thanks!
diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h b/drivers/infiniband/hw/mlx5/mlx5_ib.h index bf20a388eabe..f63bf204a7a1 100644 --- a/drivers/infiniband/hw/mlx5/mlx5_ib.h +++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h @@ -644,6 +644,7 @@ struct mlx5_ib_mr { struct ib_umem *umem; /* This is zero'd when the MR is allocated */ + struct_group(cleared, union { /* Used only while the MR is in the cache */ struct { @@ -691,12 +692,13 @@ struct mlx5_ib_mr { bool is_odp_implicit; }; }; + ); }; /* Zero the fields in the mr that are variant depending on usage */ static inline void mlx5_clear_mr(struct mlx5_ib_mr *mr) { - memset(mr->out, 0, sizeof(*mr) - offsetof(struct mlx5_ib_mr, out)); + memset(&mr->cleared, 0, sizeof(mr->cleared)); } static inline bool is_odp_mr(struct mlx5_ib_mr *mr)
In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memset(), avoid intentionally writing across neighboring fields. Add struct_group() to mark region of struct mlx5_ib_mr that should be initialized to zero. Cc: Leon Romanovsky <leon@kernel.org> Cc: Doug Ledford <dledford@redhat.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: linux-rdma@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> --- drivers/infiniband/hw/mlx5/mlx5_ib.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)