linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Kweh, Hock Leong" <hock.leong.kweh@intel.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Matt Fleming <matt@console-pimps.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Ong, Boon Leong" <boon.leong.ong@intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
	Sam Protsenko <semen.protsenko@linaro.org>,
	Peter Jones <pjones@redhat.com>, Roy Franz <roy.franz@linaro.org>,
	"Borislav Petkov" <bp@alien8.de>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	"Fleming, Matt" <matt.fleming@intel.com>
Subject: RE: [PATCH v6 2/2] efi: a misc char interface for user to update efi firmware
Date: Tue, 6 Oct 2015 03:03:54 +0000	[thread overview]
Message-ID: <F54AEECA5E2B9541821D670476DAE19C4A8648AB@PGSMSX102.gar.corp.intel.com> (raw)
In-Reply-To: <CALCETrU4+UT_2z1J+WUwnweMSuAyA0=-qoc24b2QStqUzyL3mw@mail.gmail.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3981 bytes --]

> -----Original Message-----
> From: Andy Lutomirski [mailto:luto@amacapital.net]
> Sent: Tuesday, October 06, 2015 3:06 AM
>
> >> And what if cap_hdr isn't written yet?
> >
> > This design mainly targeting a simplest interface that user could
> > upload efi capsule in a single command action: cat capsule.bin >
> > /dev/efi_capsule_loader
> >
> > So, it is expected that efi capsule header is at the starting of the binary file.
> > Already capture this into efi_capsule_write() comment in v7 patchset:
> > https://lkml.org/lkml/2015/10/5/232
> >
> > If you want to enhance this module to support creating efi capsule
> > header for your binary, strongly believe this design can cater the
> > implementation such as adding ioctl to pass in efi guid, flags and so on
> parameters to create the header.
> >
> 
> No, that's not what I mean.  What I mean is: what if cat writes too little in the
> first write call (e.g. 3 bytes).

Yes, I could add a condition checking for this:
if (write_byte < sizeof(efi_capsule_header_t) { ... }
to ensure the 1st block count does not less than the capsule header size.
If not, will return error.

Do you have any idea that in what kind of situation user app will pass in less than
28 bytes each time?

> 
> >
> >>
> >> > +               if (ret) {
> >> > +                       pr_err("%s: efi_capsule_supported() failed\n",
> >> > +                              __func__);
> >> > +                       kunmap(kbuff_page);
> >> > +                       efi_free_all_buff_pages(kbuff_page);
> >> > +                       return ret;
> >> > +               }
> >> > +
> >> > +               cap_info.total_size = cap_hdr->imagesize;
> >> > +               cap_info.pages = kmalloc_array(pages_needed, sizeof(void *),
> >> > +                                               GFP_KERNEL);
> >> > +               if (!cap_info.pages) {
> >> > +                       pr_debug("%s: kmalloc_array() failed\n", __func__);
> >> > +                       kunmap(kbuff_page);
> >> > +                       efi_free_all_buff_pages(kbuff_page);
> >> > +                       return -ENOMEM;
> >> > +               }
> >> > +
> >> > +               cap_info.header_obtained = 1;
> >>
> >> I don't see how you know that the header is obtained.
> >
> > Capsule header is at the starting block of image binary. We can obtain
> > the header through the 1st block of write action.
> 
> That's quite an assumption to make.

Answered as above.

> 
> >> > +       cap_info.pages[cap_info.index++] = kbuff_page;
> >>
> >> Huh?  You might now have allocated a whole page.
> >
> > Yes, the efi capsule header does tell the whole image size.
> 
> So what?  Did you allocate a page in this particular write call?  If so, then
> cap_info.index++, etc is okay.  If not, it's wrong.

Yes, the allocation is at:
cap_info.pages = kmalloc_array(pages_needed, sizeof(void *),
                                                                 GFP_KERNEL);
before line:
cap_info.header_obtained = 1;

> 
> >> > +               }
> >> > +               /* indicate capsule binary uploading is done */
> >> > +               cap_info.index = -1;
> >>
> >> Should count > cap_info.total_size be an error?
> >>
> >> --Andy
> >
> > Yes, this is why after the write count already reaches the image size
> > stated in efi capsule header, an indicator will be flagged for
> > subsequence write to be returned -EIO as what Matt has commented.
> 
> What if *this very same write* writes too much data?
> 

I think it is still okay as the data is still within a page and this could cater the image
binary that padding to page size. Whatever next write that more than the current
page, will return error -EIO.

If you think that should flag an error, I could simply add the condition checking
to it.


Thanks & Regards,
Wilson

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

  reply	other threads:[~2015-10-06  3:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-05 16:07 [PATCH v6 2/2] efi: a misc char interface for user to update efi firmware Kweh, Hock Leong
2015-10-05 19:05 ` Andy Lutomirski
2015-10-06  3:03   ` Kweh, Hock Leong [this message]
  -- strict thread matches above, loose matches on Subject: below --
2015-10-01 21:05 [PATCH v6 0/2] Enable capsule loader interface for efi firmware updating Kweh, Hock Leong
2015-10-01 21:05 ` [PATCH v6 2/2] efi: a misc char interface for user to update efi firmware Kweh, Hock Leong
2015-10-02 17:39   ` Borislav Petkov
2015-10-03 23:16   ` Andy Lutomirski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F54AEECA5E2B9541821D670476DAE19C4A8648AB@PGSMSX102.gar.corp.intel.com \
    --to=hock.leong.kweh@intel.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=boon.leong.ong@intel.com \
    --cc=bp@alien8.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=matt.fleming@intel.com \
    --cc=matt@console-pimps.org \
    --cc=pjones@redhat.com \
    --cc=roy.franz@linaro.org \
    --cc=semen.protsenko@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).