All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Andy Lutomirski <luto@kernel.org>, X86 ML <x86@kernel.org>
Cc: Borislav Petkov <bpetkov@suse.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Brian Gerst <brgerst@gmail.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [RFC 5/7] x86/asm: Rearrange struct cpu_tss to enlarge SYSENTER_stack and fix alignment
Date: Mon, 13 Nov 2017 11:19:25 -0800	[thread overview]
Message-ID: <cfcd0693-e5ea-ddbe-622a-bde24e58f84a@intel.com> (raw)
In-Reply-To: <2a675c72e35f737156c98ccad5cc3c73c3aa9d72.1510371795.git.luto@kernel.org>

On 11/10/2017 08:05 PM, Andy Lutomirski wrote:
>  struct tss_struct {
>  	/*
> +	 * Space for the temporary SYSENTER stack.  Used for the entry
> +	 * trampoline as well.  Size it such that tss_struct ends up
> +	 * as a multiple of PAGE_SIZE.  This calculation assumes that
> +	 * io_bitmap is a multiple of PAGE_SIZE (8192 bytes) plus one
> +	 * long.
> +	 */
> +	unsigned long		SYSENTER_stack_canary;
> +	unsigned long		SYSENTER_stack[(PAGE_SIZE - sizeof(struct x86_hw_tss)) / sizeof(unsigned long) - 2];
> +
> +	/*
>  	 * The hardware state:
>  	 */
>  	struct x86_hw_tss	x86_tss;
> @@ -337,15 +347,9 @@ struct tss_struct {
>  	 * be within the limit.
>  	 */
>  	unsigned long		io_bitmap[IO_BITMAP_LONGS + 1];
> -
> -	/*
> -	 * Space for the temporary SYSENTER stack.
> -	 */
> -	unsigned long		SYSENTER_stack_canary;
> -	unsigned long		SYSENTER_stack[64];
>  } ____cacheline_aligned;


If io_bitmap[] is already page-size-aligned, how does it help us to move
SYSENTER_stack[]?

It seems like it would be easier to just leave SYSENTER_stack[] where it
is, make it SYSENTER_stack[0], and just find somewhere else to choose
how much to bloat the tss_struct *allocation* instead of trying to make
sure that sizeof(tss_struct) matches the allocation.

That SYSENTER_stack[] size calculation is pretty hideous. :)

  parent reply	other threads:[~2017-11-13 19:19 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-11  4:05 [RFC 0/7] Prep code for better stack switching Andy Lutomirski
2017-11-11  4:05 ` [RFC 1/7] x86/asm/64: Allocate and enable the SYSENTER stack Andy Lutomirski
2017-11-13 19:07   ` Dave Hansen
2017-11-14  2:17     ` Andy Lutomirski
2017-11-14  7:15       ` Ingo Molnar
2017-11-11  4:05 ` [RFC 2/7] x86/gdt: Put per-cpu GDT remaps in ascending order Andy Lutomirski
2017-11-11  4:05 ` [RFC 3/7] x86/fixmap: Generalize the GDT fixmap mechanism Andy Lutomirski
2017-11-11  4:05 ` [RFC 4/7] x86/asm: Fix assumptions that the HW TSS is at the beginning of cpu_tss Andy Lutomirski
2017-11-13 17:01   ` Dave Hansen
2017-11-26 13:48     ` [PATCH v2] x86/entry: " Ingo Molnar
2017-11-26 15:41       ` Andy Lutomirski
2017-11-26 15:58         ` Ingo Molnar
2017-11-26 16:00           ` Ingo Molnar
2017-11-26 16:05             ` Andy Lutomirski
2017-11-26 16:43               ` Ingo Molnar
2017-11-11  4:05 ` [RFC 5/7] x86/asm: Rearrange struct cpu_tss to enlarge SYSENTER_stack and fix alignment Andy Lutomirski
2017-11-11  4:11   ` Andy Lutomirski
2017-11-13 19:19   ` Dave Hansen [this message]
2017-11-11  4:05 ` [RFC 6/7] x86/asm: Remap the TSS into the cpu entry area Andy Lutomirski
2017-11-13 19:22   ` Dave Hansen
2017-11-13 19:36     ` Linus Torvalds
2017-11-14  2:25       ` Andy Lutomirski
2017-11-14  2:28         ` Linus Torvalds
2017-11-14  2:30           ` Andy Lutomirski
2017-11-14  2:27     ` Andy Lutomirski
2017-11-11  4:05 ` [RFC 7/7] x86/unwind/64: Add support for the SYSENTER stack Andy Lutomirski
2017-11-13 22:46   ` Josh Poimboeuf
2017-11-14  2:13     ` Andy Lutomirski
2017-11-11 10:58 ` [RFC 0/7] Prep code for better stack switching Borislav Petkov
2017-11-12  2:59   ` Andy Lutomirski
2017-11-12  4:25     ` Andy Lutomirski
2017-11-13  4:37       ` Andy Lutomirski

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=cfcd0693-e5ea-ddbe-622a-bde24e58f84a@intel.com \
    --to=dave.hansen@intel.com \
    --cc=bpetkov@suse.de \
    --cc=brgerst@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --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.