diff mbox

allow placing exception table in .rodata (and do so on x86)

Message ID 4DB85404020000780003E6D7@vpn.id2.novell.com (mailing list archive)
State New, archived
Headers show

Commit Message

Jan Beulich April 27, 2011, 3:36 p.m. UTC
This is since the table is really a set of pointers, i.e. misplaced in
.text.

Quite likely other architectures would want to follow.

Signed-off-by: Jan Beulich <jbeulich@novell.com>

---
 arch/x86/include/asm/sections.h   |    2 +-
 arch/x86/kernel/vmlinux.lds.S     |    5 +++--
 arch/x86/mm/init_64.c             |    6 +++---
 include/asm-generic/vmlinux.lds.h |    5 +++++
 4 files changed, 12 insertions(+), 6 deletions(-)




--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Heiko Carstens April 28, 2011, 10:43 a.m. UTC | #1
On Wed, Apr 27, 2011 at 04:36:04PM +0100, Jan Beulich wrote:
> This is since the table is really a set of pointers, i.e. misplaced in
> .text.
> 
> Quite likely other architectures would want to follow.
> 
> Signed-off-by: Jan Beulich <jbeulich@novell.com>
> 

[...]

> --- 2.6.39-rc5/include/asm-generic/vmlinux.lds.h
> +++ 2.6.39-rc5-extable-in-rodata/include/asm-generic/vmlinux.lds.h
> @@ -226,6 +226,7 @@
>  		*(.rodata1)						\
>  	}								\
>  									\
> +	EXCEPTION_TABLE_RO						\

That's odd. The kernel actually writes to it (sort_main_extable()), so
it shouldn't be in the ro data section, but the data section.

>  	JUMP_TABLE							\

same here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jan Beulich April 28, 2011, 11:40 a.m. UTC | #2
>>> On 28.04.11 at 12:43, Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> On Wed, Apr 27, 2011 at 04:36:04PM +0100, Jan Beulich wrote:
>> This is since the table is really a set of pointers, i.e. misplaced in
>> .text.
>> 
>> Quite likely other architectures would want to follow.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@novell.com>
>> 
> 
> [...]
> 
>> --- 2.6.39-rc5/include/asm-generic/vmlinux.lds.h
>> +++ 2.6.39-rc5-extable-in-rodata/include/asm-generic/vmlinux.lds.h
>> @@ -226,6 +226,7 @@
>>  		*(.rodata1)						\
>>  	}								\
>>  									\
>> +	EXCEPTION_TABLE_RO						\
> 
> That's odd. The kernel actually writes to it (sort_main_extable()), so
> it shouldn't be in the ro data section, but the data section.

This area does get written, but only at boot time, before read-only
data gets set to r/o (on x86 at least). With this in mind, it's better
to place it in .rodata, as that way run-time protection will be in place
(and I think you agree that it was misplaced in .text in any case).

Jan

>>  	JUMP_TABLE							\
> 
> same here.



--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Geert Uytterhoeven April 28, 2011, 11:47 a.m. UTC | #3
On Thu, Apr 28, 2011 at 13:40, Jan Beulich <JBeulich@novell.com> wrote:
>>>> On 28.04.11 at 12:43, Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
>> On Wed, Apr 27, 2011 at 04:36:04PM +0100, Jan Beulich wrote:
>>> This is since the table is really a set of pointers, i.e. misplaced in
>>> .text.
>>>
>>> Quite likely other architectures would want to follow.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@novell.com>
>>>
>>
>> [...]
>>
>>> --- 2.6.39-rc5/include/asm-generic/vmlinux.lds.h
>>> +++ 2.6.39-rc5-extable-in-rodata/include/asm-generic/vmlinux.lds.h
>>> @@ -226,6 +226,7 @@
>>>              *(.rodata1)                                             \
>>>      }                                                               \
>>>                                                                      \
>>> +    EXCEPTION_TABLE_RO                                              \
>>
>> That's odd. The kernel actually writes to it (sort_main_extable()), so
>> it shouldn't be in the ro data section, but the data section.
>
> This area does get written, but only at boot time, before read-only
> data gets set to r/o (on x86 at least). With this in mind, it's better
> to place it in .rodata, as that way run-time protection will be in place
> (and I think you agree that it was misplaced in .text in any case).

