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: <Y/dfyh1U/qDR1Ymw@zn.tnic>
Date:   Thu, 23 Feb 2023 13:44:58 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     KP Singh <kpsingh@...nel.org>
Cc:     linux-kernel@...r.kernel.org, pjt@...gle.com, evn@...gle.com,
        jpoimboe@...nel.org, tglx@...utronix.de, x86@...nel.org,
        hpa@...or.com, peterz@...radead.org,
        pawan.kumar.gupta@...ux.intel.com, kim.phillips@....com,
        alexandre.chartre@...cle.com, daniel.sneddon@...ux.intel.com,
        corbet@....net, bp@...e.de, linyujun809@...wei.com,
        jmattson@...gle.com,
        José Oliveira <joseloliveira11@...il.com>,
        Rodrigo Branco <rodrigo@...nelhacking.com>,
        Alexandra Sandulescu <aesa@...gle.com>, stable@...r.kernel.org
Subject: Re: [PATCH v2 1/2] x86/speculation: Allow enabling STIBP with legacy
 IBRS

On Wed, Feb 22, 2023 at 11:41:59AM -0800, KP Singh wrote:
> Sure, I think the docs do already cover it,

I mean *our docs*. The stuff you're adding in your patch 2.

> but I sort of disagree with your statement around the commit message.
> I feel the more context you can add in the commit message, the better
> it is.

That's ofc wrong. And you'll find that out when you do git archeology
and you come across a huuuge wall of text explaining the world and some
more.

No, commit messages should be to the point with a structure similar to
something like this:

1. Prepare the context for the explanation briefly.

2. Explain the problem at hand.

3. "It happens because of <...>"

4. "Fix it by doing X"

5. "(Potentially do Y)."

concentrating on *why* the fix is being done.

> When I am looking at the change log, it would be helpful to have the
> information that I mentioned in the Q&A. Small things like, "eIBRS
> needs the IBRS bit set which also enables cross-thread protections" is
> a very important context for this patch IMHO. Without this one is just
> left head scratching and scrambling to read lengthy docs and processor
> manuals.

Yes, that's why you say in the commit message: "For more details, see
Documentation/admin-guide/hw-vuln/spectre.rst." where:

1. you can explain in a lot more detail

2. put it in place where people can find it *easily*

> This sort of loosely implies that the IBRS bit also enables
> cross-thread protections. Can you atleast add this one explicitly?
> 
> "Setting the IBRS bit also enables cross thread protections"

Ok.

> Not at the stage when the kernel decides to drop the STIBP protection
> when eIBRS is enabled.

We can't dump every possible interaction between the mitigations. It is
a huge mess already. But I'm open to looking at improvements of the
situation *and* documenting stuff as we go.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