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, 4 Oct 2017 12:32:12 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Catalin Marinas <catalin.marinas@....com>
Cc:     Suzuki K Poulose <suzuki.poulose@....com>,
        Will Deacon <will.deacon@....com>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        matwey.kornilov@...il.com, James Morse <james.morse@....com>,
        Dave Martin <Dave.martin@....com>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] arm64: Enable MRS emulation early

On Wed, Oct 04, 2017 at 12:10:40PM +0100, Catalin Marinas wrote:
> On Wed, Oct 04, 2017 at 11:14:26AM +0100, Mark Rutland wrote:
> > On Wed, Oct 04, 2017 at 10:48:05AM +0100, Suzuki K Poulose wrote:
> > > Make sure the MRS emulation is enabled early enough, such that the
> > > early userspace applications (e.g, those run from initrd) could
> > > use the facility without crashing them.
> > > 
> > > Fixes: commit 77c97b4ee2129 ("arm64: cpufeature: Expose CPUID registers by emulation")
> > > Reported-by: Matwey V. Kornilov <matwey.kornilov@...il.com>
> > > Cc: James Morse <james.morse@....com>
> > > Cc: Dave Martin <Dave.martin@....com>
> > > Cc: Catalin Marinas <catalin.marinas@....com>
> > > Cc: Will Deacon <will.deacon@....com>
> > > Cc: stable@...r.kernel.org
> > > Cc: Mark Rutland <mark.rutland@....com>
> > > Signed-off-by: Suzuki K Poulose <suzuki.poulose@....com>
> > 
> > This looks sensible, but shouldn't we do the same for other
> > late_inicalls can affect initrd userspace?
> > 
> > e.g. armv8_deprecated_init, fpsimd_init, sys_reg_genericv8_init?
> 
> I think we should, though not all of them are concerned with the user
> code. For example, fpsimd_init() takes care of the pm/hotplug aspect and
> nothing to do with user space.

My worry was that without the pm/hotplug notifiers, things could go
wrong during the initrd. e.g. we could lose userspace fp state without
the pm notifier, or userspace could trigger hotplpug that we wouldn't
manage correctly

So even if it's not directly userspace related, it can affect (or can be
affected by) initrd userspace.

> That said, making it core_initcall() is probably not a bad thing (just
> a statement that it is concerned with the core initialisation), as
> long as all the other infrastructure it registers with is up.

Sure.

> For Suzuki's patch, I was thinking of enabling emulation before we
> register the HWCAP_CPUID bit (setup_elf_hwcaps). However, that means we
> have to bring it before smp_cpus_done(). It's not really worth it as we
> don't expect any user space at that point.

I think so long as we bring it up before *any* userspace can run, it
doesn't matter if we set the hwcaps earlier.

Thanks,
Mark.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