Which means it may be in ROM (which is really read-only) on some embedded
devices, so it cannot be sorted?

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jan Beulich April 28, 2011, 12:07 p.m. UTC | #4
>>> On 28.04.11 at 13:47, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Apr 28, 2011 at 13:40, Jan Beulich <JBeulich@novell.com> wrote:
>>>>> On 28.04.11 at 12:43, Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
>>> On Wed, Apr 27, 2011 at 04:36:04PM +0100, Jan Beulich wrote:
>>>> This is since the table is really a set of pointers, i.e. misplaced in
>>>> .text.
>>>>
>>>> Quite likely other architectures would want to follow.
>>>>
>>>> Signed-off-by: Jan Beulich <jbeulich@novell.com>
>>>>
>>>
>>> [...]
>>>
>>>> --- 2.6.39-rc5/include/asm-generic/vmlinux.lds.h
>>>> +++ 2.6.39-rc5-extable-in-rodata/include/asm-generic/vmlinux.lds.h
>>>> @@ -226,6 +226,7 @@
>>>>              *(.rodata1)                                             \
>>>>      }                                                               \
>>>>                                                                      \
>>>> +    EXCEPTION_TABLE_RO                                              \
>>>
>>> That's odd. The kernel actually writes to it (sort_main_extable()), so
>>> it shouldn't be in the ro data section, but the data section.
>>
>> This area does get written, but only at boot time, before read-only
>> data gets set to r/o (on x86 at least). With this in mind, it's better
>> to place it in .rodata, as that way run-time protection will be in place
>> (and I think you agree that it was misplaced in .text in any case).
> 
> Which means it may be in ROM (which is really read-only) on some embedded
> devices, so it cannot be sorted?

Perhaps - but since sorting is a requirement, people building such
systems must have found a way... Anyway, I don't see where both
your and Heiko's comment are heading, since the situation is even
worse without the patch afaics (since .text gets marked read-only
as much as .rodata does, and could equally be placed in ROM).

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Heiko Carstens April 28, 2011, 12:53 p.m. UTC | #5
On Thu, Apr 28, 2011 at 01:07:07PM +0100, Jan Beulich wrote:
> >>> On 28.04.11 at 13:47, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Thu, Apr 28, 2011 at 13:40, Jan Beulich <JBeulich@novell.com> wrote:
> >>>>> On 28.04.11 at 12:43, Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> >>> On Wed, Apr 27, 2011 at 04:36:04PM +0100, Jan Beulich wrote:
> >>> That's odd. The kernel actually writes to it (sort_main_extable()), so
> >>> it shouldn't be in the ro data section, but the data section.
> >>
> >> This area does get written, but only at boot time, before read-only
> >> data gets set to r/o (on x86 at least). With this in mind, it's better
> >> to place it in .rodata, as that way run-time protection will be in place
> >> (and I think you agree that it was misplaced in .text in any case).
> > 
> > Which means it may be in ROM (which is really read-only) on some embedded
> > devices, so it cannot be sorted?
> 
> Perhaps - but since sorting is a requirement, people building such
> systems must have found a way... Anyway, I don't see where both

Yes, we found a way on s390: we put the exception table in the data section.

> your and Heiko's comment are heading, since the situation is even
> worse without the patch afaics (since .text gets marked read-only
> as much as .rodata does, and could equally be placed in ROM).

My point is that your default is wrong. If it makes sense to put the extable
into the rodata section then an architecture could do so. However making the
default to put data into the rodata section that is actually written to is
the wrong approach.
It just asks for breakage.
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jan Beulich April 28, 2011, 1:31 p.m. UTC | #6
>>> On 28.04.11 at 14:53, Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> On Thu, Apr 28, 2011 at 01:07:07PM +0100, Jan Beulich wrote:
>> >>> On 28.04.11 at 13:47, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> > On Thu, Apr 28, 2011 at 13:40, Jan Beulich <JBeulich@novell.com> wrote:
>> >>>>> On 28.04.11 at 12:43, Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
>> >>> On Wed, Apr 27, 2011 at 04:36:04PM +0100, Jan Beulich wrote:
>> >>> That's odd. The kernel actually writes to it (sort_main_extable()), so
>> >>> it shouldn't be in the ro data section, but the data section.
>> >>
>> >> This area does get written, but only at boot time, before read-only
>> >> data gets set to r/o (on x86 at least). With this in mind, it's better
>> >> to place it in .rodata, as that way run-time protection will be in place
>> >> (and I think you agree that it was misplaced in .text in any case).
>> > 
>> > Which means it may be in ROM (which is really read-only) on some embedded
>> > devices, so it cannot be sorted?
>> 
>> Perhaps - but since sorting is a requirement, people building such
>> systems must have found a way... Anyway, I don't see where both
> 
> Yes, we found a way on s390: we put the exception table in the data section.
> 
>> your and Heiko's comment are heading, since the situation is even
>> worse without the patch afaics (since .text gets marked read-only
>> as much as .rodata does, and could equally be placed in ROM).
> 
> My point is that your default is wrong. If it makes sense to put the extable
> into the rodata section then an architecture could do so. However making the
> default to put data into the rodata section that is actually written to is
> the wrong approach.
> It just asks for breakage.

