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

Groups > linux.kernel > #1666354 > unrolled thread

Re: linux-next: build failure after merge of the akpm-current tree

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: linux-next: build failure after merge of the akpm-current tree Stephen Rothwell <sfr@canb.auug.org.au> - 2017-06-15 03:40 +0200
    Re: linux-next: build failure after merge of the akpm-current tree Kees Cook <keescook@chromium.org> - 2017-06-15 04:00 +0200
      Re: linux-next: build failure after merge of the akpm-current tree Daniel Micay <danielmicay@gmail.com> - 2017-06-15 04:00 +0200
        Re: linux-next: build failure after merge of the akpm-current tree Stephen Rothwell <sfr@canb.auug.org.au> - 2017-06-15 04:10 +0200
          Re: linux-next: build failure after merge of the akpm-current tree Daniel Micay <danielmicay@gmail.com> - 2017-06-15 04:20 +0200
            Re: linux-next: build failure after merge of the akpm-current tree Kees Cook <keescook@chromium.org> - 2017-06-15 04:30 +0200
              Re: linux-next: build failure after merge of the akpm-current tree Daniel Micay <danielmicay@gmail.com> - 2017-06-15 04:40 +0200
      Re: linux-next: build failure after merge of the akpm-current tree Stephen Rothwell <sfr@canb.auug.org.au> - 2017-06-15 04:10 +0200
        Re: linux-next: build failure after merge of the akpm-current tree Kees Cook <keescook@chromium.org> - 2017-06-15 04:20 +0200
          Re: linux-next: build failure after merge of the akpm-current tree Daniel Micay <danielmicay@gmail.com> - 2017-06-15 05:20 +0200
            Re: linux-next: build failure after merge of the akpm-current tree Michael Ellerman <mpe@ellerman.id.au> - 2017-06-15 08:00 +0200
              Re: linux-next: build failure after merge of the akpm-current tree Kees Cook <keescook@chromium.org> - 2017-06-15 17:20 +0200
      Re: linux-next: build failure after merge of the akpm-current tree Andrew Morton <akpm@linux-foundation.org> - 2017-06-15 21:20 +0200
        Re: linux-next: build failure after merge of the akpm-current tree Kees Cook <keescook@chromium.org> - 2017-06-16 01:50 +0200
          Re: linux-next: build failure after merge of the akpm-current tree Daniel Micay <danielmicay@gmail.com> - 2017-06-16 02:10 +0200
            Re: linux-next: build failure after merge of the akpm-current tree Kees Cook <keescook@chromium.org> - 2017-06-16 02:40 +0200
              Re: linux-next: build failure after merge of the akpm-current tree Stephen Rothwell <sfr@canb.auug.org.au> - 2017-06-16 03:30 +0200
          Re: linux-next: build failure after merge of the akpm-current tree Andrew Morton <akpm@linux-foundation.org> - 2017-06-16 19:20 +0200
            Re: linux-next: build failure after merge of the akpm-current tree Kees Cook <keescook@chromium.org> - 2017-06-19 22:30 +0200

#1666354 — Re: linux-next: build failure after merge of the akpm-current tree

Hi all,

