All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
	Borislav Petkov <bp@alien8.de>,
	linux-crypto@vger.kernel.org, Mike Galbraith <efault@gmx.de>,
	torvalds@linux-foundation.org, tglx@linutronix.de,
	luto@kernel.org, peterz@infradead.org, brgerst@gmail.com,
	hpa@zytor.com, linux-kernel@vger.kernel.org, dvlasenk@redhat.com,
	h.peter.anvin@intel.com,
	linux-tip-commits <linux-tip-commits@vger.kernel.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [PATCH] x86/crypto: Add missing RETs
Date: Thu, 5 Jul 2018 09:58:15 +0200	[thread overview]
Message-ID: <20180705075815.GA20903@gmail.com> (raw)
In-Reply-To: <20180626123154.unjji5glpokedwal@treble>


* Josh Poimboeuf <jpoimboe@redhat.com> wrote:

> > So that's still incomplete in that doesn't analyze the 32-bit build yet, right?
> 
> We could do INT3s on 64-bit and NOPs on 32-bit.
> 
> Or, possibly even better, we could just keep NOPs everywhere and instead
> make objtool smart enough to detect function fallthroughs.  That should
> be pretty easy, actually.  It already does it for C files.
> 
> Something like the below should work, though it's still got a few
> issues:
> 
>   a) objtool is currently disabled for crypto code because it doesn't
>      yet understand crypto stack re-alignments (which really needs
>      fixing anyway); and
> 
>   b) it complains about the blank xen hypercalls falling through.  Those
>      aren't actual functions anyway, so we should probably annotate
>      those somehow so that objtool ignores them anyway.
> 
> I'm a bit swamped at the moment but I can fix those once I get a little
> more bandwidth.  I at least verified that this patch caught the crypto
> missing RETs.

Great, I'd be perfectly fine with such an approach.

Also, if we have that then we could re-apply Alexey's patch and switch to INT3 
(only on 64-bit kernels) without any trouble, because objtool should detect any 
execution flow bugs before the INT3 could trigger, right?

I.e. any INT3 fault would show a combination of *both* an objtool bug and a 
probable code flow bug - which I suspect would warrant crashing the box ...

Thanks,

	Ingo

  reply	other threads:[~2018-07-05  7:58 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-07 21:37 [PATCH] x86: pad assembly functions with INT3 Alexey Dobriyan
2018-05-07 21:41 ` hpa
2018-05-09 16:55   ` Alexey Dobriyan
2018-05-09 19:28     ` H. Peter Anvin
2018-05-10 16:39 ` David Laight
2018-05-11 18:53   ` H. Peter Anvin
2018-05-14  9:04     ` David Laight
2018-05-14 11:05       ` hpa
2018-05-15  6:54         ` Ingo Molnar
2018-05-15  6:59           ` hpa
2018-05-14 12:53 ` [tip:x86/pti] x86/asm: Pad assembly functions with INT3 instructions tip-bot for Alexey Dobriyan
2018-06-17 11:40   ` Mike Galbraith
2018-06-17 12:00     ` Borislav Petkov
2018-06-17 13:38       ` Mike Galbraith
2018-06-17 14:02         ` Mike Galbraith
2018-06-17 19:47           ` Borislav Petkov
2018-06-18  2:34             ` Mike Galbraith
2018-06-23 10:36               ` [PATCH] x86/crypto: Add missing RETs Borislav Petkov
2018-06-23 17:30                 ` Ondrej Mosnáček
2018-06-24  7:11                 ` Ingo Molnar
2018-06-24  7:12                   ` Thomas Gleixner
2018-06-24 10:15                     ` Borislav Petkov
2018-06-24 10:44                   ` Alexey Dobriyan
2018-06-25  7:24                     ` Ingo Molnar
2018-06-25 13:19                       ` Josh Poimboeuf
2018-06-26  6:49                         ` Ingo Molnar
2018-06-26 12:31                           ` Josh Poimboeuf
2018-07-05  7:58                             ` Ingo Molnar [this message]
2018-07-06 14:06                               ` Josh Poimboeuf
2018-07-06 14:57                                 ` Ingo Molnar
2018-07-01 13:19                 ` Herbert Xu
2018-07-01 15:24                   ` Ondrej Mosnáček
2018-07-01 15:45                     ` Herbert Xu
2018-06-19 11:27         ` [tip:x86/pti] x86/asm: Pad assembly functions with INT3 instructions 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=20180705075815.GA20903@gmail.com \
    --to=mingo@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=adobriyan@gmail.com \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=dvlasenk@redhat.com \
    --cc=efault@gmx.de \
    --cc=h.peter.anvin@intel.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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.