Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1638436 > unrolled thread

[PATCH] kexec_file: Adjust type of kexec_purgatory

Started byKees Cook <keescook@chromium.org>
First post2017-05-10 01:10 +0200
Last post2017-05-10 22:00 +0200
Articles 5 — 3 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH] kexec_file: Adjust type of kexec_purgatory Kees Cook <keescook@chromium.org> - 2017-05-10 01:10 +0200
    Re: [PATCH] kexec_file: Adjust type of kexec_purgatory Daniel Micay <danielmicay@gmail.com> - 2017-05-10 01:20 +0200
      Re: [PATCH] kexec_file: Adjust type of kexec_purgatory Kees Cook <keescook@chromium.org> - 2017-05-10 01:30 +0200
        Re: [PATCH] kexec_file: Adjust type of kexec_purgatory ebiederm@xmission.com (Eric W. Biederman) - 2017-05-10 02:30 +0200
          Re: [PATCH] kexec_file: Adjust type of kexec_purgatory Kees Cook <keescook@chromium.org> - 2017-05-10 22:00 +0200

#1638436 — [PATCH] kexec_file: Adjust type of kexec_purgatory

FromKees Cook <keescook@chromium.org>
Date2017-05-10 01:10 +0200
Subject[PATCH] kexec_file: Adjust type of kexec_purgatory
Message-ID<tFmqu-8sO-3@gated-at.bofh.it>
Defining kexec_purgatory as a zero-length char array upsets compile
time size checking. Since this is entirely runtime sized, switch
this to void *. This silences the warning generated by the future
CONFIG_FORTIFY_SOURCE, which did not like the memcmp() of a "0 byte"
array.

Cc: Daniel Micay <danielmicay@gmail.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 kernel/kexec_file.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index b118735fea9d..bc86f85f1329 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -30,7 +30,7 @@
  * Declare these symbols weak so that if architecture provides a purgatory,
  * these will be overridden.
  */
-char __weak kexec_purgatory[0];
+void * __weak kexec_purgatory;
 size_t __weak kexec_purgatory_size = 0;
 
 static int kexec_calculate_store_digests(struct kimage *image);
-- 
2.7.4


-- 
Kees Cook
Pixel Security

[toc] | [next] | [standalone]

#1638445

FromDaniel Micay <danielmicay@gmail.com>
Date2017-05-10 01:20 +0200
Message-ID<tFmA9-5P-9@gated-at.bofh.it>
In reply to#1638436
On Tue, 2017-05-09 at 16:06 -0700, Kees Cook wrote:
> Defining kexec_purgatory as a zero-length char array upsets compile
> time size checking. Since this is entirely runtime sized, switch
> this to void *. This silences the warning generated by the future
> CONFIG_FORTIFY_SOURCE, which did not like the memcmp() of a "0 byte"
> array.
> 
> Cc: Daniel Micay <danielmicay@gmail.com>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
>  kernel/kexec_file.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index b118735fea9d..bc86f85f1329 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -30,7 +30,7 @@
>   * Declare these symbols weak so that if architecture provides a
> purgatory,
>   * these will be overridden.
>   */
> -char __weak kexec_purgatory[0];
> +void * __weak kexec_purgatory;
>  size_t __weak kexec_purgatory_size = 0;
>  
>  static int kexec_calculate_store_digests(struct kimage *image);
> -- 
> 2.7.4

It seems more correct to use char `char __weak kexec_purgatory[]`,
otherwise isn't __builtin_object_size ending up as 8, which is still
wrong?

[toc] | [prev] | [next] | [standalone]

#1638448

FromKees Cook <keescook@chromium.org>
Date2017-05-10 01:30 +0200
Message-ID<tFmJQ-9n-7@gated-at.bofh.it>
In reply to#1638445
On Tue, May 9, 2017 at 4:13 PM, Daniel Micay <danielmicay@gmail.com> wrote:
> On Tue, 2017-05-09 at 16:06 -0700, Kees Cook wrote:
>> Defining kexec_purgatory as a zero-length char array upsets compile
>> time size checking. Since this is entirely runtime sized, switch
>> this to void *. This silences the warning generated by the future
>> CONFIG_FORTIFY_SOURCE, which did not like the memcmp() of a "0 byte"
>> array.
>>
>> Cc: Daniel Micay <danielmicay@gmail.com>
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>> ---
>>  kernel/kexec_file.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
>> index b118735fea9d..bc86f85f1329 100644
>> --- a/kernel/kexec_file.c
>> +++ b/kernel/kexec_file.c
>> @@ -30,7 +30,7 @@
>>   * Declare these symbols weak so that if architecture provides a
>> purgatory,
>>   * these will be overridden.
>>   */
>> -char __weak kexec_purgatory[0];
>> +void * __weak kexec_purgatory;
>>  size_t __weak kexec_purgatory_size = 0;
>>
>>  static int kexec_calculate_store_digests(struct kimage *image);
>> --
>> 2.7.4
>
> It seems more correct to use char `char __weak kexec_purgatory[]`,
> otherwise isn't __builtin_object_size ending up as 8, which is still
> wrong?

