linux-kernel - Re: [lkp-robot] [x86/asm] 51bad67ffb: int3:#[##]

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: <CA+55aFwrT-BAvdujUonX5MvB=8GFopQJT4x6xMhtjNN2G0AxSw@mail.gmail.com>
Date:   Tue, 15 May 2018 16:05:33 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     Alexey Dobriyan <adobriyan@...il.com>,
        Peter Anvin <h.peter.anvin@...el.com>,
        kernel test robot <xiaolong.ye@...el.com>,
        Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andrew Lutomirski <luto@...nel.org>,
        Borislav Petkov <bp@...en8.de>,
        Brian Gerst <brgerst@...il.com>,
        Denys Vlasenko <dvlasenk@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Peter Anvin <hpa@...or.com>, tipbuild@...or.com,
        LKP <lkp@...org>
Subject: Re: [lkp-robot] [x86/asm] 51bad67ffb: int3:#[##]

Side note: doing some grepping, I find some other sequences that are a bit
scary, like this:

arch/x86/kernel/acpi/wakeup_32.S-.data
arch/x86/kernel/acpi/wakeup_32.S-ALIGN
arch/x86/kernel/acpi/wakeup_32.S:ENTRY(saved_magic)     .long   0
arch/x86/kernel/acpi/wakeup_32.S:ENTRY(saved_eip)       .long   0

so apparently people are using ENTRY() for data too (the same pattern
exists in wakeup_64.S).

So we end up having those odd 0x90 bytes (now 0xcc) in the data section as
"padding" between those two values. Crazy.

Not an actual problem, but it does show that people seem to be mis-using
ENTRY().

There that padding is actually entirely wrong. We do *not* want to pad
between those "saved_xyz" fields. I think those should use GLOBAL too.

Or lookie here:

arch/x86/kernel/head_32.S-# boot GDT descriptor (later on used by CPU#0):
arch/x86/kernel/head_32.S-      .word 0                         # 32 bit
align gdt_desc.address
arch/x86/kernel/head_32.S:ENTRY(early_gdt_descr)
arch/x86/kernel/head_32.S-      .word GDT_ENTRIES*8-1
arch/x86/kernel/head_32.S-      .long gdt_page                  /*
Overwritten for secondary CPUs */

where ENTRY() will actually screw up how the code says it wants to align
the address, but now it doesn't.

I wonder if there's some way to add a test for "ENTRY only works in a code
section"?

My grep was just me doing a visual scan, I might have missed something.

               Linus