On Wed, May 30, 2018 at 11:50 PM Nick Desaulniers
wrote:
> Will do further testing and cut a patch set tomorrow.
https://lkml.org/lkml/2018/6/1/679
(sorry, should have re-cc-ed everyone from this thread, will try to
re-add when there's feedback)
--
Thanks,
~Nick Desaulniers
On Fri, May 25, 2018 at 3:38 PM Nick Desaulniers
wrote:
>
> On Fri, May 25, 2018 at 2:06 PM H. Peter Anvin wrote:
> > On 05/25/18 13:36, Nick Desaulniers wrote:
> > > On Fri, May 25, 2018 at 10:56 AM wrote:
> > >> You need the extern inline in the .h file and the out-of-line .S file
> > > I don'
On Fri, May 25, 2018 at 2:06 PM H. Peter Anvin wrote:
> On 05/25/18 13:36, Nick Desaulniers wrote:
> > On Fri, May 25, 2018 at 10:56 AM wrote:
> >> You need the extern inline in the .h file and the out-of-line .S file
> > I don't see how you can specify to the linker from assembly source that
> >
On 05/25/18 13:36, Nick Desaulniers wrote:
> On Fri, May 25, 2018 at 10:56 AM wrote:
>> You need the extern inline in the .h file and the out-of-line .S file
> both.
>
> But the out-of-line .S file looks like:
>
> ...
> 10 ENTRY(native_save_fl)
>
> 11 pushf
>
> 12 pop %_ASM_AX
On Fri, May 25, 2018 at 10:56 AM wrote:
> You need the extern inline in the .h file and the out-of-line .S file
both.
But the out-of-line .S file looks like:
...
10 ENTRY(native_save_fl)
11 pushf
12 pop %_ASM_AX
13 ret
14 ENDPROC(native_save_fl)
15 EXPORT_SYMBO
On Fri, May 25, 2018 at 10:49 AM Nick Desaulniers
wrote:
> gcc 8.1 and trunk inserts a `ud2` instruction (what?!) (let me see if I
can
> repro outside of godbolt, and will file a bug report).
Filed:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85927
--
Thanks,
~Nick Desaulniers
On May 25, 2018 10:49:28 AM PDT, Nick Desaulniers
wrote:
>On Fri, May 25, 2018 at 10:35 AM Tom Stellard
>wrote:
>> On 05/25/2018 10:31 AM, Nick Desaulniers wrote:
>> > On Fri, May 25, 2018 at 9:53 AM wrote:
>> >> On May 25, 2018 9:46:42 AM PDT, Nick Desaulniers <
>ndesaulni...@google.com>
>> >
On May 25, 2018 10:31:51 AM PDT, Nick Desaulniers
wrote:
>On Fri, May 25, 2018 at 9:53 AM wrote:
>> On May 25, 2018 9:46:42 AM PDT, Nick Desaulniers
>
>wrote:
>> >On Fri, May 25, 2018 at 9:33 AM wrote:
>> >> On May 25, 2018 9:27:40 AM PDT, Nick Desaulniers
>> > wrote:
>> >When you say
>> >
>> >
On Fri, May 25, 2018 at 10:35 AM Tom Stellard wrote:
> On 05/25/2018 10:31 AM, Nick Desaulniers wrote:
> > On Fri, May 25, 2018 at 9:53 AM wrote:
> >> On May 25, 2018 9:46:42 AM PDT, Nick Desaulniers <
ndesaulni...@google.com>
> > wrote:
> >>> On Fri, May 25, 2018 at 9:33 AM wrote:
> On May
On 05/25/2018 10:31 AM, Nick Desaulniers wrote:
> On Fri, May 25, 2018 at 9:53 AM wrote:
>> On May 25, 2018 9:46:42 AM PDT, Nick Desaulniers
> wrote:
>>> On Fri, May 25, 2018 at 9:33 AM wrote:
On May 25, 2018 9:27:40 AM PDT, Nick Desaulniers
>>> wrote:
>>> When you say
>>>
It still sh
On Fri, May 25, 2018 at 9:53 AM wrote:
> On May 25, 2018 9:46:42 AM PDT, Nick Desaulniers
wrote:
> >On Fri, May 25, 2018 at 9:33 AM wrote:
> >> On May 25, 2018 9:27:40 AM PDT, Nick Desaulniers
> > wrote:
> >When you say
> >
> >> It still should be available as as inline, however, but now "extern
On May 25, 2018 9:46:42 AM PDT, Nick Desaulniers
wrote:
>On Fri, May 25, 2018 at 9:33 AM wrote:
>> On May 25, 2018 9:27:40 AM PDT, Nick Desaulniers
>
>wrote:
>> >On Thu, May 24, 2018 at 3:43 PM wrote:
>> >> On May 24, 2018 3:31:05 PM PDT, Nick Desaulniers
>> >
>> >wrote:
>> >> >On Thu, May 24,
On Fri, May 25, 2018 at 9:33 AM wrote:
> On May 25, 2018 9:27:40 AM PDT, Nick Desaulniers
wrote:
> >On Thu, May 24, 2018 at 3:43 PM wrote:
> >> On May 24, 2018 3:31:05 PM PDT, Nick Desaulniers
> >
> >wrote:
> >> >On Thu, May 24, 2018 at 3:05 PM H. Peter Anvin
> >wrote:
> >> >> COMPILER AR: "=rm
On May 25, 2018 9:27:40 AM PDT, Nick Desaulniers
wrote:
>On Thu, May 24, 2018 at 3:43 PM wrote:
>> On May 24, 2018 3:31:05 PM PDT, Nick Desaulniers
>
>wrote:
>> >On Thu, May 24, 2018 at 3:05 PM H. Peter Anvin
>wrote:
>> >> COMPILER AR: "=rm" should NEVER generate worse code than "=r".
>That
>>
On May 25, 2018 9:27:40 AM PDT, Nick Desaulniers
wrote:
>On Thu, May 24, 2018 at 3:43 PM wrote:
>> On May 24, 2018 3:31:05 PM PDT, Nick Desaulniers
>
>wrote:
>> >On Thu, May 24, 2018 at 3:05 PM H. Peter Anvin
>wrote:
>> >> COMPILER AR: "=rm" should NEVER generate worse code than "=r".
>That
>>
On Thu, May 24, 2018 at 3:43 PM wrote:
> On May 24, 2018 3:31:05 PM PDT, Nick Desaulniers
wrote:
> >On Thu, May 24, 2018 at 3:05 PM H. Peter Anvin wrote:
> >> COMPILER AR: "=rm" should NEVER generate worse code than "=r". That
> >is
> >> unequivocally a compiler bug.
> >
> >Filed: https://bugs.l
On Thu, May 24, 2018 at 10:26 PM, Nick Desaulniers
wrote:
[...]
>> Issue 2: ... The other option is to turn stack canary explicitly off for
> all such functions.
>
> We're looking to add the compiler attribute no_stack_protector. It's added
> in mainline clang, the llvm bug cited earlier is about
On May 24, 2018 3:31:05 PM PDT, Nick Desaulniers
wrote:
>On Thu, May 24, 2018 at 3:05 PM H. Peter Anvin 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 claimin
On Thu, May 24, 2018 at 3:05 PM H. Peter Anvin 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
On 05/24/18 13:26, Nick Desaulniers wrote:
>
> Considering the bigger picture is why we have this thread going. You have
> much more context about the kernel than I or the llvm maintainers do. We
> can't consider the bigger picture until we ask.
>
And this is correct. However, *every* LLVM req
On 05/24/18 14:27, Nick Desaulniers wrote:
> https://godbolt.org/g/oku8ux
>
> Is there a more canonical way the kernel does feature detection that looks
> better than:
>
Hm. I though we had, but it doesn't seem so. For cc we only seem to be
able to detect flags. For as we have rules that can det
On 05/24/18 14:12, Nick Desaulniers wrote:
>
> Looks like those builtins got added to GCC around the 4.9 timeframe:
> https://godbolt.org/g/9VS2E9
>
> Problematically, it seems that GCC does not have __has_builtin to do
> feature detection:
> https://clang.llvm.org/docs/LanguageExtensions.html#fe
On May 24, 2018 1:52:16 PM PDT, Nick Desaulniers
wrote:
>On Thu, May 24, 2018 at 1:26 PM Nick Desaulniers
>
>wrote:
>> On Thu, May 24, 2018 at 11:59 AM wrote:
>> > Issue 3: Let's face it, reading and writing the flags should be
>builtins,
>> exactly because it has to do stack operations, which r
On May 24, 2018 12:49:56 PM PDT, Tom Stellard wrote:
>On 05/24/2018 11:19 AM, h...@zytor.com wrote:
>> On May 23, 2018 3:08:19 PM PDT, Nick Desaulniers
> wrote:
>>> H. Peter,
>>>
>>> It was reported [0] that compiling the Linux kernel with Clang +
>>> CC_STACKPROTECTOR_STRONG was causing a crash i
On Thu, May 24, 2018 at 2:12 PM Nick Desaulniers
wrote:
> On Thu, May 24, 2018 at 1:52 PM Nick Desaulniers
> wrote:
> > On Thu, May 24, 2018 at 1:26 PM Nick Desaulniers <
ndesaulni...@google.com>
> > wrote:
> > > On Thu, May 24, 2018 at 11:59 AM wrote:
> > > > Issue 3: Let's face it, reading and
On Thu, May 24, 2018 at 1:52 PM Nick Desaulniers
wrote:
> On Thu, May 24, 2018 at 1:26 PM Nick Desaulniers
> wrote:
> > On Thu, May 24, 2018 at 11:59 AM wrote:
> > > Issue 3: Let's face it, reading and writing the flags should be
> builtins,
> > exactly because it has to do stack operations, whi
On Thu, May 24, 2018 at 1:26 PM Nick Desaulniers
wrote:
> On Thu, May 24, 2018 at 11:59 AM wrote:
> > Issue 3: Let's face it, reading and writing the flags should be
builtins,
> exactly because it has to do stack operations, which really means the
> compiler should be involved.
> I'm happy to pr
On Thu, May 24, 2018 at 11:59 AM wrote:
> Ok, this is the *second* thing about LLVM-originated bug reports that
drives me batty. When you *do* identify a real problem, you propose a paper
over and/or talk about it as an LLVM issue and don't consider the often far
bigger picture.
Considering the b
On 05/24/2018 11:19 AM, h...@zytor.com wrote:
> On May 23, 2018 3:08:19 PM PDT, Nick Desaulniers
> wrote:
>> H. Peter,
>>
>> It was reported [0] that compiling the Linux kernel with Clang +
>> CC_STACKPROTECTOR_STRONG was causing a crash in native_save_fl(), due
>> to
>> how GCC does not emit a s
On May 23, 2018 3:08:19 PM PDT, Nick Desaulniers
wrote:
>H. Peter,
>
>It was reported [0] that compiling the Linux kernel with Clang +
>CC_STACKPROTECTOR_STRONG was causing a crash in native_save_fl(), due
>to
>how GCC does not emit a stack guard for static inline functions (see
>Alistair's excel
(Resent plain text)
On Thu, May 24, 2018 at 11:24 AM Nick Desaulniers
wrote:
> On Thu, May 24, 2018 at 11:20 AM wrote:
> > A stack canary on an *inlined* function? That's bound to break things
> elsewhere too sooner or later.
> But it's *not* inlined by GCC or Clang.
FWIW, GCC can also insert
On Thu, May 24, 2018 at 11:20 AM wrote:
> A stack canary on an *inlined* function? That's bound to break things
elsewhere too sooner or later.
But it's *not* inlined by GCC or Clang.
While the function is marked `static inline`, it's not in
arch/x86/kernel/paravirt.o due to:
arch/x86/kernel/para
On May 23, 2018 3:08:19 PM PDT, Nick Desaulniers
wrote:
>H. Peter,
>
>It was reported [0] that compiling the Linux kernel with Clang +
>CC_STACKPROTECTOR_STRONG was causing a crash in native_save_fl(), due
>to
>how GCC does not emit a stack guard for static inline functions (see
>Alistair's excel
On Thu, May 24, 2018 at 3:33 AM Sedat Dilek wrote:
> with reverting...
> commit ab94fcf528d127fcb490175512a8910f37e5b346
> "x86: allow "=rm" in native_save_fl()"
> ...I had success to boot into a paravirtualized/strong-stackprotected
> Linux-kernel v4.14.43 on *bare metal* (Lenovo ThinkPad T470).
H. Peter,
It was reported [0] that compiling the Linux kernel with Clang +
CC_STACKPROTECTOR_STRONG was causing a crash in native_save_fl(), due to
how GCC does not emit a stack guard for static inline functions (see
Alistair's excellent report in [1]) but Clang does.
When working with the LLVM r
35 matches
Mail list logo
