Add a new member to struct pstore_info for passing information about
kmesg dump maximum reason. This allows a finer control of what kmesg
dumps are sent to pstore storage backends.

Those backends that do not explicitly set this field (keeping it equal to
0), get the default behavior: store only Oopses and Panics, or everything
if the printk.always_kmsg_dump boot param is set.
Signed-off-by: NPavel Tatashin <pasha.tatashin@soleen.com>
Link: https://lore.kernel.org/lkml/20200515184434.8470-5-keescook@chromium.org/Co-developed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKees Cook <keescook@chromium.org>

The pstore subsystem already had a private version of this function.
With the coming addition of the pstore/zone driver, this needs to be
shared. As it really should live with printk, move it there instead.

Link: https://lore.kernel.org/lkml/20200515184434.8470-4-keescook@chromium.org/Acked-by: NPetr Mladek <pmladek@suse.com>
Acked-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reviewed-by: NPavel Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: NKees Cook <keescook@chromium.org>

To turn the KMSG_DUMP_* reasons into a more ordered list, collapse
the redundant KMSG_DUMP_(RESTART|HALT|POWEROFF) reasons into
KMSG_DUMP_SHUTDOWN. The current users already don't meaningfully
distinguish between them, so there's no need to, as discussed here:
https://lore.kernel.org/lkml/CA+CK2bAPv5u1ih5y9t5FUnTyximtFCtDYXJCpuyjOyHNOkRdqw@mail.gmail.com/

Link: https://lore.kernel.org/lkml/20200515184434.8470-2-keescook@chromium.org/Reviewed-by: NPavel Tatashin <pasha.tatashin@soleen.com>
Reviewed-by: NPetr Mladek <pmladek@suse.com>
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Signed-off-by: NKees Cook <keescook@chromium.org>

It is easier to see how module params are used if they're near the
variables they use.

Link: https://lore.kernel.org/lkml/20200510202436.63222-4-keescook@chromium.org/Signed-off-by: NKees Cook <keescook@chromium.org>

If the pstore backend changes, there's no indication in the logs what
the console is (it always says "pstore"). Instead, pass through the
active backend's name. (Also adjust the selftest to match.)

Link: https://lore.kernel.org/lkml/20200510202436.63222-5-keescook@chromium.org/
Link: https://lore.kernel.org/lkml/20200526135429.GQ12456@shao2-debianSigned-off-by: NKees Cook <keescook@chromium.org>

In order to more cleanly pass around backend names, make the "name" member
const. This means the module param needs to be dynamic (technically, it
was before, so this actually cleans up a minor memory leak if a backend
was specified and then gets unloaded.)

Link: https://lore.kernel.org/lkml/20200510202436.63222-3-keescook@chromium.org/Signed-off-by: NKees Cook <keescook@chromium.org>

The CON_ENABLED flag gets cleared during unregister_console(), so make
sure we already reset the console flags before calling register_console(),
otherwise unloading and reloading a pstore backend will not restart
console logging.
Signed-off-by: NKees Cook <keescook@chromium.org>

If a backend was unloaded without having first removed all its
associated records in pstorefs, subsequent removals would crash while
attempting to call into the now missing backend. Add automatic removal
from the tree in pstore_unregister(), so that no references to the
backend remain.
Reported-by: NLuis Henriques <lhenriques@suse.com>
Link: https://lore.kernel.org/lkml/87o8yrmv69.fsf@suse.com
Link: https://lore.kernel.org/lkml/20200506152114.50375-11-keescook@chromium.org/Signed-off-by: NKees Cook <keescook@chromium.org>

The pstore.update_ms value was being disabled during pstore_unregister(),
which would cause any prior value to go unnoticed on the next
pstore_register(). Instead, just let del_timer() stop the timer, which
was always sufficient. This additionally refactors the timer reset code
and allows the timer to be enabled if the module parameter is changed
away from the default.

Link: https://lore.kernel.org/lkml/20200506152114.50375-10-keescook@chromium.org/Signed-off-by: NKees Cook <keescook@chromium.org>

