linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: hpa@zytor.com
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Alistair Strachan <astrachan@google.com>,
	Manoj Gupta <manojgupta@google.com>,
	Matthias Kaehlcke <mka@google.com>,
	Greg Hackmann <ghackmann@google.com>,
	sedat.dilek@gmail.com, tstellar@redhat.com,
	LKML <linux-kernel@vger.kernel.org>,
	Kees Cook <keescook@google.com>
Subject: Re: [clang] stack protector and f1f029c7bf
Date: Fri, 25 May 2018 09:34:12 -0700	[thread overview]
Message-ID: <E6A629A5-CBDF-4301-B10C-A60E1556027A@zytor.com> (raw)
In-Reply-To: <CAKwvOdk_4g5PsRUoLgOeWEwt+d0diyD_Ycx6s7LQsJrSMsBEuA@mail.gmail.com>

On May 25, 2018 9:27:40 AM PDT, Nick Desaulniers <ndesaulniers@google.com> wrote:
>On Thu, May 24, 2018 at 3:43 PM <hpa@zytor.com> wrote:
>> On May 24, 2018 3:31:05 PM PDT, Nick Desaulniers
><ndesaulniers@google.com>
>wrote:
>> >On Thu, May 24, 2018 at 3:05 PM H. Peter Anvin <hpa@zytor.com>
>wrote:
>> >> COMPILER AR: "=rm" should NEVER generate worse code than "=r".
>That
>> >is
>> >> unequivocally a compiler bug.
>> >
>> >Filed: https://bugs.llvm.org/show_bug.cgi?id=37583
>> >
>> >> >> You are claiming it doesn't buy us anything, but you are only
>> >looking
>> >at
>> >> > the paravirt case which is kind of "special" (in the short bus
>kind
>> >of
>> >way),
>> >> >
>> >> > That's fair.  Is another possible solution to have paravirt
>maybe
>> >not
>> >use
>> >> > native_save_fl() then, but its own
>> >non-static-inline-without-m-constraint
>> >> > implementation?
>> >
>> >> KERNEL AR: change native_save_fl() to an extern inline with an
>> >assembly
>> >> out-of-line implementation, to satisfy the paravirt requirement
>that
>> >no
>> >> GPRs other than %rax are clobbered.
>> >
>> >i'm happy to add that, do you have a recommendation if it should go
>in
>> >an
>> >existing .S file or a new one (and if so where/what shall I call
>it?).
>
>> How about irqflags.c since that is what the .h file is called.
>
>> It should simply be:
>
>> push %rdi
>> popf
>> ret
>
>> pushf
>> pop %rax
>> ret
>
>> ... but with all the regular assembly decorations, of course.
>
>Something like the following?
>
>
>diff --git a/arch/x86/kernel/irqflags.c b/arch/x86/kernel/irqflags.c
>new file mode 100644
>index 000000000000..59dc21bd3327
>--- /dev/null
>+++ b/arch/x86/kernel/irqflags.c
>@@ -0,0 +1,24 @@
>+#include <asm/asm.h>
>+
>+extern unsigned long native_save_fl(void);
>+extern void native_restore_fl(unsigned long flags);
>+
>+asm(
>+".pushsection .text;"
>+".global native_save_fl;"
>+".type native_save_fl, @function;"
>+"native_save_fl:"
>+"pushf;"
>+"pop %" _ASM_AX ";"
>+"ret;"
>+".popsection");
>+
>+asm(
>+".pushsection .text;"
>+".global native_restore_fl;"
>+".type native_restore_fl, @function;"
>+"native_restore_fl:"
>+"push %" _ASM_DI ";"
>+"popf;"
>+"ret;"
>+".popsection");
>
>And change the declaration in arch/x86/include/asm/irqflags.h to:
>+extern inline unsigned long native_save_fl(void);
>+extern inline void native_restore_fl(unsigned long flags);
>
>This seems to work, but
>1. arch/x86/boot/compressed/misc.o warns that native_save_fl() is never
>defined (arch_local_save_flags() uses it).  Does that mean
>arch_local_save_flags(), and friends would also have to move to the
>newly
>created .c file as well?
>2. `extern inline` doesn't inline any instances (from what I can tell
>from
>disassembling vmlinux).  I think this is strictly worse. Don't we only
>want
>pv_irq_ops.save_fl to be non-inlined in a way that no stack protector
>can
>be added? If that's the case, should my assembly based implementation
>have
>a different identifier (`native_save_fl_paravirt` or something). That
>would
>also fix point #1 above. But now the paravirt code has its own copy of
>the
>function.

You keep compiling with paravirtualization enabled... that code will not do any inlining.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

  parent reply	other threads:[~2018-05-25 16:34 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-23 22:08 [clang] stack protector and f1f029c7bf Nick Desaulniers
2018-05-24 10:33 ` Sedat Dilek
2018-05-24 18:12   ` Nick Desaulniers
2018-05-24 18:19 ` hpa
2018-05-24 18:24   ` Nick Desaulniers
2018-05-24 18:48     ` Alistair Strachan
2018-05-24 19:49   ` Tom Stellard
2018-05-24 21:33     ` hpa
2018-05-24 18:59 ` hpa
2018-05-24 20:26   ` Nick Desaulniers
2018-05-24 20:52     ` Nick Desaulniers
2018-05-24 21:12       ` Nick Desaulniers
2018-05-24 21:27         ` Nick Desaulniers
2018-05-24 21:56           ` H. Peter Anvin
2018-05-24 21:49         ` H. Peter Anvin
2018-05-24 21:38       ` hpa
2018-05-24 22:05     ` H. Peter Anvin
2018-05-24 22:31       ` Nick Desaulniers
2018-05-24 22:43         ` hpa
2018-05-25 16:27           ` Nick Desaulniers
2018-05-25 16:32             ` hpa
2018-05-25 16:46               ` Nick Desaulniers
2018-05-25 16:53                 ` hpa
2018-05-25 17:31                   ` Nick Desaulniers
2018-05-25 17:35                     ` Tom Stellard
2018-05-25 17:49                       ` Nick Desaulniers
2018-05-25 17:57                         ` hpa
2018-05-25 17:59                         ` Nick Desaulniers
2018-05-25 17:56                     ` hpa
2018-05-25 20:36                       ` Nick Desaulniers
2018-05-25 21:06                         ` H. Peter Anvin
2018-05-25 22:38                           ` Nick Desaulniers
2018-05-31  6:50                             ` Nick Desaulniers
2018-06-01 17:13                               ` Nick Desaulniers
2018-05-25 16:34             ` hpa [this message]
2018-05-25  8:24     ` Sedat Dilek

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=E6A629A5-CBDF-4301-B10C-A60E1556027A@zytor.com \
    --to=hpa@zytor.com \
    --cc=astrachan@google.com \
    --cc=ghackmann@google.com \
    --cc=keescook@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manojgupta@google.com \
    --cc=mka@google.com \
    --cc=ndesaulniers@google.com \
    --cc=sedat.dilek@gmail.com \
    --cc=tstellar@redhat.com \
    /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).