linux-kernel - Re: [PATCH] perf/x86/intel: Mark expected switch fall-throughs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 28 Jun 2019 11:44:16 -0700
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     "Gustavo A. R. Silva" <gustavo@...eddedor.com>,
        Joe Perches <joe@...ches.com>,
        Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        Kan Liang <kan.liang@...ux.intel.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>,
        Shawn Landden <shawn@....icu>,
        Nathan Chancellor <natechancellor@...il.com>,
        Luc Van Oostenryck <luc.vanoostenryck@...il.com>,
        Chandler Carruth <chandlerc@...gle.com>,
        Jann Horn <jannh@...gle.com>, Bill Wendling <morbo@...gle.com>,
        Alexander Potapenko <glider@...gle.com>
Subject: Re: [PATCH] perf/x86/intel: Mark expected switch fall-throughs

On Fri, Jun 28, 2019 at 6:31 AM Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Thu, Jun 27, 2019 at 09:12:50AM +0200, Peter Zijlstra wrote:
>
> > Josh came up with the following:
> >
> > +             /* If the jump target is close, do a 2-byte nop: */
> > +             ".skip -(%l[l_yes] - 1b <= 126), 0x66\n"
> > +             ".skip -(%l[l_yes] - 1b <= 126), 0x90\n"
> > +             /* Otherwise do a 5-byte nop: */
> > +             ".skip -(%l[l_yes] - 1b > 126), 0x0f\n"
> > +             ".skip -(%l[l_yes] - 1b > 126), 0x1f\n"
> > +             ".skip -(%l[l_yes] - 1b > 126), 0x44\n"
> > +             ".skip -(%l[l_yes] - 1b > 126), 0x00\n"
> > +             ".skip -(%l[l_yes] - 1b > 126), 0x00\n"
> >
> > Which is a wonderfully gruesome hack :-) So I'll be playing with that
> > for a bit.
>
> For those with interest; full patches at:
>
>   https://lkml.kernel.org/r/20190628102113.360432762@infradead.org

Do you have a branch pushed that I can pull this from to quickly test w/ Clang?

The .skip trick is wild; I don't quite understand the negation in the
above or patch 8/8 for is_byte/is_long.

Also, the comment on 8/8 about patching early hits home; we had a
sign-extending-booleans bug that was causing the address calculation
to be off by two.  Jann and Bill had to help me debug that one, and
funnily enough Kees fixed it in LLVM.  Fetching exception frames out
of early_idt_handler_common has been my most memorable kernel
debugging experience to date, and hope I don't have to do that ever
again.  Kees this week adjusted where arm64 does static_key enablement
(moved it earlier for Alexander Potapenko's slab
initialization/poisoning set).

For the wrong __jump_table entry; I consider that a critical issue we
need to fix before the clang-9 release.  I'm unloading my current
responsibilities at work to be able to sit and focus on bug.  I'll
probably start a new thread with you, tglx, Josh, and our mailing list
next week (sorry for co-opting this thread).  I have been using
creduce quite successfully for finding and fixing our previous codegen
bugs (https://nickdesaulniers.github.io/blog/2019/01/18/finding-compiler-bugs-with-c-reduce/),
but I need to sit and understand the precise failure more in order to
reduce the input.  We can see pretty well where in the compilation
pipeline things go wrong; I just find it hard to page through large
inputs such as whole translation units.
-- 
Thanks,
~Nick Desaulniers