linux-kernel - Re: [RFC 11/14] x86: add support for Dynamic Kernel Stacks

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: <871q8cmzzy.ffs@tglx>
Date: Thu, 14 Mar 2024 19:26:09 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Pasha Tatashin <pasha.tatashin@...een.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 akpm@...ux-foundation.org, x86@...nel.org, bp@...en8.de,
 brauner@...nel.org, bristot@...hat.com, bsegall@...gle.com,
 dave.hansen@...ux.intel.com, dianders@...omium.org,
 dietmar.eggemann@....com, eric.devolder@...cle.com, hca@...ux.ibm.com,
 hch@...radead.org, hpa@...or.com, jacob.jun.pan@...ux.intel.com,
 jgg@...pe.ca, jpoimboe@...nel.org, jroedel@...e.de, juri.lelli@...hat.com,
 kent.overstreet@...ux.dev, kinseyho@...gle.com,
 kirill.shutemov@...ux.intel.com, lstoakes@...il.com, luto@...nel.org,
 mgorman@...e.de, mic@...ikod.net, michael.christie@...cle.com,
 mingo@...hat.com, mjguzik@...il.com, mst@...hat.com, npiggin@...il.com,
 peterz@...radead.org, pmladek@...e.com, rick.p.edgecombe@...el.com,
 rostedt@...dmis.org, surenb@...gle.com, urezki@...il.com,
 vincent.guittot@...aro.org, vschneid@...hat.com
Subject: Re: [RFC 11/14] x86: add support for Dynamic Kernel Stacks

On Thu, Mar 14 2024 at 10:03, Pasha Tatashin wrote:
> On Wed, Mar 13, 2024 at 12:12 PM Thomas Gleixner <tglx@...utronixde> wrote:
>> That needs to validate whether anything uses current between the stack
>> switch and the place where current is updated today. I think nothing
>> should do so, but I would not be surprised either if it would be the
>> case. Such code would already today just work by chance I think,
>>
>> That should not be hard to analyze and fixup if necessary.
>>
>> So that's fixable, but I'm not really convinced that all of this is safe
>> and correct under all circumstances. That needs a lot more analysis than
>> just the trivial one I did for switch_to().
>
> Agreed, if the current task pointer can be switched later, after loads
> and stores to the stack, that would be a better solution. I will
> incorporate this approach into my next version.

No. You need to ensure that there is neither a load or store on the
stack between:

        movq    %rsp, TASK_threadsp(%rdi)
        movq    TASK_threadsp(%rsi), %rsp

and update_current(). IOW, you need to move the update of
pcpu_hot.current to ASM right after the RSP switch.

> I also concur that this proposal necessitates more rigorous analysis.

Glad we agree here :)

Thanks,

        tglx