linux-kernel - RE: [PATCH] pstore/ram: Clarify resource reservation labels

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 18 Oct 2018 22:43:12 +0000
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Kees Cook <keescook@...omium.org>,
        "Williams, Dan J" <dan.j.williams@...el.com>
CC:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Anton Vorontsov <anton@...msg.org>,
        Colin Cross <ccross@...roid.com>,
        Joel Fernandes <joel@...lfernandes.org>,
        Ross Zwisler <zwisler@...gle.com>
Subject: RE: [PATCH] pstore/ram: Clarify resource reservation labels

> If the filesystem existed on the namespace before the user specified
> the ramoops command line then ramoops will clobber the filesystem and
> the user will only find out when mount later fails. All the kernel
> will say is:
>
>     dev_warn(dev, "could not reserve region %pR\n", res);
>
> ...from the pmem driver, and then the only way to figure who the
> conflict is with is to look at /proc/iomem, but the damage is already
> likely done by that point.

When you set up a ramoops region in pmem, write a magic header block
at the start of the area.  Then when pstore/ramoops goes to find the
region, it checks for the magic header.  Not there? Don't write to the
region. Problem solved.

-Tony