linux-kernel - Re: [RFC/PATCHSET 0/3] virtio: Implement virtio pstore device (v3)

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]

Message-ID: <CAM9d7ciwHMPExe++dbTCOwfueKTgEx5O=pEw8bLPpOkpwQtBYw@mail.gmail.com>
Date:   Wed, 24 Aug 2016 00:20:55 +0900
From:   Namhyung Kim <namhyung@...nel.org>
To:     Joel Fernandes <agnel.joel@...il.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        qemu-devel <qemu-devel@...gnu.org>,
        Kees Cook <keescook@...omium.org>
Subject: Re: [RFC/PATCHSET 0/3] virtio: Implement virtio pstore device (v3)

Hi Joel,

On Tue, Aug 23, 2016 at 7:25 PM, Joel Fernandes <agnel.joel@...il.com> wrote:
> 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.

Thanks!

>
> 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.

I wasn't aware of the -mem-path option and it seems that the existing
ramoops pstore backend can take care of it.

>
> 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.

The pstore (ramoops) requires the region of the memory is preserved
across reboot.  Is it possible when -mem-path is used?  I think it's
better to use a separate region/file for pstore rather than being a part
of guest RAM or as you said, it'd be great if qemu supported such a
hybrid mem-path.

Also my approach can handle streams of data bigger than the pstore
buffer size.  Although we can extract the contents of mem-path file
periodically, it might be hard for externel process to know the right
time to extract and there's a possibility of information loss IMHO.

Thanks,
Namhyung