linux-kernel - Re: bug: kernel 3.0-rc3 not relocatable on i386?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 15 Jun 2011 12:01:18 +0200
From:	Petr Tesarik <ptesarik@...e.cz>
To:	Maarten Lankhorst <m.b.lankhorst@...il.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: bug: kernel 3.0-rc3 not relocatable on i386?

Maarten Lankhorst píše v St 15. 06. 2011 v 11:21 +0200:
> Hi Petr,
> 
> 2011/6/15 Petr Tesarik <ptesarik@...e.cz>:
> > Hi all,
> >
> > it seems that the 3.0-rc3 kernel is not relocatable on i386. I get
> > warnings about jiffies being an absolute symbol, and indeed, when GRUB
> > loads the kernel at a non-default address, jiffies is not relocated.
> >
> > In my example the kernel is configured with
> > CONFIG_PHYSICAL_START=0x1000000
> > CONFIG_PHYSICAL_ALIGN=0x200000
> > CONFIG_RELOCATABLE=y
> > and loaded at 0x200000 by GRUB.
> >
> > Booting fails when checking whether the timer works, because do_timer()
> > increments jiffies_64, but timer_irq_works() checks jiffies. The code
> > looks like this:
> >
> > c13daab7:       8b 3d 40 7a 39 c1       mov    0xc1397a40,%edi
> >
> > but arch/x86/boot/compressed/vmlinux.relocs does not contain c13daaba.
> > Consequently, timer_irq_works() reads the wrong memory location and
> > fails, causing a panic:
> >
> > kernel panic: IO-APIC + timer doesn't work! Boot with apic=debug and
> > send a report.  Then try booting with the 'noapic' option.
> >
> > Needless to say, the kernel freezes a few initcalls later when booted
> > with noapic, because IO-APIC worked fine, in fact. I verified that by
> > inserting a debugging printk() in do_timer(), and I also verified with
> > that printk() that the address of jiffies_64 and the address of jiffies
> > differ at run time.
> >
> > Any idea how to fix this?
> Does reverting this commit fix it?

Isn't this related to VDSO? I've got no troubles with the VDSO. It's
just that the kernel assumes a fixed location of jiffies (in the kernel
direct mapping), so it cannot be relocated.

OTOH this must have worked the other day, so searching for the commit
that broke it is a good hint. I'll try it here, too.

Petr

> commit 8c49d9a74bac5ea3f18480307057241b808fcc0c
> Author: Andy Lutomirski <luto@....EDU>
> Date:   Mon May 23 09:31:24 2011 -0400
> 
>     x86-64: Clean up vdso/kernel shared variables
> 
> ~Maarten

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/