__init poisoning for i386, too

__init poisoning for i386, too

[Pavel Machek]

Hi!

Overwrite __init section so calls to __init functions from normal code
are catched, reliably. I wonder if this should be configurable... but
it is configurable on x86-64 so I copied it. Please apply,

								Pavel

--- tmp/linux/arch/i386/Kconfig.debug	2004-10-01 00:29:59.000000000 +0200
+++ linux/arch/i386/Kconfig.debug	2004-10-07 00:11:09.000000000 +0200
@@ -15,6 +15,13 @@
 	  with klogd/syslogd or the X server. You should normally N here,
 	  unless you want to debug such a crash.
 
+config INIT_DEBUG
+	bool "Debug __init statements"
+	depends on DEBUG_KERNEL
+	help
+	  Fill __init and __initdata at the end of boot. This helps debugging
+	  illegal uses of __init and __initdata after initialization.
+
 config DEBUG_STACKOVERFLOW
 	bool "Check for stack overflows"
 	depends on DEBUG_KERNEL
--- tmp/linux/arch/i386/mm/init.c	2004-10-01 00:29:59.000000000 +0200
+++ linux/arch/i386/mm/init.c	2004-10-07 00:09:04.000000000 +0200
@@ -705,6 +705,9 @@
 		ClearPageReserved(virt_to_page(addr));
 		set_page_count(virt_to_page(addr), 1);
 		free_page(addr);
+#ifdef CONFIG_INIT_DEBUG
+		memset((void *)(addr & ~(PAGE_SIZE-1)), 0xcc, PAGE_SIZE); 
+#endif
 		totalram_pages++;
 	}
 	printk (KERN_INFO "Freeing unused kernel memory: %dk freed\n", (__init_end - __init_begin) >> 10);

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: __init poisoning for i386, too

[Andrew Morton]

Pavel Machek <pavel@ucw.cz> wrote:
>
> Overwrite __init section so calls to __init functions from normal code
> are catched, reliably. I wonder if this should be configurable... but
> it is configurable on x86-64 so I copied it. Please apply,

No, I'll change it to just enable the thing unconditionally.

Re: __init poisoning for i386, too

[Geert Uytterhoeven]

On Wed, 6 Oct 2004, Andrew Morton wrote:
> Pavel Machek <pavel@ucw.cz> wrote:
> > Overwrite __init section so calls to __init functions from normal code
> > are catched, reliably. I wonder if this should be configurable... but
> > it is configurable on x86-64 so I copied it. Please apply,
> 
> No, I'll change it to just enable the thing unconditionally.

And can't such things be done in architecture-neutral code, to avoid code
duplication and out-of-sync code among different architectures?

The magic value that corresponds to an illegal instruction (as suggested by
wli) is arch-dependent, of course.

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

Re: __init poisoning for i386, too

[Nigel Cunningham]

Hi.

On Thu, 2004-10-07 at 08:18, Pavel Machek wrote:
>  		free_page(addr);
> +#ifdef CONFIG_INIT_DEBUG
> +		memset((void *)(addr & ~(PAGE_SIZE-1)), 0xcc, PAGE_SIZE); 
> +#endif

Shouldn't the memset be before the free_page? (Changing freed pages?)

Regards,

Nigel
-- 
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901

Many today claim to be tolerant. True tolerance, however, can cope with others
being intolerant.

Re: __init poisoning for i386, too

[Pavel Machek]

Hi!

> On Thu, 2004-10-07 at 08:18, Pavel Machek wrote:
> >  		free_page(addr);
> > +#ifdef CONFIG_INIT_DEBUG
> > +		memset((void *)(addr & ~(PAGE_SIZE-1)), 0xcc, PAGE_SIZE); 
> > +#endif
> 
> Shouldn't the memset be before the free_page? (Changing freed pages?)

Ouch, you are right. Interrupt could come and grab them. Yes, we need
first memset, then free_page().
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: __init poisoning for i386, too

[William Lee Irwin III]

On Thu, Oct 07, 2004 at 12:18:55AM +0200, Pavel Machek wrote:
> Overwrite __init section so calls to __init functions from normal code
> are catched, reliably. I wonder if this should be configurable... but
> it is configurable on x86-64 so I copied it. Please apply,

