From: Heiko Carstens <hca@linux.ibm.com>
To: Janosch Frank <frankja@linux.ibm.com>
Cc: Steffen Eiden <seiden@linux.ibm.com>,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
Ingo Franzki <ifranzki@linux.ibm.com>,
Christoph Schlameuss <schlameuss@linux.ibm.com>,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
borntraeger@linux.ibm.com
Subject: Re: [PATCH v3] s390/uvdevice: Support longer secret lists
Date: Wed, 6 Nov 2024 10:13:45 +0100 [thread overview]
Message-ID: <20241106091345.16507-B-hca@linux.ibm.com> (raw)
In-Reply-To: <a74cfc12-f404-47ca-85a8-164da22bdbfc@linux.ibm.com>
On Wed, Nov 06, 2024 at 09:54:33AM +0100, Janosch Frank wrote:
> On 11/6/24 9:10 AM, Heiko Carstens wrote:
> > On Mon, Nov 04, 2024 at 04:36:09PM +0100, Steffen Eiden wrote:
> > > + copy_len = sizeof(list->secrets[0]) * list->num_secr_stored;
> > > + WARN_ON(copy_len > sizeof(list->secrets));
> >
> > Is this really possible? Without checking the documentation I guess
> > this is not possible and therefore the WARN_ON() should be removed.
> >
>
> This happening requires a FW error, no?
> list->num_secr_stored is reported by FW and would need to be >85.
>
> We could clamp it down to 85 secrets / 4k - sizeof(header) with a
> WARN_ON_ONCE() to catch FW problems if that suits you more.
If this would be an *error* why even add this check? We have tons of
code without doing sanity checks for firmware provided values - where
should we start or end?
So imho: either remove this check if this would be firmware error,
unless there is a good reason do keep this check, or if this is not an
error convert to WARN_ON_ONCE() and limit the copy_to_user().
next prev parent reply other threads:[~2024-11-06 9:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-04 15:36 [PATCH v3] s390/uvdevice: Support longer secret lists Steffen Eiden
2024-11-05 13:09 ` Janosch Frank
2024-11-05 16:07 ` Christoph Schlameuss
2024-11-06 8:10 ` Heiko Carstens
2024-11-06 8:54 ` Janosch Frank
2024-11-06 9:13 ` Heiko Carstens [this message]
2024-11-06 12:18 ` Steffen Eiden
2024-11-06 12:25 ` [PATCH v4] " Steffen Eiden
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241106091345.16507-B-hca@linux.ibm.com \
--to=hca@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=frankja@linux.ibm.com \
--cc=ifranzki@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=schlameuss@linux.ibm.com \
--cc=seiden@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.