linux-kernel - Re: [PATCH] kdump, vmcoreinfo: Export sme_me

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:   Wed, 31 Oct 2018 11:10:54 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Dave Young <dyoung@...hat.com>
Cc:     lijiang <lijiang@...hat.com>, Baoquan He <bhe@...hat.com>,
        Petr Tesarik <ptesarik@...e.cz>, linux-kernel@...r.kernel.org,
        x86@...nel.org, kexec@...ts.infradead.org, mingo@...hat.com,
        tglx@...utronix.de, Kazuhito Hagio <khagio@...hat.com>
Subject: Re: [PATCH] kdump, vmcoreinfo: Export sme_me_mask value to vmcoreinfo

On Wed, Oct 31, 2018 at 10:47:48AM +0800, Dave Young wrote:
> It is a mist only a few kdump people know them, documenting them will help
> people to understand and review. It will also be clearer instead of
> digging into code?

Wholeheartedly agreed. Especially if people start using vmcoreinfo for
other stuff, like live debugging:

https://lkml.kernel.org/r/1540593788-28181-1-git-send-email-bhsharma@redhat.com

> The document can briefly explain what is vmcoreinfo, why we need it, and
> some background info.  Then list the exported values with some
> classifying by core kernel, arch related,  string or number etc.  For
> most of them like Baoquan said no need more explanation, but add
> explanations for something if needed like this sme mask.

And add explanations for *all* of them!

If this becomes an API, then it better be documented.

> But I think this can be done separately instead of blocking this patch.

We have three months to the next merge window - I'm sure you guys can do
both. :-)

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.