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  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:   Tue, 1 Dec 2020 13:51:35 +0000
From:   David Brazdil <>
To:     Sudeep Holla <>
Cc:, Jonathan Corbet <>,
        Catalin Marinas <>,
        Will Deacon <>, Marc Zyngier <>,
        James Morse <>,
        Julien Thierry <>,
        Suzuki K Poulose <>,
        Dennis Zhou <>, Tejun Heo <>,
        Christoph Lameter <>,
        Mark Rutland <>,
        Lorenzo Pieralisi <>,,,,
Subject: Re: [PATCH v3 19/23] kvm: arm64: Intercept host's CPU_ON SMCs

Hey Sudeep,

> > +static unsigned int find_cpu_id(u64 mpidr)
> > +{
> > +	unsigned int i;
> > +
> > +	/* Reject invalid MPIDRs */
> > +	if (mpidr & ~MPIDR_HWID_BITMASK)
> > +		return INVALID_CPU_ID;
> > +
> > +	for (i = 0; i < NR_CPUS; i++) {
> I may not have understood the flow correctly, so just asking:

> This is just called for secondaries on boot right ? 
No, secondaries are booted before KVM is initialized. kvm_arch_init() installs
the hypervisor on each core that is online at that point. That flow does not
touch this code.

But the kernel can later power down some of those cares and then this handler
is called if it tries to power them on again. You can exercise this with:

	# echo 0 > /sys/devices/system/cpu/cpu5/online
	# echo 1 > /sys/devices/system/cpu/cpu5/online

> And the cpumasks are setup by then ? 
Cpumasks are initialized before KVM init, so yes, we could copy that
information up to EL2 and use it here. That comes down to copying `nr_cpu_ids`
because the possible set is logical IDs 0..nr_cpu_ids-1 (see smp_init_cpus()).

> Just trying to see if we can use cpu_possible_mask instead of running through
> all 256/1k/4k cpus(ofcourse based on NR_CPUS config)

I decided to keep things simple because a valid MPIDR should not need to
scan the entire array, at most the first `nr_cpu_ids` entries. An invalid MPIDR
will scan all NR_CPUS entries but that does not seem worth optimizing for.


Powered by blists - more mailing lists