The patch doesn't make this the default - it just makes it possible
for an architecture to do so.

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Geert Uytterhoeven April 28, 2011, 1:44 p.m. UTC | #7
On Thu, Apr 28, 2011 at 15:31, Jan Beulich <JBeulich@novell.com> wrote:
>>>> On 28.04.11 at 14:53, Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
>> On Thu, Apr 28, 2011 at 01:07:07PM +0100, Jan Beulich wrote:
>>> >>> On 28.04.11 at 13:47, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>> > On Thu, Apr 28, 2011 at 13:40, Jan Beulich <JBeulich@novell.com> wrote:
>>> >>>>> On 28.04.11 at 12:43, Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
>>> >>> On Wed, Apr 27, 2011 at 04:36:04PM +0100, Jan Beulich wrote:
>>> >>> That's odd. The kernel actually writes to it (sort_main_extable()), so
>>> >>> it shouldn't be in the ro data section, but the data section.
>>> >>
>>> >> This area does get written, but only at boot time, before read-only
>>> >> data gets set to r/o (on x86 at least). With this in mind, it's better
>>> >> to place it in .rodata, as that way run-time protection will be in place
>>> >> (and I think you agree that it was misplaced in .text in any case).
>>> >
>>> > Which means it may be in ROM (which is really read-only) on some embedded
>>> > devices, so it cannot be sorted?
>>>
>>> Perhaps - but since sorting is a requirement, people building such
>>> systems must have found a way... Anyway, I don't see where both
>>
>> Yes, we found a way on s390: we put the exception table in the data section.
>>
>>> your and Heiko's comment are heading, since the situation is even
>>> worse without the patch afaics (since .text gets marked read-only
>>> as much as .rodata does, and could equally be placed in ROM).
>>
>> My point is that your default is wrong. If it makes sense to put the extable
>> into the rodata section then an architecture could do so. However making the
>> default to put data into the rodata section that is actually written to is
>> the wrong approach.
>> It just asks for breakage.
>
> The patch doesn't make this the default - it just makes it possible
> for an architecture to do so.

"asm-generic" is the default for new architectures.

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

--- 2.6.39-rc5/arch/x86/include/asm/sections.h
+++ 2.6.39-rc5-extable-in-rodata/arch/x86/include/asm/sections.h
@@ -5,7 +5,7 @@ 
 #include <asm/uaccess.h>
 
 extern char __brk_base[], __brk_limit[];
-extern struct exception_table_entry __stop___ex_table[];
+extern const char __stop_notes[];
 
 #if defined(CONFIG_X86_64) && defined(CONFIG_DEBUG_RODATA)
 extern char __end_rodata_hpage_align[];
--- 2.6.39-rc5/arch/x86/kernel/vmlinux.lds.S
+++ 2.6.39-rc5-extable-in-rodata/arch/x86/kernel/vmlinux.lds.S
@@ -20,6 +20,8 @@ 
 #define LOAD_OFFSET __START_KERNEL_map
 #endif
 
+#define EXCEPTION_TABLE_RO EXCEPTION_TABLE(16)
+
 #include <asm-generic/vmlinux.lds.h>
 #include <asm/asm-offsets.h>
 #include <asm/thread_info.h>
@@ -114,8 +116,7 @@  SECTIONS
 	} :text = 0x9090
 
 	NOTES :text :note
-
-	EXCEPTION_TABLE(16) :text = 0x9090
+	text_continues : {} :text /* switch back to regular text... */
 
 #if defined(CONFIG_DEBUG_RODATA)
 	/* .text should occupy whole number of pages */
--- 2.6.39-rc5/arch/x86/mm/init_64.c
+++ 2.6.39-rc5-extable-in-rodata/arch/x86/mm/init_64.c
@@ -741,7 +741,7 @@  int kernel_set_to_readonly;
 void set_kernel_text_rw(void)
 {
 	unsigned long start = PFN_ALIGN(_text);
-	unsigned long end = PFN_ALIGN(__stop___ex_table);
+	unsigned long end = PFN_ALIGN(_etext);
 
 	if (!kernel_set_to_readonly)
 		return;
@@ -760,7 +760,7 @@  void set_kernel_text_rw(void)
 void set_kernel_text_ro(void)
 {
 	unsigned long start = PFN_ALIGN(_text);
-	unsigned long end = PFN_ALIGN(__stop___ex_table);
+	unsigned long end = PFN_ALIGN(_etext);
 
 	if (!kernel_set_to_readonly)
 		return;
@@ -780,7 +780,7 @@  void mark_rodata_ro(void)
 	unsigned long rodata_start =
 		((unsigned long)__start_rodata + PAGE_SIZE - 1) & PAGE_MASK;
 	unsigned long end = (unsigned long) &__end_rodata_hpage_align;
-	unsigned long text_end = PAGE_ALIGN((unsigned long) &__stop___ex_table);
+	unsigned long text_end = PAGE_ALIGN((unsigned long) &__stop_notes);
 	unsigned long rodata_end = PAGE_ALIGN((unsigned long) &__end_rodata);
 	unsigned long data_start = (unsigned long) &_sdata;
 
--- 2.6.39-rc5/include/asm-generic/vmlinux.lds.h
+++ 2.6.39-rc5-extable-in-rodata/include/asm-generic/vmlinux.lds.h
@@ -226,6 +226,7 @@ 
 		*(.rodata1)						\
 	}								\
 									\
+	EXCEPTION_TABLE_RO						\
 	BUG_TABLE							\
 									\
 	JUMP_TABLE							\
@@ -459,6 +460,10 @@ 
 		VMLINUX_SYMBOL(__stop___ex_table) = .;			\
 	}
 
+#ifndef EXCEPTION_TABLE_RO
+#define EXCEPTION_TABLE_RO
+#endif
+
 /*
  * Init task
  */