Linux Hardening
 help / color / mirror / Atom feed
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
To: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Kees Cook <keescook@chromium.org>,
	Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
	linux-hardening@vger.kernel.org, error27@gmail.com,
	gustavoars@kernel.org, Bryan Tan <bryantan@vmware.com>,
	Vishnu Dasa <vdasa@vmware.com>,
	VMware PV-Drivers Reviewers <pv-drivers@vmware.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, vegard.nossum@oracle.com,
	darren.kenny@oracle.com, syzkaller <syzkaller@googlegroups.com>
Subject: Re: [PATCH v2 2/2] VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host()
Date: Tue, 9 Jan 2024 08:35:37 -0600	[thread overview]
Message-ID: <4603630c-3bb2-42b6-b0dd-79d500460ab4@embeddedor.com> (raw)
In-Reply-To: <36aecc9a-ac30-436f-b42b-39f63513d743@moroto.mountain>



On 1/9/24 07:22, Dan Carpenter wrote:
> On Tue, Jan 09, 2024 at 06:31:41AM -0600, Gustavo A. R. Silva wrote:
>>
>> You're arguing that fortify caused a problem.
> 
> Yes.
> 
> Before: Code working correctly
> After: Kernel Panic
> 
> At first, I started to question if I was going mad, but then I looked
> through the email thread and Harshit tested it and proved that the
> kernel does actually panic depending on the .config.
> 
> I mean realistically we should backport this patch to old kernels,
> right?  And if we had to assign a Fixes tag to this it would need to be
> the commit which adds Fortify to the kernel.  Prior to that commit the
> code was fine.
> 
> Again, I'm not saying that Fortify is bad overall.  Probably in DnD it
> would be Chaotic Good where it's overall good but sometimes a pain.
> 

You know what, I think the discrepancy here lies in the fact that, before,
fortify didn't complain about writes across multiple members in the same
struct, as long as we remained between the boundaries of the struct. This
was done via __builtin_object_size(p, 0).

In recent times, that has changed, and now fortify has been tightened to warn
about writes beyond the boundaries of a single object. This is now done via
__builtin_dynamic_object_size(p, 1)/__builtin_object_size(p, 1).

And, if this patch is to be backported, _technically_, the Fixes tag should
probably be assigned to that change from __bos(p, 0) to __bos(p, 1):

commit f68f2ff91512 ("fortify: Detect struct member overflows in memcpy() at compile-time")

In any case, fortify should now emit this sort of warning, and that adds
an extra layer of hardening to the kernel.

Thanks
--
Gustavo

  reply	other threads:[~2024-01-09 14:35 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-05 16:39 [PATCH v2 1/2] VMCI: Use struct_size() in kmalloc() Harshit Mogalapalli
2024-01-05 16:40 ` [PATCH v2 2/2] VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host() Harshit Mogalapalli
2024-01-05 17:11   ` Gustavo A. R. Silva
2024-01-08  7:33   ` Dan Carpenter
2024-01-08 17:03     ` Gustavo A. R. Silva
2024-01-08 17:31       ` Harshit Mogalapalli
2024-01-08 17:38         ` Gustavo A. R. Silva
2024-01-08 18:36       ` Dan Carpenter
2024-01-08 19:21         ` Gustavo A. R. Silva
2024-01-08 22:37   ` Kees Cook
2024-01-09  2:05     ` Gustavo A. R. Silva
2024-01-09  9:07       ` Dan Carpenter
2024-01-09 12:31         ` Gustavo A. R. Silva
2024-01-09 13:22           ` Dan Carpenter
2024-01-09 14:35             ` Gustavo A. R. Silva [this message]
2024-01-11  0:03       ` Kees Cook
2024-01-11  7:15         ` Dan Carpenter
2024-01-11 18:13           ` Kees Cook
2024-01-12  5:35             ` Dan Carpenter
2024-01-11 12:53   ` kovalev
2024-02-16  7:35     ` Harshit Mogalapalli
2024-01-05 16:57 ` [PATCH v2 1/2] VMCI: Use struct_size() in kmalloc() Gustavo A. R. Silva
2024-01-08 22:28 ` Kees Cook
2024-02-01 18:06 ` Kees Cook

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=4603630c-3bb2-42b6-b0dd-79d500460ab4@embeddedor.com \
    --to=gustavo@embeddedor.com \
    --cc=arnd@arndb.de \
    --cc=bryantan@vmware.com \
    --cc=dan.carpenter@linaro.org \
    --cc=darren.kenny@oracle.com \
    --cc=error27@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=gustavoars@kernel.org \
    --cc=harshit.m.mogalapalli@oracle.com \
    --cc=keescook@chromium.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pv-drivers@vmware.com \
    --cc=syzkaller@googlegroups.com \
    --cc=vdasa@vmware.com \
    --cc=vegard.nossum@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox