Re: self-modifying code in 2.6 kernel for ppc writes into readonly section

[Michael Neuling <mikey@neuling.org>]

> It seems like no one else is interested in the subject, so i will talk
> directly to you.
> 
> If you say that the cpu also seg faults, it means that the problem is
> in the code of the linux kernel... :)

Sorry, I was only joking.  The hardware does _not_ segfault.  There is
no equivalent to segfault in real hardware.

> I'm not sure you are completely familiar with this particular piece of
> code I'm talking about, so just to make sure... On powerpc, in the
> beggining, it jumps to the early initialization, where it checks cpu
> type and then does the cpu features fixup, which means that it
> overwrites with nop's code that is not intended for this particular
> cpu. This happens on every powerpc cpu (32 bits at least), so if the
> problem was here, somebody would have reported it at least. So it is
> supposed to work this way. But in my emulator at least, I can't get
> the code to write over code and not get a segmentation fault. The
> emulator (psim, the one that comes with gdb) keeps it from writing to
> sections that were loaded as readonly. You're saying it happens the
> same on real hw ?

I'm familiar with the code you are talking about... and it works
correctly on real hardware (the code is replaced with NOPs)

The section notes are just a hints to the loader.  In the case of the
Linux kernel, it's ignored or can't be enforced by the PPC architecture.

Mikey

> 
> On Mon, Aug 18, 2008 at 11:51 PM, Michael Neuling <mikey@neuling.org> wrote:
> > In message <78ef7ce10808181257u637c5597xaa992b9e4e7a0925@mail.gmail.com> yo
u wrote:
> >> The mmu is still disabled at this point.
> >>
> >> What is marked as readonly is the text section of the vmlinux file
> >> generated when compiling the kernel. And since the code tries to write
> >> to the text section, I assumed it was the reason for the segmentation
> >> fault.
> >
> > Seriously, a seg fault in your emulator is a bug in the emulator!
> >
> >> I'm not sure how this is dealt with on real hardware.
> >
> > The CPU seg faults... :-P
> >
> >> Can somebody please explain how is it supposed to work ? Is it ok to
> >> write to text section that you load on real hardware as readonly ?
> >> (again, no mmu involved, as it is still turned off, so i'm not sure
> >> who's guarding this section against writing)
> >
> > I'm not sure how this works for 32 bit CPUs, so I can't speak to the
> > details of it.
> >
> > For the 64bit MMU, if you're in real mode (MMU off), nothing can stop
> > this from being written.  The kernel ignores the elf sections
> > permissions and does it's own mapping but this can only be enforced once
> > the MMU is on.
> >
> > Mikey
> >
> >> On Mon, Aug 18, 2008 at 10:19 PM, Michael Neuling <mikey@neuling.org> wrot
e:
> >> > In message <78ef7ce10808180901v6c694e63xefc37dd97485533@mail.gmail.com> 
you
> >  wrote:
> >> >> Hello,
> >> >>
> >> >> First, I'm talkin about the 2.6.11 version. I know arch/ppc is gone in
> >> >> latest versions,
> >> >> but i assume the code is still the same and just moved to powerpc.
> >> >>
> >> >> There is a piece of code in the early initialization of the 2.6 kernel
> >> >> that identifies the cpu type and then tries to eliminate code that
> >> >> does not apply to the current cpu. This is done by writing nop's over
> >> >> sections of code that are not needed (do_cpu_ftr_fixups in
> >> >> arch/ppc/kernel/misc.S)
> >> >>
> >> >> When I try to run the kernel in a ppc emulator, I get a segmentation
> >> >> fault in do_cpu_ftr_fixups. From examining the section headers of the
> >> >> vmlinux, the text section is marked as readonly. The piece of code
> >> >> above mentioned is trying to write a nop to memory location inside the
> >> >> text section which is readonly, so that explains the sigsegv  error.
> >> >
> >> > Any segv in the emulator sounds like a bug in the emulator.
> >> >
> >> > If the page really is marked read only, then writing to it should cause
> >> > a page fault.
> >> >
> >> >> Since the kernel does run on boards with ppc cpu's, can somebody
> >> >> explain how come this is actually working ? Or if/where I am mistaking
> >> >> with my assumptions ?
> >> >>
> >> >> Thank you
> >> >>
> >> >> P.S. please add me in cc in a reply to this message
> >> >> _______________________________________________
> >> >> Linuxppc-dev mailing list
> >> >> Linuxppc-dev@ozlabs.org
> >> >> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >> >>
> >> >
> >>
> >
>