From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752351AbeCMOVy (ORCPT ); Tue, 13 Mar 2018 10:21:54 -0400 Received: from foss.arm.com ([217.140.101.70]:39038 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751740AbeCMOVw (ORCPT ); Tue, 13 Mar 2018 10:21:52 -0400 Subject: Re: [3/3] irqchip/gic-v3: Bounds check redistributor accesses To: Lokesh Vutla , Punit Agrawal , linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org, "Menon, Nishanth" References: <20171011094148.15674-4-punit.agrawal@arm.com> <28f9c1cd-e1df-f4db-32b4-c9ca0f0f256a@ti.com> From: Marc Zyngier Organization: ARM Ltd Message-ID: <8366ba39-a5a1-7734-752e-f3dce18e8007@arm.com> Date: Tue, 13 Mar 2018 14:21:50 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <28f9c1cd-e1df-f4db-32b4-c9ca0f0f256a@ti.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Lokesh, On 13/03/18 13:38, Lokesh Vutla wrote: > Hi All, > > On Wednesday 11 October 2017 03:11 PM, Punit Agrawal wrote: >> The kernel crashes while iterating over a redistributor that is >> in-correctly sized by the platform firmware or doesn't contain the last >> record. >> >> Prevent the crash by checking accesses against the size of the region >> provided by the firmware. While we are at it, warn the user about >> incorrect region size. >> >> Signed-off-by: Punit Agrawal >> Cc: Marc Zyngier > > Sorry to bring up an old thread. Just wanted to check what is the status > on this series. So far, I wasn't inclined to merge it, as it only allowed you to detect a broken system, as opposed to help with a working one. > This will also be useful when we try to boot linux + hypervisor with > less number of cores than the SoC supports. For example: > - SoC has 4 cores and Linux tries to boot with 2 cores. > - then a type-2 hypervisor gets installed. > - Hypervisor tries to boot a VM with linux on core 1. > > Now the VM boot will fail while it iterates over all the GICR regions > till GICR_TYPER is found. Hypervisor will trap any accesses to GICR > regions of any invalid cpus(cpu 2, cpu 3 in this case). It you're passing the redistributors to a guest, you're doing something terribly wrong. You're putting the guest in a position to do a DoS on the hypervisor (disabling its timer interrupt, for example). Not the greatest move. There is a number of other gotchas with this approach (virtual interrupts, distributor virtualization...). > If the $patch is not the right approach, can you suggest on how to > handle the above scenario? The proper way to handle this is to virtualize the distributor and redistributor by trap/emulate. The only thing you can safely pass to a guest is the CPU interface, either as system registers or in its MMIO form (if you have the GICv2 compatibility interface). Thanks, M. -- Jazz is not dead. It just smells funny...