linux-kernel - Re: [GIT PULL] EFI changes for v3.16

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, 20 May 2014 13:00:31 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Matt Fleming <matt@...sole-pimps.org>,
	Ingo Molnar <mingo@...nel.org>, linux-efi@...r.kernel.org,
	linux-kernel@...r.kernel.org, "Luck, Tony" <tony.luck@...el.com>
Subject: Re: [GIT PULL] EFI changes for v3.16

On Mon, May 19, 2014 at 05:17:01PM -0700, H. Peter Anvin wrote:
> I thought the whole point of allowing pstore in IRQ context was to
> write oopsen (panics?)

Right, so Tony meant last time we were talking about it that nvram is
too slow for collecting the whole dmesg into it (could mess up timing
and such - although, come to think of it, we do have CONFIG_PRINTK_TIME
so we can sort them if they're out of order...)

So what I'm questioning is whether a single oops/panic can be written
out to nvram reliably too?

Because if not, then the problem we're trying to solve is moot and
beside the point - maybe we should not use EFI as a pstore backend in
irq context at all?

I'm just putting it on the table so that we have talked about it too,
before devising a solution.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/