I tried [], that was my instinct, too, but since this is a __weak and
not an extern, that doesn't work:

kernel/kexec_file.c:33:13: warning: array ‘kexec_purgatory’ assumed to
have one element
 char __weak kexec_purgatory[];
             ^~~~~~~~~~~~~~~

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [next] | [standalone]

#1638467

Fromebiederm@xmission.com (Eric W. Biederman)
Date2017-05-10 02:30 +0200
Message-ID<tFnFU-MR-9@gated-at.bofh.it>
In reply to#1638448
Kees Cook <keescook@chromium.org> writes:

> On Tue, May 9, 2017 at 4:13 PM, Daniel Micay <danielmicay@gmail.com> wrote:
>> On Tue, 2017-05-09 at 16:06 -0700, Kees Cook wrote:
>>> Defining kexec_purgatory as a zero-length char array upsets compile
>>> time size checking. Since this is entirely runtime sized, switch
>>> this to void *. This silences the warning generated by the future
>>> CONFIG_FORTIFY_SOURCE, which did not like the memcmp() of a "0 byte"
>>> array.
>>>
>>> Cc: Daniel Micay <danielmicay@gmail.com>
>>> Signed-off-by: Kees Cook <keescook@chromium.org>
>>> ---
>>>  kernel/kexec_file.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
>>> index b118735fea9d..bc86f85f1329 100644
>>> --- a/kernel/kexec_file.c
>>> +++ b/kernel/kexec_file.c
>>> @@ -30,7 +30,7 @@
>>>   * Declare these symbols weak so that if architecture provides a
>>> purgatory,
>>>   * these will be overridden.
>>>   */
>>> -char __weak kexec_purgatory[0];
>>> +void * __weak kexec_purgatory;
>>>  size_t __weak kexec_purgatory_size = 0;
>>>
>>>  static int kexec_calculate_store_digests(struct kimage *image);
>>> --
>>> 2.7.4
>>
>> It seems more correct to use char `char __weak kexec_purgatory[]`,
>> otherwise isn't __builtin_object_size ending up as 8, which is still
>> wrong?
>
> I tried [], that was my instinct, too, but since this is a __weak and
> not an extern, that doesn't work:
>
> kernel/kexec_file.c:33:13: warning: array ‘kexec_purgatory’ assumed to
> have one element
>  char __weak kexec_purgatory[];
>              ^~~~~~~~~~~~~~~

Nor does "void *kexec_purgatory" as that says at the address known as
kexec_purgatory is a void pointer not a blob a bytes that can be used
for something interesting.

Better to get rid of the __weak and deal with that fallout.

Eric

[toc] | [prev] | [next] | [standalone]

#1639061

FromKees Cook <keescook@chromium.org>
Date2017-05-10 22:00 +0200
Message-ID<tFFW9-4OQ-1@gated-at.bofh.it>
In reply to#1638467
On Tue, May 9, 2017 at 5:15 PM, Eric W. Biederman <ebiederm@xmission.com> wrote:
> Kees Cook <keescook@chromium.org> writes:
>> kernel/kexec_file.c:33:13: warning: array ‘kexec_purgatory’ assumed to
>> have one element
>>  char __weak kexec_purgatory[];
>>              ^~~~~~~~~~~~~~~
>
> Nor does "void *kexec_purgatory" as that says at the address known as
> kexec_purgatory is a void pointer not a blob a bytes that can be used
> for something interesting.
>
> Better to get rid of the __weak and deal with that fallout.

Agreed. This is actually pretty easy, since only x86 and PPC use
kexec_file, and both define purgatories. I'll send an updated patch.

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web