In preparation for moving NOTES into RO_DATA, rename the linker script
internal identifier for the PT_LOAD Program Header from "kernel" to
"text" to match other architectures.
Signed-off-by: Kees Cook <redacted>
---
arch/powerpc/kernel/vmlinux.lds.S | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
The resource reservations in /proc/iomem made for the kernel image did
not reflect the gaps between text, rodata, and data. Add the "rodata"
resource and update the start/end calculations to match the respective
calls to free_kernel_image_pages().
Before (booted with "nokaslr" for easier comparison):
00100000-bffd9fff : System RAM
01000000-01e011d0 : Kernel code
01e011d1-025619bf : Kernel data
02a95000-035fffff : Kernel bss
After:
00100000-bffd9fff : System RAM
01000000-01e011d0 : Kernel code
02000000-023d4fff : Kernel rodata
02400000-025619ff : Kernel data
02a95000-035fffff : Kernel bss
Signed-off-by: Kees Cook <redacted>
---
arch/x86/kernel/setup.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
@@ -1040,6 +1049,7 @@ void __init setup_arch(char **cmdline_p)/* after parse_early_param, so could debug it */insert_resource(&iomem_resource,&code_resource);+insert_resource(&iomem_resource,&rodata_resource);insert_resource(&iomem_resource,&data_resource);insert_resource(&iomem_resource,&bss_resource);
Various calculations are using the end of the exception table (which
does not need to be executable) as the end of the text segment. Instead,
in preparation for moving the exception table into RO_DATA, move _etext
after the exception table and update the calculations.
Signed-off-by: Kees Cook <redacted>
---
arch/x86/include/asm/sections.h | 1 -
arch/x86/kernel/vmlinux.lds.S | 7 +++----
arch/x86/mm/init_64.c | 6 +++---
arch/x86/mm/pti.c | 2 +-
4 files changed, 7 insertions(+), 9 deletions(-)
The exception table was needlessly marked executable. In preparation
for execute-only memory, move the table into the RO_DATA segment via
the new macro that can be used by any architectures that want to make
a similar consolidation.
Signed-off-by: Kees Cook <redacted>
---
arch/x86/kernel/vmlinux.lds.S | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Since the EXCEPTION_TABLE is read-only, collapse it into RO_DATA.
Signed-off-by: Kees Cook <redacted>
---
arch/h8300/kernel/vmlinux.lds.S | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
@@ -518,9 +518,6 @@.=ALIGN((align));\__end_rodata=.;-/* All archs are supposed to use RO_DATA() */-#define RO_DATA(align) RO_DATA_SECTION(align)-/**.textsection.Maptofunctionalignmenttoavoidaddresschanges*duringsecondldruninsecondldpasswhengeneratingSystem.map
In preparation for moving NOTES into RO_DATA, move RO_DATA back into the
"text" PT_LOAD Program Header, as done with other architectures. The
"data" PT_LOAD now starts with the writable data section.
Signed-off-by: Kees Cook <redacted>
---
arch/s390/kernel/vmlinux.lds.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
@@ -518,9 +518,7 @@.=ALIGN((align));\__end_rodata=.;-/* RODATA & RO_DATA provided for backward compatibility.-*AllarchsaresupposedtouseRO_DATA()*/-#define RODATA RO_DATA_SECTION(4096)+/* All archs are supposed to use RO_DATA() */#define RO_DATA(align) RO_DATA_SECTION(align)/*
In preparation for moving NOTES into RO_DATA, rename the linker script
internal identifier for the PT_LOAD Program Header from "code" to "text"
to match other architectures.
Signed-off-by: Kees Cook <redacted>
---
arch/ia64/kernel/vmlinux.lds.S | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
In a linker script, if once places a section in one or more segments using
":PHDR", then the linker will place all subsequent allocatable sections,
which do not specify ":PHDR", into the same segments. In order to have
the NOTES section in both PT_LOAD (":text") and PT_NOTE (":note"), both
segments are marked, and the only way to to undo this to keep subsequent
sections out of PT_NOTE is to mark the following section with just the
single desired PT_LOAD (":text").
In preparation for having a common NOTES macro, perform the segment
assignment use a dummy section (as done by other architectures).
Signed-off-by: Kees Cook <redacted>
---
arch/x86/kernel/vmlinux.lds.S | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
The Program Header identifiers are internal to the linker scripts. In
preparation for moving the NOTES segment declaration into RO_DATA,
standardize the identifier for the PT_NOTE entry to "note" as used by
all other architectures that emit PT_NOTE.
Signed-off-by: Kees Cook <redacted>
---
arch/powerpc/kernel/vmlinux.lds.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
In preparation for moving NOTES into RO_DATA, rename the linker script
internal identifier for the PT_LOAD Program Header from "kernel" to
"text" to match other architectures.
Signed-off-by: Kees Cook <redacted>
---
arch/alpha/kernel/vmlinux.lds.S | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
In preparation for moving NOTES into RO_DATA, remove the PT_NOTE
workaround since the kernel requires at least gcc 4.6 now.
Signed-off-by: Kees Cook <redacted>
---
arch/powerpc/kernel/vmlinux.lds.S | 24 ++----------------------
1 file changed, 2 insertions(+), 22 deletions(-)
@@ -20,20 +20,6 @@ ENTRY(_stext)PHDRS{kernelPT_LOADFLAGS(7);/*RWX*/notePT_NOTEFLAGS(0);-dummyPT_NOTEFLAGS(0);--/*binutils<2.18hasabugthatmakesitmisbehavewhentakingan-ELFfilewithallsegmentsatloadaddress0asinput.This-happenswhenrunning"strip"onvmlinux,becauseoftheAT()magic-inthislinkerscript.PeopleusingGCC>=4.2won't run into-thisproblem,becausethe"build-id"supportwillputsomedata-intothe"notes"segment (atanon-zeroloadaddress).--Toworkaroundthis,weforcesomedataintoboththe"dummy"-segmentandthekernelsegment,sothedummysegmentwillgeta-non-zeroloadaddress.It's not enough to always create the-"notes"segment,sinceifnothinggetsassignedtoit,itsload-addresswillbezero.*/}#ifdef CONFIG_PPC64
Since the EXCEPTION_TABLE is read-only, collapse it into RO_DATA.
Signed-off-by: Kees Cook <redacted>
---
arch/alpha/kernel/vmlinux.lds.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Since the EXCEPTION_TABLE is read-only, collapse it into RO_DATA.
Signed-off-by: Kees Cook <redacted>
---
arch/parisc/kernel/vmlinux.lds.S | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
Since the EXCEPTION_TABLE is read-only, collapse it into RO_DATA.
Signed-off-by: Kees Cook <redacted>
---
arch/microblaze/kernel/vmlinux.lds.S | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Since the EXCEPTION_TABLE is read-only, collapse it into RO_DATA.
Signed-off-by: Kees Cook <redacted>
---
arch/ia64/kernel/vmlinux.lds.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The &s on addresses are redundant. Remove them to match all the other
similar functions.
Signed-off-by: Kees Cook <redacted>
---
arch/x86/mm/init_64.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Instead of using 0x90 (NOP) to fill bytes between functions, which makes
it easier to sloppily target functions in function pointer overwrite
attacks, fill with 0xCC (INT3) to force a trap. Also drop the space
between "=" and the value to better match the binutils documentation
https://sourceware.org/binutils/docs/ld/Output-Section-Fill.html#Output-Section-Fill
Example "objdump -d" before:
...
ffffffff810001e0 <start_cpu0>:
ffffffff810001e0: 48 8b 25 e1 b1 51 01 mov 0x151b1e1(%rip),%rsp # ffffffff8251b3c8 <initial_stack>
ffffffff810001e7: e9 d5 fe ff ff jmpq ffffffff810000c1 <secondary_startup_64+0x91>
ffffffff810001ec: 90 nop
ffffffff810001ed: 90 nop
ffffffff810001ee: 90 nop
ffffffff810001ef: 90 nop
ffffffff810001f0 <__startup_64>:
...
After:
...
ffffffff810001e0 <start_cpu0>:
ffffffff810001e0: 48 8b 25 41 79 53 01 mov 0x1537941(%rip),%rsp # ffffffff82537b28 <initial_stack>
ffffffff810001e7: e9 d5 fe ff ff jmpq ffffffff810000c1 <secondary_startup_64+0x91>
ffffffff810001ec: cc int3
ffffffff810001ed: cc int3
ffffffff810001ee: cc int3
ffffffff810001ef: cc int3
ffffffff810001f0 <__startup_64>:
...
Signed-off-by: Kees Cook <redacted>
---
arch/x86/kernel/vmlinux.lds.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Many architectures have an EXCEPTION_TABLE that only needs to
be readable. As such, it should live in RO_DATA. Create a macro to
identify this case for the architectures that can move EXCEPTION_TABLE
into RO_DATA.
Signed-off-by: Kees Cook <redacted>
Acked-by: Will Deacon <will@kernel.org>
---
include/asm-generic/vmlinux.lds.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
Since the EXCEPTION_TABLE is read-only, collapse it into RO_DATA.
Signed-off-by: Kees Cook <redacted>
---
arch/powerpc/kernel/vmlinux.lds.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Since the EXCEPTION_TABLE is read-only, collapse it into RO_DATA. Also
removes the redundant ALIGN, which is already present at the end of the
RO_DATA macro.
Signed-off-by: Kees Cook <redacted>
Acked-by: Will Deacon <will@kernel.org>
---
arch/arm64/kernel/vmlinux.lds.S | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
Since the EXCEPTION_TABLE is read-only, collapse it into RO_DATA.
Signed-off-by: Kees Cook <redacted>
---
arch/c6x/kernel/vmlinux.lds.S | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Since the EXCEPTION_TABLE is read-only, collapse it into RO_DATA.
Signed-off-by: Kees Cook <redacted>
---
arch/xtensa/kernel/vmlinux.lds.S | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2019-10-11 06:01:11
Kees Cook [off-list ref] writes:
The Program Header identifiers are internal to the linker scripts. In
preparation for moving the NOTES segment declaration into RO_DATA,
standardize the identifier for the PT_NOTE entry to "note" as used by
all other architectures that emit PT_NOTE.
Signed-off-by: Kees Cook <redacted>
---
arch/powerpc/kernel/vmlinux.lds.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
cheers
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2019-10-11 06:07:14
Kees Cook [off-list ref] writes:
In preparation for moving NOTES into RO_DATA, remove the PT_NOTE
workaround since the kernel requires at least gcc 4.6 now.
Signed-off-by: Kees Cook <redacted>
---
arch/powerpc/kernel/vmlinux.lds.S | 24 ++----------------------
1 file changed, 2 insertions(+), 22 deletions(-)
@@ -20,20 +20,6 @@ ENTRY(_stext)PHDRS{kernelPT_LOADFLAGS(7);/*RWX*/notePT_NOTEFLAGS(0);-dummyPT_NOTEFLAGS(0);--/*binutils<2.18hasabugthatmakesitmisbehavewhentakingan-ELFfilewithallsegmentsatloadaddress0asinput.This-happenswhenrunning"strip"onvmlinux,becauseoftheAT()magic-inthislinkerscript.PeopleusingGCC>=4.2won't run into-thisproblem,becausethe"build-id"supportwillputsomedata-intothe"notes"segment (atanon-zeroloadaddress).--Toworkaroundthis,weforcesomedataintoboththe"dummy"-segmentandthekernelsegment,sothedummysegmentwillgeta-non-zeroloadaddress.It's not enough to always create the-"notes"segment,sinceifnothinggetsassignedtoit,itsload-addresswillbezero.*/}#ifdef CONFIG_PPC64
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2019-10-11 06:07:27
Kees Cook [off-list ref] writes:
In preparation for moving NOTES into RO_DATA, rename the linker script
internal identifier for the PT_LOAD Program Header from "kernel" to
"text" to match other architectures.
Signed-off-by: Kees Cook <redacted>
---
arch/powerpc/kernel/vmlinux.lds.S | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
cheers
On Fri, Oct 11, 2019 at 2:07 AM Kees Cook [off-list ref] wrote:
Rename RW_DATA_SECTION to RW_DATA. (Calling this a "section" is a lie,
since it's multiple sections and section flags cannot be applied to
the macro.)
Signed-off-by: Kees Cook <redacted>
For m68k:
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Fri, Oct 11, 2019 at 2:07 AM Kees Cook [off-list ref] wrote:
Finish renaming RO_DATA_SECTION to RO_DATA. (Calling this a "section"
is a lie, since it's multiple sections and section flags cannot be
applied to the macro.)
Signed-off-by: Kees Cook <redacted>
arch/m68k/kernel/vmlinux-nommu.lds | 2 +-
For m68k:
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Thu, Oct 10, 2019 at 05:05:41PM -0700, Kees Cook wrote:
The Program Header identifiers are internal to the linker scripts. In
preparation for moving the NOTES segment declaration into RO_DATA,
standardize the identifier for the PT_NOTE entry to "note" as used by
all other architectures that emit PT_NOTE.
All other archs are wrong, and "notes" is a much better name. This
segment does not contain a single "note", but multiple "notes".
Segher
On Fri, Oct 11, 2019 at 05:07:04PM +1100, Michael Ellerman wrote:
Kees Cook [off-list ref] writes:
quoted
In preparation for moving NOTES into RO_DATA, remove the PT_NOTE
workaround since the kernel requires at least gcc 4.6 now.
Signed-off-by: Kees Cook <redacted>
---
arch/powerpc/kernel/vmlinux.lds.S | 24 ++----------------------
1 file changed, 2 insertions(+), 22 deletions(-)
On Fri, Oct 11, 2019 at 03:25:19AM -0500, Segher Boessenkool wrote:
On Thu, Oct 10, 2019 at 05:05:41PM -0700, Kees Cook wrote:
quoted
The Program Header identifiers are internal to the linker scripts. In
preparation for moving the NOTES segment declaration into RO_DATA,
standardize the identifier for the PT_NOTE entry to "note" as used by
all other architectures that emit PT_NOTE.
All other archs are wrong, and "notes" is a much better name. This
segment does not contain a single "note", but multiple "notes".
True, but the naming appears to be based off the Program Header name of
"PT_NOTE". Regardless, it is an entirely internal-to-the-linker-script
identifier, so I am just consolidating on a common name with the least
number of collateral changes.
--
Kees Cook
On Fri, Oct 11, 2019 at 09:11:43AM -0700, Kees Cook wrote:
On Fri, Oct 11, 2019 at 03:25:19AM -0500, Segher Boessenkool wrote:
quoted
On Thu, Oct 10, 2019 at 05:05:41PM -0700, Kees Cook wrote:
quoted
The Program Header identifiers are internal to the linker scripts. In
preparation for moving the NOTES segment declaration into RO_DATA,
standardize the identifier for the PT_NOTE entry to "note" as used by
all other architectures that emit PT_NOTE.
All other archs are wrong, and "notes" is a much better name. This
segment does not contain a single "note", but multiple "notes".
True, but the naming appears to be based off the Program Header name of
"PT_NOTE".
Ah, so that's why the kernel segment (which isn't text btw, it's rwx) is
called "load" :-P
(Not convinced. Some arch just got it wrong, and many others blindly
copied it? That sounds a lot more likely imo.)
Regardless, it is an entirely internal-to-the-linker-script
identifier, so I am just consolidating on a common name with the least
number of collateral changes.
Yes, that's what I'm complaining about.
Names *matter*, internal names doubly so. So why replace a good name with
a worse name? Because it is slightly less work for you?
Segher
p.s. Thanks for doing this, removing the powerpc workaround etc. :-)
Since the EXCEPTION_TABLE is read-only, collapse it into RO_DATA.
Signed-off-by: Kees Cook <redacted>
---
arch/parisc/kernel/vmlinux.lds.S | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
From: Max Filippov <jcmvbkbc@gmail.com> Date: 2019-10-14 07:41:22
On Thu, Oct 10, 2019 at 5:16 PM Kees Cook [off-list ref] wrote:
Since the EXCEPTION_TABLE is read-only, collapse it into RO_DATA.
Signed-off-by: Kees Cook <redacted>
---
arch/xtensa/kernel/vmlinux.lds.S | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Acked-by: Max Filippov <jcmvbkbc@gmail.com>
--
Thanks.
-- Max
On Fri, Oct 11, 2019 at 11:25:52AM -0500, Segher Boessenkool wrote:
Names *matter*, internal names doubly so. So why replace a good name with
a worse name? Because it is slightly less work for you?
So if we agree on the name "notes" and we decide to rename the other
arches, this should all be done in a separate patchset anyway, and ontop
of this one. And I believe Kees wouldn't mind doing it ontop since he's
gotten his hands dirty already. :-P
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Tue, Oct 15, 2019 at 06:54:13PM +0200, Borislav Petkov wrote:
On Fri, Oct 11, 2019 at 11:25:52AM -0500, Segher Boessenkool wrote:
quoted
Names *matter*, internal names doubly so. So why replace a good name with
a worse name? Because it is slightly less work for you?
So if we agree on the name "notes" and we decide to rename the other
arches, this should all be done in a separate patchset anyway, and ontop
of this one. And I believe Kees wouldn't mind doing it ontop since he's
gotten his hands dirty already. :-P
Yeah, I'm fine with that. I would prefer to do it as a separate step,
just to minimize the logical steps each patch takes. Shall I spin a v3
with the Acks added and a final rename for this?
--
Kees Cook
On Thu, Oct 10, 2019 at 05:05:46PM -0700, Kees Cook wrote:
quoted hunk
In preparation for moving NOTES into RO_DATA, move RO_DATA back into the
"text" PT_LOAD Program Header, as done with other architectures. The
"data" PT_LOAD now starts with the writable data section.
Signed-off-by: Kees Cook <redacted>
---
arch/s390/kernel/vmlinux.lds.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
On Thu, Oct 10, 2019 at 05:05:40PM -0700, Kees Cook wrote:
Arch maintainers: please send Acks (if you haven't already) for your
respective linker script changes; the intention is for this series to
land via -tip.
v1: https://lore.kernel.org/lkml/20190926175602.33098-1-keescook@chromium.org
v2: clean up commit messages, rename RO_EXCEPTION_TABLE (bp)
This series works to move the linker sections for NOTES and
EXCEPTION_TABLE into the RO_DATA area, where they belong on most
(all?) architectures. The problem being addressed was the discovery
by Rick Edgecombe that the exception table was accidentally marked
executable while he was developing his execute-only-memory series. When
permissions were flipped from readable-and-executable to only-executable,
the exception table became unreadable, causing things to explode rather
badly. :)
Feel free to add
Acked-by: Heiko Carstens <redacted>
to every patch in this series which touches s390.
On Tue, Oct 15, 2019 at 06:54:13PM +0200, Borislav Petkov wrote:
On Fri, Oct 11, 2019 at 11:25:52AM -0500, Segher Boessenkool wrote:
quoted
Names *matter*, internal names doubly so. So why replace a good name with
a worse name? Because it is slightly less work for you?
So if we agree on the name "notes" and we decide to rename the other
arches, this should all be done in a separate patchset anyway, and ontop
of this one. And I believe Kees wouldn't mind doing it ontop since he's
gotten his hands dirty already. :-P
I've added more rationale to patch #1 in the just-sent v3 of this
series. If I still can't convince you Segher, I'm happy to send "patch
30/29" to do a bulk rename to "notes". Let me know. :)
--
Kees Cook
On Tue, Oct 29, 2019 at 02:15:39PM -0700, Kees Cook wrote:
On Tue, Oct 15, 2019 at 06:54:13PM +0200, Borislav Petkov wrote:
quoted
On Fri, Oct 11, 2019 at 11:25:52AM -0500, Segher Boessenkool wrote:
quoted
Names *matter*, internal names doubly so. So why replace a good name with
a worse name? Because it is slightly less work for you?
So if we agree on the name "notes" and we decide to rename the other
arches, this should all be done in a separate patchset anyway, and ontop
of this one. And I believe Kees wouldn't mind doing it ontop since he's
gotten his hands dirty already. :-P
I've added more rationale to patch #1 in the just-sent v3 of this
series. If I still can't convince you Segher, I'm happy to send "patch
30/29" to do a bulk rename to "notes". Let me know. :)
I am still not convinced the worse name is a better name, no :-) But if
you don't want to do the work, and instead prefer the much smaller change,
that is of course a fine decision. Thank you!
(I would be happy with such a 30/29 as well, of course.)
Segher
On Tue, Oct 29, 2019 at 08:01:17PM -0500, Segher Boessenkool wrote:
I am still not convinced the worse name is a better name, no :-) But if
you don't want to do the work, and instead prefer the much smaller change,
that is of course a fine decision. Thank you!
(I would be happy with such a 30/29 as well, of course.)
Hi Kees,
On Fri, Oct 11, 2019 at 2:07 AM Kees Cook [off-list ref] wrote:
There's no reason to keep the RODATA macro: replace the callers with
the expected RO_DATA macro.
Signed-off-by: Kees Cook <redacted>
---
arch/alpha/kernel/vmlinux.lds.S | 2 +-
arch/ia64/kernel/vmlinux.lds.S | 2 +-
arch/microblaze/kernel/vmlinux.lds.S | 2 +-
arch/mips/kernel/vmlinux.lds.S | 2 +-
arch/um/include/asm/common.lds.S | 2 +-
arch/xtensa/kernel/vmlinux.lds.S | 2 +-
include/asm-generic/vmlinux.lds.h | 4 +---
7 files changed, 7 insertions(+), 9 deletions(-)
Somehow you missed:
arch/m68k/kernel/vmlinux-std.lds: RODATA
arch/m68k/kernel/vmlinux-sun3.lds: RODATA
Leading to build failures in next-20191111:
/opt/cross/kisskb/gcc-4.6.3-nolibc/m68k-linux/bin/m68k-linux-ld:./arch/m68k/kernel/vmlinux.lds:29:
syntax error
make[1]: *** [/kisskb/src/Makefile:1075: vmlinux] Error 1
Reported-by: noreply@ellerman.id.au
http://kisskb.ellerman.id.au/kisskb/buildresult/14022846/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Mon, Nov 11, 2019 at 05:58:06PM +0100, Geert Uytterhoeven wrote:
Hi Kees,
On Fri, Oct 11, 2019 at 2:07 AM Kees Cook [off-list ref] wrote:
quoted
There's no reason to keep the RODATA macro: replace the callers with
the expected RO_DATA macro.
Signed-off-by: Kees Cook <redacted>
---
arch/alpha/kernel/vmlinux.lds.S | 2 +-
arch/ia64/kernel/vmlinux.lds.S | 2 +-
arch/microblaze/kernel/vmlinux.lds.S | 2 +-
arch/mips/kernel/vmlinux.lds.S | 2 +-
arch/um/include/asm/common.lds.S | 2 +-
arch/xtensa/kernel/vmlinux.lds.S | 2 +-
include/asm-generic/vmlinux.lds.h | 4 +---
7 files changed, 7 insertions(+), 9 deletions(-)
Somehow you missed:
arch/m68k/kernel/vmlinux-std.lds: RODATA
arch/m68k/kernel/vmlinux-sun3.lds: RODATA
Argh. I've sent a patch; sorry and thanks for catching this. For my own
cross-build testing, which defconfig targets will hit these two linker
scripts?
-Kees
Leading to build failures in next-20191111:
/opt/cross/kisskb/gcc-4.6.3-nolibc/m68k-linux/bin/m68k-linux-ld:./arch/m68k/kernel/vmlinux.lds:29:
syntax error
make[1]: *** [/kisskb/src/Makefile:1075: vmlinux] Error 1
Reported-by: noreply@ellerman.id.au
http://kisskb.ellerman.id.au/kisskb/buildresult/14022846/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi Kees,
On Mon, Nov 11, 2019 at 6:23 PM Kees Cook [off-list ref] wrote:
On Mon, Nov 11, 2019 at 05:58:06PM +0100, Geert Uytterhoeven wrote:
quoted
On Fri, Oct 11, 2019 at 2:07 AM Kees Cook [off-list ref] wrote:
quoted
There's no reason to keep the RODATA macro: replace the callers with
the expected RO_DATA macro.
Signed-off-by: Kees Cook <redacted>
---
arch/alpha/kernel/vmlinux.lds.S | 2 +-
arch/ia64/kernel/vmlinux.lds.S | 2 +-
arch/microblaze/kernel/vmlinux.lds.S | 2 +-
arch/mips/kernel/vmlinux.lds.S | 2 +-
arch/um/include/asm/common.lds.S | 2 +-
arch/xtensa/kernel/vmlinux.lds.S | 2 +-
include/asm-generic/vmlinux.lds.h | 4 +---
7 files changed, 7 insertions(+), 9 deletions(-)
Somehow you missed:
arch/m68k/kernel/vmlinux-std.lds: RODATA
arch/m68k/kernel/vmlinux-sun3.lds: RODATA
Argh. I've sent a patch; sorry and thanks for catching this. For my own
cross-build testing, which defconfig targets will hit these two linker
scripts?
vmlinux-sun3.lds: sun3_defconfig
vmlinux-std.lds: All other classic 680x0 targets with an MMU, e.g. plain
defconfig aka multi_defconfig.
quoted
Leading to build failures in next-20191111:
/opt/cross/kisskb/gcc-4.6.3-nolibc/m68k-linux/bin/m68k-linux-ld:./arch/m68k/kernel/vmlinux.lds:29:
syntax error
make[1]: *** [/kisskb/src/Makefile:1075: vmlinux] Error 1
Reported-by: noreply@ellerman.id.au
http://kisskb.ellerman.id.au/kisskb/buildresult/14022846/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Mon, Nov 11, 2019 at 07:08:51PM +0100, Geert Uytterhoeven wrote:
vmlinux-std.lds: All other classic 680x0 targets with an MMU, e.g. plain
defconfig aka multi_defconfig.
FWIW, the defconfig doesn't build with the cross compiler¹ here, even with Kees'
patch applied but for a different reason:
$ make.cross ARCH=m68k defconfig
...
$make.cross ARCH=m68k 2>w.log
...
drivers/video/fbdev/c2p_planar.o: In function `transp8':
c2p_planar.c:(.text+0x13a): undefined reference to `c2p_unsupported'
c2p_planar.c:(.text+0x1de): undefined reference to `c2p_unsupported'
drivers/video/fbdev/c2p_iplan2.o: In function `transp4x.constprop.0':
c2p_iplan2.c:(.text+0x98): undefined reference to `c2p_unsupported'
make: *** [Makefile:1094: vmlinux] Error 1
¹ https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Hi Borislav,
On Tue, Nov 12, 2019 at 10:08 AM Borislav Petkov [off-list ref] wrote:
On Mon, Nov 11, 2019 at 07:08:51PM +0100, Geert Uytterhoeven wrote:
quoted
vmlinux-std.lds: All other classic 680x0 targets with an MMU, e.g. plain
defconfig aka multi_defconfig.
FWIW, the defconfig doesn't build with the cross compiler¹ here, even with Kees'
patch applied but for a different reason:
$ make.cross ARCH=m68k defconfig
...
$make.cross ARCH=m68k 2>w.log
...
drivers/video/fbdev/c2p_planar.o: In function `transp8':
c2p_planar.c:(.text+0x13a): undefined reference to `c2p_unsupported'
c2p_planar.c:(.text+0x1de): undefined reference to `c2p_unsupported'
drivers/video/fbdev/c2p_iplan2.o: In function `transp4x.constprop.0':
c2p_iplan2.c:(.text+0x98): undefined reference to `c2p_unsupported'
make: *** [Makefile:1094: vmlinux] Error 1
The fix for that regression (finally) made it in rc7:
b330f3972f4f2a82 ("fbdev: c2p: Fix link failure on non-inlining").
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Mon, Nov 11, 2019 at 07:08:51PM +0100, Geert Uytterhoeven wrote:
Hi Kees,
On Mon, Nov 11, 2019 at 6:23 PM Kees Cook [off-list ref] wrote:
quoted
On Mon, Nov 11, 2019 at 05:58:06PM +0100, Geert Uytterhoeven wrote:
quoted
On Fri, Oct 11, 2019 at 2:07 AM Kees Cook [off-list ref] wrote:
quoted
There's no reason to keep the RODATA macro: replace the callers with
the expected RO_DATA macro.
Signed-off-by: Kees Cook <redacted>
---
arch/alpha/kernel/vmlinux.lds.S | 2 +-
arch/ia64/kernel/vmlinux.lds.S | 2 +-
arch/microblaze/kernel/vmlinux.lds.S | 2 +-
arch/mips/kernel/vmlinux.lds.S | 2 +-
arch/um/include/asm/common.lds.S | 2 +-
arch/xtensa/kernel/vmlinux.lds.S | 2 +-
include/asm-generic/vmlinux.lds.h | 4 +---
7 files changed, 7 insertions(+), 9 deletions(-)
Somehow you missed:
arch/m68k/kernel/vmlinux-std.lds: RODATA
arch/m68k/kernel/vmlinux-sun3.lds: RODATA
Argh. I've sent a patch; sorry and thanks for catching this. For my own
cross-build testing, which defconfig targets will hit these two linker
scripts?
vmlinux-sun3.lds: sun3_defconfig
vmlinux-std.lds: All other classic 680x0 targets with an MMU, e.g. plain
defconfig aka multi_defconfig.