Nothing was protecting changes to the pstorefs superblock. Add locking
and refactor away is_pstore_mounted(), instead using a helper to add a
way to safely lock the pstorefs root inode during filesystem changes.

Link: https://lore.kernel.org/lkml/20200506152114.50375-9-keescook@chromium.org/Signed-off-by: NKees Cook <keescook@chromium.org>

The pstore backend lock wasn't being used during pstore_unregister().
Add sanity check and locking.

Link: https://lore.kernel.org/lkml/20200506152114.50375-7-keescook@chromium.org/Signed-off-by: NKees Cook <keescook@chromium.org>

Currently pstore can only have a single backend attached at a time, and it
tracks the active backend via "psinfo", under a lock. The locking for this
does not need to be a spinlock, and in order to avoid may_sleep() issues
during future changes to pstore_unregister(), switch to a mutex instead.

Link: https://lore.kernel.org/lkml/20200506152114.50375-4-keescook@chromium.org/Signed-off-by: NKees Cook <keescook@chromium.org>

The name "pstore_lock" sounds very global, but it is only supposed to be
used for managing changes to "psinfo", so rename it accordingly.

Link: https://lore.kernel.org/lkml/20200506152114.50375-3-keescook@chromium.org/Signed-off-by: NKees Cook <keescook@chromium.org>

There is no reason to be doing a module get/put in pstore_register(),
since the module calling pstore_register() cannot be unloaded since it
hasn't finished its initialization. Remove it so there is no confusion
about how registration ordering works.

Link: https://lore.kernel.org/lkml/20200506152114.50375-2-keescook@chromium.org/Signed-off-by: NKees Cook <keescook@chromium.org>

There is a potential mem leak when pstore_init_fs failed,
since the pstore compression maybe unlikey to initialized
successfully. We must clean up the allocation once this
unlikey issue happens.
Signed-off-by: Nchenqiwu <chenqiwu@xiaomi.com>
Link: https://lore.kernel.org/r/1581068800-13817-1-git-send-email-qiwuchen55@gmail.comSigned-off-by: NKees Cook <keescook@chromium.org>

The pstore_choose_compression() function is not exported so make it
static to avoid the following sparse warning:

fs/pstore/platform.c:796:13: warning: symbol 'pstore_choose_compression' was not declared. Should it be static?
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Link: https://lore.kernel.org/r/20191016123317.3154-1-ben.dooks@codethink.co.uk
Fixes: cb095afd ("pstore: Centralize init/exit routines")
Signed-off-by: NKees Cook <keescook@chromium.org>

Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation this program is
  distributed in the hope that it will be useful but without any
  warranty without even the implied warranty of merchantability or
  fitness for a particular purpose see the gnu general public license
  for more details you should have received a copy of the gnu general
  public license along with this program if not write to the free
  software foundation inc 59 temple place suite 330 boston ma 02111
  1307 usa

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 136 file(s).
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NAlexios Zavras <alexios.zavras@intel.com>
Reviewed-by: NAllison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190530000436.384967451@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The ram pstore backend has always had the crash dumper frontend enabled
unconditionally. However, it was possible to effectively disable it
by setting a record_size=0. All the machinery would run (storing dumps
to the temporary crash buffer), but 0 bytes would ultimately get stored
due to there being no przs allocated for dumps. Commit 89d328f6
("pstore/ram: Correctly calculate usable PRZ bytes"), however, assumed
that there would always be at least one allocated dprz for calculating
the size of the temporary crash buffer. This was, of course, not the
case when record_size=0, and would lead to a NULL deref trying to find
the dprz buffer size:

BUG: unable to handle kernel NULL pointer dereference at (null)
...
IP: ramoops_probe+0x285/0x37e (fs/pstore/ram.c:808)

        cxt->pstore.bufsize = cxt->dprzs[0]->buffer_size;

