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]

Message-ID: <alpine.DEB.2.21.1906252127290.32342@nanos.tec.linutronix.de>
Date:   Tue, 25 Jun 2019 21:53:09 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Nathan Chancellor <natechancellor@...il.com>
cc:     Kees Cook <keescook@...omium.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
        "Gustavo A. R. Silva" <gustavo@...eddedor.com>,
        Joe Perches <joe@...ches.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>,
        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>,
        Shawn Landden <shawn@....icu>
Subject: Re: [PATCH] perf/x86/intel: Mark expected switch fall-throughs

On Tue, 25 Jun 2019, Nathan Chancellor wrote:
> On Tue, Jun 25, 2019 at 10:12:42AM -0700, Kees Cook wrote:
> > On Tue, Jun 25, 2019 at 09:18:46AM +0200, Peter Zijlstra wrote:
> > > Can it build a kernel without patches yet? That is, why should I care
> > > what LLVM does?
> > 
> > Yes. LLVM trunk builds and boots x86 now. As for distro availability,
> > AIUI, the asm-goto feature missed the 9.0 LLVM branch point, so it'll
> > appear in the following release.
> > 
> > -- 
> > Kees Cook
> 
> I don't think that's right. LLVM 9 hasn't been branched yet so it should
> make it in.
> 
> http://lists.llvm.org/pipermail/llvm-dev/2019-June/133155.html
> 
> If anyone wants to play around with it before then, we wrote a
> self-contained script that will build an LLVM toolchain suitable for
> kernel development:
> 
> https://github.com/ClangBuiltLinux/tc-build

Useful!

But can the script please check for a minimal clang version required to
build that thing.

The default clang-3.8 which is installed on Debian stretch explodes. The
6.0 variant from backports works as advertised.

Kernel builds with the new shiny compiler. Jump labels seem to be enabled.

It complains about a few type conversions:

 arch/x86/kvm/mmu.c:4596:39: warning: implicit conversion from 'int' to 'u8' (aka 'unsigned char') changes value from -205 to 51 [-Wconstant-conversion]
                u8 wf = (pfec & PFERR_WRITE_MASK) ? ~w : 0;
                   ~~                               ^~

but it also makes objtool unhappy:

 arch/x86/events/intel/core.o: warning: objtool: intel_pmu_nhm_workaround()+0xb3: unreachable instruction
 kernel/fork.o: warning: objtool: free_thread_stack()+0x126: unreachable instruction
 mm/workingset.o: warning: objtool: count_shadow_nodes()+0x11f: unreachable instruction
 arch/x86/kernel/cpu/mtrr/generic.o: warning: objtool: get_fixed_ranges()+0x9b: unreachable instruction
 arch/x86/kernel/platform-quirks.o: warning: objtool: x86_early_init_platform_quirks()+0x84: unreachable instruction
 drivers/iommu/irq_remapping.o: warning: objtool: irq_remap_enable_fault_handling()+0x1d: unreachable instruction

Kernel boots. As I'm currently benchmarking VDSO performance, this was
obviosly my first test. Compared to the same kernel built with gcc6.3 the
performance of the VDSO drops slightly.

It's below 1%. Though I need to run the same tests on 4 other uarchs to get
the full picture. This stuff is randomly changing behaviour accross uarchs
depending on how the c source is arranged. So nothing to worry about (yet).

Thanks,

	tglx