To work around a misbehavior of the compiler's ability to see into
composite flexible array structs (as detailed in the coming memcpy()
hardening series[1]), split the memcpy() of the header and the payload
so no false positive run-time overflow warning will be generated. As it
turns out, this appears to actually reduce the text size:
$ size drivers/hv/vmbus_drv.o.before drivers/hv/vmbus_drv.o
text data bss dec hex filename
22968 5239 232 28439 6f17 drivers/hv/vmbus_drv.o.before
23032 5239 232 28503 6f57 drivers/hv/vmbus_drv.o
[1] https://lore.kernel.org/linux-hardening/[email protected]/
Cc: "K. Y. Srinivasan" <[email protected]>
Cc: Haiyang Zhang <[email protected]>
Cc: Stephen Hemminger <[email protected]>
Cc: Wei Liu <[email protected]>
Cc: Dexuan Cui <[email protected]>
Cc: [email protected]
Reported-by: Nathan Chancellor <[email protected]>
Reported-by: "Gustavo A. R. Silva" <[email protected]>
Signed-off-by: Kees Cook <[email protected]>
---
drivers/hv/vmbus_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 23c680d1a0f5..9b111a8262e3 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1131,7 +1131,8 @@ void vmbus_on_msg_dpc(unsigned long data)
return;
INIT_WORK(&ctx->work, vmbus_onmessage_work);
- memcpy(&ctx->msg, &msg_copy, sizeof(msg->header) + payload_size);
+ ctx->msg.header = msg_copy.header;
+ memcpy(&ctx->msg.payload, msg_copy.u.payload, payload_size);
/*
* The host can generate a rescind message while we
--
2.34.1
On Fri, Sep 23, 2022 at 08:07:41PM -0700, Kees Cook wrote:
> To work around a misbehavior of the compiler's ability to see into
> composite flexible array structs (as detailed in the coming memcpy()
> hardening series[1]), split the memcpy() of the header and the payload
> so no false positive run-time overflow warning will be generated. As it
> turns out, this appears to actually reduce the text size:
>
> $ size drivers/hv/vmbus_drv.o.before drivers/hv/vmbus_drv.o
> text data bss dec hex filename
> 22968 5239 232 28439 6f17 drivers/hv/vmbus_drv.o.before
> 23032 5239 232 28503 6f57 drivers/hv/vmbus_drv.o
>
> [1] https://lore.kernel.org/linux-hardening/[email protected]/
>
> Cc: "K. Y. Srinivasan" <[email protected]>
> Cc: Haiyang Zhang <[email protected]>
> Cc: Stephen Hemminger <[email protected]>
> Cc: Wei Liu <[email protected]>
> Cc: Dexuan Cui <[email protected]>
> Cc: [email protected]
> Reported-by: Nathan Chancellor <[email protected]>
> Reported-by: "Gustavo A. R. Silva" <[email protected]>
> Signed-off-by: Kees Cook <[email protected]>
Reviewed-by: Gustavo A. R. Silva <[email protected]>
Thanks!
--
Gustavo
> ---
> drivers/hv/vmbus_drv.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index 23c680d1a0f5..9b111a8262e3 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -1131,7 +1131,8 @@ void vmbus_on_msg_dpc(unsigned long data)
> return;
>
> INIT_WORK(&ctx->work, vmbus_onmessage_work);
> - memcpy(&ctx->msg, &msg_copy, sizeof(msg->header) + payload_size);
> + ctx->msg.header = msg_copy.header;
> + memcpy(&ctx->msg.payload, msg_copy.u.payload, payload_size);
>
> /*
> * The host can generate a rescind message while we
> --
> 2.34.1
>
On Fri, Sep 23, 2022 at 10:42:38PM -0500, Gustavo A. R. Silva wrote:
> On Fri, Sep 23, 2022 at 08:07:41PM -0700, Kees Cook wrote:
> > To work around a misbehavior of the compiler's ability to see into
> > composite flexible array structs (as detailed in the coming memcpy()
> > hardening series[1]), split the memcpy() of the header and the payload
> > so no false positive run-time overflow warning will be generated. As it
> > turns out, this appears to actually reduce the text size:
Er, actually, I can't read/math. ;) It _does_ grow the text size. (That's
2_3_ not 22 at the start of the text size...) On examination, it appears
to unroll the already inlined memcpy further.
> >
> > $ size drivers/hv/vmbus_drv.o.before drivers/hv/vmbus_drv.o
> > text data bss dec hex filename
> > 22968 5239 232 28439 6f17 drivers/hv/vmbus_drv.o.before
> > 23032 5239 232 28503 6f57 drivers/hv/vmbus_drv.o
^
-Kees
--
Kees Cook
Hi Kees
On Fri, Sep 23, 2022 at 09:22:55PM -0700, Kees Cook wrote:
> On Fri, Sep 23, 2022 at 10:42:38PM -0500, Gustavo A. R. Silva wrote:
> > On Fri, Sep 23, 2022 at 08:07:41PM -0700, Kees Cook wrote:
> > > To work around a misbehavior of the compiler's ability to see into
> > > composite flexible array structs (as detailed in the coming memcpy()
> > > hardening series[1]), split the memcpy() of the header and the payload
> > > so no false positive run-time overflow warning will be generated. As it
> > > turns out, this appears to actually reduce the text size:
>
> Er, actually, I can't read/math. ;) It _does_ grow the text size. (That's
> 2_3_ not 22 at the start of the text size...) On examination, it appears
> to unroll the already inlined memcpy further.
Can you provide an updated commit message? No need to resend.
Thanks,
Wei.
>
> > >
> > > $ size drivers/hv/vmbus_drv.o.before drivers/hv/vmbus_drv.o
> > > text data bss dec hex filename
> > > 22968 5239 232 28439 6f17 drivers/hv/vmbus_drv.o.before
> > > 23032 5239 232 28503 6f57 drivers/hv/vmbus_drv.o
> ^
>
> -Kees
>
> --
> Kees Cook
On Fri, Sep 23, 2022 at 08:07:41PM -0700, Kees Cook wrote:
> To work around a misbehavior of the compiler's ability to see into
> composite flexible array structs (as detailed in the coming memcpy()
> hardening series[1]), split the memcpy() of the header and the payload
> so no false positive run-time overflow warning will be generated. As it
> turns out, this appears to actually reduce the text size:
>
> $ size drivers/hv/vmbus_drv.o.before drivers/hv/vmbus_drv.o
> text data bss dec hex filename
> 22968 5239 232 28439 6f17 drivers/hv/vmbus_drv.o.before
> 23032 5239 232 28503 6f57 drivers/hv/vmbus_drv.o
>
> [1] https://lore.kernel.org/linux-hardening/[email protected]/
>
> Cc: "K. Y. Srinivasan" <[email protected]>
> Cc: Haiyang Zhang <[email protected]>
> Cc: Stephen Hemminger <[email protected]>
> Cc: Wei Liu <[email protected]>
> Cc: Dexuan Cui <[email protected]>
> Cc: [email protected]
> Reported-by: Nathan Chancellor <[email protected]>
> Reported-by: "Gustavo A. R. Silva" <[email protected]>
> Signed-off-by: Kees Cook <[email protected]>
I was waiting for another -next update to test this in WSL2; now that
said update has happened, I can see that this does resolve the runtime
warning that I saw.
Tested-by: Nathan Chancellor <[email protected]>
> ---
> drivers/hv/vmbus_drv.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index 23c680d1a0f5..9b111a8262e3 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -1131,7 +1131,8 @@ void vmbus_on_msg_dpc(unsigned long data)
> return;
>
> INIT_WORK(&ctx->work, vmbus_onmessage_work);
> - memcpy(&ctx->msg, &msg_copy, sizeof(msg->header) + payload_size);
> + ctx->msg.header = msg_copy.header;
> + memcpy(&ctx->msg.payload, msg_copy.u.payload, payload_size);
>
> /*
> * The host can generate a rescind message while we
> --
> 2.34.1
>
>
On Sat, Sep 24, 2022 at 10:34:12AM +0000, Wei Liu wrote:
> Hi Kees
>
> On Fri, Sep 23, 2022 at 09:22:55PM -0700, Kees Cook wrote:
> > On Fri, Sep 23, 2022 at 10:42:38PM -0500, Gustavo A. R. Silva wrote:
> > > On Fri, Sep 23, 2022 at 08:07:41PM -0700, Kees Cook wrote:
> > > > To work around a misbehavior of the compiler's ability to see into
> > > > composite flexible array structs (as detailed in the coming memcpy()
> > > > hardening series[1]), split the memcpy() of the header and the payload
> > > > so no false positive run-time overflow warning will be generated. As it
> > > > turns out, this appears to actually reduce the text size:
> >
> > Er, actually, I can't read/math. ;) It _does_ grow the text size. (That's
> > 2_3_ not 22 at the start of the text size...) On examination, it appears
> > to unroll the already inlined memcpy further.
>
> Can you provide an updated commit message? No need to resend.
Since I got more testing from Nathan (and the original warning message),
I figured a full v2 respin would easier. Now sent. :) Thanks!
-Kees
--
Kees Cook