linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v4 4/5] pstore: add pmsg
@ 2015-01-14  0:16 Mark Salyzyn
  2015-01-14 18:16 ` Kees Cook
       [not found] ` <871tmfz06r.fsf%stlman@poczta.fm>
  0 siblings, 2 replies; 8+ messages in thread
From: Mark Salyzyn @ 2015-01-14  0:16 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mark Salyzyn, Anton Vorontsov, Colin Cross, Kees Cook, Tony Luck

A secured user-space accessible pstore object. Writes
to /dev/pmsg0 are appended to the buffer, on reboot
the persistent contents are available in
/sys/fs/pstore/pmsg-ramoops-[ID].

One possible use is syslogd, or other daemon, can
write messages, then on reboot provides a means to
triage user-space activities leading up to a panic
as a companion to the pstore dmesg or console logs.

Signed-off-by: Mark Salyzyn <salyzyn@android.com>
---
v2: switch from snprintf to scnprintf
v3: split out prz_ok checking into PATCH 3/5
    replace pmsg_lseek with noop_llseek
    use pr_fmt() macro
    make write atomic and use a vmalloc'd bounce buffer
v4: use mutex_lock instead of of spin_lock.

 fs/pstore/Kconfig          |  10 ++++
 fs/pstore/Makefile         |   2 +
 fs/pstore/inode.c          |   3 ++
 fs/pstore/internal.h       |   6 +++
 fs/pstore/platform.c       |   1 +
 fs/pstore/pmsg.c           | 114 +++++++++++++++++++++++++++++++++++++++++++++
 fs/pstore/ram.c            |  34 +++++++++++++-
 include/linux/pstore.h     |   1 +
 include/linux/pstore_ram.h |   1 +
 9 files changed, 170 insertions(+), 2 deletions(-)
 create mode 100644 fs/pstore/pmsg.c

diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
index 983d951..916b8e2 100644
--- a/fs/pstore/Kconfig
+++ b/fs/pstore/Kconfig
@@ -21,6 +21,16 @@ config PSTORE_CONSOLE
 	  When the option is enabled, pstore will log all kernel
 	  messages, even if no oops or panic happened.
 
+config PSTORE_PMSG
+	bool "Log user space messages"
+	depends on PSTORE
+	help
+	  When the option is enabled, pstore will export a character
+	  interface /dev/pmsg0 to log user space messages. On reboot
+	  data can be retrieved from /sys/fs/pstore/pmsg-ramoops-[ID].
+
+	  If unsure, say N.
+
 config PSTORE_FTRACE
 	bool "Persistent function tracer"
 	depends on PSTORE
diff --git a/fs/pstore/Makefile b/fs/pstore/Makefile
index 4c9095c..e647d8e 100644
--- a/fs/pstore/Makefile
+++ b/fs/pstore/Makefile
@@ -7,5 +7,7 @@ obj-y += pstore.o
 pstore-objs += inode.o platform.o
 obj-$(CONFIG_PSTORE_FTRACE)	+= ftrace.o
 
+obj-$(CONFIG_PSTORE_PMSG)	+= pmsg.o
+
 ramoops-objs += ram.o ram_core.o
 obj-$(CONFIG_PSTORE_RAM)	+= ramoops.o
diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
index d69586f..b32ce53 100644
--- a/fs/pstore/inode.c
+++ b/fs/pstore/inode.c
@@ -361,6 +361,9 @@ int pstore_mkfile(enum pstore_type_id type, char *psname, u64 id, int count,
 		scnprintf(name, sizeof(name), "powerpc-common-%s-%lld",
 			  psname, id);
 		break;
+	case PSTORE_TYPE_PMSG:
+		scnprintf(name, sizeof(name), "pmsg-%s-%lld", psname, id);
+		break;
 	case PSTORE_TYPE_UNKNOWN:
 		scnprintf(name, sizeof(name), "unknown-%s-%lld", psname, id);
 		break;
diff --git a/fs/pstore/internal.h b/fs/pstore/internal.h
index 3b3d305..c36ba2c 100644
--- a/fs/pstore/internal.h
+++ b/fs/pstore/internal.h
@@ -45,6 +45,12 @@ extern void pstore_register_ftrace(void);
 static inline void pstore_register_ftrace(void) {}
 #endif
 
+#ifdef CONFIG_PSTORE_PMSG
+extern void pstore_register_pmsg(void);
+#else
+static inline void pstore_register_pmsg(void) {}
+#endif
+
 extern struct pstore_info *psinfo;
 
 extern void	pstore_set_kmsg_bytes(int);
diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 0a9b72c..15ee78c 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -447,6 +447,7 @@ int pstore_register(struct pstore_info *psi)
 	if ((psi->flags & PSTORE_FLAGS_FRAGILE) == 0) {
 		pstore_register_console();
 		pstore_register_ftrace();
+		pstore_register_pmsg();
 	}
 
 	if (pstore_update_ms >= 0) {
diff --git a/fs/pstore/pmsg.c b/fs/pstore/pmsg.c
new file mode 100644
index 0000000..feb5dd2
--- /dev/null
+++ b/fs/pstore/pmsg.c
@@ -0,0 +1,114 @@
+/*
+ * Copyright 2014  Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ */
+
+#include <linux/cdev.h>
+#include <linux/device.h>
+#include <linux/fs.h>
+#include <linux/uaccess.h>
+#include <linux/vmalloc.h>
+#include "internal.h"
+
+static DEFINE_MUTEX(pmsg_lock);
+#define PMSG_MAX_BOUNCE_BUFFER_SIZE (2*PAGE_SIZE)
+
+static ssize_t write_pmsg(struct file *file, const char __user *buf,
+			  size_t count, loff_t *ppos)
+{
+	size_t i, buffer_size;
+	char *buffer;
+
+	if (!count)
+		return 0;
+
+	if (!access_ok(VERIFY_READ, buf, count))
+		return -EFAULT;
+
+	buffer_size = count;
+	if (buffer_size > PMSG_MAX_BOUNCE_BUFFER_SIZE)
+		buffer_size = PMSG_MAX_BOUNCE_BUFFER_SIZE;
+	buffer = vmalloc(buffer_size);
+
+	mutex_lock(&pmsg_lock);
+	for (i = 0; i < count; ) {
+		size_t c = min(count - i, buffer_size);
+		u64 id;
+		long ret;
+
+		ret = __copy_from_user(buffer, buf + i, c);
+		if (unlikely(ret != 0)) {
+			mutex_unlock(&pmsg_lock);
+			vfree(buffer);
+			return -EFAULT;
+		}
+		psinfo->write_buf(PSTORE_TYPE_PMSG, 0, &id, 0, buffer, 0, c,
+				  psinfo);
+
+		i += c;
+	}
+
+	mutex_unlock(&pmsg_lock);
+	vfree(buffer);
+	return count;
+}
+
+static const struct file_operations pmsg_fops = {
+	.owner		= THIS_MODULE,
+	.llseek		= noop_llseek,
+	.write		= write_pmsg,
+};
+
+static struct class *pmsg_class;
+static int pmsg_major;
+#define PMSG_NAME "pmsg"
+#undef pr_fmt
+#define pr_fmt(fmt) PMSG_NAME ": " fmt
+
+static char *pmsg_devnode(struct device *dev, umode_t *mode)
+{
+	if (mode)
+		*mode = 0220;
+	return NULL;
+}
+
+void pstore_register_pmsg(void)
+{
+	struct device *pmsg_device;
+
+	pmsg_major = register_chrdev(0, PMSG_NAME, &pmsg_fops);
+	if (pmsg_major < 0) {
+		pr_err("register_chrdev failed\n");
+		goto err;
+	}
+
+	pmsg_class = class_create(THIS_MODULE, PMSG_NAME);
+	if (IS_ERR(pmsg_class)) {
+		pr_err("device class file already in use\n");
+		goto err_class;
+	}
+	pmsg_class->devnode = pmsg_devnode;
+
+	pmsg_device = device_create(pmsg_class, NULL, MKDEV(pmsg_major, 0),
+					NULL, "%s%d", PMSG_NAME, 0);
+	if (IS_ERR(pmsg_device)) {
+		pr_err("failed to create device\n");
+		goto err_device;
+	}
+	return;
+
+err_device:
+	class_destroy(pmsg_class);
+err_class:
+	unregister_chrdev(pmsg_major, PMSG_NAME);
+err:
+	return;
+}
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 6150e54..39d1373 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -51,6 +51,10 @@ static ulong ramoops_ftrace_size = MIN_MEM_SIZE;
 module_param_named(ftrace_size, ramoops_ftrace_size, ulong, 0400);
 MODULE_PARM_DESC(ftrace_size, "size of ftrace log");
 
+static ulong ramoops_pmsg_size = MIN_MEM_SIZE;
+module_param_named(pmsg_size, ramoops_pmsg_size, ulong, 0400);
+MODULE_PARM_DESC(pmsg_size, "size of user space message log");
+
 static ulong mem_address;
 module_param(mem_address, ulong, 0400);
 MODULE_PARM_DESC(mem_address,
@@ -82,12 +86,14 @@ struct ramoops_context {
 	struct persistent_ram_zone **przs;
 	struct persistent_ram_zone *cprz;
 	struct persistent_ram_zone *fprz;
+	struct persistent_ram_zone *mprz;
 	phys_addr_t phys_addr;
 	unsigned long size;
 	unsigned int memtype;
 	size_t record_size;
 	size_t console_size;
 	size_t ftrace_size;
+	size_t pmsg_size;
 	int dump_oops;
 	struct persistent_ram_ecc_info ecc_info;
 	unsigned int max_dump_cnt;
@@ -96,6 +102,7 @@ struct ramoops_context {
 	unsigned int dump_read_cnt;
 	unsigned int console_read_cnt;
 	unsigned int ftrace_read_cnt;
+	unsigned int pmsg_read_cnt;
 	struct pstore_info pstore;
 };
 
@@ -109,6 +116,7 @@ static int ramoops_pstore_open(struct pstore_info *psi)
 	cxt->dump_read_cnt = 0;
 	cxt->console_read_cnt = 0;
 	cxt->ftrace_read_cnt = 0;
+	cxt->pmsg_read_cnt = 0;
 	return 0;
 }
 
@@ -191,6 +199,9 @@ static ssize_t ramoops_pstore_read(u64 *id, enum pstore_type_id *type,
 		prz = ramoops_get_next_prz(&cxt->fprz, &cxt->ftrace_read_cnt,
 					   1, id, type, PSTORE_TYPE_FTRACE, 0);
 	if (!prz_ok(prz))
+		prz = ramoops_get_next_prz(&cxt->mprz, &cxt->pmsg_read_cnt,
+					   1, id, type, PSTORE_TYPE_PMSG, 0);
+	if (!prz_ok(prz))
 		return 0;
 
 	if (!persistent_ram_old(prz))
@@ -258,6 +269,11 @@ static int notrace ramoops_pstore_write_buf(enum pstore_type_id type,
 			return -ENOMEM;
 		persistent_ram_write(cxt->fprz, buf, size);
 		return 0;
+	} else if (type == PSTORE_TYPE_PMSG) {
+		if (!cxt->mprz)
+			return -ENOMEM;
+		persistent_ram_write(cxt->mprz, buf, size);
+		return 0;
 	}
 
 	if (type != PSTORE_TYPE_DMESG)
@@ -315,6 +331,9 @@ static int ramoops_pstore_erase(enum pstore_type_id type, u64 id, int count,
 	case PSTORE_TYPE_FTRACE:
 		prz = cxt->fprz;
 		break;
+	case PSTORE_TYPE_PMSG:
+		prz = cxt->mprz;
+		break;
 	default:
 		return -EINVAL;
 	}
@@ -441,7 +460,7 @@ static int ramoops_probe(struct platform_device *pdev)
 		goto fail_out;
 
 	if (!pdata->mem_size || (!pdata->record_size && !pdata->console_size &&
-			!pdata->ftrace_size)) {
+			!pdata->ftrace_size && !pdata->pmsg_size)) {
 		pr_err("The memory size and the record/console size must be "
 			"non-zero\n");
 		goto fail_out;
@@ -453,6 +472,8 @@ static int ramoops_probe(struct platform_device *pdev)
 		pdata->console_size = rounddown_pow_of_two(pdata->console_size);
 	if (pdata->ftrace_size && !is_power_of_2(pdata->ftrace_size))
 		pdata->ftrace_size = rounddown_pow_of_two(pdata->ftrace_size);
+	if (pdata->pmsg_size && !is_power_of_2(pdata->pmsg_size))
+		pdata->pmsg_size = rounddown_pow_of_two(pdata->pmsg_size);
 
 	cxt->size = pdata->mem_size;
 	cxt->phys_addr = pdata->mem_address;
@@ -460,12 +481,14 @@ static int ramoops_probe(struct platform_device *pdev)
 	cxt->record_size = pdata->record_size;
 	cxt->console_size = pdata->console_size;
 	cxt->ftrace_size = pdata->ftrace_size;
+	cxt->pmsg_size = pdata->pmsg_size;
 	cxt->dump_oops = pdata->dump_oops;
 	cxt->ecc_info = pdata->ecc_info;
 
 	paddr = cxt->phys_addr;
 
-	dump_mem_sz = cxt->size - cxt->console_size - cxt->ftrace_size;
+	dump_mem_sz = cxt->size - cxt->console_size - cxt->ftrace_size
+			- cxt->pmsg_size;
 	err = ramoops_init_przs(dev, cxt, &paddr, dump_mem_sz);
 	if (err)
 		goto fail_out;
@@ -480,6 +503,10 @@ static int ramoops_probe(struct platform_device *pdev)
 	if (err)
 		goto fail_init_fprz;
 
+	err = ramoops_init_prz(dev, cxt, &cxt->mprz, &paddr, cxt->pmsg_size, 0);
+	if (err)
+		goto fail_init_mprz;
+
 	cxt->pstore.data = cxt;
 	/*
 	 * Console can handle any buffer size, so prefer LOG_LINE_MAX. If we
@@ -523,6 +550,8 @@ fail_buf:
 	kfree(cxt->pstore.buf);
 fail_clear:
 	cxt->pstore.bufsize = 0;
+	kfree(cxt->mprz);
+fail_init_mprz:
 	kfree(cxt->fprz);
 fail_init_fprz:
 	kfree(cxt->cprz);
@@ -580,6 +609,7 @@ static void ramoops_register_dummy(void)
 	dummy_data->record_size = record_size;
 	dummy_data->console_size = ramoops_console_size;
 	dummy_data->ftrace_size = ramoops_ftrace_size;
+	dummy_data->pmsg_size = ramoops_pmsg_size;
 	dummy_data->dump_oops = dump_oops;
 	/*
 	 * For backwards compatibility ramoops.ecc=1 means 16 bytes ECC
diff --git a/include/linux/pstore.h b/include/linux/pstore.h
index ece0c6b..8884f6e 100644
--- a/include/linux/pstore.h
+++ b/include/linux/pstore.h
@@ -39,6 +39,7 @@ enum pstore_type_id {
 	PSTORE_TYPE_PPC_RTAS	= 4,
 	PSTORE_TYPE_PPC_OF	= 5,
 	PSTORE_TYPE_PPC_COMMON	= 6,
+	PSTORE_TYPE_PMSG	= 7,
 	PSTORE_TYPE_UNKNOWN	= 255
 };
 
diff --git a/include/linux/pstore_ram.h b/include/linux/pstore_ram.h
index 4af3fdc..9c9d6c1 100644
--- a/include/linux/pstore_ram.h
+++ b/include/linux/pstore_ram.h
@@ -81,6 +81,7 @@ struct ramoops_platform_data {
 	unsigned long	record_size;
 	unsigned long	console_size;
 	unsigned long	ftrace_size;
+	unsigned long	pmsg_size;
 	int		dump_oops;
 	struct persistent_ram_ecc_info ecc_info;
 };
-- 
2.2.0.rc0.207.ga3a616c


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH v4 4/5] pstore: add pmsg
  2015-01-14  0:16 [PATCH v4 4/5] pstore: add pmsg Mark Salyzyn
@ 2015-01-14 18:16 ` Kees Cook
  2015-01-17  0:05   ` Luck, Tony
       [not found] ` <871tmfz06r.fsf%stlman@poczta.fm>
  1 sibling, 1 reply; 8+ messages in thread
From: Kees Cook @ 2015-01-14 18:16 UTC (permalink / raw)
  To: Mark Salyzyn; +Cc: LKML, Anton Vorontsov, Colin Cross, Tony Luck

On Tue, Jan 13, 2015 at 4:16 PM, Mark Salyzyn <salyzyn@android.com> wrote:
> A secured user-space accessible pstore object. Writes
> to /dev/pmsg0 are appended to the buffer, on reboot
> the persistent contents are available in
> /sys/fs/pstore/pmsg-ramoops-[ID].
>
> One possible use is syslogd, or other daemon, can
> write messages, then on reboot provides a means to
> triage user-space activities leading up to a panic
> as a companion to the pstore dmesg or console logs.
>
> Signed-off-by: Mark Salyzyn <salyzyn@android.com>
> ---
> v2: switch from snprintf to scnprintf
> v3: split out prz_ok checking into PATCH 3/5
>     replace pmsg_lseek with noop_llseek
>     use pr_fmt() macro
>     make write atomic and use a vmalloc'd bounce buffer
> v4: use mutex_lock instead of of spin_lock.

Cool, seems reasonable to me. Thanks for the respins!

Acked-by: Kees Cook <keescook@chromium.org>

-Kees

>
>  fs/pstore/Kconfig          |  10 ++++
>  fs/pstore/Makefile         |   2 +
>  fs/pstore/inode.c          |   3 ++
>  fs/pstore/internal.h       |   6 +++
>  fs/pstore/platform.c       |   1 +
>  fs/pstore/pmsg.c           | 114 +++++++++++++++++++++++++++++++++++++++++++++
>  fs/pstore/ram.c            |  34 +++++++++++++-
>  include/linux/pstore.h     |   1 +
>  include/linux/pstore_ram.h |   1 +
>  9 files changed, 170 insertions(+), 2 deletions(-)
>  create mode 100644 fs/pstore/pmsg.c
>
> diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
> index 983d951..916b8e2 100644
> --- a/fs/pstore/Kconfig
> +++ b/fs/pstore/Kconfig
> @@ -21,6 +21,16 @@ config PSTORE_CONSOLE
>           When the option is enabled, pstore will log all kernel
>           messages, even if no oops or panic happened.
>
> +config PSTORE_PMSG
> +       bool "Log user space messages"
> +       depends on PSTORE
> +       help
> +         When the option is enabled, pstore will export a character
> +         interface /dev/pmsg0 to log user space messages. On reboot
> +         data can be retrieved from /sys/fs/pstore/pmsg-ramoops-[ID].
> +
> +         If unsure, say N.
> +
>  config PSTORE_FTRACE
>         bool "Persistent function tracer"
>         depends on PSTORE
> diff --git a/fs/pstore/Makefile b/fs/pstore/Makefile
> index 4c9095c..e647d8e 100644
> --- a/fs/pstore/Makefile
> +++ b/fs/pstore/Makefile
> @@ -7,5 +7,7 @@ obj-y += pstore.o
>  pstore-objs += inode.o platform.o
>  obj-$(CONFIG_PSTORE_FTRACE)    += ftrace.o
>
> +obj-$(CONFIG_PSTORE_PMSG)      += pmsg.o
> +
>  ramoops-objs += ram.o ram_core.o
>  obj-$(CONFIG_PSTORE_RAM)       += ramoops.o
> diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
> index d69586f..b32ce53 100644
> --- a/fs/pstore/inode.c
> +++ b/fs/pstore/inode.c
> @@ -361,6 +361,9 @@ int pstore_mkfile(enum pstore_type_id type, char *psname, u64 id, int count,
>                 scnprintf(name, sizeof(name), "powerpc-common-%s-%lld",
>                           psname, id);
>                 break;
> +       case PSTORE_TYPE_PMSG:
> +               scnprintf(name, sizeof(name), "pmsg-%s-%lld", psname, id);
> +               break;
>         case PSTORE_TYPE_UNKNOWN:
>                 scnprintf(name, sizeof(name), "unknown-%s-%lld", psname, id);
>                 break;
> diff --git a/fs/pstore/internal.h b/fs/pstore/internal.h
> index 3b3d305..c36ba2c 100644
> --- a/fs/pstore/internal.h
> +++ b/fs/pstore/internal.h
> @@ -45,6 +45,12 @@ extern void pstore_register_ftrace(void);
>  static inline void pstore_register_ftrace(void) {}
>  #endif
>
> +#ifdef CONFIG_PSTORE_PMSG
> +extern void pstore_register_pmsg(void);
> +#else
> +static inline void pstore_register_pmsg(void) {}
> +#endif
> +
>  extern struct pstore_info *psinfo;
>
>  extern void    pstore_set_kmsg_bytes(int);
> diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
> index 0a9b72c..15ee78c 100644
> --- a/fs/pstore/platform.c
> +++ b/fs/pstore/platform.c
> @@ -447,6 +447,7 @@ int pstore_register(struct pstore_info *psi)
>         if ((psi->flags & PSTORE_FLAGS_FRAGILE) == 0) {
>                 pstore_register_console();
>                 pstore_register_ftrace();
> +               pstore_register_pmsg();
>         }
>
>         if (pstore_update_ms >= 0) {
> diff --git a/fs/pstore/pmsg.c b/fs/pstore/pmsg.c
> new file mode 100644
> index 0000000..feb5dd2
> --- /dev/null
> +++ b/fs/pstore/pmsg.c
> @@ -0,0 +1,114 @@
> +/*
> + * Copyright 2014  Google, Inc.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * 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.
> + */
> +
> +#include <linux/cdev.h>
> +#include <linux/device.h>
> +#include <linux/fs.h>
> +#include <linux/uaccess.h>
> +#include <linux/vmalloc.h>
> +#include "internal.h"
> +
> +static DEFINE_MUTEX(pmsg_lock);
> +#define PMSG_MAX_BOUNCE_BUFFER_SIZE (2*PAGE_SIZE)
> +
> +static ssize_t write_pmsg(struct file *file, const char __user *buf,
> +                         size_t count, loff_t *ppos)
> +{
> +       size_t i, buffer_size;
> +       char *buffer;
> +
> +       if (!count)
> +               return 0;
> +
> +       if (!access_ok(VERIFY_READ, buf, count))
> +               return -EFAULT;
> +
> +       buffer_size = count;
> +       if (buffer_size > PMSG_MAX_BOUNCE_BUFFER_SIZE)
> +               buffer_size = PMSG_MAX_BOUNCE_BUFFER_SIZE;
> +       buffer = vmalloc(buffer_size);
> +
> +       mutex_lock(&pmsg_lock);
> +       for (i = 0; i < count; ) {
> +               size_t c = min(count - i, buffer_size);
> +               u64 id;
> +               long ret;
> +
> +               ret = __copy_from_user(buffer, buf + i, c);
> +               if (unlikely(ret != 0)) {
> +                       mutex_unlock(&pmsg_lock);
> +                       vfree(buffer);
> +                       return -EFAULT;
> +               }
> +               psinfo->write_buf(PSTORE_TYPE_PMSG, 0, &id, 0, buffer, 0, c,
> +                                 psinfo);
> +
> +               i += c;
> +       }
> +
> +       mutex_unlock(&pmsg_lock);
> +       vfree(buffer);
> +       return count;
> +}
> +
> +static const struct file_operations pmsg_fops = {
> +       .owner          = THIS_MODULE,
> +       .llseek         = noop_llseek,
> +       .write          = write_pmsg,
> +};
> +
> +static struct class *pmsg_class;
> +static int pmsg_major;
> +#define PMSG_NAME "pmsg"
> +#undef pr_fmt
> +#define pr_fmt(fmt) PMSG_NAME ": " fmt
> +
> +static char *pmsg_devnode(struct device *dev, umode_t *mode)
> +{
> +       if (mode)
> +               *mode = 0220;
> +       return NULL;
> +}
> +
> +void pstore_register_pmsg(void)
> +{
> +       struct device *pmsg_device;
> +
> +       pmsg_major = register_chrdev(0, PMSG_NAME, &pmsg_fops);
> +       if (pmsg_major < 0) {
> +               pr_err("register_chrdev failed\n");
> +               goto err;
> +       }
> +
> +       pmsg_class = class_create(THIS_MODULE, PMSG_NAME);
> +       if (IS_ERR(pmsg_class)) {
> +               pr_err("device class file already in use\n");
> +               goto err_class;
> +       }
> +       pmsg_class->devnode = pmsg_devnode;
> +
> +       pmsg_device = device_create(pmsg_class, NULL, MKDEV(pmsg_major, 0),
> +                                       NULL, "%s%d", PMSG_NAME, 0);
> +       if (IS_ERR(pmsg_device)) {
> +               pr_err("failed to create device\n");
> +               goto err_device;
> +       }
> +       return;
> +
> +err_device:
> +       class_destroy(pmsg_class);
> +err_class:
> +       unregister_chrdev(pmsg_major, PMSG_NAME);
> +err:
> +       return;
> +}
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index 6150e54..39d1373 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -51,6 +51,10 @@ static ulong ramoops_ftrace_size = MIN_MEM_SIZE;
>  module_param_named(ftrace_size, ramoops_ftrace_size, ulong, 0400);
>  MODULE_PARM_DESC(ftrace_size, "size of ftrace log");
>
> +static ulong ramoops_pmsg_size = MIN_MEM_SIZE;
> +module_param_named(pmsg_size, ramoops_pmsg_size, ulong, 0400);
> +MODULE_PARM_DESC(pmsg_size, "size of user space message log");
> +
>  static ulong mem_address;
>  module_param(mem_address, ulong, 0400);
>  MODULE_PARM_DESC(mem_address,
> @@ -82,12 +86,14 @@ struct ramoops_context {
>         struct persistent_ram_zone **przs;
>         struct persistent_ram_zone *cprz;
>         struct persistent_ram_zone *fprz;
> +       struct persistent_ram_zone *mprz;
>         phys_addr_t phys_addr;
>         unsigned long size;
>         unsigned int memtype;
>         size_t record_size;
>         size_t console_size;
>         size_t ftrace_size;
> +       size_t pmsg_size;
>         int dump_oops;
>         struct persistent_ram_ecc_info ecc_info;
>         unsigned int max_dump_cnt;
> @@ -96,6 +102,7 @@ struct ramoops_context {
>         unsigned int dump_read_cnt;
>         unsigned int console_read_cnt;
>         unsigned int ftrace_read_cnt;
> +       unsigned int pmsg_read_cnt;
>         struct pstore_info pstore;
>  };
>
> @@ -109,6 +116,7 @@ static int ramoops_pstore_open(struct pstore_info *psi)
>         cxt->dump_read_cnt = 0;
>         cxt->console_read_cnt = 0;
>         cxt->ftrace_read_cnt = 0;
> +       cxt->pmsg_read_cnt = 0;
>         return 0;
>  }
>
> @@ -191,6 +199,9 @@ static ssize_t ramoops_pstore_read(u64 *id, enum pstore_type_id *type,
>                 prz = ramoops_get_next_prz(&cxt->fprz, &cxt->ftrace_read_cnt,
>                                            1, id, type, PSTORE_TYPE_FTRACE, 0);
>         if (!prz_ok(prz))
> +               prz = ramoops_get_next_prz(&cxt->mprz, &cxt->pmsg_read_cnt,
> +                                          1, id, type, PSTORE_TYPE_PMSG, 0);
> +       if (!prz_ok(prz))
>                 return 0;
>
>         if (!persistent_ram_old(prz))
> @@ -258,6 +269,11 @@ static int notrace ramoops_pstore_write_buf(enum pstore_type_id type,
>                         return -ENOMEM;
>                 persistent_ram_write(cxt->fprz, buf, size);
>                 return 0;
> +       } else if (type == PSTORE_TYPE_PMSG) {
> +               if (!cxt->mprz)
> +                       return -ENOMEM;
> +               persistent_ram_write(cxt->mprz, buf, size);
> +               return 0;
>         }
>
>         if (type != PSTORE_TYPE_DMESG)
> @@ -315,6 +331,9 @@ static int ramoops_pstore_erase(enum pstore_type_id type, u64 id, int count,
>         case PSTORE_TYPE_FTRACE:
>                 prz = cxt->fprz;
>                 break;
> +       case PSTORE_TYPE_PMSG:
> +               prz = cxt->mprz;
> +               break;
>         default:
>                 return -EINVAL;
>         }
> @@ -441,7 +460,7 @@ static int ramoops_probe(struct platform_device *pdev)
>                 goto fail_out;
>
>         if (!pdata->mem_size || (!pdata->record_size && !pdata->console_size &&
> -                       !pdata->ftrace_size)) {
> +                       !pdata->ftrace_size && !pdata->pmsg_size)) {
>                 pr_err("The memory size and the record/console size must be "
>                         "non-zero\n");
>                 goto fail_out;
> @@ -453,6 +472,8 @@ static int ramoops_probe(struct platform_device *pdev)
>                 pdata->console_size = rounddown_pow_of_two(pdata->console_size);
>         if (pdata->ftrace_size && !is_power_of_2(pdata->ftrace_size))
>                 pdata->ftrace_size = rounddown_pow_of_two(pdata->ftrace_size);
> +       if (pdata->pmsg_size && !is_power_of_2(pdata->pmsg_size))
> +               pdata->pmsg_size = rounddown_pow_of_two(pdata->pmsg_size);
>
>         cxt->size = pdata->mem_size;
>         cxt->phys_addr = pdata->mem_address;
> @@ -460,12 +481,14 @@ static int ramoops_probe(struct platform_device *pdev)
>         cxt->record_size = pdata->record_size;
>         cxt->console_size = pdata->console_size;
>         cxt->ftrace_size = pdata->ftrace_size;
> +       cxt->pmsg_size = pdata->pmsg_size;
>         cxt->dump_oops = pdata->dump_oops;
>         cxt->ecc_info = pdata->ecc_info;
>
>         paddr = cxt->phys_addr;
>
> -       dump_mem_sz = cxt->size - cxt->console_size - cxt->ftrace_size;
> +       dump_mem_sz = cxt->size - cxt->console_size - cxt->ftrace_size
> +                       - cxt->pmsg_size;
>         err = ramoops_init_przs(dev, cxt, &paddr, dump_mem_sz);
>         if (err)
>                 goto fail_out;
> @@ -480,6 +503,10 @@ static int ramoops_probe(struct platform_device *pdev)
>         if (err)
>                 goto fail_init_fprz;
>
> +       err = ramoops_init_prz(dev, cxt, &cxt->mprz, &paddr, cxt->pmsg_size, 0);
> +       if (err)
> +               goto fail_init_mprz;
> +
>         cxt->pstore.data = cxt;
>         /*
>          * Console can handle any buffer size, so prefer LOG_LINE_MAX. If we
> @@ -523,6 +550,8 @@ fail_buf:
>         kfree(cxt->pstore.buf);
>  fail_clear:
>         cxt->pstore.bufsize = 0;
> +       kfree(cxt->mprz);
> +fail_init_mprz:
>         kfree(cxt->fprz);
>  fail_init_fprz:
>         kfree(cxt->cprz);
> @@ -580,6 +609,7 @@ static void ramoops_register_dummy(void)
>         dummy_data->record_size = record_size;
>         dummy_data->console_size = ramoops_console_size;
>         dummy_data->ftrace_size = ramoops_ftrace_size;
> +       dummy_data->pmsg_size = ramoops_pmsg_size;
>         dummy_data->dump_oops = dump_oops;
>         /*
>          * For backwards compatibility ramoops.ecc=1 means 16 bytes ECC
> diff --git a/include/linux/pstore.h b/include/linux/pstore.h
> index ece0c6b..8884f6e 100644
> --- a/include/linux/pstore.h
> +++ b/include/linux/pstore.h
> @@ -39,6 +39,7 @@ enum pstore_type_id {
>         PSTORE_TYPE_PPC_RTAS    = 4,
>         PSTORE_TYPE_PPC_OF      = 5,
>         PSTORE_TYPE_PPC_COMMON  = 6,
> +       PSTORE_TYPE_PMSG        = 7,
>         PSTORE_TYPE_UNKNOWN     = 255
>  };
>
> diff --git a/include/linux/pstore_ram.h b/include/linux/pstore_ram.h
> index 4af3fdc..9c9d6c1 100644
> --- a/include/linux/pstore_ram.h
> +++ b/include/linux/pstore_ram.h
> @@ -81,6 +81,7 @@ struct ramoops_platform_data {
>         unsigned long   record_size;
>         unsigned long   console_size;
>         unsigned long   ftrace_size;
> +       unsigned long   pmsg_size;
>         int             dump_oops;
>         struct persistent_ram_ecc_info ecc_info;
>  };
> --
> 2.2.0.rc0.207.ga3a616c
>



-- 
Kees Cook
Chrome OS Security

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: [PATCH v4 4/5] pstore: add pmsg
  2015-01-14 18:16 ` Kees Cook
@ 2015-01-17  0:05   ` Luck, Tony
  0 siblings, 0 replies; 8+ messages in thread
From: Luck, Tony @ 2015-01-17  0:05 UTC (permalink / raw)
  To: Kees Cook, Mark Salyzyn; +Cc: LKML, Anton Vorontsov, Colin Cross

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 490 bytes --]

> Cool, seems reasonable to me. Thanks for the respins!

I've applied it - but I have a nagging worry about it being user accessible.  We've limited
access to some pstore features on platforms that only support backend drivers that
write to limited lifetime flash storage - efivars & erst.  Should we do that for this too?

-Tony
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v4 4/5] pstore: add pmsg
       [not found] ` <871tmfz06r.fsf%stlman@poczta.fm>
@ 2015-01-28 17:28   ` Mark Salyzyn
  2015-01-30 20:57     ` Lukasz Stelmach
  0 siblings, 1 reply; 8+ messages in thread
From: Mark Salyzyn @ 2015-01-28 17:28 UTC (permalink / raw)
  To: Łukasz Stelmach
  Cc: linux-kernel, Anton Vorontsov, Colin Cross, Kees Cook, Tony Luck,
	Krzysztof Kozlowski,
	"Bartłomiej Żołnierkiewicz
	stlman@poczta.fm"

On 01/13/2015 04:16 PM, Łukasz Stelmach wrote:
>> A secured user-space accessible pstore object. Writes
>> to /dev/pmsg0 are appended to the buffer, on reboot
>> the persistent contents are available in
>> /sys/fs/pstore/pmsg-ramoops-[ID].
>>
>> One possible use is syslogd, or other daemon, can
>> write messages, then on reboot provides a means to
>> triage user-space activities leading up to a panic
>> as a companion to the pstore dmesg or console logs.
>>
>> Signed-off-by: Mark Salyzyn <salyzyn@android.com>
>> ---
> I am not an expert but this smells like duplicating /dev/kmsg. If
> I remember correctly since about Linux 3.5 /dev/kmsg is writable for the
> user-space and every single process (modulo MAC/DAC) can log there. The
> messages from user-space are preserved accross reboots as a part of the
> kmsg/printk buffer anyway.
>
> What is the advantege of pmsg0 over /dev/kmsg?

- Precious little user-space content goes to kmsg (otherwise you can ask 
why is there a syslogd?), there is a reason for this, user space is 
notorious for containing Personal Identifiable Information whereas 
kernel information does not.
- pmsg0 can take a lot of content (with a ramoops backend) and will not 
disrupt/DOS the kernel logs.
- State, Binary or packetized content can go to /dev/pmsg0 and not 
interfere with the text content in kmsg
- /dev/pmsg0 write is atomic
- /dev/pmsg0 is write only, there is no access to the live content 
_unless_ there is a reboot.
- Personal identification which abounds in user space could be placed 
into /dev/pmsg0, and there is no way except a reboot in order to extract 
the content, and then /sys/fs/pstore/pmsg-ramoops-0 can be deleted, or 
heavily MAC and DAC controlled to enforce protection (doing so to kmsg 
would be unlivable)

Sincerely -- Mark Salyzyn

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v4 4/5] pstore: add pmsg
  2015-01-28 17:28   ` Mark Salyzyn
@ 2015-01-30 20:57     ` Lukasz Stelmach
  2015-02-03 16:05       ` Mark Salyzyn
  0 siblings, 1 reply; 8+ messages in thread
From: Lukasz Stelmach @ 2015-01-30 20:57 UTC (permalink / raw)
  To: Mark Salyzyn
  Cc: LKML, Anton Vorontsov, Colin Cross, Kees Cook, Tony Luck,
	Krzysztof Kozlowski, Bartłomiej Żołnierkiewicz

[-- Attachment #1: Type: text/plain, Size: 2730 bytes --]

On 28.01.2015 18:28, Mark Salyzyn wrote:
> On 01/13/2015 04:16 PM, Łukasz Stelmach wrote:
>>> A secured user-space accessible pstore object. Writes
>>> to /dev/pmsg0 are appended to the buffer, on reboot
>>> the persistent contents are available in
>>> /sys/fs/pstore/pmsg-ramoops-[ID].
>>>
>>> One possible use is syslogd, or other daemon, can
>>> write messages, then on reboot provides a means to
>>> triage user-space activities leading up to a panic
>>> as a companion to the pstore dmesg or console logs.
>>>
>>> Signed-off-by: Mark Salyzyn <salyzyn@android.com>
>>> ---
>> I am not an expert but this smells like duplicating /dev/kmsg. If
>> I remember correctly since about Linux 3.5 /dev/kmsg is writable for the
>> user-space and every single process (modulo MAC/DAC) can log there. The
>> messages from user-space are preserved accross reboots as a part of the
>> kmsg/printk buffer anyway.
>>
>> What is the advantege of pmsg0 over /dev/kmsg?
> 
> - Precious little user-space content goes to kmsg (otherwise you
> can ask why is there a syslogd?), there is a reason for this, user
> space is notorious for containing Personal Identifiable Information
> whereas kernel information does not.

Sure it does too: MAC addresses, UUIDs, serial numbers. With mobile
devices these are actually PII.

> - pmsg0 can take a lot of content (with a ramoops backend) and
> will not disrupt/DOS the kernel logs.

Documentation/ramoops.txt says it is for logging kernel oopses
and panics not user logs.

> - State, Binary or packetized content can go to /dev/pmsg0 and
> not interfere with the text content in kmsg

Indeed kmsg can't store arbitrary binary data. However it can,
store key/value pairs next to text and there is base64 too.
Yes, this one seems a little bit better than kmsg.

> - /dev/pmsg0 write is atomic

devkmsg_write + vprintk_emit are atomic too.

> - /dev/pmsg0 is write only, there is no access to the live content
> _unless_ there is a reboot.

Why do you consider this an advantage?

> - Personal identification which abounds in user space could be placed
> into /dev/pmsg0, and there is no way except a reboot in order to
> extract the content, and then /sys/fs/pstore/pmsg-ramoops-0 can be
> deleted, or heavily MAC and DAC controlled to enforce protection
> (doing so to kmsg would be unlivable)

Read access to /dev/kmsg can be limited too.

I think that the goals you present can be met with less code.
You could try adding support for multiple /dev/kmsg instances
for example. How about that?

-- 
Było mi bardzo miło.                   Twoje oczy lubią mnie
>Łukasz<                                     i to mnie zgubi  (c)SNL


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v4 4/5] pstore: add pmsg
  2015-01-30 20:57     ` Lukasz Stelmach
@ 2015-02-03 16:05       ` Mark Salyzyn
  2015-02-03 18:21         ` Kees Cook
  2015-02-04  2:35         ` Lukasz Stelmach
  0 siblings, 2 replies; 8+ messages in thread
From: Mark Salyzyn @ 2015-02-03 16:05 UTC (permalink / raw)
  To: Lukasz Stelmach
  Cc: LKML, Anton Vorontsov, Colin Cross, Kees Cook, Tony Luck,
	Krzysztof Kozlowski, Bartłomiej Żołnierkiewicz

Thanks for your response.

On 01/30/2015 12:57 PM, Lukasz Stelmach wrote:
> On 28.01.2015 18:28, Mark Salyzyn wrote:
>> - Precious little user-space content goes to kmsg (otherwise you
>> can ask why is there a syslogd?), there is a reason for this, user
>> space is notorious for containing Personal Identifiable Information
>> whereas kernel information does not.
> Sure it does too: MAC addresses, UUIDs, serial numbers. With mobile
> devices these are actually PII.
:-)

Names, Passwords, credit card number, addresses. Personal Identifiable 
Information, lawsuits are never lodged against MAC addresses UUIDs or 
serial numbers.
>> - pmsg0 can take a lot of content (with a ramoops backend) and
>> will not disrupt/DOS the kernel logs.
> Documentation/ramoops.txt says it is for logging kernel oopses
> and panics not user logs.
I probably should have changed the ramoops.txt content with the addition 
of pmsg :-)
>
> - /dev/pmsg0 write is atomic
> devkmsg_write + vprintk_emit are atomic too.
Hmmm, I managed to get content corrupted
>> - /dev/pmsg0 is write only, there is no access to the live content
>> _unless_ there is a reboot.
> Why do you consider this an advantage?
It is more serendipity than design, once this feature was highlighted, 
it became a must-have for the security concerns. The current boot 
instance contains an environment of files, programs and state 
information that combined would be useful for cracking a large amount of 
PII. Once a kernel panics what remains is a trace of user-space 
activities that can be correlated with kernel activities in order to 
replay or triage what lead up to the kernel panic. Yet crippled enough 
to not be as useful as a vector.
>> - Personal identification which abounds in user space could be placed
>> into /dev/pmsg0, and there is no way except a reboot in order to
>> extract the content, and then /sys/fs/pstore/pmsg-ramoops-0 can be
>> deleted, or heavily MAC and DAC controlled to enforce protection
>> (doing so to kmsg would be unlivable)
> Read access to /dev/kmsg can be limited too.
When you delete /sys/fs/pstore/pmsg-ramoops-0 after moving it to secure 
storage, it is gone. Same is separately true for 
/sys/fs/pstore/console-ramoops-0, so yes, similar characteristics. The 
issue is separation. The issue is also no ability to read the live 
content of the user space data until it becomes relevant (kernel panic 
triage).
>
> I think that the goals you present can be met with less code.
> You could try adding support for multiple /dev/kmsg instances
> for example. How about that?
Not a bad idea. But with multiple kmsg instances, you also get to add 
code in pstore to divide it up along with a device tree that decides how 
much storage is provided for each instance. I would wager a desire will 
be expressed to make sure the live co There is a vacuum.ntent be 
accessible with a netlink socket and  a new flag in dmesg which would be 
counter to our security concerns.

pstore is all about persistence. kmsg is not, until pstore supports it. 
A user-space persistent storehouse felt appropriate to support at the 
bottom layer.

Sincerely -- Mark Salyzyn

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v4 4/5] pstore: add pmsg
  2015-02-03 16:05       ` Mark Salyzyn
@ 2015-02-03 18:21         ` Kees Cook
  2015-02-04  2:35         ` Lukasz Stelmach
  1 sibling, 0 replies; 8+ messages in thread
From: Kees Cook @ 2015-02-03 18:21 UTC (permalink / raw)
  To: Mark Salyzyn
  Cc: Lukasz Stelmach, LKML, Anton Vorontsov, Colin Cross, Tony Luck,
	Krzysztof Kozlowski, Bartłomiej Żołnierkiewicz

On Tue, Feb 3, 2015 at 8:05 AM, Mark Salyzyn <salyzyn@android.com> wrote:
> Thanks for your response.
>
> On 01/30/2015 12:57 PM, Lukasz Stelmach wrote:
>>
>> On 28.01.2015 18:28, Mark Salyzyn wrote:
>>>
>>> - Precious little user-space content goes to kmsg (otherwise you
>>> can ask why is there a syslogd?), there is a reason for this, user
>>> space is notorious for containing Personal Identifiable Information
>>> whereas kernel information does not.
>>
>> Sure it does too: MAC addresses, UUIDs, serial numbers. With mobile
>> devices these are actually PII.
>
> :-)
>
> Names, Passwords, credit card number, addresses. Personal Identifiable
> Information, lawsuits are never lodged against MAC addresses UUIDs or serial
> numbers.
>>>
>>> - pmsg0 can take a lot of content (with a ramoops backend) and
>>> will not disrupt/DOS the kernel logs.
>>
>> Documentation/ramoops.txt says it is for logging kernel oopses
>> and panics not user logs.
>
> I probably should have changed the ramoops.txt content with the addition of
> pmsg :-)
>>
>>
>> - /dev/pmsg0 write is atomic
>> devkmsg_write + vprintk_emit are atomic too.
>
> Hmmm, I managed to get content corrupted
>>>
>>> - /dev/pmsg0 is write only, there is no access to the live content
>>> _unless_ there is a reboot.
>>
>> Why do you consider this an advantage?
>
> It is more serendipity than design, once this feature was highlighted, it
> became a must-have for the security concerns. The current boot instance
> contains an environment of files, programs and state information that
> combined would be useful for cracking a large amount of PII. Once a kernel
> panics what remains is a trace of user-space activities that can be
> correlated with kernel activities in order to replay or triage what lead up
> to the kernel panic. Yet crippled enough to not be as useful as a vector.
>>>
>>> - Personal identification which abounds in user space could be placed
>>> into /dev/pmsg0, and there is no way except a reboot in order to
>>> extract the content, and then /sys/fs/pstore/pmsg-ramoops-0 can be
>>> deleted, or heavily MAC and DAC controlled to enforce protection
>>> (doing so to kmsg would be unlivable)
>>
>> Read access to /dev/kmsg can be limited too.
>
> When you delete /sys/fs/pstore/pmsg-ramoops-0 after moving it to secure
> storage, it is gone. Same is separately true for
> /sys/fs/pstore/console-ramoops-0, so yes, similar characteristics. The issue
> is separation. The issue is also no ability to read the live content of the
> user space data until it becomes relevant (kernel panic triage).
>>
>>
>> I think that the goals you present can be met with less code.
>> You could try adding support for multiple /dev/kmsg instances
>> for example. How about that?
>
> Not a bad idea. But with multiple kmsg instances, you also get to add code
> in pstore to divide it up along with a device tree that decides how much
> storage is provided for each instance. I would wager a desire will be
> expressed to make sure the live co There is a vacuum.ntent be accessible
> with a netlink socket and  a new flag in dmesg which would be counter to our
> security concerns.
>
> pstore is all about persistence. kmsg is not, until pstore supports it. A
> user-space persistent storehouse felt appropriate to support at the bottom
> layer.
>

FWIW, I prefer keeping "pmsg" separate from "kmsg". They do feel
similar, but given the persistence backing, I think it justifies the
separation. I'm not sure it's right to change the semantics of kmsg.

-Kees


> Sincerely -- Mark Salyzyn



-- 
Kees Cook
Chrome OS Security

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v4 4/5] pstore: add pmsg
  2015-02-03 16:05       ` Mark Salyzyn
  2015-02-03 18:21         ` Kees Cook
@ 2015-02-04  2:35         ` Lukasz Stelmach
  1 sibling, 0 replies; 8+ messages in thread
From: Lukasz Stelmach @ 2015-02-04  2:35 UTC (permalink / raw)
  To: Mark Salyzyn
  Cc: LKML, Anton Vorontsov, Colin Cross, Kees Cook, Tony Luck,
	Krzysztof Kozlowski, Bartłomiej Żołnierkiewicz

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]

On 03.02.2015 17:05, Mark Salyzyn wrote:
> Thanks for your response.
[...]
> pstore is all about persistence. kmsg is not, until pstore supports
> it. A user-space persistent storehouse felt appropriate to support
> at the bottom layer.

OK. Thanks, for the additional information. Like I said, I am no
expert but juste felt an urge to ask a few questions.

:-)


-- 
Było mi bardzo miło.                   Twoje oczy lubią mnie
>Łukasz<                                     i to mnie zgubi  (c)SNL


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2015-02-04  2:35 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-14  0:16 [PATCH v4 4/5] pstore: add pmsg Mark Salyzyn
2015-01-14 18:16 ` Kees Cook
2015-01-17  0:05   ` Luck, Tony
     [not found] ` <871tmfz06r.fsf%stlman@poczta.fm>
2015-01-28 17:28   ` Mark Salyzyn
2015-01-30 20:57     ` Lukasz Stelmach
2015-02-03 16:05       ` Mark Salyzyn
2015-02-03 18:21         ` Kees Cook
2015-02-04  2:35         ` Lukasz Stelmach

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).