linux.git/fs/pstore, branch v6.7

Merge tag 'pstore-v6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

2023-10-31T05:26:39+00:00

Pull pstore updates from Kees Cook:

 - Check for out-of-memory condition during initialization (Jiasheng
   Jiang)

 - Fix documentation typos (Tudor Ambarus)

* tag 'pstore-v6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
  pstore/platform: Add check for kstrdup
  docs: pstore-blk.rst: fix typo, s/console/ftrace
  docs: pstore-blk.rst: use "about" as a preposition after "care"

pstore: convert to new timestamp accessors

2023-10-18T12:08:26+00:00

Convert to using the new inode timestamp accessor functions.

Signed-off-by: Jeff Layton 
Link: https://lore.kernel.org/r/20231004185347.80880-60-jlayton@kernel.org
Acked-by: Kees Cook 
Signed-off-by: Christian Brauner

pstore/platform: Add check for kstrdup

2023-10-12T16:47:01+00:00

Add check for the return value of kstrdup() and return the error
if it fails in order to avoid NULL pointer dereference.

Fixes: 563ca40ddf40 ("pstore/platform: Switch pstore_info::name to const")
Signed-off-by: Jiasheng Jiang 
Link: https://lore.kernel.org/r/20230623022706.32125-1-jiasheng@iscas.ac.cn
Signed-off-by: Kees Cook

Merge tag 'pstore-v6.6-rc1-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

2023-09-02T17:45:17+00:00

Pull pstore fix from Kees Cook:

 - Adjust sizes of buffers just avoid uncompress failures (Ard
   Biesheuvel)

* tag 'pstore-v6.6-rc1-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
  pstore: Base compression input buffer size on estimated compressed size

pstore: Base compression input buffer size on estimated compressed size

2023-08-31T20:58:49+00:00

Commit 1756ddea6916 ("pstore: Remove worst-case compression size logic")
removed some clunky per-algorithm worst case size estimation routines on
the basis that we can always store pstore records uncompressed, and
these worst case estimations are about how much the size might
inadvertently *increase* due to encapsulation overhead when the input
cannot be compressed at all. So if compression results in a size
increase, we just store the original data instead.

However, it seems that the original code was misinterpreting these
calculations as an estimation of how much uncompressed data might fit
into a compressed buffer of a given size, and it was using the results
to consume the input data in larger chunks than the pstore record size,
relying on the compression to ensure that what ultimately gets stored
fits into the available space.

One result of this, as observed and reported by Linus, is that upgrading
to a newer kernel that includes the given commit may result in pstore
decompression errors reported in the kernel log. This is due to the fact
that the existing records may unexpectedly decompress to a size that is
larger than the pstore record size.

Another potential problem caused by this change is that we may
underutilize the fixed sized records on pstore backends such as ramoops.
And on pstore backends with variable sized records such as EFI, we will
end up creating many more entries than before to store the same amount
of compressed data.

So let's fix both issues, by bringing back the typical case estimation of
how much ASCII text captured from the dmesg log might fit into a pstore
record of a given size after compression. The original implementation
used the computation given below for zlib:

  switch (size) {
  /* buffer range for efivars */
  case 1000 ... 2000:
  	cmpr = 56;
  	break;
  case 2001 ... 3000:
  	cmpr = 54;
  	break;
  case 3001 ... 3999:
  	cmpr = 52;
  	break;
  /* buffer range for nvram, erst */
  case 4000 ... 10000:
  	cmpr = 45;
  	break;
  default:
  	cmpr = 60;
  	break;
  }

  return (size * 100) / cmpr;

We will use the previous worst-case of 60% for compression. For
decompression go extra large (3x) so we make sure there's enough space
for anything.

While at it, rate limit the error message so we don't flood the log
unnecessarily on systems that have accumulated a lot of pstore history.

Cc: Linus Torvalds 
Cc: Eric Biggers 
Cc: Kees Cook 
Cc: Herbert Xu 
Signed-off-by: Ard Biesheuvel 
Link: https://lore.kernel.org/r/20230830212238.135900-1-ardb@kernel.org
Co-developed-by: Kees Cook 
Signed-off-by: Kees Cook

