When CONFIG_DEBUG_ALIGN_RODATA is set, we get a link error:
arch/arm/mm/built-in.o:(.data+0x4bc): undefined reference to `__start_rodata_section_aligned'
However, this combination is useless, as XIP_KERNEL implies that all the
RODATA is already marked readonly, so both CONFIG_DEBUG_RODATA and
CONFIG_DEBUG_ALIGN_RODATA (which depends on the other) are not
needed with XIP_KERNEL, and this patches enforces that using a Kconfig
dependency.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 25362dc496ed ("ARM: 8501/1: mm: flip priority of CONFIG_DEBUG_RODATA")
---
arch/arm/mm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The __start_rodata_section_aligned is only referenced by the
DEBUG_RODATA code, which is only used when the MMU is enabled,
but the definition fails on !MMU builds:
arch/arm/kernel/vmlinux.lds:702: undefined symbol `SECTION_SHIFT' referenced in expression
This hides the symbol whenever DEBUG_RODATA is disabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 64ac2e74f0b2 ("ARM: 8502/1: mm: mark section-aligned portion of rodata NX")
---
arch/arm/kernel/vmlinux.lds.S | 2 ++
1 file changed, 2 insertions(+)
On 16 February 2016 at 17:03, Arnd Bergmann [off-list ref] wrote:
quoted hunk
The __start_rodata_section_aligned is only referenced by the
DEBUG_RODATA code, which is only used when the MMU is enabled,
but the definition fails on !MMU builds:
arch/arm/kernel/vmlinux.lds:702: undefined symbol `SECTION_SHIFT' referenced in expression
This hides the symbol whenever DEBUG_RODATA is disabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 64ac2e74f0b2 ("ARM: 8502/1: mm: mark section-aligned portion of rodata NX")
---
arch/arm/kernel/vmlinux.lds.S | 2 ++
1 file changed, 2 insertions(+)
On Tuesday 16 February 2016 17:12:52 Ard Biesheuvel wrote:
quoted
+#ifdef CONFIG_DEBUG_RODATA
/*
* Without CONFIG_DEBUG_ALIGN_RODATA, __start_rodata_section_aligned will
* be the first section-aligned location after __start_rodata. Otherwise,
* it will be equal to __start_rodata.
*/
__start_rodata_section_aligned = ALIGN(__start_rodata, 1 << SECTION_SHIFT);
+#endif
Does
PROVIDE(__start_rodata_section_aligned = xxx);
do the trick as well? If it does, it's a bit cleaner.
I would assume not, as the problem is that SECTION_SHIFT is a macro that
is not defined when the MMU is disabled.
Arnd
On 16 February 2016 at 17:34, Arnd Bergmann [off-list ref] wrote:
On Tuesday 16 February 2016 17:12:52 Ard Biesheuvel wrote:
quoted
quoted
+#ifdef CONFIG_DEBUG_RODATA
/*
* Without CONFIG_DEBUG_ALIGN_RODATA, __start_rodata_section_aligned will
* be the first section-aligned location after __start_rodata. Otherwise,
* it will be equal to __start_rodata.
*/
__start_rodata_section_aligned = ALIGN(__start_rodata, 1 << SECTION_SHIFT);
+#endif
Does
PROVIDE(__start_rodata_section_aligned = xxx);
do the trick as well? If it does, it's a bit cleaner.
I would assume not, as the problem is that SECTION_SHIFT is a macro that
is not defined when the MMU is disabled.
I just tested it myself, and it in fact does work.
PROVIDE() means the expression is evaluated lazily, and SECTION_SHIFT
is just an undefined identifier in the linker script scope if the
preprocessor does not define it.
Anyway, I don't have a strong preference, so ack either way.
On 16 February 2016 at 17:03, Arnd Bergmann [off-list ref] wrote:
When CONFIG_DEBUG_ALIGN_RODATA is set, we get a link error:
arch/arm/mm/built-in.o:(.data+0x4bc): undefined reference to `__start_rodata_section_aligned'
However, this combination is useless, as XIP_KERNEL implies that all the
RODATA is already marked readonly, so both CONFIG_DEBUG_RODATA and
CONFIG_DEBUG_ALIGN_RODATA (which depends on the other) are not
needed with XIP_KERNEL, and this patches enforces that using a Kconfig
On Tue, Feb 16, 2016 at 8:03 AM, Arnd Bergmann [off-list ref] wrote:
When CONFIG_DEBUG_ALIGN_RODATA is set, we get a link error:
arch/arm/mm/built-in.o:(.data+0x4bc): undefined reference to `__start_rodata_section_aligned'
However, this combination is useless, as XIP_KERNEL implies that all the
RODATA is already marked readonly, so both CONFIG_DEBUG_RODATA and
CONFIG_DEBUG_ALIGN_RODATA (which depends on the other) are not
needed with XIP_KERNEL, and this patches enforces that using a Kconfig
dependency.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 25362dc496ed ("ARM: 8501/1: mm: flip priority of CONFIG_DEBUG_RODATA")
Oh, hm, I didn't see this before sending my fix for the rodata start issue.
On Tue, Feb 16, 2016 at 8:03 AM, Arnd Bergmann [off-list ref] wrote:
When CONFIG_DEBUG_ALIGN_RODATA is set, we get a link error:
arch/arm/mm/built-in.o:(.data+0x4bc): undefined reference to `__start_rodata_section_aligned'
However, this combination is useless, as XIP_KERNEL implies that all the
RODATA is already marked readonly, so both CONFIG_DEBUG_RODATA and
CONFIG_DEBUG_ALIGN_RODATA (which depends on the other) are not
needed with XIP_KERNEL, and this patches enforces that using a Kconfig
dependency.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 25362dc496ed ("ARM: 8501/1: mm: flip priority of CONFIG_DEBUG_RODATA")
For this and the 2/2 patch:
Acked-by: Kees Cook <redacted>
I've sent follow-up to clean up the XIP linker script too, if you want
to take that as the 3rd patch in this series of fixes.
-Kees
On Tue, Feb 16, 2016 at 12:31 PM, Kees Cook [off-list ref] wrote:
On Tue, Feb 16, 2016 at 8:03 AM, Arnd Bergmann [off-list ref] wrote:
quoted
When CONFIG_DEBUG_ALIGN_RODATA is set, we get a link error:
arch/arm/mm/built-in.o:(.data+0x4bc): undefined reference to `__start_rodata_section_aligned'
However, this combination is useless, as XIP_KERNEL implies that all the
RODATA is already marked readonly, so both CONFIG_DEBUG_RODATA and
CONFIG_DEBUG_ALIGN_RODATA (which depends on the other) are not
needed with XIP_KERNEL, and this patches enforces that using a Kconfig
dependency.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 25362dc496ed ("ARM: 8501/1: mm: flip priority of CONFIG_DEBUG_RODATA")
For this and the 2/2 patch:
Acked-by: Kees Cook <redacted>
I've sent follow-up to clean up the XIP linker script too, if you want
to take that as the 3rd patch in this series of fixes.
Arnd, when you send your 2 patches to the tracker, can you also send
mine (so the ordering is correct)?
Thanks!
-Kees
--
Kees Cook
Chrome OS & Brillo Security