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: <87tur6jhyo.wl-maz@kernel.org>
Date:   Sun, 24 Jan 2021 18:41:19 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     David Brazdil <dbrazdil@...gle.com>
Cc:     linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.cs.columbia.edu,
        linux-kernel@...r.kernel.org,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Alexandru Elisei <alexandru.elisei@....com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Jing Zhang <jingzhangos@...gle.com>,
        Ajay Patil <pajay@....qualcomm.com>,
        Prasad Sodagudi <psodagud@...eaurora.org>,
        Srinivas Ramana <sramana@...eaurora.org>,
        James Morse <james.morse@....com>,
        Julien Thierry <julien.thierry.kdev@...il.com>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        kernel-team@...roid.com
Subject: Re: [PATCH v4 18/21] arm64: Move "nokaslr" over to the early cpufeature infrastructure

On Mon, 18 Jan 2021 14:46:36 +0000,
David Brazdil <dbrazdil@...gle.com> wrote:
> 
> On Mon, Jan 18, 2021 at 09:45:30AM +0000, Marc Zyngier wrote:
> > Given that the early cpufeature infrastructure has borrowed quite
> > a lot of code from the kaslr implementation, let's reimplement
> > the matching of the "nokaslr" option with it.
> > 
> > Signed-off-by: Marc Zyngier <maz@...nel.org>
> Acked-by: David Brazdil <dbrazdil@...gle.com>

[...]

> > @@ -126,7 +95,7 @@ u64 __init kaslr_early_init(void)
> >  	 * Check if 'nokaslr' appears on the command line, and
> >  	 * return 0 if that is the case.
> >  	 */
> > -	if (is_kaslr_disabled_cmdline(fdt)) {
> > +	if (kaslr_feature_val & kaslr_feature_mask & 0xf) {
> 
> nit: Isn't the 0xf redundant here? You don't re-mask for VH either.

Actually, I do. See the two back to back ubfx that extract both the
mask and the feature. The "& 0xf" here serves the same purpose.

Is it redundant? At the moment, quite possibly. But since we have
space for 16 "features", this is an indication that we are only using
the first one. I expect that eventually, we'll use it for other
things.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