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:	Thu, 04 Oct 2012 17:08:48 +0800
From:	Jeremy Kerr <jeremy.kerr@...onical.com>
To:	Matt Fleming <matt.fleming@...el.com>
CC:	"Lee, Chun-Yi" <joeyli.kernel@...il.com>,
	linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org,
	glin@...e.com, "Lee, Chun-Yi" <jlee@...e.com>,
	Matthew Garrett <mjg@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Peter Jones <pjones@...hat.com>
Subject: Re: [PATCH] efi: add efivars kobject to efi sysfs folder

Hi Matt,

> Jeremy, did you want to pick this up as part of your series?

I have this in my series, yes. I'm just working on the authenticated 
delete code, then will send out the next revision.

Speaking of which - Peter: I've realised that doing a GetVariable() 
after the SetVariable is a much cleaner way of checking whether we need 
to drop the inode after an authenticated delete.

Because the inode's size may not be simply updated by the write(), we 
should probably be doing a GetVariable() after an APPEND_WRITE, to read 
the new size. Rather than having a separate (and quite complex) code 
path to check for the delete case, we may as well use the same logic to 
determine if the variable has been deleted.

> Actually, shouldn't the new filesystem be called "efivarfs", or "efifs"
> to make it more explicit that it is a filesystem?

I'm not too fussed about the name, but +1 for efivarfs.

> We also need something in Documentation/filesystems/ describing the old
> EFI variable method, why it's no longer any good, and why the new
> filesystem is favoured. Does anybody have anything to add to the
> following?

Looks good to me. We can always elaborate later, if necessary.

Cheers,


Jeremy

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