linux-kernel - Re: [PATCH] irqchip/gic-v4: Disable redistributors' view of the VPE table at boot time

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: <20211216190315.GA14220@lpieralisi>
Date:   Thu, 16 Dec 2021 19:03:15 +0000
From:   Lorenzo Pieralisi <lorenzo.pieralisi@....com>
To:     Marc Zyngier <maz@...nel.org>
Cc:     linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
        kernel-team@...roid.com, Jay Chen <jkchen@...ux.alibaba.com>
Subject: Re: [PATCH] irqchip/gic-v4: Disable redistributors' view of the VPE
 table at boot time

On Thu, Dec 16, 2021 at 02:48:04PM +0000, Marc Zyngier wrote:
> Jay Chen reported that using a kdump kernel on a GICv4.1 system
> results in a RAS error being delivered when the secondary kernel
> configures the ITS's view of the new VPE table.
> 
> As it turns out, that's because each RD still has a pointer to
> the previous instance of the VPE table, and that particular
> implementation is very upset by seeing two bits of the HW that
> should point to the same table with different values.
> 
> To solve this, let's invalidate any reference that any RD has to
> the VPE table when discovering the RDs. The ITS can then be
> programmed as expected.

It makes sense. I believe there is an additional question though,
related to ITSes sharing the VPE table (SVPET) with RDs.

IIUC, all ITSes within a given affinity (that therefore are sharing the
VPE table) need to be quiesced before allocating a new VPE table.

Again, I am off the radar for a while and this patch makes sense on its
own, just raising the question since I was trying to understand whether
that can be an additional issue to solve on kexec; I will follow up
on this query.

It would be nice to know Alibaba's GIC HW topology if possible.

Thanks for putting together the fix and merging it.

Lorenzo

> Reported-by: Jay Chen <jkchen@...ux.alibaba.com>
> Signed-off-by: Marc Zyngier <maz@...nel.org>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@....com>
> Link: https://lore.kernel.org/r/20211214064716.21407-1-jkchen@linux.alibaba.com
> ---
>  drivers/irqchip/irq-gic-v3.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index daec3309b014..86397522e786 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -920,6 +920,22 @@ static int __gic_update_rdist_properties(struct redist_region *region,
>  {
>  	u64 typer = gic_read_typer(ptr + GICR_TYPER);
>  
> +	/* Boot-time cleanip */
> +	if ((typer & GICR_TYPER_VLPIS) && (typer & GICR_TYPER_RVPEID)) {
> +		u64 val;
> +
> +		/* Deactivate any present vPE */
> +		val = gicr_read_vpendbaser(ptr + SZ_128K + GICR_VPENDBASER);
> +		if (val & GICR_VPENDBASER_Valid)
> +			gicr_write_vpendbaser(GICR_VPENDBASER_PendingLast,
> +					      ptr + SZ_128K + GICR_VPENDBASER);
> +
> +		/* Mark the VPE table as invalid */
> +		val = gicr_read_vpropbaser(ptr + SZ_128K + GICR_VPROPBASER);
> +		val &= ~GICR_VPROPBASER_4_1_VALID;
> +		gicr_write_vpropbaser(val, ptr + SZ_128K + GICR_VPROPBASER);
> +	}
> +
>  	gic_data.rdists.has_vlpis &= !!(typer & GICR_TYPER_VLPIS);
>  
>  	/* RVPEID implies some form of DirectLPI, no matter what the doc says... :-/ */
> -- 
> 2.30.2
>