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: <6702ec00b1ee44b140da85644ea1f965f5d9e42b.camel@linux.ibm.com>
Date:   Tue, 07 Mar 2023 16:58:22 +1100
From:   Benjamin Gray <bgray@...ux.ibm.com>
To:     Nicholas Piggin <npiggin@...il.com>, linuxppc-dev@...ts.ozlabs.org
Cc:     ajd@...ux.ibm.com, linux-kernel@...r.kernel.org,
        linux-hardening@...r.kernel.org, cmr@...escreens.de
Subject: Re: [RFC PATCH 07/13] powerpc/dexcr: Add sysctl entry for SBHE
 system override

On Tue, 2023-03-07 at 15:30 +1000, Nicholas Piggin wrote:
> On Mon Nov 28, 2022 at 12:44 PM AEST, Benjamin Gray wrote:
> > The DEXCR Speculative Branch Hint Enable (SBHE) aspect controls
> > whether
> > the hints provided by BO field of Branch instructions are obeyed
> > during
> > speculative execution.
> > 
> > SBHE behaviour per ISA 3.1B:
> > 
> > 0:      The hints provided by BO field of Branch instructions may
> > be
> >         ignored during speculative execution
> > 
> > 1:      The hints provided by BO field of Branch instructions are
> > obeyed
> >         during speculative execution
> > 
> > Add a sysctl entry to allow changing this aspect globally in the
> > system
> > at runtime:
> > 
> >         /proc/sys/kernel/speculative_branch_hint_enable
> > 
> > Three values are supported:
> > 
> > -1:     Disable DEXCR SBHE sysctl override
> >  0:     Override and set DEXCR[SBHE] aspect to 0
> >  1:     Override and set DEXCR[SBHE] aspect to 1
> > 
> > Internally, introduces a mechanism to apply arbitrary system wide
> > overrides on top of the prctl() config.
> 
> Why have an override for this, and not others?
> 

Should be in the commit message of course, but this aspect bleeds over
to other processes, so a user may wish to prevent all processes from
changing the value. The other aspects are probably only relevant to
their own process, though the implementation here should support
arbitrary system wide overrides.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