All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Brian Gerst <brgerst@gmail.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Borislav Petkov" <bp@alien8.de>,
	"Andy Lutomirski" <luto@kernel.org>,
	"Mika Penttilä" <mpenttil@redhat.com>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"Uros Bizjak" <ubizjak@gmail.com>,
	"Denys Vlasenko" <dvlasenk@redhat.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Josh Poimboeuf" <jpoimboe@redhat.com>
Subject: Re: [PATCH v2 0/6] x86: Clean up fast syscall return validation
Date: Sat, 7 Oct 2023 11:42:00 +0200	[thread overview]
Message-ID: <ZSEn6BhETrwmry6D@gmail.com> (raw)
In-Reply-To: <CAMzpN2jdGc1P4Ha_sO5RZv8M9RsHPA+KU3a9c5BdgX5O3D5Jew@mail.gmail.com>


* Brian Gerst <brgerst@gmail.com> wrote:

> On Fri, Oct 6, 2023 at 2:59 PM H. Peter Anvin <hpa@zytor.com> wrote:
> >
> > On 10/5/23 13:20, Ingo Molnar wrote:
> > >
> > > * Brian Gerst <brgerst@gmail.com> wrote:
> > >
> > >> Looking at the compiled output, the only suboptimal code appears to be
> > >> the canonical address test, where the C code uses the CL register for
> > >> the shifts instead of immediates.
> > >>
> > >>   180:   e9 00 00 00 00          jmp    185 <do_syscall_64+0x85>
> > >>                          181: R_X86_64_PC32      .altinstr_aux-0x4
> > >>   185:   b9 07 00 00 00          mov    $0x7,%ecx
> > >>   18a:   eb 05                   jmp    191 <do_syscall_64+0x91>
> > >>   18c:   b9 10 00 00 00          mov    $0x10,%ecx
> > >>   191:   48 89 c2                mov    %rax,%rdx
> > >>   194:   48 d3 e2                shl    %cl,%rdx
> > >>   197:   48 d3 fa                sar    %cl,%rdx
> > >>   19a:   48 39 d0                cmp    %rdx,%rax
> > >>   19d:   75 39                   jne    1d8 <do_syscall_64+0xd8>
> > >
> > > Yeah, it didn't look equivalent - so I guess we want a C equivalent for:
> > >
> > > -       ALTERNATIVE "shl $(64 - 48), %rcx; sar $(64 - 48), %rcx", \
> > > -               "shl $(64 - 57), %rcx; sar $(64 - 57), %rcx", X86_FEATURE_LA57
> > >
> > > instead of the pgtable_l5_enabled() runtime test that
> > > __is_canonical_address() uses?
> > >
> >
> > I don't think such a thing (without simply duplicate the above as an
> > alternative asm, which is obviously easy enough, and still allows the
> > compiler to pick the register used) would be possible without immediate
> > patching support[*].
> >
> > Incidentally, this is a question for Uros: is there a reason this is a
> > mov to %ecx and not just %cl, which would save 3 bytes?
> >
> > Incidentally, it is possible to save one instruction and use only *one*
> > alternative immediate:
> >
> >         leaq (%rax,%rax),%rdx
> >         xorq %rax,%rdx
> >         shrq $(63 - LA),%rdx            # Yes, 63, not 64
> >         # ZF=1 if canonical
> >
> > This works because if bit [x] is set in the output, then bit [x] and
> > [x-1] in the input are different (bit [-1] considered to be zero); and
> > by definition a bit is canonical if and only if all the bits [63:LA] are
> > identical, thus bits [63:LA+1] in the output must all be zero.
> >
> > The first two instructions are pure arithmetic and can thus be done in C:
> >
> >         bar = foo ^ (foo << 1);
> >
> > ... leaving only one instruction needing to be patched at runtime.
> >
> >         -hpa
> 
> One other alternative I have been considering is comparing against
> TASK_SIZE_MAX.  The only user-executable address above that is the
> long deprecated vsyscall page.  IMHO it's not worth optimizing for
> that case, so just let it fall back to using IRET.
> 
>     if (unlikely(regs->ip >= TASK_SIZE_MAX)) return false;
> 
> compiles to:
> 
>  180:   48 b9 00 f0 ff ff ff    movabs $0x7ffffffff000,%rcx
>  187:   7f 00 00
>  18a:   48 39 c8                cmp    %rcx,%rax
>  18d:   73 39                   jae    1c8 <do_syscall_64+0xc8>
> 
> 0000000000000000 <.altinstr_replacement>:
>    0:   48 b9 00 f0 ff ff ff    movabs $0xfffffffffff000,%rcx
>    7:   ff ff 00

That sounds good - and we could do this as a separate patch on top
of your existing  patches, to keep it bisectable in case there's
any problems.

Thanks,

	Ingo

  reply	other threads:[~2023-10-07  9:42 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-21 16:10 [PATCH v2 0/6] x86: Clean up fast syscall return validation Brian Gerst
2023-07-21 16:10 ` [PATCH v2 1/6] x86/entry/64: Remove obsolete comment on tracing vs. SYSRET Brian Gerst
2023-10-05  8:28   ` [tip: x86/entry] " tip-bot2 for Brian Gerst
2023-07-21 16:10 ` [PATCH v2 2/6] x86/entry/64: Convert SYSRET validation tests to C Brian Gerst
2023-07-23  9:53   ` Li, Xin3
2023-07-23 11:17     ` Brian Gerst
2023-07-21 16:10 ` [PATCH v2 3/6] x86/entry/compat: Combine return value test from syscall handler Brian Gerst
2023-10-05  8:28   ` [tip: x86/entry] " tip-bot2 for Brian Gerst
2023-07-21 16:10 ` [PATCH v2 4/6] x86/entry/32: Convert do_fast_syscall_32() to bool return type Brian Gerst
2023-10-05  8:28   ` [tip: x86/entry] " tip-bot2 for Brian Gerst
2023-07-21 16:10 ` [PATCH v2 5/6] x86/entry/32: Remove SEP test for SYSEXIT Brian Gerst
2023-10-05  8:28   ` [tip: x86/entry] " tip-bot2 for Brian Gerst
2023-07-21 16:10 ` [PATCH v2 6/6] x86/entry/32: Clean up syscall fast exit tests Brian Gerst
2023-10-05  8:22 ` [PATCH v2 0/6] x86: Clean up fast syscall return validation Ingo Molnar
2023-10-05 15:13   ` Brian Gerst
2023-10-05 20:20     ` Ingo Molnar
2023-10-06 18:59       ` H. Peter Anvin
2023-10-06 21:32         ` Brian Gerst
2023-10-07  9:42           ` Ingo Molnar [this message]
2023-10-06 23:58         ` H. Peter Anvin
2023-10-07  9:56         ` Uros Bizjak
2023-10-07 18:07           ` Linus Torvalds

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=ZSEn6BhETrwmry6D@gmail.com \
    --to=mingo@kernel.org \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=dvlasenk@redhat.com \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mpenttil@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=ubizjak@gmail.com \
    --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.