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: <1429715913.2195.22.camel@HansenPartnership.com>
Date:	Wed, 22 Apr 2015 08:18:33 -0700
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Peter Jones <pjones@...hat.com>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Kweh, Hock Leong" <hock.leong.kweh@...el.com>,
	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 Wed, 2015-04-22 at 09:27 -0400, Peter Jones wrote:
> On Tue, Apr 21, 2015 at 06:58:58PM -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.
> 
> I checked this for the use case we'd talked about before - gnu cat
> /does/ check the error code, but it's easy to miss how, because
> coreutils code has some good ole' gnu-code complexity.  It'll print the
> strerror() representation, but it always exits with 1 as the error
> code.
> 
> Specifically the close on the output is handled by this:
> ---------------
>   initialize_main (&argc, &argv);
>   set_program_name (argv[0]);
>   setlocale (LC_ALL, "");
>   bindtextdomain (PACKAGE, LOCALEDIR);
>   textdomain (PACKAGE);
> 
>   /* Arrange to close stdout if we exit via the
>      case_GETOPT_HELP_CHAR or case_GETOPT_VERSION_CHAR code.
>      Normally STDOUT_FILENO is used rather than stdout, so
>      close_stdout does nothing.  */
>   atexit (close_stdout);
> 
>   /* Parse command line options.  */
> 
>   while ((c = getopt_long (argc, argv, "benstuvAET", long_options, NULL))
> ---------------
> 
> Which in turn does:
> ---------------
> void
> close_stdout (void)
> {
>   if (close_stream (stdout) != 0
>       && !(ignore_EPIPE && errno == EPIPE))
>     {
>       char const *write_error = _("write error");
>       if (file_name)
>         error (0, errno, "%s: %s", quotearg_colon (file_name),
>                write_error);
>       else
>         error (0, errno, "%s", write_error);
> 
>       _exit (exit_failure);
>     }
> 
>    if (close_stream (stderr) != 0)
>      _exit (exit_failure);
> }
> ---------------
> 
> exit_failure is a global from libcoreutils.a which cat never changes
> from the default, so it's always 1.
> 
> (And of course error() is coreutils' own implementation rather than
> glibc's because hey maybe you're not using glibc, but still, it's
> there.)
> 
> So it's /annoying/ to propagate the error from there programatically,
> but it can work.

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.

There are quite a few of these 'transactional blob' problems where we'd
like to use a file/device approach because the data is just passed to
something but have problems because the something wants all or nothing
rather than chunks.  I think all of us who work at the coal face on this
are not enthused by an ioctl solution because of the need for
non-standard tools to effect it.

The alternative might be a two file approach (either in sysfs or a mini
custom fs), one for load up data and the other for initiate transaction
with the data errors (like overflow) being returned on the load up file
and the transaction errors being returned on the write that initiates
the transaction.

My architectural sense is that transaction on close, provided we can
make it a more universally accepted idea, has a lot of potential because
it's more intuitive than the two file approach.

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/