Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <324df0fa5ad1f0508c5f62c25dd1f8d297d78813.camel@kernel.org>
Subject: Re: [PATCH] tpm: factor out the user space mm from
 tpm_vtpm_set_locality()
From:   Jarkko Sakkinen <jarkko@kernel.org>
To:     Stefan Berger <stefanb@linux.ibm.com>,
        linux-integrity@vger.kernel.org
Cc:     Jason Gunthorpe <jgg@nvidia.com>,
        Alejandro Cabrera <alejandro.cabreraaldaya@tuni.fi>,
        Jarkko Sakkinen <jarkko.sakkinen@tuni.fi>,
        stable@vger.kernel.org, Stefan Berger <stefanb@linux.vnet.ibm.com>,
        linux-kernel@vger.kernel.org
Date:   Wed, 31 May 2023 19:32:16 +0300
In-Reply-To: <8f15feb5-7c6e-5a16-d9b4-008b7b45b01a@linux.ibm.com>
References: <20230530205001.1302975-1-jarkko@kernel.org>
         <8f15feb5-7c6e-5a16-d9b4-008b7b45b01a@linux.ibm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.1-0ubuntu1 
MIME-Version: 1.0
Precedence: bulk

On Wed, 2023-05-31 at 11:20 -0400, Stefan Berger wrote:
>=20
> On 5/30/23 16:50, Jarkko Sakkinen wrote:
> > From: Jarkko Sakkinen <jarkko.sakkinen@tuni.fi>
> >=20
> > vtpm_proxy_fops_set_locality() causes kernel buffers to be passed to
> > copy_from_user() and copy_to_user().
>=20
> And what is the problem with that? Is it not working?

It is API contract and also clearly documented in the kernel documentation.

This should be obvious even if you have've consulted that documentation bec=
ause
both functions have 'user' suffix, and also the pointer is __user tagged.

To make things worse it is architecture specific. I'm worried that it will
break in one of the 23 microarchitectures. Have you actually ever checked i=
t
does not?

I'm not also an expert of how all the possible CPUs in the world empower
Linux to further restrict the move between different memory spaces. I'm
quite sure that this does conflict neither with SMAP or SMEP on x86
(because I know x86 pretty well), but who knows what they add in the
future to the microarchitecture.

> > Factor out the crippled code away with help of an internal API for
> > managing struct proxy_dev instances.
>=20
> What is crippled code?

Code that behaves badly, i.e. does not meat the expectations. Illegit use o=
f
in-kernel functions easily fits to the definition of crippled code.

Bad API behavior put aside, it is very inefficient implementation because i=
t
unnecessarily recurses tpm_transmit(), which makes extending the driver to
any direction so much involved process, but we don't really need this as a
rationale.

This needs to be fixed in a way or another. That is dictated by the API
cotract so for that I do not really even need feedback because it is
force majeure. I'm cool with alternatives or suggestions to the current
fact, so please focus on that instead of asking question that kernel
documentation provides you already all the answers.

BR, Jarkko