This is a bug that can cause early crashes in configurations with a
.exit.text section smaller than a page and a .init.text section that
ends in the beginning of a physical page (this is kinda random, which
might explain why this wasn't really encountered before).
The init sections are ordered like this:
.init.text
.exit.text
.init.data
Currently, these sections aren't page aligned.
Because the init code is mapped read-only at runtime and because the
.init.text section can potentially reside on the same physical page as
.init.data, the beginning of .init.data might be mapped read-only along
with .init.text.
Then when the kernel tries to modify a variable in .init.data (like
kthreadd_done, used in kernel_init()) the kernel panics.
To avoid this, I made these sections page aligned.
Fixes: 060ef9d89d18 ("powerpc32: PAGE_EXEC required for inittext")
Signed-off-by: Ariel Marcovitch <redacted>
---
arch/powerpc/kernel/vmlinux.lds.S | 7 +++++++
1 file changed, 7 insertions(+)
This is a bug that can cause early crashes in configurations with a
.exit.text section smaller than a page and a .init.text section that
ends in the beginning of a physical page (this is kinda random, which
might explain why this wasn't really encountered before).
It can cause, or it causes ? Did you encounter the issue ?
The init sections are ordered like this:
.init.text
.exit.text
.init.data
Currently, these sections aren't page aligned.
Because the init code is mapped read-only at runtime and because the
.init.text section can potentially reside on the same physical page as
.init.data, the beginning of .init.data might be mapped read-only along
with .init.text.
init code is mapped PAGE_KERNEL_TEXT.
Whether PAGE_KERNEL_TEXT is read-only or not depends on the selected options.
Then when the kernel tries to modify a variable in .init.data (like
kthreadd_done, used in kernel_init()) the kernel panics.
To avoid this, I made these sections page aligned.
Should write this unpersonal, something like "To avoid this, make these sections page aligned"
In principle, as it is text, it should be made RO as well. But what happens at the begining doesn't
really matter, anyway .exit.text should never be executed and is discarded together with init text.
So, I think it is OK the live with it as is for the time being.
Making it page aligned makes sense anyway.
Should we make _einittext page aligned instead, just like _etext ?
quoted hunk
/* .exit.text is discarded at runtime, not link time,
* to deal with references from __bug_table
*/
On Fri, Dec 18, 2020 at 5:39 PM Christophe Leroy <
christophe.leroy@csgroup.eu> wrote:
It can cause, or it causes ? Did you encounter the issue ?
Yes, in configs that result in the section layout I described, the crush is
consistent.
quoted
The init sections are ordered like this:
.init.text
.exit.text
.init.data
Currently, these sections aren't page aligned.
Because the init code is mapped read-only at runtime and because the
.init.text section can potentially reside on the same physical page as
.init.data, the beginning of .init.data might be mapped read-only along
with .init.text.
init code is mapped PAGE_KERNEL_TEXT.
Whether PAGE_KERNEL_TEXT is read-only or not depends on the selected
options.
You are right, of course. Should I change the commit message to 'might be
mapped' or something?
quoted
Then when the kernel tries to modify a variable in .init.data (like
kthreadd_done, used in kernel_init()) the kernel panics.
To avoid this, I made these sections page aligned.
Should write this unpersonal, something like "To avoid this, make these
sections page aligned"
In principle, as it is text, it should be made RO as well. But what
happens at the begining doesn't
really matter, anyway .exit.text should never be executed and is discarded
together with init text.
So, I think it is OK the live with it as is for the time being.
Making it page aligned makes sense anyway.
Should we make _einittext page aligned instead, just like _etext ?
Yes, this will probably be better (because when _einittext is not aligned,
the part of the page after _einittext is mapped RO implicitly, and it's
hard to notice from the code). I suppose you mean something like this:
_sinittext = .;
INIT_TEXT
+
+ . = ALIGN(.);
_einittext = .;
/* .exit.text is discarded at runtime, not link time,
On Fri, Dec 18, 2020 at 5:39 PM Christophe Leroy <
christophe.leroy@csgroup.eu> wrote:
It can cause, or it causes ? Did you encounter the issue ?
Yes, in configs that result in the section layout I described, the crush is
consistent.
quoted
The init sections are ordered like this:
.init.text
.exit.text
.init.data
Currently, these sections aren't page aligned.
Because the init code is mapped read-only at runtime and because the
.init.text section can potentially reside on the same physical page as
.init.data, the beginning of .init.data might be mapped read-only along
with .init.text.
init code is mapped PAGE_KERNEL_TEXT.
Whether PAGE_KERNEL_TEXT is read-only or not depends on the selected
options.
You are right, of course. Should I change the commit message to 'might be
mapped' or something?
quoted
Then when the kernel tries to modify a variable in .init.data (like
kthreadd_done, used in kernel_init()) the kernel panics.
To avoid this, I made these sections page aligned.
Should write this unpersonal, something like "To avoid this, make these
sections page aligned"
In principle, as it is text, it should be made RO as well. But what
happens at the begining doesn't
really matter, anyway .exit.text should never be executed and is discarded
together with init text.
So, I think it is OK the live with it as is for the time being.
Making it page aligned makes sense anyway.
Should we make _einittext page aligned instead, just like _etext ?
Yes, this will probably be better (because when _einittext is not aligned,
the part of the page after _einittext is mapped RO implicitly, and it's
hard to notice from the code). I suppose you mean something like this:
_sinittext = .;
INIT_TEXT
+
+ . = ALIGN(.);
_einittext = .;
/* .exit.text is discarded at runtime, not link time,