Instead, we need to only enable the frontends based on the success of the
prz initialization and only take the needed actions when those zones are
available. (This also fixes a possible error in detecting if the ftrace
frontend should be enabled.)
Reported-and-tested-by: NYaro Slav <yaro330@gmail.com>
Fixes: 89d328f6 ("pstore/ram: Correctly calculate usable PRZ bytes")
Cc: stable@vger.kernel.org
Signed-off-by: NKees Cook <keescook@chromium.org>

Set tfm to NULL on free_buf_for_compression() after crypto_free_comp().

This avoid a use-after-free when allocate_buf_for_compression()
and free_buf_for_compression() are called twice. Although
free_buf_for_compression() freed the tfm, allocate_buf_for_compression()
won't reinitialize the tfm since the tfm pointer is not NULL.

Fixes: 95047b05 ("pstore: Refactor compression initialization")
Signed-off-by: NPi-Hsun Shih <pihsun@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: NKees Cook <keescook@chromium.org>

Sometimes pstore_console_write() will write records with zero size
to persistent ram zone, which is unnecessary. It will only increase
resource consumption. Also adjust ramoops_write_kmsg_hdr() to have
same logic if memory allocation fails.
Signed-off-by: NYue Hu <huyue2@yulong.com>
Signed-off-by: NKees Cook <keescook@chromium.org>

Instead of running with interrupts disabled, use a semaphore. This should
make it easier for backends that may need to sleep (e.g. EFI) when
performing a write:

|BUG: sleeping function called from invalid context at kernel/sched/completion.c:99
|in_atomic(): 1, irqs_disabled(): 1, pid: 2236, name: sig-xstate-bum
|Preemption disabled at:
|[<ffffffff99d60512>] pstore_dump+0x72/0x330
|CPU: 26 PID: 2236 Comm: sig-xstate-bum Tainted: G      D           4.20.0-rc3 #45
|Call Trace:
| dump_stack+0x4f/0x6a
| ___might_sleep.cold.91+0xd3/0xe4
| __might_sleep+0x50/0x90
| wait_for_completion+0x32/0x130
| virt_efi_query_variable_info+0x14e/0x160
| efi_query_variable_store+0x51/0x1a0
| efivar_entry_set_safe+0xa3/0x1b0
| efi_pstore_write+0x109/0x140
| pstore_dump+0x11c/0x330
| kmsg_dump+0xa4/0xd0
| oops_exit+0x22/0x30
...
Reported-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Fixes: 21b3ddd3 ("efi: Don't use spinlocks for efi vars")
Signed-off-by: NKees Cook <keescook@chromium.org>

In later patches we will need to map types to names, so create a
constant table for that which can also be used in different parts of
old and new code. This saves the type in the PRZ which will be useful
in later patches.

Instead of having an explicit PSTORE_TYPE_UNKNOWN, just use ..._MAX.

This includes removing the now redundant filename templates which can use
a single format string. Also, there's no reason to limit the "is it still
compressed?" test to only PSTORE_TYPE_DMESG when building the pstorefs
filename. Records are zero-initialized, so a backend would need to have
explicitly set compressed=1.
Signed-off-by: NJoel Fernandes (Google) <joel@joelfernandes.org>
Co-developed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKees Cook <keescook@chromium.org>

This improves and updates some comments:
 - dump handler comment out of sync from calling convention
 - fix kern-doc typo

and improves status output:
 - reminder that only kernel crash dumps are compressed
 - do not be silent about ECC infrastructure failures
Signed-off-by: NKees Cook <keescook@chromium.org>

Since the console writer does not use the preallocated crash dump buffer
any more, there is no reason to perform locking around it.

Fixes: 70ad35db ("pstore: Convert console write to use ->write_buf")
Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NJoel Fernandes (Google) <joel@joelfernandes.org>

The pre-allocated compression buffer used for crash dumping was also
being used for decompression. This isn't technically safe, since it's
possible the kernel may attempt a crashdump while pstore is populating the
pstore filesystem (and performing decompression). Instead, just allocate
a separate buffer for decompression. Correctness is preferred over
performance here.
Signed-off-by: NKees Cook <keescook@chromium.org>

