linux-kernel - RE: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface

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-next>] [day] [month] [year] [list]

Message-ID: <F54AEECA5E2B9541821D670476DAE19C2B8AD9CA@PGSMSX102.gar.corp.intel.com>
Date:	Mon, 2 Mar 2015 10:59:00 +0000
From:	"Kweh, Hock Leong" <hock.leong.kweh@...el.com>
To:	Borislav Petkov <bp@...en8.de>
CC:	Andy Lutomirski <luto@...capital.net>,
	Sam Protsenko <semen.protsenko@...aro.org>,
	Matt Fleming <matt@...sole-pimps.org>,
	Ming Lei <ming.lei@...onical.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Ong, Boon Leong" <boon.leong.ong@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>
Subject: RE: Re: [PATCH v2 3/3] efi: Capsule update with user helper
 interface

> -----Original Message-----
> From: Borislav Petkov [mailto:bp@...en8.de]
> Sent: Wednesday, February 25, 2015 8:49 PM
> 
> On Wed, Feb 25, 2015 at 12:38:20PM +0000, Kweh, Hock Leong wrote:
> > The reason we use this interface for efi capsule is that efi capsule
> > support multi binaries to be uploaded and each binary file name
> > can be different.
> 
> So you can write the file path to a second file and reload then, once
> per file.

Thanks for the suggestion. Did some exploration on this approach and
would like to continue the discussion together with this suggested design.

Ideal condition:
- one file note is enough for load binary and status return (capsule_load)
- load steps would be as simple as just:
   echo [binary file name] > capsule_load
- status return in the same command action. If failed, the echo will fail
   with the failing status code.

Trade off:
- does not have the run time flexibility to load any firmware binaries at
   different different path as firmware class  only support one custom
   path inputted during boot time/load time. Unless to add new export
   function for firmware class.
- if any typo on user level or file path not found, firmware class falls back
   to user helper interface. User is required to open another terminal to
   performs:
   -> echo 1 > loading
   -> cat capsule.bin > data
   -> echo 0 > loading
   Or wait for timeout.
- User has the capability to configure the firmware_class time out value.
   If the infinite value is set, the only method to break the infinite waiting
   by manually perform "echo -1 > loading" on the other terminal.

Are you guys okay with these trade off?
Or you guys still okay with the previous 2 design idea?

> 
> Alternatively, you can combine all the files into a cpio archive like
> we do with the microcode loader too, and let the kernel parse the cpio
> archive.

I believe this will make the implementation complicated compare to above.


Regards,
Wilson