Any chance we could:
(a) set the stuff to 0x0f0b so illegal instructions come of it; jumps are
	most often aligned to something > 16 bits anyway
(b) poison __initdata, memsetting to some bit pattern oopsable to dereference


-- wli

Re: __init poisoning for i386, too

[H. Peter Anvin]

Followup to:  <20041007061610.GU9106@holomorphy.com>
By author:    William Lee Irwin III <wli@holomorphy.com>
In newsgroup: linux.dev.kernel
>
> On Thu, Oct 07, 2004 at 12:18:55AM +0200, Pavel Machek wrote:
> > Overwrite __init section so calls to __init functions from normal code
> > are catched, reliably. I wonder if this should be configurable... but
> > it is configurable on x86-64 so I copied it. Please apply,
> 
> Any chance we could:
> (a) set the stuff to 0x0f0b so illegal instructions come of it; jumps are
> 	most often aligned to something > 16 bits anyway
> (b) poison __initdata, memsetting to some bit pattern oopsable to dereference
> 

What's wrong with using 0xCC (breakpoint instruction)?

If you want an illegal instruction, 0xFF 0xFF is an illegal
instruction, so filling memory with 0xFF will do what you want.

	-hpa

Re: __init poisoning for i386, too

[William Lee Irwin III]

At some point in the past, I wrote:
>> Any chance we could:
>> (a) set the stuff to 0x0f0b so illegal instructions come of it; jumps are
>> 	most often aligned to something > 16 bits anyway
>> (b) poison __initdata, memsetting to some bit pattern oopsable to dereference

On Thu, Oct 07, 2004 at 09:05:45PM +0000, H. Peter Anvin wrote:
> What's wrong with using 0xCC (breakpoint instruction)?
> If you want an illegal instruction, 0xFF 0xFF is an illegal
> instruction, so filling memory with 0xFF will do what you want.

That sounds better than what I suggested.


-- wli

Re: __init poisoning for i386, too

[Ryan Cumming]

[-- Attachment #1.1: Type: text/plain, Size: 404 bytes --]

On Friday 08 October 2004 04:08, you wrote:
> On Thu, Oct 07, 2004 at 09:05:45PM +0000, H. Peter Anvin wrote:
> > What's wrong with using 0xCC (breakpoint instruction)?
> > If you want an illegal instruction, 0xFF 0xFF is an illegal
> > instruction, so filling memory with 0xFF will do what you want.
>
> That sounds better than what I suggested.
>

Here's the trivial patch against 2.4.9-rc3-mm3

-Ryan

[-- Attachment #1.2: trivial-initmem-tweak.diff --]
[-- Type: text/x-diff, Size: 502 bytes --]

--- linux-2.6.9-rc3-mm3/arch/i386/mm/init.c	2004-10-08 04:19:46.645395667 -0700
+++ linux-2.6.9-rc3-mm3-new/arch/i386/mm/init.c	2004-10-08 04:21:51.933318774 -0700
@@ -723,7 +723,7 @@
 	for (; addr < (unsigned long)(&__init_end); addr += PAGE_SIZE) {
 		ClearPageReserved(virt_to_page(addr));
 		set_page_count(virt_to_page(addr), 1);
-		memset((void *)(addr & ~(PAGE_SIZE-1)), 0xcc, PAGE_SIZE);
+		memset((void *)(addr & ~(PAGE_SIZE-1)), 0xff, PAGE_SIZE);
 		free_page(addr);
 		totalram_pages++;
 	}

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: __init poisoning for i386, too

[Andi Kleen]

William Lee Irwin III <wli@holomorphy.com> writes:

> On Thu, Oct 07, 2004 at 12:18:55AM +0200, Pavel Machek wrote:
> > Overwrite __init section so calls to __init functions from normal code
> > are catched, reliably. I wonder if this should be configurable... but
> > it is configurable on x86-64 so I copied it. Please apply,
> 
> Any chance we could:
> (a) set the stuff to 0x0f0b so illegal instructions come of it; jumps are
> 	most often aligned to something > 16 bits anyway

0xcc is an int3, that already causes an oops.

> (b) poison __initdata, memsetting to some bit pattern oopsable to dereference

Would be a good idea yes. I will add it to x86-64.

-Andi