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
| ||
|
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
Powered by blists - more mailing lists