linux-kernel - Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware

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]

Message-ID: <1429798187.2170.3.camel@HansenPartnership.com>
Date:	Thu, 23 Apr 2015 07:09:47 -0700
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	"Kweh, Hock Leong" <hock.leong.kweh@...el.com>
Cc:	Peter Jones <pjones@...hat.com>,
	Andy Lutomirski <luto@...capital.net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Matt Fleming <matt@...eblueprint.co.uk>,
	Ming Lei <ming.lei@...onical.com>,
	"Ong, Boon Leong" <boon.leong.ong@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	Sam Protsenko <semen.protsenko@...aro.org>,
	Roy Franz <roy.franz@...aro.org>,
	Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi
 firmware

On Thu, 2015-04-23 at 08:30 +0000, Kweh, Hock Leong wrote:
> > -----Original Message-----
> > From: James Bottomley [mailto:James.Bottomley@...senPartnership.com]
> > Sent: Wednesday, April 22, 2015 11:19 PM
> > 
> > 
> > Yes, I think we've all agreed we can do it ... it's now a question of whether we
> > can stomach the ick factor of actually initiating a transaction in close ... I'm still
> > feeling queasy.
> 
> The file "close" here can I understand that the file system will call the "release"
> function at the file_operations struct?
> http://lxr.free-electrons.com/source/include/linux/fs.h#L1538
> 
> So, James you are meaning that we could initiating the update transaction
> inside the f_ops->release() and return the error code if update failed in this
> function?

Well, that's what I was thinking.  However the return value of ->release
doesn't get propagated in sys_close (or indeed anywhere ... no idea why
it returns an int) thanks to the task work additions, so we'd actually
have to use the operation whose value is propagated in sys_close() which
turns out to be flush.

James


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