Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
MIME-Version: 1.0
References: <20231212235003.2036221-1-debug@rivosinc.com> <mhng-ae72b5fd-358d-48e2-87cf-f571b67afe9e@palmer-ri-x1c9a>
 <ZXkCs9ypok5X/Wx2@debug.ba.rivosinc.com> <20231213-707b4e8b5a91ceedd557eb12@orel>
In-Reply-To: <20231213-707b4e8b5a91ceedd557eb12@orel>
From:   Deepak Gupta <debug@rivosinc.com>
Date:   Wed, 13 Dec 2023 08:27:46 -0800
Message-ID: <CAKC1njQ16drCZzWCS8PuX1U7x1UfC3bwpEmeizs1L5z4KHFaPw@mail.gmail.com>
Subject: Re: [PATCH v1 2/2] riscv: envcfg save and restore on trap entry/exit
To:     Andrew Jones <ajones@ventanamicro.com>
Cc:     Palmer Dabbelt <palmer@dabbelt.com>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        aou@eecs.berkeley.edu, apatel@ventanamicro.com, guoren@kernel.org,
        mchitale@ventanamicro.com, waylingii@gmail.com,
        greentime.hu@sifive.com, samitolvanen@google.com,
        Bjorn Topel <bjorn@rivosinc.com>,
        Conor Dooley <conor.dooley@microchip.com>,
        jeeheng.sia@starfivetech.com, Heiko Stuebner <heiko@sntech.de>,
        Evan Green <evan@rivosinc.com>, jszhang@kernel.org,
        cleger@rivosinc.com, linux-riscv@lists.infradead.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Dec 13, 2023 at 4:24=E2=80=AFAM Andrew Jones <ajones@ventanamicro.c=
om> wrote:
>
> On Tue, Dec 12, 2023 at 05:02:43PM -0800, Deepak Gupta wrote:
> > On Tue, Dec 12, 2023 at 04:53:48PM -0800, Palmer Dabbelt wrote:
> > > On Tue, 12 Dec 2023 15:49:25 PST (-0800), debug@rivosinc.com wrote:
> > > > envcfg CSR defines enabling bits for cache management instructions =
and soon
> > > > will control enabling for control flow integrity and pointer maskin=
g features.
> > > >
> > > > Control flow integrity and pointer masking features need to be enab=
led on per
> > > > thread basis. Additionally, I believe cache management instructions=
 need to be
> > > > enabled on per thread basis. As an example a seccomped task on risc=
v may be
> > > > restricted to not use cache management instructions
> > >
> > > Do we have anything in the kernel that actually does that?  Generally=
 we
> > > need some use, I couldn't find any user-mode writable envcfg bits in =
any
> > > extesions I looked at (admittidly just CFI and pointer masking), and
> > > unless I'm missing something there's no per-thread state in the kerne=
l.
> > >
> >
> > Cache management operations?
> > As of now kernel blindly enables that for all the user mode. It will be=
 good if
> > that is enabled on per-thread basis. Sure, all threads can have it enab=
led by
> > default. But if strict seccomp is enabled, I would argue that cache man=
agement
> > operations for that thread to be disabled as is done on other arches. A=
s an
> > example x86 disable rdtsc on strict seccomp. RISCV allows this CMO exte=
nsion
> > and I expect CMO to leverage this (currently it
> > doesn't).
> >
> > I was being opportunistic here so that I can reduce number of patches o=
n CFI
> > enabling patchset.
> >
> > Will it be okay if I revise this patch to include with a usecase to res=
trict CMO
> > (say for case of strict seccomp on risc-v)?
>
> I opted to only expose cache block zero since giving userspace the
> ability to invalidate cache blocks seems risky from a side-channel attack
> perspective.

I didn't pay attention. You're right, it's only cbo.zero that's exposed.
I will roll up my patch with cfi set then.

>
> I'm no security expert, so feedback welcome, but I don't see a risk with
> userspace being granted cbo.zero, even for strict seccomp processes.

Yeah I don't see a risk with cbo.zero to strict seccomp thread either.

>
> Thanks,
> drew