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

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

[Mihaela Grigore]

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.

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

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

[Michael Neuling]

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
> 

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

[Mihaela Grigore]

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.

I'm not sure how this is dealt with on real hardware.

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)

On Mon, Aug 18, 2008 at 10:19 PM, Michael Neuling <mikey@neuling.org> wrote:
> 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
>>
>

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

[Michael Neuling]

In message <78ef7ce10808181257u637c5597xaa992b9e4e7a0925@mail.gmail.com> you 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> wrote:
> > 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
> >>
> >
> 

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

[Becky Bruce]

On Aug 18, 2008, at 3:51 PM, Michael Neuling wrote:

> In message <78ef7ce10808181257u637c5597xaa992b9e4e7a0925@mail.gmail.com 
> > you 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!

Mikey is likely right here. I've (unfortunately) done a lot of  
emulator work, and every time I've hit a problem like this, the  
problem has been with the emulator or the emulation environment.  Have  
you isolated the faulting instruction, verified that it's to a  
reasonable address, and tried examining memory at the faulting address  
using your emulator's command interface?

>
>
>> I'm not sure how this is dealt with on real hardware.
>
> The CPU seg faults... :-P

But only if the page is mapped non-writeable.  Even with the MMU on,  
Linux maps itself in as writeable.  It's the OS, it can do whatever it  
wants.  So it just works on real hardware, and it should just work in  
your emulator.

>
>
>> 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.

The same is true on 32-bit ppc - the basic MMU architecture is very  
similar if you have a part that has "real mode" (i.e. non-booke).   
There is no way to restrict stores in real mode.

-Becky

>
>
> Mikey
>
>> On Mon, Aug 18, 2008 at 10:19 PM, Michael Neuling  
>> <mikey@neuling.org> wrote:
>>> 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
>>>>
>>>
>>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

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

[Mihaela Grigore]

On Tue, Aug 19, 2008 at 12:25 AM, Becky Bruce <becky.bruce@freescale.com> wrote:
>
> On Aug 18, 2008, at 3:51 PM, Michael Neuling wrote:
>
>> In message <78ef7ce10808181257u637c5597xaa992b9e4e7a0925@mail.gmail.com>
>> you 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!
>
> Mikey is likely right here. I've (unfortunately) done a lot of emulator
> work, and every time I've hit a problem like this, the problem has been with
> the emulator or the emulation environment.  Have you isolated the faulting
> instruction, verified that it's to a reasonable address, and tried examining
> memory at the faulting address using your emulator's command interface?
>

yes, it's a store instruction. the value to be stored is a nop
instruction and the
address is inside the text section (it is writing over existing code that
is intended for other cpus).

>>
>>
>>> I'm not sure how this is dealt with on real hardware.
>>
>> The CPU seg faults... :-P
>
> But only if the page is mapped non-writeable.  Even with the MMU on, Linux
> maps itself in as writeable.  It's the OS, it can do whatever it wants.  So
> it just works on real hardware, and it should just work in your emulator.
>

I forgot to mention that I'm trying to run directly the vmlinux image
in psim emulator.
I'm not sure it's even supposed to work this way.

>>
>>
>>> 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.
>
> The same is true on 32-bit ppc - the basic MMU architecture is very similar
> if you have a part that has "real mode" (i.e. non-booke).  There is no way
> to restrict stores in real mode.
>
> -Becky
>
>>
>>
>> Mikey
>>
>>> On Mon, Aug 18, 2008 at 10:19 PM, Michael Neuling <mikey@neuling.org>
>>> wrote:
>>>>
>>>> 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
>>>>>
>>>>
>>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>

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

[Michael Neuling]

> 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
> >> >>
> >> >
> >>
> >
> 

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

[Scott Wood]

Michael Neuling wrote:
>> 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.

Well, there are machine checks and checkstops... :-)

-Scott

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

[Michael Neuling]

In message <48A9F423.2070602@freescale.com> you wrote:
> Michael Neuling wrote:
> >> 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.
> 
> Well, there are machine checks and checkstops... :-)

Shhhh! :-)

Mikey

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

[Michael Neuling]

In message <78ef7ce10808181507h5174be66nfe9707a421473c5c@mail.gmail.com> you wr
ote:
> On Tue, Aug 19, 2008 at 12:25 AM, Becky Bruce <becky.bruce@freescale.com> wro
te:
> >
> > On Aug 18, 2008, at 3:51 PM, Michael Neuling wrote:
> >
> >> In message <78ef7ce10808181257u637c5597xaa992b9e4e7a0925@mail.gmail.com>
> >> you 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!
> >
> > Mikey is likely right here. I've (unfortunately) done a lot of emulator
> > work, and every time I've hit a problem like this, the problem has been wit
h
> > the emulator or the emulation environment.  Have you isolated the faulting
> > instruction, verified that it's to a reasonable address, and tried examinin
g
> > memory at the faulting address using your emulator's command interface?
> >
> 
> yes, it's a store instruction. the value to be stored is a nop
> instruction and the
> address is inside the text section (it is writing over existing code that
> is intended for other cpus).
> 
> >>
> >>
> >>> I'm not sure how this is dealt with on real hardware.
> >>
> >> The CPU seg faults... :-P
> >
> > But only if the page is mapped non-writeable.  Even with the MMU on, Linux
> > maps itself in as writeable.  It's the OS, it can do whatever it wants.  So
> > it just works on real hardware, and it should just work in your emulator.
> >
> 
> I forgot to mention that I'm trying to run directly the vmlinux image
> in psim emulator.
> I'm not sure it's even supposed to work this way.

Looking at the psim web page quickly, it seems to be for userspace
binaries.

So yeah, I don't think it's designed to be used like you are try to use
it.

> 
> >>
> >>
> >>> 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.
> >
> > The same is true on 32-bit ppc - the basic MMU architecture is very similar
> > if you have a part that has "real mode" (i.e. non-booke).  There is no way
> > to restrict stores in real mode.
> >
> > -Becky
> >
> >>
> >>
> >> Mikey
> >>
> >>> On Mon, Aug 18, 2008 at 10:19 PM, Michael Neuling <mikey@neuling.org>
> >>> wrote:
> >>>>
> >>>> 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
> >>>>>
> >>>>
> >>>
> >> _______________________________________________
> >> Linuxppc-dev mailing list
> >> Linuxppc-dev@ozlabs.org
> >> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
> >
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>