All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Morse <james.morse@arm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Pratyush Anand <panand@redhat.com>,
	geoff@infradead.org, kexec@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] arm64: Add enable/disable d-cache support for purgatory
Date: Wed, 14 Dec 2016 12:11:33 +0000	[thread overview]
Message-ID: <585136F5.3070606@arm.com> (raw)
In-Reply-To: <20161214113701.GE17982@leverpostej>

Hi Mark,

On 14/12/16 11:37, Mark Rutland wrote:
> On Wed, Dec 14, 2016 at 11:16:17AM +0000, James Morse wrote:
>> On 14/12/16 10:12, Pratyush Anand wrote:
>>> On Wednesday 14 December 2016 03:08 PM, Pratyush Anand wrote:
>>>>> I would go as far as to generate the page tables at 'kexec -l' time,
>>>>> and only if
>>>>
>>>> Ok..So you mean that I create a new section which will have page table
>>>> entries mapping physicalmemory represented by remaining section, and
>>>> then purgatory can just enable mmu with page table from that section,
>>>> right? Seems doable. can do that.
>>>
>>> I see a problem here. If we create  page table as a new segment then, how can we
>>> verify in purgatory that sha for page table is correct? We need page table
>>> before sha verification start,and we can not rely the page table created by
>>> first kernel until it's sha is verified. So a chicken-egg problem.
>>
>> There is more than one of those! What happens if your sha256 calculation code is
>> corrupted? You have to run it before you know. The same goes for all the
>> purgatory code.
>>
>> This is why I think its better to do this in the kernel before we exit to
>> purgatory, but obviously that doesn't work for kdump.
> 
> I see in an earlier message that the need for sha256 was being discussed
> in another thread. Do either of you happen to have a pointer to that.

https://www.spinics.net/lists/arm-kernel/msg544472.html


Thanks,

James

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: james.morse@arm.com (James Morse)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] arm64: Add enable/disable d-cache support for purgatory
Date: Wed, 14 Dec 2016 12:11:33 +0000	[thread overview]
Message-ID: <585136F5.3070606@arm.com> (raw)
In-Reply-To: <20161214113701.GE17982@leverpostej>

Hi Mark,

On 14/12/16 11:37, Mark Rutland wrote:
> On Wed, Dec 14, 2016 at 11:16:17AM +0000, James Morse wrote:
>> On 14/12/16 10:12, Pratyush Anand wrote:
>>> On Wednesday 14 December 2016 03:08 PM, Pratyush Anand wrote:
>>>>> I would go as far as to generate the page tables at 'kexec -l' time,
>>>>> and only if
>>>>
>>>> Ok..So you mean that I create a new section which will have page table
>>>> entries mapping physicalmemory represented by remaining section, and
>>>> then purgatory can just enable mmu with page table from that section,
>>>> right? Seems doable. can do that.
>>>
>>> I see a problem here. If we create  page table as a new segment then, how can we
>>> verify in purgatory that sha for page table is correct? We need page table
>>> before sha verification start,and we can not rely the page table created by
>>> first kernel until it's sha is verified. So a chicken-egg problem.
>>
>> There is more than one of those! What happens if your sha256 calculation code is
>> corrupted? You have to run it before you know. The same goes for all the
>> purgatory code.
>>
>> This is why I think its better to do this in the kernel before we exit to
>> purgatory, but obviously that doesn't work for kdump.
> 
> I see in an earlier message that the need for sha256 was being discussed
> in another thread. Do either of you happen to have a pointer to that.

https://www.spinics.net/lists/arm-kernel/msg544472.html


Thanks,

James

  reply	other threads:[~2016-12-14 12:11 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-22  4:32 [PATCH 0/2] kexec-tools: arm64: Add dcache enabling facility Pratyush Anand
2016-11-22  4:32 ` Pratyush Anand
2016-11-22  4:32 ` [PATCH 1/2] arm64: Add enable/disable d-cache support for purgatory Pratyush Anand
2016-11-22  4:32   ` Pratyush Anand
2016-11-25 18:30   ` James Morse
2016-11-25 18:30     ` James Morse
2016-12-14  9:38     ` Pratyush Anand
2016-12-14  9:38       ` Pratyush Anand
2016-12-14 10:12       ` Pratyush Anand
2016-12-14 10:12         ` Pratyush Anand
2016-12-14 11:16         ` James Morse
2016-12-14 11:16           ` James Morse
2016-12-14 11:37           ` Mark Rutland
2016-12-14 11:37             ` Mark Rutland
2016-12-14 12:11             ` James Morse [this message]
2016-12-14 12:11               ` James Morse
2016-12-14 12:21             ` Pratyush Anand
2016-12-14 12:21               ` Pratyush Anand
2016-12-14 13:44               ` Mark Rutland
2016-12-14 13:44                 ` Mark Rutland
2016-12-14 14:13                 ` Pratyush Anand
2016-12-14 14:13                   ` Pratyush Anand
2016-12-14 12:13           ` Pratyush Anand
2016-12-14 12:13             ` Pratyush Anand
2016-12-14 11:16       ` James Morse
2016-12-14 11:16         ` James Morse
2016-12-14 11:28         ` Mark Rutland
2016-12-14 11:28           ` Mark Rutland
2016-11-22  4:32 ` [PATCH 2/2] arm64: Pass RAM boundary and enable-dcache flag to purgatory Pratyush Anand
2016-11-22  4:32   ` Pratyush Anand
2016-11-22 18:57   ` Geoff Levand
2016-11-22 18:57     ` Geoff Levand
2016-11-23  1:46     ` Pratyush Anand
2016-11-23  1:46       ` Pratyush Anand
2016-11-23  2:03       ` Dave Young
2016-11-23  2:03         ` Dave Young
2016-11-23  2:11         ` Pratyush Anand
2016-11-23  2:11           ` Pratyush Anand
2016-11-23  8:08           ` Simon Horman
2016-11-23  8:08             ` Simon Horman
2016-11-23  8:17             ` Pratyush Anand
2016-11-23  8:17               ` Pratyush Anand
2016-11-22 18:56 ` [PATCH 0/2] kexec-tools: arm64: Add dcache enabling facility Geoff Levand
2016-11-22 18:56   ` Geoff Levand
2016-11-23  1:39   ` Pratyush Anand
2016-11-23  1:39     ` Pratyush Anand
2016-11-25 18:30   ` James Morse
2016-11-25 18:30     ` James Morse

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=585136F5.3070606@arm.com \
    --to=james.morse@arm.com \
    --cc=geoff@infradead.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=panand@redhat.com \
    /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.