netdev - Re: [PATCH v4 00/13] "Task

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: <877dutx5xj.fsf@nanos.tec.linutronix.de>
Date:   Thu, 23 Jul 2020 23:44:24 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Alex Belits <abelits@...vell.com>,
        "peterz\@infradead.org" <peterz@...radead.org>
Cc:     "davem\@davemloft.net" <davem@...emloft.net>,
        Prasun Kapoor <pkapoor@...vell.com>,
        "mingo\@kernel.org" <mingo@...nel.org>,
        "linux-api\@vger.kernel.org" <linux-api@...r.kernel.org>,
        "rostedt\@goodmis.org" <rostedt@...dmis.org>,
        "frederic\@kernel.org" <frederic@...nel.org>,
        "catalin.marinas\@arm.com" <catalin.marinas@....com>,
        "linux-arch\@vger.kernel.org" <linux-arch@...r.kernel.org>,
        "will\@kernel.org" <will@...nel.org>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev\@vger.kernel.org" <netdev@...r.kernel.org>,
        "linux-arm-kernel\@lists.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v4 00/13] "Task_isolation" mode

Alex Belits <abelits@...vell.com> writes:
> On Thu, 2020-07-23 at 17:49 +0200, Peter Zijlstra wrote:
>> 
>> 'What does noinstr mean? and why do we have it" -- don't dare touch
>> the
>> entry code until you can answer that.
>
> noinstr disables instrumentation, so there would not be calls and
> dependencies on other parts of the kernel when it's not yet safe to
> call them. Relevant functions already have it, and I add an inline call
> to perform flags update and synchronization. Unless something else is
> involved, those operations are safe, so I am not adding anything that
> can break those.

Sure.

 1) That inline function can be put out of line by the compiler and
    placed into the regular text section which makes it subject to
    instrumentation

 2) That inline function invokes local_irq_save() which is subject to
    instrumentation _before_ the entry state for the instrumentation
    mechanisms is established.

 3) That inline function invokes sync_core() before important state has
    been established, which is especially interesting in NMI like
    exceptions.

As you clearly documented why all of the above is safe and does not
cause any problems, it's just me and Peter being silly, right?

Try again.

Thanks,

        tglx