On Mon, 5 Jun 2017 17:01:17 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> sound/pcmcia/pdaudiocf/pdaudiocf.o: warning: objtool: .text: unexpected end of section
> arch/x86/ras/mce_amd_inj.o: warning: objtool: inj_readme_read() falls through to next function extcpu_fops_open()
> sound/sound_core.o: warning: objtool: register_sound_special_device() falls through to next function register_sound_special()
> 
> and many more like those. Also:
> 
> In file included from /home/sfr/next/next/include/linux/bitmap.h:8:0,
>                  from /home/sfr/next/next/include/linux/cpumask.h:11,
>                  from /home/sfr/next/next/arch/x86/include/asm/cpumask.h:4,
>                  from /home/sfr/next/next/arch/x86/include/asm/msr.h:10,
>                  from /home/sfr/next/next/arch/x86/include/asm/processor.h:20,
>                  from /home/sfr/next/next/arch/x86/include/asm/cpufeature.h:4,
>                  from /home/sfr/next/next/arch/x86/include/asm/thread_info.h:52,
>                  from /home/sfr/next/next/include/linux/thread_info.h:37,
>                  from /home/sfr/next/next/arch/x86/include/asm/preempt.h:6,
>                  from /home/sfr/next/next/include/linux/preempt.h:80,
>                  from /home/sfr/next/next/include/linux/spinlock.h:50,
>                  from /home/sfr/next/next/include/linux/mmzone.h:7,
>                  from /home/sfr/next/next/include/linux/gfp.h:5,
>                  from /home/sfr/next/next/arch/x86/power/hibernate_64.c:11:
> In function 'memcpy',
>     inlined from 'relocate_restore_code' at /home/sfr/next/next/arch/x86/power/hibernate_64.c:150:2,
>     inlined from 'swsusp_arch_resume' at /home/sfr/next/next/arch/x86/power/hibernate_64.c:185:8:
> /home/sfr/next/next/include/linux/string.h:309:4: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter
>     __read_overflow2();
>     ^
> 
> Caused by commit
> 
>   088a5ecf7581 ("include/linux/string.h: add the option of fortified string.h functions")
> 
> We really need to fix all the known problems it detects *before*
> merging this commit ...
> 
> I have reverted it for today.

I am still needing to revert this every day ...

-- 
Cheers,
Stephen Rothwell

[toc] | [next] | [standalone]

#1666365

On Wed, Jun 14, 2017 at 6:35 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> On Mon, 5 Jun 2017 17:01:17 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> After merging the akpm-current tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> sound/pcmcia/pdaudiocf/pdaudiocf.o: warning: objtool: .text: unexpected end of section
>> arch/x86/ras/mce_amd_inj.o: warning: objtool: inj_readme_read() falls through to next function extcpu_fops_open()
>> sound/sound_core.o: warning: objtool: register_sound_special_device() falls through to next function register_sound_special()

Are these related to the fortify patch? I wouldn't expect that...

>>
>> and many more like those. Also:
>>
>> In file included from /home/sfr/next/next/include/linux/bitmap.h:8:0,
>>                  from /home/sfr/next/next/include/linux/cpumask.h:11,
>>                  from /home/sfr/next/next/arch/x86/include/asm/cpumask.h:4,
>>                  from /home/sfr/next/next/arch/x86/include/asm/msr.h:10,
>>                  from /home/sfr/next/next/arch/x86/include/asm/processor.h:20,
>>                  from /home/sfr/next/next/arch/x86/include/asm/cpufeature.h:4,
>>                  from /home/sfr/next/next/arch/x86/include/asm/thread_info.h:52,
>>                  from /home/sfr/next/next/include/linux/thread_info.h:37,
>>                  from /home/sfr/next/next/arch/x86/include/asm/preempt.h:6,
>>                  from /home/sfr/next/next/include/linux/preempt.h:80,
>>                  from /home/sfr/next/next/include/linux/spinlock.h:50,
>>                  from /home/sfr/next/next/include/linux/mmzone.h:7,
>>                  from /home/sfr/next/next/include/linux/gfp.h:5,
>>                  from /home/sfr/next/next/arch/x86/power/hibernate_64.c:11:
>> In function 'memcpy',
>>     inlined from 'relocate_restore_code' at /home/sfr/next/next/arch/x86/power/hibernate_64.c:150:2,
>>     inlined from 'swsusp_arch_resume' at /home/sfr/next/next/arch/x86/power/hibernate_64.c:185:8:
>> /home/sfr/next/next/include/linux/string.h:309:4: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter
>>     __read_overflow2();
>>     ^
>>
>> Caused by commit
>>
>>   088a5ecf7581 ("include/linux/string.h: add the option of fortified string.h functions")
>>
>> We really need to fix all the known problems it detects *before*
>> merging this commit ...
>>
>> I have reverted it for today.
>
> I am still needing to revert this every day ...

I sent a series for -mm (or maintainers) to merge that should catch
everything. Do you want me to carry it in my kspp tree instead? (My
original intention was to carry all the fixes and the fortify patch in
kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
complaining.)

-Kees

-- 
Kees Cook
Pixel Security

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

#1666368

On Wed, 2017-06-14 at 18:56 -0700, Kees Cook wrote:
> On Wed, Jun 14, 2017 at 6:35 PM, Stephen Rothwell <sfr@canb.auug.org.a
> u> wrote:
> > Hi all,
> > 
> > On Mon, 5 Jun 2017 17:01:17 +1000 Stephen Rothwell <sfr@canb.auug.or
> > g.au> wrote:
> > > 
> > > After merging the akpm-current tree, today's linux-next build
> > > (x86_64
> > > allmodconfig) failed like this:
> > > 
> > > sound/pcmcia/pdaudiocf/pdaudiocf.o: warning: objtool: .text:
> > > unexpected end of section
> > > arch/x86/ras/mce_amd_inj.o: warning: objtool: inj_readme_read()
> > > falls through to next function extcpu_fops_open()
> > > sound/sound_core.o: warning: objtool:
> > > register_sound_special_device() falls through to next function
> > > register_sound_special()
> 
> Are these related to the fortify patch? I wouldn't expect that...

They're false positive warnings. I think objtool has a list of
__noreturn functions and needs fortify_panic added there. It's just a
warning so it doesn't need to happen immediately.

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

#1666373

Hi Daniel,

On Wed, 14 Jun 2017 21:58:42 -0400 Daniel Micay <danielmicay@gmail.com> wrote:
>
> They're false positive warnings. I think objtool has a list of
> __noreturn functions and needs fortify_panic added there. It's just a
> warning so it doesn't need to happen immediately.

There are *lots* of them, so it does need to be fixed (Linus will be
very irritated if it hits his tree like that).  Create a patch to
objtool and get the x86 guys to Ack it?

-- 
Cheers,
Stephen Rothwell

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

#1666378

On Thu, 2017-06-15 at 12:04 +1000, Stephen Rothwell wrote:
> Hi Daniel,
> 
> On Wed, 14 Jun 2017 21:58:42 -0400 Daniel Micay <danielmicay@gmail.com
> > wrote:
> > 
> > They're false positive warnings. I think objtool has a list of
> > __noreturn functions and needs fortify_panic added there. It's just
> > a
> > warning so it doesn't need to happen immediately.
> 
> There are *lots* of them, so it does need to be fixed (Linus will be
> very irritated if it hits his tree like that).  Create a patch to
> objtool and get the x86 guys to Ack it?

Okay, I'll send a patch. It turns out that it's very straightforward.

c1fad9ef7ed14aad464972e6444e7a3bd5670f26 is an example of an earlier
one.

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

#1666383

On Wed, Jun 14, 2017 at 7:12 PM, Daniel Micay <danielmicay@gmail.com> wrote:
> On Thu, 2017-06-15 at 12:04 +1000, Stephen Rothwell wrote:
>> Hi Daniel,
>>
>> On Wed, 14 Jun 2017 21:58:42 -0400 Daniel Micay <danielmicay@gmail.com
>> > wrote:
>> >
>> > They're false positive warnings. I think objtool has a list of
>> > __noreturn functions and needs fortify_panic added there. It's just
>> > a
>> > warning so it doesn't need to happen immediately.
>>
>> There are *lots* of them, so it does need to be fixed (Linus will be
>> very irritated if it hits his tree like that).  Create a patch to
>> objtool and get the x86 guys to Ack it?
>
> Okay, I'll send a patch. It turns out that it's very straightforward.
>
> c1fad9ef7ed14aad464972e6444e7a3bd5670f26 is an example of an earlier
> one.

Oops, I just sent one too! :P I can use whatever; like you said, it's
a trivial fix.

-Kees

-- 
Kees Cook
Pixel Security

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

#1666395

On Wed, 2017-06-14 at 19:19 -0700, Kees Cook wrote:
> On Wed, Jun 14, 2017 at 7:12 PM, Daniel Micay <danielmicay@gmail.com>
> wrote:
> > On Thu, 2017-06-15 at 12:04 +1000, Stephen Rothwell wrote:
> > > Hi Daniel,
> > > 
> > > On Wed, 14 Jun 2017 21:58:42 -0400 Daniel Micay <danielmicay@gmail
> > > .com
> > > > wrote:
> > > > 
> > > > They're false positive warnings. I think objtool has a list of
> > > > __noreturn functions and needs fortify_panic added there. It's
> > > > just
> > > > a
> > > > warning so it doesn't need to happen immediately.
> > > 
> > > There are *lots* of them, so it does need to be fixed (Linus will
> > > be
> > > very irritated if it hits his tree like that).  Create a patch to
> > > objtool and get the x86 guys to Ack it?
> > 
> > Okay, I'll send a patch. It turns out that it's very
> > straightforward.
> > 
> > c1fad9ef7ed14aad464972e6444e7a3bd5670f26 is an example of an earlier
> > one.
> 
> Oops, I just sent one too! :P I can use whatever; like you said, it's
> a trivial fix.
> 
> -Kees

Less work for me is better ;).

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

#1666370

Hi Kees,

On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <keescook@chromium.org> wrote:
>
> I sent a series for -mm (or maintainers) to merge that should catch
> everything. Do you want me to carry it in my kspp tree instead? (My
> original intention was to carry all the fixes and the fortify patch in
> kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
> complaining.)

Andrew is currently not responding to stuff (he warned us last week),
so if you do put the series in your tree, I will remove it from my copy
of Andrew's quilt series.  All the fixes necessary to make this usable
should really be in the same tree if possible.

(I am assuming that the fix patches have been reviewed and acked by
appropriate people.)
-- 
Cheers,
Stephen Rothwell

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

#1666380

On Wed, Jun 14, 2017 at 7:06 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Kees,
>
> On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <keescook@chromium.org> wrote:
>>
>> I sent a series for -mm (or maintainers) to merge that should catch
>> everything. Do you want me to carry it in my kspp tree instead? (My
>> original intention was to carry all the fixes and the fortify patch in
>> kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
>> complaining.)
>
> Andrew is currently not responding to stuff (he warned us last week),
> so if you do put the series in your tree, I will remove it from my copy
> of Andrew's quilt series.  All the fixes necessary to make this usable
> should really be in the same tree if possible.
>
> (I am assuming that the fix patches have been reviewed and acked by
> appropriate people.)

Mostly, yes. But they're usually trivial. All have been sent out for
review (some a few times).

Given that the fixes are already scattered between various trees and
you merge -mm last in -next, I'll just carry the remaining fixes and
you can leave akpm's fortify patch in -mm.

-Kees

-- 
Kees Cook
Pixel Security

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

#1666430

On Wed, 2017-06-14 at 19:16 -0700, Kees Cook wrote:
> On Wed, Jun 14, 2017 at 7:06 PM, Stephen Rothwell <sfr@canb.auug.org.a
> u> wrote:
> > Hi Kees,
> > 
> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <keescook@chromium.org>
> > wrote:
> > > 
> > > I sent a series for -mm (or maintainers) to merge that should
> > > catch
> > > everything. Do you want me to carry it in my kspp tree instead?
> > > (My
> > > original intention was to carry all the fixes and the fortify
> > > patch in
> > > kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
> > > complaining.)
> > 
> > Andrew is currently not responding to stuff (he warned us last
> > week),
> > so if you do put the series in your tree, I will remove it from my
> > copy
> > of Andrew's quilt series.  All the fixes necessary to make this
> > usable
> > should really be in the same tree if possible.
> > 
> > (I am assuming that the fix patches have been reviewed and acked by
> > appropriate people.)
> 
> Mostly, yes. But they're usually trivial. All have been sent out for
> review (some a few times).
> 
> Given that the fixes are already scattered between various trees and
> you merge -mm last in -next, I'll just carry the remaining fixes and
> you can leave akpm's fortify patch in -mm.
> 
> -Kees

I think compile-time fixes should be totally done for 32-bit x86,
x86_64, arm64 and powerpc but the patches just aren't all queued up in
-mm/-next.

The arch mailing list was pinged about this which is how the powerpc
folks got involved and fixed the issues there, including at least one
runtime one. Not sure where (if anywhere) those are queued up, but Kees
could pick those up too.

For other archs, these might end up being issues requiring #ifndef
CONFIG_FORTIFY_SOURCE wrapped around them as was done for 32-bit x86, or
just removal because it's obsolete with GCC from the past 6+ years:

arch/alpha/include/asm/string.h:21:#define memcpy __builtin_memcpy
arch/m68k/include/asm/string.h:63:#define memcmp(d, s, n) __builtin_memcmp(d, s, n)
arch/m68k/include/asm/string.h:67:#define memset(d, c, n) __builtin_memset(d, c, n)
arch/m68k/include/asm/string.h:71:#define memcpy(d, s, n) __builtin_memcpy(d, s, n)

I didn't do anything about those because I can't compile it or test it
right now, but maybe someone can be pinged about it. Might be a one or
two other archs with the same issue. An -mm build bot complained about
alpha (probably that) and xtensa (seems to define inline functions in
arch/xtensa/include/asm/string.h).

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

#1666479

Daniel Micay <danielmicay@gmail.com> writes:
> ...
>
> The arch mailing list was pinged about this which is how the powerpc
> folks got involved and fixed the issues there, including at least one
> runtime one. Not sure where (if anywhere) those are queued up, but Kees
> could pick those up too.

I was expecting Kees to pick them up.

cheers

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

#1666792

]

On Wed, Jun 14, 2017 at 10:56 PM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> Daniel Micay <danielmicay@gmail.com> writes:
>> ...
>>
>> The arch mailing list was pinged about this which is how the powerpc
>> folks got involved and fixed the issues there, including at least one
>> runtime one. Not sure where (if anywhere) those are queued up, but Kees
>> could pick those up too.
>
> I was expecting Kees to pick them up.

Okay, cool. I'll get them into the kspp tree.

-Kees

-- 
Kees Cook
Pixel Security

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

#1667178

On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <keescook@chromium.org> wrote:

> >> Caused by commit
> >>
> >>   088a5ecf7581 ("include/linux/string.h: add the option of fortified string.h functions")
> >>
> >> We really need to fix all the known problems it detects *before*
> >> merging this commit ...
> >>
> >> I have reverted it for today.
> >
> > I am still needing to revert this every day ...
> 
> I sent a series for -mm (or maintainers) to merge that should catch
> everything. Do you want me to carry it in my kspp tree instead? (My
> original intention was to carry all the fixes and the fortify patch in
> kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
> complaining.)

This is all getting a bit foggy in my mind.  Can we please have a full
resend of everything?  Sufficient to hopefully produce a tree which has
no build-time or run-time regressions?  Including the buildbot's
recently-reported alpha and xtensa issues?

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

#1667341

On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <keescook@chromium.org> wrote:
>
>> >> Caused by commit
>> >>
>> >>   088a5ecf7581 ("include/linux/string.h: add the option of fortified string.h functions")
>> >>
>> >> We really need to fix all the known problems it detects *before*
>> >> merging this commit ...
>> >>
>> >> I have reverted it for today.
>> >
>> > I am still needing to revert this every day ...
>>
>> I sent a series for -mm (or maintainers) to merge that should catch
>> everything. Do you want me to carry it in my kspp tree instead? (My
>> original intention was to carry all the fixes and the fortify patch in
>> kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
>> complaining.)
>
> This is all getting a bit foggy in my mind.  Can we please have a full
> resend of everything?  Sufficient to hopefully produce a tree which has
> no build-time or run-time regressions?  Including the buildbot's
> recently-reported alpha and xtensa issues?

It's been sent a few times (and a few fixes have been collected in
other trees already). What I've got in my for-next/kspp tree right now
is all the fixes that haven't already been picked up by other tree
maintainers, and I added the fortify patch itself to the end of the
tree too now since sfr asked for that a few hours ago.

Merged with latest -next, this passes x86_64, i386, arm64, and powerpc
allmodconfig builds for me. It doesn't pass arm, though. Perhaps we
need to add an ARCH_HAS_FORTIFY_SOURCE to gate the all*config builds?

Should we let the dust settle first? I'm happy to do whatever makes
the most sense, I'm just following what (I understand) sfr suggested
most recently. :)

-Kees

-- 
Kees Cook
Pixel Security

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

#1667349

On Thu, 2017-06-15 at 16:46 -0700, Kees Cook wrote:
> On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <keescook@chromium.org>
> > wrote:
> > 
> > > > > Caused by commit
> > > > > 
> > > > >   088a5ecf7581 ("include/linux/string.h: add the option of
> > > > > fortified string.h functions")
> > > > > 
> > > > > We really need to fix all the known problems it detects
> > > > > *before*
> > > > > merging this commit ...
> > > > > 
> > > > > I have reverted it for today.
> > > > 
> > > > I am still needing to revert this every day ...
> > > 
> > > I sent a series for -mm (or maintainers) to merge that should
> > > catch
> > > everything. Do you want me to carry it in my kspp tree instead?
> > > (My
> > > original intention was to carry all the fixes and the fortify
> > > patch in
> > > kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
> > > complaining.)
> > 
> > This is all getting a bit foggy in my mind.  Can we please have a
> > full
> > resend of everything?  Sufficient to hopefully produce a tree which
> > has
> > no build-time or run-time regressions?  Including the buildbot's
> > recently-reported alpha and xtensa issues?
> 
> It's been sent a few times (and a few fixes have been collected in
> other trees already). What I've got in my for-next/kspp tree right now
> is all the fixes that haven't already been picked up by other tree
> maintainers, and I added the fortify patch itself to the end of the
> tree too now since sfr asked for that a few hours ago.
> 
> Merged with latest -next, this passes x86_64, i386, arm64, and powerpc
> allmodconfig builds for me. It doesn't pass arm, though. Perhaps we
> need to add an ARCH_HAS_FORTIFY_SOURCE to gate the all*config builds?
> 
> Should we let the dust settle first? I'm happy to do whatever makes
> the most sense, I'm just following what (I understand) sfr suggested
> most recently. :)
> 
> -Kees
> 

If it needs to build and boot on every architecture, I think we should
gate it on i386, x86_64, arm64 or powerpc where it has been tested.

I think I know what has to be fixed for alpha and xtensa but there might
be more problems. It's better to wait for someone willing / able to do
it properly by building it themselves and doing basic runtime testing.

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

#1667354

On Thu, Jun 15, 2017 at 5:05 PM, Daniel Micay <danielmicay@gmail.com> wrote:
> On Thu, 2017-06-15 at 16:46 -0700, Kees Cook wrote:
>> On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton
>> <akpm@linux-foundation.org> wrote:
>> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <keescook@chromium.org>
>> > wrote:
>> >
>> > > > > Caused by commit
>> > > > >
>> > > > >   088a5ecf7581 ("include/linux/string.h: add the option of
>> > > > > fortified string.h functions")
>> > > > >
>> > > > > We really need to fix all the known problems it detects
>> > > > > *before*
>> > > > > merging this commit ...
>> > > > >
>> > > > > I have reverted it for today.
>> > > >
>> > > > I am still needing to revert this every day ...
>> > >
>> > > I sent a series for -mm (or maintainers) to merge that should
>> > > catch
>> > > everything. Do you want me to carry it in my kspp tree instead?
>> > > (My
>> > > original intention was to carry all the fixes and the fortify
>> > > patch in
>> > > kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
>> > > complaining.)
>> >
>> > This is all getting a bit foggy in my mind.  Can we please have a
>> > full
>> > resend of everything?  Sufficient to hopefully produce a tree which
>> > has
>> > no build-time or run-time regressions?  Including the buildbot's
>> > recently-reported alpha and xtensa issues?
>>
>> It's been sent a few times (and a few fixes have been collected in
>> other trees already). What I've got in my for-next/kspp tree right now
>> is all the fixes that haven't already been picked up by other tree
>> maintainers, and I added the fortify patch itself to the end of the
>> tree too now since sfr asked for that a few hours ago.
>>
>> Merged with latest -next, this passes x86_64, i386, arm64, and powerpc
>> allmodconfig builds for me. It doesn't pass arm, though. Perhaps we
>> need to add an ARCH_HAS_FORTIFY_SOURCE to gate the all*config builds?
>>
>> Should we let the dust settle first? I'm happy to do whatever makes
>> the most sense, I'm just following what (I understand) sfr suggested
>> most recently. :)
>>
>> -Kees
>>
>
> If it needs to build and boot on every architecture, I think we should
> gate it on i386, x86_64, arm64 or powerpc where it has been tested.
>
> I think I know what has to be fixed for alpha and xtensa but there might
> be more problems. It's better to wait for someone willing / able to do
> it properly by building it themselves and doing basic runtime testing.

Sounds good. I've added ARCH_HAS_FORTIFY_SOURCE to the patch (and noted it).

-Kees

-- 
Kees Cook
Pixel Security

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

#1667371

Hi Kees,

On Thu, 15 Jun 2017 17:35:43 -0700 Kees Cook <keescook@chromium.org> wrote:
>
> Sounds good. I've added ARCH_HAS_FORTIFY_SOURCE to the patch (and noted it).

And that just made it in time for today's linux-next.  I have removed
the patches from Andrew's tree.

-- 
Cheers,
Stephen Rothwell

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

#1667909

On Thu, 15 Jun 2017 16:46:33 -0700 Kees Cook <keescook@chromium.org> wrote:

> On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <keescook@chromium.org> wrote:
> >
> >> >> Caused by commit
> >> >>
> >> >>   088a5ecf7581 ("include/linux/string.h: add the option of fortified string.h functions")
> >> >>
> >> >> We really need to fix all the known problems it detects *before*
> >> >> merging this commit ...
> >> >>
> >> >> I have reverted it for today.
> >> >
> >> > I am still needing to revert this every day ...
> >>
> >> I sent a series for -mm (or maintainers) to merge that should catch
> >> everything. Do you want me to carry it in my kspp tree instead? (My
> >> original intention was to carry all the fixes and the fortify patch in
> >> kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
> >> complaining.)
> >
> > This is all getting a bit foggy in my mind.  Can we please have a full
> > resend of everything?  Sufficient to hopefully produce a tree which has
> > no build-time or run-time regressions?  Including the buildbot's
> > recently-reported alpha and xtensa issues?
> 
> It's been sent a few times (and a few fixes have been collected in
> other trees already). What I've got in my for-next/kspp tree right now
> is all the fixes that haven't already been picked up by other tree
> maintainers, and I added the fortify patch itself to the end of the
> tree too now since sfr asked for that a few hours ago.

I think it's best to try to keep everything in a single tree, with
maintainer acks where possible.

I do this stuff all the time - please just send everything at me when
we think we have all the fixes and I'll sort it out.

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

#1669908

On Fri, Jun 16, 2017 at 10:17 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Thu, 15 Jun 2017 16:46:33 -0700 Kees Cook <keescook@chromium.org> wrote:
>
>> On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton
>> <akpm@linux-foundation.org> wrote:
>> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <keescook@chromium.org> wrote:
>> >
>> >> >> Caused by commit
>> >> >>
>> >> >>   088a5ecf7581 ("include/linux/string.h: add the option of fortified string.h functions")
>> >> >>
>> >> >> We really need to fix all the known problems it detects *before*
>> >> >> merging this commit ...
>> >> >>
>> >> >> I have reverted it for today.
>> >> >
>> >> > I am still needing to revert this every day ...
>> >>
>> >> I sent a series for -mm (or maintainers) to merge that should catch
>> >> everything. Do you want me to carry it in my kspp tree instead? (My
>> >> original intention was to carry all the fixes and the fortify patch in
>> >> kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
>> >> complaining.)
>> >
>> > This is all getting a bit foggy in my mind.  Can we please have a full
>> > resend of everything?  Sufficient to hopefully produce a tree which has
>> > no build-time or run-time regressions?  Including the buildbot's
>> > recently-reported alpha and xtensa issues?
>>
>> It's been sent a few times (and a few fixes have been collected in
>> other trees already). What I've got in my for-next/kspp tree right now
>> is all the fixes that haven't already been picked up by other tree
>> maintainers, and I added the fortify patch itself to the end of the
>> tree too now since sfr asked for that a few hours ago.
>
> I think it's best to try to keep everything in a single tree, with
> maintainer acks where possible.
>
> I do this stuff all the time - please just send everything at me when
> we think we have all the fixes and I'll sort it out.

I'll send you the series now and remove it from my kspp tree.

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web