Merge tag 'pstore-v6.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

2023-08-28T19:36:04+00:00

Pull pstore updates from Kees Cook:

 - Greatly simplify compression support (Ard Biesheuvel)

 - Avoid crashes for corrupted offsets when prz size is 0 (Enlin Mu)

 - Expand range of usable record sizes (Yuxiao Zhang)

 - Fix kernel-doc warning (Matthew Wilcox)

* tag 'pstore-v6.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
  pstore: Fix kernel-doc warning
  pstore: Support record sizes larger than kmalloc() limit
  pstore/ram: Check start of empty przs during init
  pstore: Replace crypto API compression with zlib_deflate library calls
  pstore: Remove worst-case compression size logic

pstore: Fix kernel-doc warning

2023-08-18T20:27:28+00:00

Fix the warning for the description of struct persistent_ram_buffer and
improve the descriptions of the other struct members while I'm here.

Signed-off-by: "Matthew Wilcox (Oracle)" 
Link: https://lore.kernel.org/r/20230818201253.2729485-1-willy@infradead.org
Signed-off-by: Kees Cook

pstore: Support record sizes larger than kmalloc() limit

2023-08-17T22:18:24+00:00

Currently pstore record buffers are allocated using kmalloc() which has
a maximum size based on page size. If a large "pmsg-size" module
parameter is specified, pmsg will fail to copy the contents since
memdup_user() is limited to kmalloc() allocation sizes.

Since we don't need physically contiguous memory for any of the pstore
record buffers, use kvzalloc() to avoid such limitations in the core of
pstore and in the ram backend, and explicitly read from userspace using
vmemdup_user(). This also means that any other backends that want to
(or do already) support larger record sizes will Just Work now.

Signed-off-by: Yuxiao Zhang 
Link: https://lore.kernel.org/r/20230627202540.881909-2-yuxiaozhang@google.com
Co-developed-by: Kees Cook 
Signed-off-by: Kees Cook

pstore/ram: Check start of empty przs during init

2023-08-04T17:03:20+00:00

After commit 30696378f68a ("pstore/ram: Do not treat empty buffers as
valid"), initialization would assume a prz was valid after seeing that
the buffer_size is zero (regardless of the buffer start position). This
unchecked start value means it could be outside the bounds of the buffer,
leading to future access panics when written to:

 sysdump_panic_event+0x3b4/0x5b8
 atomic_notifier_call_chain+0x54/0x90
 panic+0x1c8/0x42c
 die+0x29c/0x2a8
 die_kernel_fault+0x68/0x78
 __do_kernel_fault+0x1c4/0x1e0
 do_bad_area+0x40/0x100
 do_translation_fault+0x68/0x80
 do_mem_abort+0x68/0xf8
 el1_da+0x1c/0xc0
 __raw_writeb+0x38/0x174
 __memcpy_toio+0x40/0xac
 persistent_ram_update+0x44/0x12c
 persistent_ram_write+0x1a8/0x1b8
 ramoops_pstore_write+0x198/0x1e8
 pstore_console_write+0x94/0xe0
 ...

To avoid this, also check if the prz start is 0 during the initialization
phase. If not, the next prz sanity check case will discover it (start >
size) and zap the buffer back to a sane state.

Fixes: 30696378f68a ("pstore/ram: Do not treat empty buffers as valid")
Cc: Yunlong Xing 
Cc: stable@vger.kernel.org
Signed-off-by: Enlin Mu 
Link: https://lore.kernel.org/r/20230801060432.1307717-1-yunlong.xing@unisoc.com
[kees: update commit log with backtrace and clarifications]
Signed-off-by: Kees Cook

pstore: convert to ctime accessor functions

2023-07-24T08:30:03+00:00

In later patches, we're going to change how the inode's ctime field is
used. Switch to using accessor functions instead of raw accesses of
inode->i_ctime.

Acked-by: Kees Cook 
Signed-off-by: Jeff Layton 
Reviewed-by: Jan Kara 
Message-Id: <20230705190309.579783-66-jlayton@kernel.org>
Signed-off-by: Christian Brauner