This refactors compression initialization slightly to better handle
getting potentially called twice (via early pstore_register() calls
and later pstore_init()) and improves the comments and reporting to be
more verbose.
Signed-off-by: NKees Cook <keescook@chromium.org>
Tested-by: NGuenter Roeck <groeck@chromium.org>

ramoops's call of pstore_register() was recently moved to run during
late_initcall() because the crypto backend may not have been ready during
postcore_initcall(). This meant early-boot crash dumps were not getting
caught by pstore any more.

Instead, lets allow calls to pstore_register() earlier, and once crypto
is ready we can initialize the compression.
Reported-by: NSai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Signed-off-by: NJoel Fernandes (Google) <joel@joelfernandes.org>
Tested-by: NSai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Fixes: cb3bee03 ("pstore: Use crypto compress API")
[kees: trivial rebase]
Signed-off-by: NKees Cook <keescook@chromium.org>
Tested-by: NGuenter Roeck <groeck@chromium.org>

In preparation for having additional actions during init/exit, this moves
the init/exit into platform.c, centralizing the logic to make call outs
to the fs init/exit.
Signed-off-by: NKees Cook <keescook@chromium.org>
Tested-by: NGuenter Roeck <groeck@chromium.org>

This patch added the 6th compression algorithm support for pstore: zstd.
Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
Signed-off-by: NKees Cook <keescook@chromium.org>

This prepares pstore for converting the VFS layer to timespec64.
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NDeepa Dinamani <deepa.kernel@gmail.com>

Commit 58eb5b67 ("pstore: fix crypto dependencies") fixed up the crypto
dependencies but missed the case when no compression is selected.

With CONFIG_PSTORE=y, CONFIG_PSTORE_COMPRESS=n  and CONFIG_CRYPTO=m we see
the following link error:

fs/pstore/platform.o: In function `pstore_register':
(.text+0x1b1): undefined reference to `crypto_has_alg'
(.text+0x205): undefined reference to `crypto_alloc_base'
fs/pstore/platform.o: In function `pstore_unregister':
(.text+0x3b0): undefined reference to `crypto_destroy_tfm'

Fix this by checking at compile-time if CONFIG_PSTORE_COMPRESS is enabled.

Fixes: 58eb5b67 ("pstore: fix crypto dependencies")
Signed-off-by: NTobias Regnery <tobias.regnery@gmail.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NKees Cook <keescook@chromium.org>

The new crypto API use causes some problems with Kconfig dependencies,
including this link error:

fs/pstore/platform.o: In function `pstore_register':
platform.c:(.text+0x248): undefined reference to `crypto_has_alg'
platform.c:(.text+0x2a0): undefined reference to `crypto_alloc_base'
fs/pstore/platform.o: In function `pstore_unregister':
platform.c:(.text+0x498): undefined reference to `crypto_destroy_tfm'
crypto/lz4hc.o: In function `lz4hc_sdecompress':
lz4hc.c:(.text+0x1a): undefined reference to `LZ4_decompress_safe'
crypto/lz4hc.o: In function `lz4hc_decompress_crypto':
lz4hc.c:(.text+0x5a): undefined reference to `LZ4_decompress_safe'
crypto/lz4hc.o: In function `lz4hc_scompress':
lz4hc.c:(.text+0xaa): undefined reference to `LZ4_compress_HC'
crypto/lz4hc.o: In function `lz4hc_mod_init':
lz4hc.c:(.init.text+0xf): undefined reference to `crypto_register_alg'
lz4hc.c:(.init.text+0x1f): undefined reference to `crypto_register_scomp'
lz4hc.c:(.init.text+0x2f): undefined reference to `crypto_unregister_alg'

The problem is that with CONFIG_CRYPTO=m, we must not 'select CRYPTO_LZ4'
from a bool symbol, or call crypto API functions from a built-in
module.

This turns the sub-options into 'tristate' ones so the dependencies
are honored, and makes the pstore itself select the crypto core
if necessary.

Fixes: cb3bee03 ("pstore: Use crypto compress API")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NKees Cook <keescook@chromium.org>

In the pstore compression part, we use zlib/lzo/lz4/lz4hc/842
compression algorithm API to implement pstore compression backends. But
there are many repeat codes in these implementations. This patch uses
crypto compress API to simplify these codes.

1) rewrite allocate_buf_for_compression, free_buf_for_compression,
pstore_compress, pstore_decompress functions using crypto compress API.
2) drop compress, decompress, allocate, free functions in pstore_zbackend,
and add zbufsize function to get each different compress buffer size.
3) use late_initcall to call ramoops_init later, to make sure the crypto
subsystem has already initialized.
4) use 'unsigned int' type instead of 'size_t' in pstore_compress,
pstore_decompress functions' length arguments.
5) rename 'zlib' to 'deflate' to follow the crypto API's name convention.
Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
[kees: tweaked error messages on allocation failures and Kconfig help]
Signed-off-by: NKees Cook <keescook@chromium.org>

To allow for easier build test coverage and run-time testing, this allows
multiple compression algorithms to be built into pstore. Still only one
is supported to operate at a time (which can be selected at build time
or at boot time, similar to how LSMs are selected).
Signed-off-by: NKees Cook <keescook@chromium.org>

Instead of casting, make sure we don't end up with giant values and just
perform regular assignments with unsigned int instead of re-cast size_t.
Signed-off-by: NKees Cook <keescook@chromium.org>

Currently, pstore has supported three compression algorithms: zlib,
lzo and lz4. This patch added two more compression algorithms: lz4hc
and 842.
Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
[kees: tweaked Kconfig help text slightly]
Signed-off-by: NKees Cook <keescook@chromium.org>

Preempt counter APIs have been split out, currently, hardirq.h just
includes irq_enter/exit APIs which are not used by pstore at all.

So, remove the unused hardirq.h.
Signed-off-by: NYang Shi <yang.s@alibaba-inc.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Anton Vorontsov <anton@enomsg.org>
Cc: Colin Cross <ccross@android.com>
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: NKees Cook <keescook@chromium.org>

This changes all DEFINE_TIMER() callbacks to use a struct timer_list
pointer instead of unsigned long. Since the data argument has already been
removed, none of these callbacks are using their argument currently, so
this renames the argument to "unused".

Done using the following semantic patch:

@match_define_timer@
declarer name DEFINE_TIMER;
identifier _timer, _callback;
@@

 DEFINE_TIMER(_timer, _callback);

@change_callback depends on match_define_timer@
identifier match_define_timer._callback;
type _origtype;
identifier _origarg;
@@

 void
-_callback(_origtype _origarg)
+_callback(struct timer_list *unused)
 { ... }
Signed-off-by: NKees Cook <keescook@chromium.org>

__getnstimeofday() is a rather odd interface, with a number of quirks:

- The caller may come from NMI context, but the implementation is not NMI safe,
  one way to get there from NMI is

      NMI handler:
        something bad
          panic()
            kmsg_dump()
              pstore_dump()
                 pstore_record_init()
                   __getnstimeofday()

- The calling conventions are different from any other timekeeping functions,
  to deal with returning an error code during suspended timekeeping.

Address the above issues by using a completely different method to get the
time: ktime_get_real_fast_ns() is NMI safe and has a reasonable behavior
when timekeeping is suspended: it returns the time at which it got
suspended. As Thomas Gleixner explained, this is safe, as
ktime_get_real_fast_ns() does not call into the clocksource driver that
might be suspended.

The result can easily be transformed into a timespec structure. Since
ktime_get_real_fast_ns() was not exported to modules, add the export.

The pstore behavior for the suspended case changes slightly, as it now
stores the timestamp at which timekeeping was suspended instead of storing
a zero timestamp.

This change is not addressing y2038-safety, that's subject to a more
complex follow up patch.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NKees Cook <keescook@chromium.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Anton Vorontsov <anton@enomsg.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Colin Cross <ccross@android.com>
Link: https://lkml.kernel.org/r/20171110152530.1926955-1-arnd@arndb.de

IS_ERR() macro it is already including unlikely().
Signed-off-by: NHirofumi Nakagawa <nklabs@gmail.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>