All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <kees@kernel.org>
To: Alexandre Ghiti <alex@ghiti.fr>
Cc: "Jessica Clarke" <jrtc27@jrtc27.com>,
	"Alexandre Ghiti" <alexghiti@rivosinc.com>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Björn Töpel" <bjorn@rivosinc.com>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	"Jason Montleon" <jmontleo@redhat.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH -fixes] riscv: Do not use fortify in early code
Date: Wed, 16 Oct 2024 09:56:30 -0700	[thread overview]
Message-ID: <202410160951.E825F7A5@keescook> (raw)
In-Reply-To: <3fe1e610-c863-4fbf-85cb-6e83ba7684af@ghiti.fr>

On Wed, Oct 16, 2024 at 01:26:24PM +0200, Alexandre Ghiti wrote:
> On 16/10/2024 00:04, Jessica Clarke wrote:
> > Is the problem in [1] not just that the early boot path uses memcpy on
> > the result of ALT_OLD_PTR, which is a wildly out-of-bounds pointer from
> > the compiler’s perspective? If so, it would seem better to use
> > unsafe_memcpy for that one call site rather than use the big
> > __NO_FORTIFY hammer, surely?
> 
> Not sure why fortify complains here, and I have just seen that I forgot to
> cc Kees (done now).

I haven't had time to investigate this -- something is confusing the
compiler about the object size. It's likely that it has decided that
"char *" is literally pointing to a single byte. (Instead of being
unable to determine the origin of the pointer and being forced to return
SIZE_MAX for the object size -- "unknown" size.) In other cases, we've
been able to convert "char *ptr" to "char ptr[]" and that tells the
compiler it's an array of unknown size. That didn't look very possible
here.

> [...]
> And I believe that enabling fortify and using the unsafe_*() variants is
> error-prone since we'd have to make sure that all the "fortified" functions
> used in that code use the unsafe_*() variants.
> 
> So to me, it's way easier in terms of maintenance to just disabling fortify.

I would agree: there's no way to report a fortify failure, so best to
turn it off here.

-- 
Kees Cook

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <kees@kernel.org>
To: Alexandre Ghiti <alex@ghiti.fr>
Cc: "Jessica Clarke" <jrtc27@jrtc27.com>,
	"Alexandre Ghiti" <alexghiti@rivosinc.com>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Björn Töpel" <bjorn@rivosinc.com>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	"Jason Montleon" <jmontleo@redhat.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH -fixes] riscv: Do not use fortify in early code
Date: Wed, 16 Oct 2024 09:56:30 -0700	[thread overview]
Message-ID: <202410160951.E825F7A5@keescook> (raw)
In-Reply-To: <3fe1e610-c863-4fbf-85cb-6e83ba7684af@ghiti.fr>

On Wed, Oct 16, 2024 at 01:26:24PM +0200, Alexandre Ghiti wrote:
> On 16/10/2024 00:04, Jessica Clarke wrote:
> > Is the problem in [1] not just that the early boot path uses memcpy on
> > the result of ALT_OLD_PTR, which is a wildly out-of-bounds pointer from
> > the compiler’s perspective? If so, it would seem better to use
> > unsafe_memcpy for that one call site rather than use the big
> > __NO_FORTIFY hammer, surely?
> 
> Not sure why fortify complains here, and I have just seen that I forgot to
> cc Kees (done now).

I haven't had time to investigate this -- something is confusing the
compiler about the object size. It's likely that it has decided that
"char *" is literally pointing to a single byte. (Instead of being
unable to determine the origin of the pointer and being forced to return
SIZE_MAX for the object size -- "unknown" size.) In other cases, we've
been able to convert "char *ptr" to "char ptr[]" and that tells the
compiler it's an array of unknown size. That didn't look very possible
here.

> [...]
> And I believe that enabling fortify and using the unsafe_*() variants is
> error-prone since we'd have to make sure that all the "fortified" functions
> used in that code use the unsafe_*() variants.
> 
> So to me, it's way easier in terms of maintenance to just disabling fortify.

I would agree: there's no way to report a fortify failure, so best to
turn it off here.

-- 
Kees Cook

  parent reply	other threads:[~2024-10-16 16:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-09  7:27 [PATCH -fixes] riscv: Do not use fortify in early code Alexandre Ghiti
2024-10-09  7:27 ` Alexandre Ghiti
2024-10-15 20:05 ` Felix Yan
2024-10-15 20:05   ` Felix Yan
2024-10-15 22:04 ` Jessica Clarke
2024-10-15 22:04   ` Jessica Clarke
2024-10-16  5:26   ` Jason Montleon
2024-10-16  5:26     ` Jason Montleon
2024-10-16 11:26   ` Alexandre Ghiti
2024-10-16 11:26     ` Alexandre Ghiti
2024-10-16 15:30     ` Jessica Clarke
2024-10-16 15:30       ` Jessica Clarke
2024-10-16 16:56     ` Kees Cook [this message]
2024-10-16 16:56       ` Kees Cook
2024-10-17 16:30 ` patchwork-bot+linux-riscv
2024-10-17 16:30   ` patchwork-bot+linux-riscv

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=202410160951.E825F7A5@keescook \
    --to=kees@kernel.org \
    --cc=alex@ghiti.fr \
    --cc=alexghiti@rivosinc.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=bjorn@rivosinc.com \
    --cc=heiko@sntech.de \
    --cc=jmontleo@redhat.com \
    --cc=jrtc27@jrtc27.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=stable@vger.kernel.org \
    /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.