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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 12 Apr 2013 20:19:13 +0800
From:	Lingzhu Xiang <lxiang@...hat.com>
To:	Matthew Garrett <matthew.garrett@...ula.com>
CC:	matt.fleming@...el.com, linux-efi@...r.kernel.org, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH V4 1/3] efi: Determine how much space is used by boot
 services-only variables

On 04/11/2013 01:46 AM, Matthew Garrett wrote:
> EFI variables can be flagged as being accessible only within boot services.
> This makes it awkward for us to figure out how much space they use at
> runtime. In theory we could figure this out by simply comparing the results
> from QueryVariableInfo() to the space used by all of our variables, but
> that fails if the platform doesn't garbage collect on every boot. Thankfully,
> calling QueryVariableInfo() while still inside boot services gives a more
> reliable answer. This patch passes that information from the EFI boot stub
> up to the efivars code, letting us calculate a reasonably accurate value.
>
> Signed-off-by: Matthew Garrett <matthew.garrett@...ula.com>

I just tried this 3.9-rc6 with this patchset with pstore fulling up 
space and various attempts to manually fulling up space. So far I've 
been able to delete variables and continue creating variables.

Since QueryVariableInfo is no longer trusted and the accounting is done 
by the kernel, I'm somewhat concerned that variables can be repeatedly 
created and deleted until nvram is full of garbage to collect and the 
firmware hits EFI_OUT_OF_RESOURCES. Could this be any kind of problem?


Lingzhu Xiang
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