linux-kernel - RE: [PATCH v4 1/4] x86/cpufeatures: Enumerate #DB for bus lock detection

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]

Date:   Wed, 27 Jan 2021 22:39:59 +0000
From:   "Yu, Fenghua" <fenghua.yu@...el.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...en8.de>, Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        "Luck, Tony" <tony.luck@...el.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        "Li, Xiaoyao" <xiaoyao.li@...el.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>
CC:     linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>
Subject: RE: [PATCH v4 1/4] x86/cpufeatures: Enumerate #DB for bus lock
 detection

Hi, Thomas,

> On Wed, Jan 27, 2021 2:16 PM, Thomas Gleixner wrote:
> On Tue, Nov 24 2020 at 20:52, Fenghua Yu wrote:
> 
> > A bus lock is acquired though either split locked access to writeback
> > (WB) memory or any locked access to non-WB memory. This is typically
> > >1000 cycles slower than an atomic operation within a cache line. It
> > also disrupts performance on other cores.
> >
> > Some CPUs have ability to notify the kernel by an #DB trap after a
> > user instruction acquires a bus lock and is executed. This allows the
> > kernel to enforce user application throttling or mitigations.
> 
> That's nice, but how does that interact with a data breakpoint on the same
> location?

If both data breakpoint and bus lock happen on the same location, the bus lock
is handled first and then the data breakpoint is handled in the same exception:

1. If warn on bus lock, a rate limited warning is printed for the bus lock and then
    a SIGTRAP is sent to the user process.
2. If fatal on bus lock, a SIGBUS is sent to the user process for the bus lock and a
    SIGTRAP is also sent to the user process. I think the SIGBUS will be delivered first
    to the process and then SIGTRAP will be delivered to the process.
3. If ratelimit on bus lock, first the tasks in the user sleep for specified time, then
    SIGTRAP is sent to the user process.

Is the interaction OK?

> 
> Also the information you pointed to in the cover letter
> 
> >  [1] Intel Instruction Set Extension Chapter 8:
> > https://software.intel.com/sites/default/files/managed/c5/15/architect
> > ure-instruction-set-extensions-programming-reference.pdf
> 
> does not contain anything which is even remotely related to this patch series.
> That chapter describes another bit in TEST_CTRL_MSR ...

I think either I gave an old link or the content in the link was changed to an older version of ISE doc after this series was released.

Here is the new ISE doc and the bus lock exception is described in Chapter 9.
https://software.intel.com/content/dam/develop/public/us/en/documents/architecture-instruction-set-extensions-programming-reference.pdf

I'll update the link in the next version.

Thanks!

-Fenghua