Received-SPF: pass (google.com: domain of linux-kernel+bounces-48886-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Thu, 01 Feb 2024 23:43:50 +0200
Message-Id: <CYU2JV57VXA9.3C5QTG4LX50TD@suppilovahvero>
Cc: "Jiang, Dave" <dave.jiang@intel.com>, "linux-integrity@vger.kernel.org"
 <linux-integrity@vger.kernel.org>, "linux-cxl@vger.kernel.org"
 <linux-cxl@vger.kernel.org>, "linux-kernel@vger.kernel.org"
 <linux-kernel@vger.kernel.org>, "keyrings@vger.kernel.org"
 <keyrings@vger.kernel.org>, "linux-security-module@vger.kernel.org"
 <linux-security-module@vger.kernel.org>, "nvdimm@lists.linux.dev"
 <nvdimm@lists.linux.dev>
Subject: Re: [PATCH] KEYS: encrypted: Add check for strsep
From: "Jarkko Sakkinen" <jarkko@kernel.org>
To: "Dan Williams" <dan.j.williams@intel.com>, "Verma, Vishal L"
 <vishal.l.verma@intel.com>, "zohar@linux.ibm.com" <zohar@linux.ibm.com>,
 "paul@paul-moore.com" <paul@paul-moore.com>, "dhowells@redhat.com"
 <dhowells@redhat.com>, "yaelt@google.com" <yaelt@google.com>,
 "serge@hallyn.com" <serge@hallyn.com>, "nichen@iscas.ac.cn"
 <nichen@iscas.ac.cn>, "sumit.garg@linaro.org" <sumit.garg@linaro.org>,
 "jmorris@namei.org" <jmorris@namei.org>
References: <20231108073627.1063464-1-nichen@iscas.ac.cn>
 <4d3465b48b9c5a87deb385b15bf5125fc1704019.camel@intel.com>
 <e3275c0cfe21d75e0d71ea3fc24a31252efc9ad6.camel@linux.ibm.com>
 <e3b1a5e532ed86e674385abc4812c5a774f851d4.camel@intel.com>
 <49c48e3e96bf0f5ebef14e7328cc8a6ca6380e08.camel@linux.ibm.com>
 <50c2fa781e3266ee8151afdef5a8659d63ca952e.camel@intel.com>
 <CYS7QMYS8XAJ.2QPI3MS5KXK8E@suppilovahvero>
 <CYS7WMFLXNE1.35OBTKTONKNX3@suppilovahvero>
 <65b93f2b3099b_5cc6f29453@dwillia2-mobl3.amr.corp.intel.com.notmuch>
In-Reply-To: <65b93f2b3099b_5cc6f29453@dwillia2-mobl3.amr.corp.intel.com.notmuch>

On Tue Jan 30, 2024 at 8:25 PM EET, Dan Williams wrote:
> Jarkko Sakkinen wrote:
> > On Tue Jan 30, 2024 at 7:22 PM EET, Jarkko Sakkinen wrote:
> > > On Wed Jan 24, 2024 at 11:10 PM EET, Verma, Vishal L wrote:
> > > > On Wed, 2024-01-24 at 15:40 -0500, Mimi Zohar wrote:
> > > > > On Wed, 2024-01-24 at 20:10 +0000, Verma, Vishal L wrote:
> > > > > > >=20
> > > > > > Ah, thanks for confirming! Would you like me to send a revert p=
atch or
> > > > > > will you do it?
> > > > >=20
> > > > > Revert "KEYS: encrypted: Add check for strsep"
> > > > > =C2=A0=C2=A0=C2=A0=20
> > > > > This reverts commit b4af096b5df5dd131ab796c79cedc7069d8f4882.
> > > > > =C2=A0=C2=A0=C2=A0=20
> > > > > New encrypted keys are created either from kernel-generated rando=
m
> > > > > numbers or user-provided decrypted data.=C2=A0 Revert the change =
requiring
> > > > > user-provided decrypted data.
> > > > >=20
> > > > >=20
> > > > > Can I add your Reported-by?
> > > >
> > > > Yes that works, Thank you.
> > >
> > > This went totally wrong IMHO.
> > >
> > > Priority should be to locate and fix the bug not revert useful stuff
> > > when a bug is found that has limited scope.
> >=20
> > By guidelines here the commit is also a bug fix and reverting
> > such commit means seeding a bug to the mainline. Also the klog
> > message alone is a bug fix here. So also by book it really has
> > to come back as it was already commit because we cannot
> > knowingly mount bugs to the mainline, right?
>
> No, the commit broke userspace. The rule is do not cause regressions
> even if userspace is abusing the ABI in an undesirable way. Even the
> new pr_info() is a log spamming behavior change, a pr_debug() might be
> suitable, but otherwise a logic change here needs a clear description
> about what is broken about the old userspace behavior and why the kernel
> can not possibly safely handle it.

The rationale literally gives empirical proof that the log message
is useful by measure. It would be useless if log level is decreased
to debug, as then sysadmin's won't take notice. I don't really know
what is the definition of "spam" here but at least for me actually
useful log message are not in that category.

Issue was legit but git revert is objectively an incorrect way to
address the bug.

BR, Jarkko