Re: [PATCH] target/riscv: Add asserts for out-of-bound access

[Peter Maydell]

On Sat, 27 Jul 2024 at 02:36, Atish Kumar Patra <atishp@rivosinc.com> wrote:
>
> On Thu, Jul 25, 2024 at 10:12 PM Alistair Francis <alistair23@gmail.com> 
> wrote:
> >
> > On Wed, Jul 24, 2024 at 6:33 PM Atish Patra <atishp@rivosinc.com> wrote:
> > >
> > > Coverity complained about the possible out-of-bounds access with
> > > counter_virt/counter_virt_prev because these two arrays are
> > > accessed with privilege mode. However, these two arrays are accessed
> > > only when virt is enabled. Thus, the privilege mode can't be M mode.
> > >
> > > Add the asserts anyways to detect any wrong usage of these arrays
> > > in the future.
> > >
> > > Suggested-by: Peter Maydell <peter.maydell@linaro.org>
> > > Signed-off-by: Atish Patra <atishp@rivosinc.com>
> >
> > Fixes: Coverity CID 1558459
> > Fixes: Coverity CID 1558462
> >
>
> I think one of the Coverity issues was about the get_field issue in
> the other thread?
> This doesn't necessarily fix the coverity issue also as the issue
> reported is a false positive.
> But I don't mind citing the coverity issues as it is reported by that.
>
> Is there a link to both coverity issues to know which issue describes
> the out-of-bound access one ?

You can't do deep links into the Coverity Scan UI, but if you
want to ask for an account at https://scan.coverity.com/projects/qemu
we generally give them to any developer who asks.

In this case 1558459 is complaining about the call to
     riscv_pmu_update_fixed_ctrs(env, newpriv, virt_en);
in riscv_cpu_set_mode(), and 1558462 is complaining about the call to
 riscv_cpu_set_mode(env, PRV_M, virt)
in riscv_cpu_do_interrupt().

So it's basically reported the same problem twice, at different
levels in the callstack. I don't know why it's done that, but it's
not that uncommon that the same problem gets detected several ways.

The complaints about get_field/set_field were different: those were
1558461, 1558463. I've already marked those as false-positives in the UI.

(Generally my practice is that where we think there's no point in
making a change to QEMU's code I mark the issue as a false-positive;
where we think it is reasonable to make a change to QEMU's code
(e.g. to aid the human reader or where we think an assert() is useful)
I leave it marked as "bug" to indicate we want to change something,
even if Coverity's analysis is wrong and it's a can't-happen case.)

thanks
-- PMM