linux-kernel - Re: [PATCH 2/2] pstore: update the policy of the UEFI-based backend

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] [day] [month] [year] [list]

Message-ID: <20110903123611.GA28765@srcf.ucam.org>
Date:	Sat, 3 Sep 2011 13:36:11 +0100
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Chen Gong <gong.chen@...ux.intel.com>
Cc:	tony.luck@...el.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] pstore: update the policy of the UEFI-based backend

I don't think this is reasonable. EFI variable space is a shared 
resource. We have no idea what the failure modes of entirely filling it 
would be. If we're going to store multiple records then at the very 
least we need to use QueryVariableInfo() to identify how much space 
there is left, and if it's a 2.1 or later system then we ideally need to 
store these as EFI_VARIABLE_HARDWARE_ERROR_RECORD rather than just plain 
runtime variables. The reason the current implementation doesn't do that 
is that there's still hardware floating around that implements EFI 1.10 
rather than UEFI 2.0

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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/