From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: kernel: Detect DTB overwrite and error out
Date: Thu, 21 Nov 2013 12:56:03 -0700 [thread overview]
Message-ID: <528E6553.9020608@wwwdotorg.org> (raw)
In-Reply-To: <528E63A4.7050708@ti.com>
On 11/21/2013 12:48 PM, Joel Fernandes wrote:
> On 11/21/2013 10:48 AM, Stephen Warren wrote:
>> On 11/20/2013 09:04 PM, Joel Fernandes wrote:
>>> Kernel can silenty fail for DT-boot after the decompression stage, if DTB is
>>> overwritten. Instead of simply failing, we detect the condition and print an
>>> error.
>>>
>>> One may think that it is sufficient for the bootloader to place the DTB away
>>> from kernel, but this is not the right fix because: (1) We add more dependence
>>> to the bootloader's stupidity (2) the decompressed kernel end address is not
>>> known to the loader. Also, we shouldn't depend on bootloader for silently
>>> failing us, so we detect the condition and error out.
>>
>> If this problem happens, is there any guarantee that the kernel will
>> still execute far enough to actually print this error message? Can the
>
> Yes, because till this point we don't depend on DTB yet. We're still just about
> to parse it. The problem detected here is the kernel overwriting the DTB, not
> the other way.
Ah yes, that makes sense. Thanks.
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren@wwwdotorg.org>
To: Joel Fernandes <joelf@ti.com>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, will.deacon@arm.com,
rnayak@ti.com, santosh.shilimkar@ti.com, balbi@ti.com
Subject: Re: [PATCH] ARM: kernel: Detect DTB overwrite and error out
Date: Thu, 21 Nov 2013 12:56:03 -0700 [thread overview]
Message-ID: <528E6553.9020608@wwwdotorg.org> (raw)
In-Reply-To: <528E63A4.7050708@ti.com>
On 11/21/2013 12:48 PM, Joel Fernandes wrote:
> On 11/21/2013 10:48 AM, Stephen Warren wrote:
>> On 11/20/2013 09:04 PM, Joel Fernandes wrote:
>>> Kernel can silenty fail for DT-boot after the decompression stage, if DTB is
>>> overwritten. Instead of simply failing, we detect the condition and print an
>>> error.
>>>
>>> One may think that it is sufficient for the bootloader to place the DTB away
>>> from kernel, but this is not the right fix because: (1) We add more dependence
>>> to the bootloader's stupidity (2) the decompressed kernel end address is not
>>> known to the loader. Also, we shouldn't depend on bootloader for silently
>>> failing us, so we detect the condition and error out.
>>
>> If this problem happens, is there any guarantee that the kernel will
>> still execute far enough to actually print this error message? Can the
>
> Yes, because till this point we don't depend on DTB yet. We're still just about
> to parse it. The problem detected here is the kernel overwriting the DTB, not
> the other way.
Ah yes, that makes sense. Thanks.
next prev parent reply other threads:[~2013-11-21 19:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-21 4:04 [PATCH] ARM: kernel: Detect DTB overwrite and error out Joel Fernandes
2013-11-21 4:04 ` Joel Fernandes
2013-11-21 16:48 ` Stephen Warren
2013-11-21 16:48 ` Stephen Warren
2013-11-21 19:48 ` Joel Fernandes
2013-11-21 19:48 ` Joel Fernandes
2013-11-21 19:56 ` Stephen Warren [this message]
2013-11-21 19:56 ` Stephen Warren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=528E6553.9020608@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.