All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] x86: Disable kernel stack offset randomization for !TSC
Date: Mon, 9 Jan 2023 11:40:40 +0100	[thread overview]
Message-ID: <Y7vvKHYXpe7KmwCI@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2301082113350.65308@angie.orcam.me.uk>


* Maciej W. Rozycki <macro@orcam.me.uk> wrote:

> For x86 kernel stack offset randomization uses the RDTSC instruction, 
> which causes an invalid opcode exception with hardware that does not 
> implement this instruction:

> @@ -85,7 +86,8 @@ static inline void arch_exit_to_user_mod
>  	 * Therefore, final stack offset entropy will be 5 (x86_64) or
>  	 * 6 (ia32) bits.
>  	 */
> -	choose_random_kstack_offset(rdtsc() & 0xFF);
> +	if (cpu_feature_enabled(X86_FEATURE_TSC))
> +		choose_random_kstack_offset(rdtsc() & 0xFF);
>  }

While this is an obscure corner case, falling back to 0 offset silently 
feels a bit wrong - could we at least attempt to generate some 
unpredictability in this case?

It's not genuine entropy, but we could pass in a value that varies from 
task to task and which is not an 'obviously known' constant value like the 
0 fallback?

For example the lowest 8 bits of the virtual page number of the current 
task plus the lowest 8 bits of jiffies should vary from task to task, has 
some time dependence and is cheap to compute:

	(((unsigned long)current >> 12) + jiffies) & 0xFF

This combined with the per-CPU forward storage of previous offsets:

#define choose_random_kstack_offset(rand) do {                          \
        if (static_branch_maybe(CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT, \
                                &randomize_kstack_offset)) {            \
                u32 offset = raw_cpu_read(kstack_offset);               \
                offset ^= (rand);                                       \
                raw_cpu_write(kstack_offset, offset);                   \
        }                                                               \

Should make this reasonably hard to guess for long-running tasks even if 
there's no TSC - and make it hard to guess even for tasks whose creation an 
attacker controls, unless there's an info-leak to rely on.

Thanks,

	Ingo

  reply	other threads:[~2023-01-09 10:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-08 21:26 [PATCH v2] x86: Disable kernel stack offset randomization for !TSC Maciej W. Rozycki
2023-01-09 10:40 ` Ingo Molnar [this message]
2023-01-09 22:53   ` Maciej W. Rozycki
2023-01-10 10:47     ` Ingo Molnar
2023-01-10 13:56       ` David Laight
2023-01-10 15:19 ` Jason A. Donenfeld
2023-01-12  1:34   ` Maciej W. Rozycki
2023-01-12  1:53     ` H. Peter Anvin
2023-01-12 11:30       ` Borislav Petkov
2023-01-12 11:58         ` Maciej W. Rozycki
2023-01-30 20:43       ` Maciej W. Rozycki
2023-01-13 15:33     ` Jason A. Donenfeld
2023-01-30 20:43       ` Maciej W. Rozycki

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=Y7vvKHYXpe7KmwCI@gmail.com \
    --to=mingo@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@orcam.me.uk \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@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.