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:   Tue, 23 Aug 2016 03:25:01 -0700
From:   Joel Fernandes <agnel.joel@...il.com>
To:     namhyung@...nel.org
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [RFC/PATCHSET 0/3] virtio: Implement virtio pstore device (v3)

From: Namhyung Kim <namhyung@...nel.org>

> Hello,
>
> This is another iteration of the virtio-pstore work.  In this patchset
> I addressed most of feedbacks from previous version and drooped the
> support for PSTORE_TYPE_CONSOLE for simplicity.  It'll be added once the basic 

Hi Namhyung,

This looks like a useful pstore backend. Great work.

BTW, Have you considered using -mem-path in Qemu for this purpose?
I was thinking about using this, and then somehow have kernel reserve a part of physical memory for the pstore. Then after the crash, or whenever you want to read the contents of the pstore on the host, you could just extract that part of the mem-path file.

Any thoughts on what you think about it? In your approach though, you wouldn't need a backing mem-path file which is the size of the guest RAM (which could be as big as the mem-path file). I wonder if the mem-path file can be created sparse, and/or Qemu has support to configure a certain part of guest RAM as file-backed memory and the rest of it from Anonymous memory (not backed by mem-path) so that the size of the mem-path file can be kept at a minimum.

Thanks,
Joel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