Commits · c10e8031d5b34cde06b039ca2e8af87a33d5ba11 · Kirill Smelkov / linux

22 May, 2017 1 commit

efi-pstore: Fix write/erase id tracking · c10e8031

Kees Cook authored May 18, 2017

Prior to the pstore interface refactoring, the "id" generated during
a backend pstore_write() was only retained by the internal pstore
inode tracking list. Additionally the "part" was ignored, so EFI
would encode this in the id. This corrects the misunderstandings
and correctly sets "id" during pstore_write(), and uses "part"
directly during pstore_erase().
Reported-by: Marta Lofstedt <marta.lofstedt@intel.com>
Fixes: 76cc9580 ("pstore: Replace arguments for write() API")
Fixes: a61072aa ("pstore: Replace arguments for erase() API")
Signed-off-by: Kees Cook <keescook@chromium.org>
Tested-by: Marta Lofstedt <marta.lofstedt@intel.com>

c10e8031

16 May, 2017 1 commit

efi-pstore: Fix read iter after pstore API refactor · 6f61dd3a

Kees Cook authored May 12, 2017

During the internal pstore API refactoring, the EFI vars read entry was
accidentally made to update a stack variable instead of the pstore
private data pointer. This corrects the problem (and removes the now
needless argument).

Fixes: 125cc42b ("pstore: Replace arguments for read() API")
Signed-off-by: Kees Cook <keescook@chromium.org>

6f61dd3a

28 Apr, 2017 1 commit

pstore: Solve lockdep warning by moving inode locks · 3a7d2fd1

Kees Cook authored Apr 27, 2017

Lockdep complains about a possible deadlock between mount and unlink
(which is technically impossible), but fixing this improves possible
future multiple-backend support, and keeps locking in the right order.

The lockdep warning could be triggered by unlinking a file in the
pstore filesystem:

  -> #1 (&sb->s_type->i_mutex_key#14){++++++}:
         lock_acquire+0xc9/0x220
         down_write+0x3f/0x70
         pstore_mkfile+0x1f4/0x460
         pstore_get_records+0x17a/0x320
         pstore_fill_super+0xa4/0xc0
         mount_single+0x89/0xb0
         pstore_mount+0x13/0x20
         mount_fs+0xf/0x90
         vfs_kern_mount+0x66/0x170
         do_mount+0x190/0xd50
         SyS_mount+0x90/0xd0
         entry_SYSCALL_64_fastpath+0x1c/0xb1

  -> #0 (&psinfo->read_mutex){+.+.+.}:
         __lock_acquire+0x1ac0/0x1bb0
         lock_acquire+0xc9/0x220
         __mutex_lock+0x6e/0x990
         mutex_lock_nested+0x16/0x20
         pstore_unlink+0x3f/0xa0
         vfs_unlink+0xb5/0x190
         do_unlinkat+0x24c/0x2a0
         SyS_unlinkat+0x16/0x30
         entry_SYSCALL_64_fastpath+0x1c/0xb1

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(&sb->s_type->i_mutex_key#14);
                                lock(&psinfo->read_mutex);
                                lock(&sb->s_type->i_mutex_key#14);
   lock(&psinfo->read_mutex);
Reported-by: Marta Lofstedt <marta.lofstedt@intel.com>
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Namhyung Kim <namhyung@kernel.org>

3a7d2fd1

27 Apr, 2017 2 commits

pstore: Fix flags to enable dumps on powerpc · 041939c1

Ankit Kumar authored Apr 27, 2017

After commit c950fd6f kernel registers pstore write based on flag set.
Pstore write for powerpc is broken as flags(PSTORE_FLAGS_DMESG) is not set for
powerpc architecture. On panic, kernel doesn't write message to
/fs/pstore/dmesg*(Entry doesn't gets created at all).

This patch enables pstore write for powerpc architecture by setting
PSTORE_FLAGS_DMESG flag.

Fixes: c950fd6f ("pstore: Split pstore fragile flags")
Cc: stable@vger.kernel.org # v4.9+
Signed-off-by: Ankit Kumar <ankit@linux.vnet.ibm.com>
Signed-off-by: Kees Cook <keescook@chromium.org>

041939c1

pstore: Remove unused vmalloc.h in pmsg · 3509d048

Geliang Tang authored Mar 23, 2017

Since the vmalloc code has been removed from write_pmsg() in the commit
"5bf6d1b9 pstore/pmsg: drop bounce buffer", remove the unused header
vmalloc.h.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Kees Cook <keescook@chromium.org>

3509d048

07 Mar, 2017 20 commits

pstore: simplify write_user_compat() · 30800d99

Kees Cook authored Mar 07, 2017

Nothing actually uses write_user_compat() currently, but there is no
reason to reuse the dmesg buffer. Instead, just allocate a new record
buffer, copy in from userspace, and pass it to write() as normal.
Signed-off-by: Kees Cook <keescook@chromium.org>

30800d99

pstore: Remove write_buf() callback · 4c9ec219

Kees Cook authored Mar 05, 2017

Now that write() and write_buf() are functionally identical, this removes
write_buf(), and renames write_buf_user() to write_user(). Additionally
adds sanity-checks for pstore_info's declared functions and flags at
registration time.
Signed-off-by: Kees Cook <keescook@chromium.org>

4c9ec219

pstore: Replace arguments for write_buf_user() API · fdd03118

Kees Cook authored Mar 05, 2017

Removes argument list in favor of pstore record, though the user buffer
remains passed separately since it must carry the __user annotation.
Signed-off-by: Kees Cook <keescook@chromium.org>

fdd03118

pstore: Replace arguments for write_buf() API · b10b4711

Kees Cook authored Mar 05, 2017

As with the other API updates, this removes the long argument list in favor
of passing a single pstore recaord.
Signed-off-by: Kees Cook <keescook@chromium.org>

b10b4711

pstore: Replace arguments for erase() API · a61072aa

Kees Cook authored Mar 04, 2017

This removes the argument list for the erase() callback and replaces it
with a pointer to the backend record details to be removed.
Signed-off-by: Kees Cook <keescook@chromium.org>

a61072aa

pstore: Do not duplicate record metadata · 83f70f07

Kees Cook authored Mar 04, 2017

This switches the inode-private data from carrying duplicate metadata to
keeping the record passed in during pstore_mkfile().
Signed-off-by: Kees Cook <keescook@chromium.org>

83f70f07

pstore: Allocate records on heap instead of stack · 2a2b0acf

Kees Cook authored Mar 04, 2017

In preparation for handling records off to pstore_mkfile(), allocate the
record instead of reusing stack. This still always frees the record,
though, since pstore_mkfile() isn't yet keeping it.
Signed-off-by: Kees Cook <keescook@chromium.org>

2a2b0acf

pstore: Pass record contents instead of copying · 1dfff7dd

Kees Cook authored Mar 04, 2017

pstore_mkfile() shouldn't have to memcpy the record contents. It can use
the existing copy instead. This adjusts the allocation lifetime management
and renames the contents variable from "data" to "buf" to assist moving to
struct pstore_record in the future.
Signed-off-by: Kees Cook <keescook@chromium.org>

1dfff7dd

pstore: Always allocate buffer for decompression · 7e8cc8dc

Kees Cook authored Mar 04, 2017

Currently, pstore_mkfile() performs a memcpy() of the record contents,
so it can live anywhere. However, this is needlessly wasteful. In
preparation of pstore_mkfile() keeping the record contents, always
allocate a buffer for the contents.
Signed-off-by: Kees Cook <keescook@chromium.org>

7e8cc8dc

pstore: Replace arguments for write() API · 76cc9580