From: Ard Biesheuvel <ardb@kernel.org>
To: James Morse <james.morse@arm.com>
Cc: Joe Perches <joe@perches.com>, Borislav Petkov <bp@alien8.de>,
Tony Luck <tony.luck@intel.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <lenb@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-tip-commits@vger.kernel.org,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
X86 ML <x86@kernel.org>
Subject: Re: [tip: efi/core] efi: cper: fix scnprintf() use in cper_mem_err_location()
Date: Wed, 1 Sep 2021 08:50:47 +0200 [thread overview]
Message-ID: <CAMj1kXGs36bL111qfv8HsOxuZ_GAHTkCSij7qzp7E_mprk=EgQ@mail.gmail.com> (raw)
In-Reply-To: <44c6c9b3-bade-41ab-2166-b4cd1ed97408@arm.com>
On Tue, 31 Aug 2021 at 18:02, James Morse <james.morse@arm.com> wrote:
>
> Hi guys,
>
> On 28/08/2021 13:18, Ard Biesheuvel wrote:
> > (add RAS/APEI folks)
> >
> > On Sat, 28 Aug 2021 at 13:31, Joe Perches <joe@perches.com> wrote:
> >>
> >> On Sat, 2021-08-28 at 10:37 +0000, tip-bot2 for Rasmus Villemoes wrote:
> >>> The following commit has been merged into the efi/core branch of tip:
> >> []
> >>> efi: cper: fix scnprintf() use in cper_mem_err_location()
> >>>
> >>> The last two if-clauses fail to update n, so whatever they might have
> >>> written at &msg[n] would be cut off by the final nul-termination.
> >>>
> >>> That nul-termination is redundant; scnprintf(), just like snprintf(),
> >>> guarantees a nul-terminated output buffer, provided the buffer size is
> >>> positive.
> >>>
> >>> And there's no need to discount one byte from the initial buffer;
> >>> vsnprintf() expects to be given the full buffer size - it's not going
> >>> to write the nul-terminator one beyond the given (buffer, size) pair.
> >> []
> >>> diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
> >> []
> >>> @@ -221,7 +221,7 @@ static int cper_mem_err_location(struct cper_mem_err_compact *mem, char *msg)
> >>> return 0;
> >>>
> >>>
> >>> n = 0;
> >>> - len = CPER_REC_LEN - 1;
> >>> + len = CPER_REC_LEN;
> >>> if (mem->validation_bits & CPER_MEM_VALID_NODE)
> >>> n += scnprintf(msg + n, len - n, "node: %d ", mem->node);
> >>> if (mem->validation_bits & CPER_MEM_VALID_CARD)
> >>
> >> [etc...]
> >>
> >> Is this always single threaded?
> >>
> >> It doesn't seem this is safe for reentry as the output buffer
> >> being written into is a single static
> >>
> >> static char rcd_decode_str[CPER_REC_LEN];
>
> > Good question. CPER error record decoding typically occurs in response
> > to an error event raised by firmware, so I think this happens to work
> > fine in practice. Whether this is guaranteed, I'm not so sure ...
>
> There is locking to prevent concurrent access to the firmware buffer, but that only
> serialises the CPER records being copied. The printing may happen in parallel on different
> CPUs if there are multiple errors.
>
> cper_estatus_print() is called in NMI context if an NMI indicates a fatal error. See
> __ghes_panic().
>
OK, better to fix it then - there does not seem to be a good reason
for using a buffer in BSS here anyway.
I'll send out a patch.
Thanks,
Ard.
prev parent reply other threads:[~2021-09-01 6:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-28 10:37 [tip: efi/core] efi: cper: fix scnprintf() use in cper_mem_err_location() tip-bot2 for Rasmus Villemoes
2021-08-28 11:22 ` Joe Perches
2021-08-28 12:18 ` Ard Biesheuvel
2021-08-31 16:02 ` James Morse
2021-09-01 6:50 ` Ard Biesheuvel [this message]
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='CAMj1kXGs36bL111qfv8HsOxuZ_GAHTkCSij7qzp7E_mprk=EgQ@mail.gmail.com' \
--to=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=james.morse@arm.com \
--cc=joe@perches.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=rjw@rjwysocki.net \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).