| 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
| ||
|
Message-ID: <CAGXu5jJY478UM0fnqB5SML0gCc1HxoJyA-d6+rZH6mTWQkGegw@mail.gmail.com>
Date: Thu, 17 May 2012 09:34:19 -0700
From: Kees Cook <keescook@...omium.org>
To: Anton Vorontsov <anton.vorontsov@...aro.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Colin Cross <ccross@...roid.com>,
Tony Luck <tony.luck@...el.com>, Arnd Bergmann <arnd@...db.de>,
John Stultz <john.stultz@...aro.org>,
Shuah Khan <shuahkhan@...il.com>, arve@...roid.com,
Rebecca Schultz Zavin <rebecca@...roid.com>,
Jesper Juhl <jj@...osbits.net>,
Randy Dunlap <rdunlap@...otime.net>,
Stephen Boyd <sboyd@...eaurora.org>,
Thomas Meyer <thomas@...3r.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Marco Stornelli <marco.stornelli@...il.com>,
WANG Cong <xiyou.wangcong@...il.com>,
linux-kernel@...r.kernel.org, devel@...verdev.osuosl.org,
linaro-kernel@...ts.linaro.org, patches@...aro.org,
kernel-team@...roid.com
Subject: Re: [PATCH 2/3] pstore/ram: Switch to persistent_ram routines
On Thu, May 17, 2012 at 12:15 AM, Anton Vorontsov
<anton.vorontsov@...aro.org> wrote:
> The patch switches pstore RAM backend to use persistent_ram routines,
> one step closer to the ECC support.
>
> Signed-off-by: Anton Vorontsov <anton.vorontsov@...aro.org>
> Acked-by: Marco Stornelli <marco.stornelli@...il.com>
> ---
> fs/pstore/ram.c | 106 +++++++++++++++++++++++++++++++------------------------
> 1 file changed, 59 insertions(+), 47 deletions(-)
>
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index e443c9c..62b13ed 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -57,7 +57,7 @@ MODULE_PARM_DESC(dump_oops,
> "set to 1 to dump oopses, 0 to only dump panics (default 1)");
>
> struct ramoops_context {
> - void *virt_addr;
> + struct persistent_ram_zone **przs;
> phys_addr_t phys_addr;
> unsigned long size;
> size_t record_size;
> @@ -85,39 +85,56 @@ static ssize_t ramoops_pstore_read(u64 *id, enum pstore_type_id *type,
> struct pstore_info *psi)
> {
> ssize_t size;
> - char *rambuf;
> struct ramoops_context *cxt = psi->data;
> + struct persistent_ram_zone *prz;
>
> if (cxt->read_count >= cxt->max_count)
> return -EINVAL;
> +
> *id = cxt->read_count++;
> + prz = cxt->przs[*id];
> +
> /* Only supports dmesg output so far. */
> *type = PSTORE_TYPE_DMESG;
> /* TODO(kees): Bogus time for the moment. */
> time->tv_sec = 0;
> time->tv_nsec = 0;
>
> - rambuf = cxt->virt_addr + (*id * cxt->record_size);
> - size = strnlen(rambuf, cxt->record_size);
> + size = persistent_ram_old_size(prz);
> *buf = kmalloc(size, GFP_KERNEL);
> if (*buf == NULL)
> return -ENOMEM;
> - memcpy(*buf, rambuf, size);
> + memcpy(*buf, persistent_ram_old(prz), size);
>
> return size;
> }
>
> +static size_t ramoops_write_kmsg_hdr(struct persistent_ram_zone *prz)
> +{
> + char *hdr;
> + struct timeval timestamp;
> + size_t len;
> +
> + do_gettimeofday(×tamp);
> + hdr = kasprintf(GFP_ATOMIC, RAMOOPS_KERNMSG_HDR "%lu.%lu\n",
> + (long)timestamp.tv_sec, (long)timestamp.tv_usec);
> + WARN_ON_ONCE(!hdr);
> + len = hdr ? strlen(hdr) : 0;
> + persistent_ram_write(prz, hdr, len);
> + kfree(hdr);
> +
> + return len;
> +}
> +
> static int ramoops_pstore_write(enum pstore_type_id type,
> enum kmsg_dump_reason reason,
> u64 *id,
> unsigned int part,
> size_t size, struct pstore_info *psi)
> {
> - char *buf;
> - size_t res;
> - struct timeval timestamp;
> struct ramoops_context *cxt = psi->data;
> - size_t available = cxt->record_size;
> + struct persistent_ram_zone *prz = cxt->przs[cxt->count];
> + size_t hlen;
>
> /* Currently ramoops is designed to only store dmesg dumps. */
> if (type != PSTORE_TYPE_DMESG)
> @@ -142,22 +159,10 @@ static int ramoops_pstore_write(enum pstore_type_id type,
> if (part != 1)
> return -ENOSPC;
>
> - buf = cxt->virt_addr + (cxt->count * cxt->record_size);
> -
> - res = sprintf(buf, "%s", RAMOOPS_KERNMSG_HDR);
> - buf += res;
> - available -= res;
> -
> - do_gettimeofday(×tamp);
> - res = sprintf(buf, "%lu.%lu\n", (long)timestamp.tv_sec, (long)timestamp.tv_usec);
> - buf += res;
> - available -= res;
> -
> - if (size > available)
> - size = available;
> -
> - memcpy(buf, cxt->pstore.buf, size);
> - memset(buf + size, '\0', available - size);
> + hlen = ramoops_write_kmsg_hdr(prz);
> + if (size + hlen > prz->buffer_size)
> + size = prz->buffer_size - hlen;
> + persistent_ram_write(prz, cxt->pstore.buf, size);
This still needs to wipe out the remaining bytes in the buffer (the
second memset above).
> cxt->count = (cxt->count + 1) % cxt->max_count;
>
> @@ -167,14 +172,12 @@ static int ramoops_pstore_write(enum pstore_type_id type,
> static int ramoops_pstore_erase(enum pstore_type_id type, u64 id,
> struct pstore_info *psi)
> {
> - char *buf;
> struct ramoops_context *cxt = psi->data;
>
> if (id >= cxt->max_count)
> return -EINVAL;
>
> - buf = cxt->virt_addr + (id * cxt->record_size);
> - memset(buf, '\0', cxt->record_size);
> + persistent_ram_free_old(cxt->przs[id]);
Same here -- erasing the buffer means wiping it with NULL bytes.
Otherwise, it looks good to me.
-Kees
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists