LinuxLists.cc - linux-next: build failure after merge of the akpm-current tree

[permalink] [raw]

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

On Mon, 2017-06-05 at 17:01 +1000, Stephen Rothwell wrote:
> Hi Andrew,
>
> 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.

It looks like that's complaining about the __noreturn fortify_panic. It
isn't a compile-time error, just a false positive warning which needs to
be fixed in objtool. I guess it needs another symbol added to a hard-
wired list of __noreturn functions which sounds like it exists.

> 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.

The errors caught at compile-time including these are all fixed, but not
all the fixes have landed in -next yet. They're in various other trees.
GCC 7 came out which found an extra bug or two which are now fixed too.
I guess those need to be queued up with it in -mm if it's going to land
with -mm but I wasn't sure how things were going to work.

It also probably finds more architecture-specific issues and may need
compatibility fixes for them. I could mark it as compatible with only
arm64 and x86(_64) since they're what I've tested to build and work at
runtime and the compile-time errors could be turned into warnings for
now, if it's mandatory that FORTIFY_SOURCE=y doesn't find problems at
compile-time anywhere. If it's a warning, it will still catch the issue
at runtime like the rest where the size isn't a constant.

2017-06-05 13:34:54

[permalink] [raw]

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

> It also probably finds more architecture-specific issues and may need
> compatibility fixes for them. I could mark it as compatible with only
> arm64 and x86(_64) since they're what I've tested to build and work at
> runtime and the compile-time errors could be turned into warnings for
> now, if it's mandatory that FORTIFY_SOURCE=y doesn't find problems at
> compile-time anywhere. If it's a warning, it will still catch the
> issue
> at runtime like the rest where the size isn't a constant.

I'm already leaving out intra-object overflow checks and the alloc_size
attributes in this initial submission to make it easier to land so
scaling it back a bit more (errors -> warnings, gating on archs) isn't a
problem if it's needed to get started.

2017-06-15 01:35:51

[permalink] [raw]

Subject: 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 <[email protected]> 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

2017-06-15 01:56:33

[permalink] [raw]

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

On Wed, Jun 14, 2017 at 6:35 PM, Stephen Rothwell <[email protected]> wrote:
> Hi all,
>
> On Mon, 5 Jun 2017 17:01:17 +1000 Stephen Rothwell <[email protected]> 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

2017-06-15 01:58:46

[permalink] [raw]

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

On Wed, 2017-06-14 at 18:56 -0700, Kees Cook wrote:
> On Wed, Jun 14, 2017 at 6:35 PM, Stephen Rothwell <[email protected]
> u> wrote:
> > Hi all,
> >
> > On Mon, 5 Jun 2017 17:01:17 +1000 Stephen Rothwell <[email protected]
> > 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.

2017-06-15 02:04:10

[permalink] [raw]

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

Hi Daniel,

On Wed, 14 Jun 2017 21:58:42 -0400 Daniel Micay <[email protected]> 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

2017-06-15 02:06:35

[permalink] [raw]

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

Hi Kees,

On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <[email protected]> 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

2017-06-15 02:12:05

[permalink] [raw]

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

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 <[email protected]
> > 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.

2017-06-15 02:16:45

[permalink] [raw]

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

On Wed, Jun 14, 2017 at 7:06 PM, Stephen Rothwell <[email protected]> wrote:
> Hi Kees,
>
> On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <[email protected]> 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

2017-06-15 02:19:53

[permalink] [raw]

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

On Wed, Jun 14, 2017 at 7:12 PM, Daniel Micay <[email protected]> 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 <[email protected]
>> > 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

2017-06-15 02:25:52

[permalink] [raw]

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

On Wed, 2017-06-14 at 19:19 -0700, Kees Cook wrote:
> On Wed, Jun 14, 2017 at 7:12 PM, Daniel Micay <[email protected]>
> 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 ;).

2017-06-15 03:18:33

[permalink] [raw]

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

On Wed, 2017-06-14 at 19:16 -0700, Kees Cook wrote:
> On Wed, Jun 14, 2017 at 7:06 PM, Stephen Rothwell <[email protected]
> u> wrote:
> > Hi Kees,
> >
> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <[email protected]>
> > 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).

2017-06-15 05:56:16

by Michael Ellerman

[permalink] [raw]

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

Daniel Micay <[email protected]> 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

2017-06-15 15:19:49

[permalink] [raw]

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

]

On Wed, Jun 14, 2017 at 10:56 PM, Michael Ellerman <[email protected]> wrote:
> Daniel Micay <[email protected]> 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

2017-06-15 19:12:30

by Andrew Morton

[permalink] [raw]

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

On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <[email protected]> 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?

2017-06-15 23:46:36

[permalink] [raw]

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

On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton
<[email protected]> wrote:
> On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <[email protected]> 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

2017-06-16 00:05:18

[permalink] [raw]

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

On Thu, 2017-06-15 at 16:46 -0700, Kees Cook wrote:
> On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton
> <[email protected]> wrote:
> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <[email protected]>
> > 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.

2017-06-16 00:35:47

[permalink] [raw]

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

On Thu, Jun 15, 2017 at 5:05 PM, Daniel Micay <[email protected]> wrote:
> On Thu, 2017-06-15 at 16:46 -0700, Kees Cook wrote:
>> On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton
>> <[email protected]> wrote:
>> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <[email protected]>
>> > 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

2017-06-16 01:20:23

[permalink] [raw]

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

Hi Kees,

On Thu, 15 Jun 2017 17:35:43 -0700 Kees Cook <[email protected]> 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

2017-06-16 17:17:45

by Andrew Morton

[permalink] [raw]

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

On Thu, 15 Jun 2017 16:46:33 -0700 Kees Cook <[email protected]> wrote:

> On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton
> <[email protected]> wrote:
> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <[email protected]> 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.

2017-06-19 20:28:52