All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>,
	"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	"Bryan O'Donoghue" <pure.logic@nexus-software.ie>,
	Hock Leong Kweh <hock.leong.kweh@intel.com>,
	Borislav Petkov <bp@alien8.de>,
	Sascha Weisenberger <sascha.weisenberger@siemens.com>
Subject: Re: [PATCH v2 5/7] efi/capsule: Prepare for loading images with security header
Date: Tue, 4 Apr 2017 19:39:49 +0200	[thread overview]
Message-ID: <87067f08-4569-f614-3066-09ef4e6a65ed@siemens.com> (raw)
In-Reply-To: <CAKv+Gu9Qf=-atcuz+UcuR9OTaLM3JjUDnmmSMfYeiFKiU5BZvg@mail.gmail.com>

On 2017-03-28 19:23, Ard Biesheuvel wrote:
> On 28 March 2017 at 18:17, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> On 28 March 2017 at 17:18, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>> On 2017-03-28 17:52, Ard Biesheuvel wrote:
>>>> On 28 March 2017 at 16:43, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>> On 2017-03-28 17:13, Jan Kiszka wrote:
>>>>>> On 2017-03-28 15:49, Ard Biesheuvel wrote:
>>>> [..]
>>>>>>> Could you please have a look at
>>>>>>>
>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=quark-capsule
>>>>>>>
>>>>>>> and tell me if that would work for you? I will send them out for
>>>>>>> proper review in any case, but to avoid confusion (if I missed
>>>>>>> something obvious), I don't want to send them out just yet.
>>>>>>
>>>>>> There is more needed to make things work again, maybe around passing the
>>>>>> right image size. I'm looking into this.
>>>>>>
>>>>>
>>>>> This makes CSH images being accepted again:
>>>>>
>>>>> diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
>>>>> index 4b6f93f..a4e2311 100644
>>>>> --- a/arch/x86/platform/efi/quirks.c
>>>>> +++ b/arch/x86/platform/efi/quirks.c
>>>>> @@ -562,6 +562,8 @@ int efi_capsule_setup_info(struct capsule_info *cap_info, void *kbuff,
>>>>>  {
>>>>>         struct quark_security_header *csh = kbuff;
>>>>>
>>>>> +       cap_info->total_size = 0;
>>>>> +
>>>>>         if (!x86_match_cpu(quark_ids))
>>>>>                 goto fallback;
>>>>>
>>>>> @@ -587,12 +589,16 @@ int efi_capsule_setup_info(struct capsule_info *cap_info, void *kbuff,
>>>>>
>>>>>         kbuff += csh->headersize;
>>>>>
>>>>> +       cap_info->total_size = csh->headersize;
>>>>> +
>>>>>  fallback:
>>>>>         if (hdr_bytes < sizeof(efi_capsule_header_t))
>>>>>                 return 0;
>>>>>
>>>>>         memcpy(&cap_info->header, kbuff, sizeof(cap_info->header));
>>>>>
>>>>> +       cap_info->total_size += cap_info->header.imagesize;
>>>>> +
>>>>>         return __efi_capsule_setup_info(cap_info);
>>>>>  }
>>>>>
>>>>> diff --git a/drivers/firmware/efi/capsule-loader.c b/drivers/firmware/efi/capsule-loader.c
>>>>> index e851951..40dc354 100644
>>>>> --- a/drivers/firmware/efi/capsule-loader.c
>>>>> +++ b/drivers/firmware/efi/capsule-loader.c
>>>>> @@ -42,7 +42,7 @@ int __efi_capsule_setup_info(struct capsule_info *cap_info)
>>>>>         int ret;
>>>>>         void *temp_page;
>>>>>
>>>>> -       pages_needed = ALIGN(cap_info->header.imagesize, PAGE_SIZE) / PAGE_SIZE;
>>>>> +       pages_needed = ALIGN(cap_info->total_size, PAGE_SIZE) / PAGE_SIZE;
>>>>>
>>>>>         if (pages_needed == 0) {
>>>>>                 pr_err("invalid capsule size");
>>>>> @@ -59,7 +59,6 @@ int __efi_capsule_setup_info(struct capsule_info *cap_info)
>>>>>                 return ret;
>>>>>         }
>>>>>
>>>>> -       cap_info->total_size = cap_info->header.imagesize;
>>>>>         temp_page = krealloc(cap_info->pages,
>>>>>                              pages_needed * sizeof(void *),
>>>>>                              GFP_KERNEL | __GFP_ZERO);
>>>>> @@ -87,6 +86,8 @@ int __weak efi_capsule_setup_info(struct capsule_info *cap_info, void *kbuff,
>>>>>
>>>>>         memcpy(&cap_info->header, kbuff, sizeof(cap_info->header));
>>>>>
>>>>> +       cap_info->total_size = cap_info->header.imagesize;
>>>>> +
>>>>>         return __efi_capsule_setup_info(cap_info);
>>>>>  }
>>>>>
>>>>
>>>> OK, thanks for debugging that.
>>>>
>>>>> But then my changes to efi_capsule_update are missing the present the
>>>>> right format to the loader. As efi_capsule_update needs to lay out the
>>>>> sg-list in as special way, excluding the CSH on the first page, it needs
>>>>> to know about the displacement.
>>>>>
>>>>> Any suggestions how to address that without rolling back to my aproach?
>>>>>
>>>>
>>>> OK, I'm a bit lost now: for my understanding, could you please
>>>> reiterate how the CSH image deviates from the ordinary one? Or more
>>>> specifically, what exactly is preventing us from simply chopping off
>>>> the CSH header and pushing the capsule header + payload into
>>>> /dev/capsule_loader?
>>>>
>>>
>>> Devices that mandate a signed capsule for updates expect the CSH in
>>> front of the regular capsule image. The interface to UEFI remains
>>> unchanged, i.e. you pass the virtually chopped off capsule, but you have
>>> to leave the CSH in RAM right in front of that very same image. It's a
>>> "nice" side-channel API.
>>>
>>
>> Wow, that is worse than I thought.
>>
>> So my suggestion (which I coded up, please pull again),
> 
> Hmm, it does not build on x86 atm. Let me fix that up first (~15 min)
> 

Just tested the patches from b51f20c780 on top of our queue, and this
time the flashing worked fine!

Thanks,
Jan

>> is to replace
>> the array of struct page pointers with an array of physical addresses
>> in the capsule_info struct. This way, your special version of
>> efi_capsule_setup_info() can advance the first one by the size of the
>> header.
>>
>> I hope this works for you. I am not sure whether imagesize needs to be
>> modified, so I left it alone for now (but I suspect it should be).

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kiszka <jan.kiszka-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org>
To: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Matt Fleming
	<matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>,
	"linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linux Kernel Mailing List
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Andy Shevchenko
	<andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Bryan O'Donoghue
	<pure.logic-SyKdqv6vbfZdzvEItQ6vdLNAH6kLmebB@public.gmane.org>,
	Hock Leong Kweh
	<hock.leong.kweh-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>,
	Sascha Weisenberger
	<sascha.weisenberger-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org>
Subject: Re: [PATCH v2 5/7] efi/capsule: Prepare for loading images with security header
Date: Tue, 4 Apr 2017 19:39:49 +0200	[thread overview]
Message-ID: <87067f08-4569-f614-3066-09ef4e6a65ed@siemens.com> (raw)
In-Reply-To: <CAKv+Gu9Qf=-atcuz+UcuR9OTaLM3JjUDnmmSMfYeiFKiU5BZvg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 2017-03-28 19:23, Ard Biesheuvel wrote:
> On 28 March 2017 at 18:17, Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> On 28 March 2017 at 17:18, Jan Kiszka <jan.kiszka-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org> wrote:
>>> On 2017-03-28 17:52, Ard Biesheuvel wrote:
>>>> On 28 March 2017 at 16:43, Jan Kiszka <jan.kiszka-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org> wrote:
>>>>> On 2017-03-28 17:13, Jan Kiszka wrote:
>>>>>> On 2017-03-28 15:49, Ard Biesheuvel wrote:
>>>> [..]
>>>>>>> Could you please have a look at
>>>>>>>
>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=quark-capsule
>>>>>>>
>>>>>>> and tell me if that would work for you? I will send them out for
>>>>>>> proper review in any case, but to avoid confusion (if I missed
>>>>>>> something obvious), I don't want to send them out just yet.
>>>>>>
>>>>>> There is more needed to make things work again, maybe around passing the
>>>>>> right image size. I'm looking into this.
>>>>>>
>>>>>
>>>>> This makes CSH images being accepted again:
>>>>>
>>>>> diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
>>>>> index 4b6f93f..a4e2311 100644
>>>>> --- a/arch/x86/platform/efi/quirks.c
>>>>> +++ b/arch/x86/platform/efi/quirks.c
>>>>> @@ -562,6 +562,8 @@ int efi_capsule_setup_info(struct capsule_info *cap_info, void *kbuff,
>>>>>  {
>>>>>         struct quark_security_header *csh = kbuff;
>>>>>
>>>>> +       cap_info->total_size = 0;
>>>>> +
>>>>>         if (!x86_match_cpu(quark_ids))
>>>>>                 goto fallback;
>>>>>
>>>>> @@ -587,12 +589,16 @@ int efi_capsule_setup_info(struct capsule_info *cap_info, void *kbuff,
>>>>>
>>>>>         kbuff += csh->headersize;
>>>>>
>>>>> +       cap_info->total_size = csh->headersize;
>>>>> +
>>>>>  fallback:
>>>>>         if (hdr_bytes < sizeof(efi_capsule_header_t))
>>>>>                 return 0;
>>>>>
>>>>>         memcpy(&cap_info->header, kbuff, sizeof(cap_info->header));
>>>>>
>>>>> +       cap_info->total_size += cap_info->header.imagesize;
>>>>> +
>>>>>         return __efi_capsule_setup_info(cap_info);
>>>>>  }
>>>>>
>>>>> diff --git a/drivers/firmware/efi/capsule-loader.c b/drivers/firmware/efi/capsule-loader.c
>>>>> index e851951..40dc354 100644
>>>>> --- a/drivers/firmware/efi/capsule-loader.c
>>>>> +++ b/drivers/firmware/efi/capsule-loader.c
>>>>> @@ -42,7 +42,7 @@ int __efi_capsule_setup_info(struct capsule_info *cap_info)
>>>>>         int ret;
>>>>>         void *temp_page;
>>>>>
>>>>> -       pages_needed = ALIGN(cap_info->header.imagesize, PAGE_SIZE) / PAGE_SIZE;
>>>>> +       pages_needed = ALIGN(cap_info->total_size, PAGE_SIZE) / PAGE_SIZE;
>>>>>
>>>>>         if (pages_needed == 0) {
>>>>>                 pr_err("invalid capsule size");
>>>>> @@ -59,7 +59,6 @@ int __efi_capsule_setup_info(struct capsule_info *cap_info)
>>>>>                 return ret;
>>>>>         }
>>>>>
>>>>> -       cap_info->total_size = cap_info->header.imagesize;
>>>>>         temp_page = krealloc(cap_info->pages,
>>>>>                              pages_needed * sizeof(void *),
>>>>>                              GFP_KERNEL | __GFP_ZERO);
>>>>> @@ -87,6 +86,8 @@ int __weak efi_capsule_setup_info(struct capsule_info *cap_info, void *kbuff,
>>>>>
>>>>>         memcpy(&cap_info->header, kbuff, sizeof(cap_info->header));
>>>>>
>>>>> +       cap_info->total_size = cap_info->header.imagesize;
>>>>> +
>>>>>         return __efi_capsule_setup_info(cap_info);
>>>>>  }
>>>>>
>>>>
>>>> OK, thanks for debugging that.
>>>>
>>>>> But then my changes to efi_capsule_update are missing the present the
>>>>> right format to the loader. As efi_capsule_update needs to lay out the
>>>>> sg-list in as special way, excluding the CSH on the first page, it needs
>>>>> to know about the displacement.
>>>>>
>>>>> Any suggestions how to address that without rolling back to my aproach?
>>>>>
>>>>
>>>> OK, I'm a bit lost now: for my understanding, could you please
>>>> reiterate how the CSH image deviates from the ordinary one? Or more
>>>> specifically, what exactly is preventing us from simply chopping off
>>>> the CSH header and pushing the capsule header + payload into
>>>> /dev/capsule_loader?
>>>>
>>>
>>> Devices that mandate a signed capsule for updates expect the CSH in
>>> front of the regular capsule image. The interface to UEFI remains
>>> unchanged, i.e. you pass the virtually chopped off capsule, but you have
>>> to leave the CSH in RAM right in front of that very same image. It's a
>>> "nice" side-channel API.
>>>
>>
>> Wow, that is worse than I thought.
>>
>> So my suggestion (which I coded up, please pull again),
> 
> Hmm, it does not build on x86 atm. Let me fix that up first (~15 min)
> 

Just tested the patches from b51f20c780 on top of our queue, and this
time the flashing worked fine!

Thanks,
Jan

>> is to replace
>> the array of struct page pointers with an array of physical addresses
>> in the capsule_info struct. This way, your special version of
>> efi_capsule_setup_info() can advance the first one by the size of the
>> header.
>>
>> I hope this works for you. I am not sure whether imagesize needs to be
>> modified, so I left it alone for now (but I suspect it should be).

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

  parent reply	other threads:[~2017-04-04 17:40 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-24 17:34 [PATCH v2 0/7] efi: Enhance capsule loader to support signed Quark images Jan Kiszka
2017-03-24 17:34 ` Jan Kiszka
2017-03-24 17:34 ` [PATCH v2 1/7] efi/capsule: Fix return code on failing kmap/vmap Jan Kiszka
2017-03-24 17:34   ` Jan Kiszka
2017-03-24 18:14   ` Ard Biesheuvel
2017-03-24 17:34 ` [PATCH v2 2/7] efi/capsule: Remove pr_debug on ENOMEM or EFAULT Jan Kiszka
2017-03-24 17:34   ` Jan Kiszka
2017-03-24 18:15   ` Ard Biesheuvel
2017-03-24 18:15     ` Ard Biesheuvel
2017-03-24 17:34 ` [PATCH v2 3/7] efi/capsule: Clean up pr_err/info messages Jan Kiszka
2017-03-24 17:34   ` Jan Kiszka
2017-03-24 18:17   ` Ard Biesheuvel
2017-03-24 18:17     ` Ard Biesheuvel
2017-03-24 17:34 ` [PATCH v2 4/7] efi/capsule: Adjust return type of efi_capsule_setup_info Jan Kiszka
2017-03-24 17:34   ` Jan Kiszka
2017-03-24 18:42   ` Ard Biesheuvel
2017-03-24 18:42     ` Ard Biesheuvel
2017-03-24 17:34 ` [PATCH v2 5/7] efi/capsule: Prepare for loading images with security header Jan Kiszka
2017-03-24 17:34   ` Jan Kiszka
2017-03-24 20:25   ` Andy Shevchenko
2017-03-24 20:25     ` Andy Shevchenko
2017-03-28 13:49   ` Ard Biesheuvel
2017-03-28 13:49     ` Ard Biesheuvel
2017-03-28 15:13     ` Jan Kiszka
2017-03-28 15:13       ` Jan Kiszka
2017-03-28 15:43       ` Jan Kiszka
2017-03-28 15:52         ` Ard Biesheuvel
2017-03-28 16:18           ` Jan Kiszka
2017-03-28 16:18             ` Jan Kiszka
2017-03-28 17:17             ` Ard Biesheuvel
2017-03-28 17:17               ` Ard Biesheuvel
2017-03-28 17:23               ` Ard Biesheuvel
2017-03-28 17:23                 ` Ard Biesheuvel
2017-03-30  9:06                 ` Jan Kiszka
2017-04-04 17:39                 ` Jan Kiszka [this message]
2017-04-04 17:39                   ` Jan Kiszka
2017-03-24 17:34 ` [PATCH v2 6/7] efi/capsule: Factor out overloadable efi_capsule_identify_image Jan Kiszka
2017-03-24 17:34   ` Jan Kiszka
2017-03-24 17:34 ` [PATCH v2 7/7] efi/capsule: Add support for Quark security header Jan Kiszka
2017-03-24 17:34   ` Jan Kiszka
2017-03-24 20:36   ` Andy Shevchenko
2017-03-24 20:36     ` Andy Shevchenko
2017-03-25 23:33   ` kbuild test robot
2017-03-24 20:39 ` [PATCH v2 0/7] efi: Enhance capsule loader to support signed Quark images Andy Shevchenko
2017-03-24 20:39   ` Andy Shevchenko
2017-03-27 11:19   ` Jan Kiszka
2017-03-27 11:19     ` Jan Kiszka
2017-03-27 10:29 ` Bryan O'Donoghue
2017-03-27 10:29   ` Bryan O'Donoghue
2017-03-27 11:01   ` Jan Kiszka
2017-03-27 11:01     ` Jan Kiszka
2017-03-28  0:48     ` Bryan O'Donoghue
2017-03-28  0:48       ` Bryan O'Donoghue

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=87067f08-4569-f614-3066-09ef4e6a65ed@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bp@alien8.de \
    --cc=hock.leong.kweh@intel.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=pure.logic@nexus-software.ie \
    --cc=sascha.weisenberger@siemens.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.