[3/3] irqchip/gic-v3: Bounds check redistributor accesses

[Marc Zyngier]

On Tue, 13 Mar 2018 18:49:44 +0000,
Nishanth Menon wrote:
> 
> Marc,
> 
> On Tue, Mar 13, 2018 at 9:21 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> > 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 <punit.agrawal at arm.com>
> >>> Cc: Marc Zyngier <marc.zyngier at arm.com>
> >>
> >> 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.
> 
> Is'nt that a good reason to have it? Why not help an error in dtb with
> a debug helper than an obtuse crash to debug painfully?

The kernel is not in the business of validating DTBs. And we both know
that if we start papering over firmware bugs, these bugs become ABI,
and we live with them forever. If you want to validate DTBs, you
should use a tool that is actually validating it against your HW, and
not use the kernel as the validation tool.

> 
> >
> >> 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).
> >
> 
> Dumb question: Would'nt a trap emulate be real expensive with hyp
> context in v8 (all the context save/restore we'd have to do? (in the
> context of discussion, GICV2 compat is disabled).

How often do you hit the distributor and redistributors? Why do you
need to context switch a distributor that you emulate (hint: you
don't). I suggest you look at how real life hypervisor works (there's
a pretty good one in the tree).

Thanks,

	M.

-- 
Jazz is not dead, it just smell funny.