linux-kernel - Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

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: <B36138FF-6BA5-4868-A321-2E31CA4875F4@amacapital.net>
Date:   Thu, 29 Nov 2018 09:35:42 -0800
From:   Andy Lutomirski <luto@...capital.net>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Josh Poimboeuf <jpoimboe@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrew Lutomirski <luto@...nel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>, mhiramat@...nel.org,
        jbaron@...mai.com, Jiri Kosina <jkosina@...e.cz>,
        David.Laight@...lab.com, bp@...en8.de, julia@...com,
        jeyu@...nel.org, Peter Anvin <hpa@...or.com>
Subject: Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64



> On Nov 29, 2018, at 9:29 AM, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> 
> On Thu, Nov 29, 2018 at 9:02 AM Andy Lutomirski <luto@...capital.net> wrote:
>>> 
>>> - just restart the instruction (with the suggested "ptregs->rip --")
>>> 
>>> - to avoid any "oh, we're not making progress" issues, just fix the
>>> instruction yourself to be the right call, by looking it up in the
>>> "what needs to be fixed" tables.
>> 
>> I thought that too.  I think it deadlocks. CPU A does text_poke_bp().  CPU B is waiting for a spinlock with IRQs off.  CPU C holds the spinlock and hits the int3.  The int3 never goes away because CPU A is waiting for CPU B to handle the sync_core IPI.
>> 
>> Or do you think we can avoid the IPI while the int3 is there?
> 
> I'm handwaving and thinking that CPU C that hits the int3 can just fix
> up the instruction directly in its own caches, and return.
> 
> Yes, it does what he "text_poke" *will* do (so now the instruction
> gets rewritten _twice_), but who cares? It's idempotent.
> 
> 

But it’s out of order. I’m not concerned about the final IPI — I’m concerned about the IPI after the int3 write and before the int3 is removed again. If one CPU replaces 0xcc with 0xe8, another CPU could observe that before the last couple bytes of the call target are written and observed by all CPUs.