public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
	Matthew Garrett <mjg59@srcf.ucam.org>,
	Peter Jones <pjones@redhat.com>, Tony Luck <tony.luck@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>
Subject: Re: [PATCH v2 1/9] pstore: Don't expose ECC metadata via pstore file system
Date: Tue, 21 Jun 2022 14:19:14 -0700	[thread overview]
Message-ID: <202206211402.1D0B5A4D7@keescook> (raw)
In-Reply-To: <20220621153623.3786960-2-ardb@kernel.org>

On Tue, Jun 21, 2022 at 05:36:15PM +0200, Ard Biesheuvel wrote:
> If a pstore record has its ecc_notice_size field set to >0, it means the
> record's buffer has that many additional bytes appended to the end that
> carry backend specific metadata, typically used for error correction.
> 
> Given that this is backend specific, and that user space cannot really
> make sense of this metadata anyway, let's not expose it via the pstore
> filesystem.
> 
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

"ecc_notice_size" is actually describing the length of the string
generated and appended by persistent_ram_ecc_string().

I've been bothered by this string, though, as it confuses what was
actually stored with additional lines. "Why does every entry end with a
string about ECC?"

I think it's more sensible to show to userspace the record "as stored". We
already prepend some chunking details when a panic write may split the
dump across multiple records, so if anyone needs this IN the userspace
file contents again, it could move there.

I'd rather ECC status be reported at boot, really. Given that nothing I
can find[1] parses the ECC notice string, I think it'd be fine to just
remove it from the string buffer entirely.

-Kees

[1] https://codesearch.debian.net/search?q=Corrected+bytes

-- 
Kees Cook

  reply	other threads:[~2022-06-21 21:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-21 15:36 [PATCH v2 0/9] efi: Restructure EFI varstore driver Ard Biesheuvel
2022-06-21 15:36 ` [PATCH v2 1/9] pstore: Don't expose ECC metadata via pstore file system Ard Biesheuvel
2022-06-21 21:19   ` Kees Cook [this message]
2022-06-21 15:36 ` [PATCH v2 2/9] efi: vars: Don't drop lock in the middle of efivar_init() Ard Biesheuvel
2022-06-21 15:36 ` [PATCH v2 3/9] efi: vars: Add thin wrapper around EFI get/set variable interface Ard Biesheuvel
2022-06-21 15:36 ` [PATCH v2 4/9] efi: pstore: Omit efivars caching EFI varstore access layer Ard Biesheuvel
2022-06-21 21:00   ` Kees Cook
2022-06-21 21:12     ` Ard Biesheuvel
2022-06-21 21:21       ` Kees Cook
2022-06-21 21:33         ` Ard Biesheuvel
2022-06-21 22:00           ` Kees Cook
2022-06-21 15:36 ` [PATCH v2 5/9] efi: vars: Use locking version to iterate over efivars linked lists Ard Biesheuvel
2022-06-21 15:36 ` [PATCH v2 6/9] efi: vars: Drop __efivar_entry_iter() helper which is no longer used Ard Biesheuvel
2022-06-21 15:36 ` [PATCH v2 7/9] efi: vars: Remove deprecated 'efivars' sysfs interface Ard Biesheuvel
2022-06-21 15:36 ` [PATCH v2 8/9] efi: vars: Switch to new wrapper layer Ard Biesheuvel
2022-06-21 15:36 ` [PATCH v2 9/9] efi: vars: Move efivar caching layer into efivarfs Ard Biesheuvel

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=202206211402.1D0B5A4D7@keescook \
    --to=keescook@chromium.org \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=mjg59@srcf.ucam.org \
    --cc=pjones@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox