linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
	linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org
Subject: Re: stackinit unit test failures on m68k
Date: Tue, 27 Feb 2024 14:25:33 -0800	[thread overview]
Message-ID: <202402271423.270DBF1@keescook> (raw)
In-Reply-To: <202402271401.CB43AB2E8@keescook>

On Tue, Feb 27, 2024 at 02:19:07PM -0800, Kees Cook wrote:
> It is basically doing this:
> 
> static void *fill_start, *target_start;
> static size_t fill_size, target_size;
> 
> static noinline int leaf_char_array_none(unsigned long sp, bool fill,
>                                   unsigned char *arg)
> {
>         char buf[32];
>         unsigned char var[16];
> 
>         target_start = &var;
>         target_size = sizeof(var);
>         /*
>          * Keep this buffer around to make sure we've got a
>          * stack frame of SOME kind...
>          */
>         memset(buf, (char)(sp & 0xff), sizeof(buf));
>         /* Fill variable with 0xFF. */
>         if (fill) {
>                 fill_start = &var;
>                 fill_size = sizeof(var);
>                 memset(fill_start,
>                        (char)((sp & 0xff) | forced_mask),
>                        fill_size);
>         }
> 
>         /* Silence "never initialized" warnings. */
> 	do_nothing_char_array(var);
> 
>         /* Exfiltrate "var". */
>         memcpy(check_buf, target_start, target_size);
> 
>         return (int)buf[0] | (int)buf[sizeof(buf) - 1];
> }
> 
> and it's called as:
> 
> 
>         ignored = leaf_char_array_none((unsigned long)&ignored, 1, zero);
> 	...
>         ignored = leaf_char_array_none((unsigned long)&ignored, 0, zero);
> 
> The first call remembers where "var" is in the stack frame via the
> fill_start assignment, and the second call records where "var" is via
> the target_start assignment.
> 
> The complaint is that it _changes_ between the two calls. ... Oh, I
> think I see what's happened. Between the two calls, the stack grows (and
> is for some reason not reclaimed) due to the KUNIT checks between the two
> leaf calls. Yes, moving that fixes it.
> 
> I'll send a patch!

Oh, no, that wasn't it. Something else is happening. The stack pointer
isn't moving between them. Is there anything special about character
arrays on m68k?

-- 
Kees Cook

  reply	other threads:[~2024-02-27 22:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-11 23:06 stackinit unit test failures on m68k Guenter Roeck
2024-02-12  8:34 ` Geert Uytterhoeven
2024-02-27 22:19   ` Kees Cook
2024-02-27 22:25     ` Kees Cook [this message]
2024-02-27 22:52       ` Andreas Schwab
2024-02-27 22:33     ` Finn Thain
2024-02-27 22:54       ` Guenter Roeck
2024-02-29 22:34     ` David Laight

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=202402271423.270DBF1@keescook \
    --to=keescook@chromium.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux@roeck-us.net \
    /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;
as well as URLs for NNTP newsgroup(s).