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:	Wed, 22 Apr 2015 09:50:30 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	James Bottomley <James.Bottomley@...senpartnership.com>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Kweh Hock Leong <hock.leong.kweh@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Matt Fleming <matt@...eblueprint.co.uk>,
	"Ong, Boon Leong" <boon.leong.ong@...el.com>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	Ming Lei <ming.lei@...onical.com>
Subject: Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware

On Apr 21, 2015 9:51 PM, "James Bottomley"
<James.Bottomley@...senpartnership.com> wrote:
>
> On Tue, 2015-04-21 at 20:24 -0700, Andy Lutomirski wrote:
> > On Tue, Apr 21, 2015 at 7:20 PM, James Bottomley
> > <James.Bottomley@...senpartnership.com> wrote:
> > > On Tue, 2015-04-21 at 18:58 -0700, Andy Lutomirski wrote:
> > >> On Tue, Apr 21, 2015 at 6:21 PM, James Bottomley
> > >> <James.Bottomley@...senpartnership.com> wrote:
> > >> > Andy, just on the misc device idea, what about triggering the capsule
> > >> > update from close()?  In theory close returns an error code (not sure if
> > >> > most tools actually check this, though).  That means we can do the write
> > >> > in chunks but pass it in atomically on the close and cat will work
> > >> > (provided it checks the return code of close).
> > >>
> > >> I thought about this but IIRC cat doesn't check the return value from close.
> > >
> > > It does in my copy (coreutils-8.23) :
> > >
> > >       if (!STREQ (infile, "-") && close (input_desc) < 0)
> > >         {
> > >           error (0, errno, "%s", infile);
> > >           ok = false;
> > >         }
> > > [...]
> > >   if (have_read_stdin && close (STDIN_FILENO) < 0)
> > >     error (EXIT_FAILURE, errno, _("closing standard input"));
> > >
> >
> > True, but it's stdout that we care about, not stdin :(
>
> Gosh you're determined to force me to wade through this source code,
> aren't you?  That's handled in lib/closeout.c:
>
> /* Close standard output.  On error, issue a diagnostic and _exit
>    with status 'exit_failure'.
>
> ...
>
>
> The point is that, admittedly much to my surprise, it all looks to be
> handled by cat ... so we could proceed to have the transaction completed
> in close in a misc device (or a sysfs file).
>
> Unless there are any other rabbits you'd like to pull out of the hat?

No, maybe it's okay, unless there's an issue where the error would
only be returned on the close of the last reference of the struct
file.  After all, 'cat foo >/sys/bar' doesn't fully close /sys/bar
until after cat exits.

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