From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Julien Grall <julien.grall@arm.com>
Cc: xen-devel@lists.xenproject.org, ross.lagerwall@citrix.com,
sstabellini@kernel.org
Subject: Re: [PATCH v4 03/16] arm: poison initmem when it is freed.
Date: Mon, 19 Sep 2016 10:19:35 -0400 [thread overview]
Message-ID: <20160919141928.GA9860@localhost.localdomain> (raw)
In-Reply-To: <e771e5ee-0295-9288-5206-486f54f4e19c@arm.com>
On Mon, Sep 19, 2016 at 11:35:57AM +0200, Julien Grall wrote:
> Hi Konrad,
>
> On 16/09/2016 18:38, Konrad Rzeszutek Wilk wrote:
> > The current byte sequence is '0xcc' which makes sense on x86,
> > but on ARM it is:
> >
> > cccccccc stclgt 12, cr12, [ip], {204} ; 0xcc
> >
> > Picking something more ARM applicable such as:
> >
> > efefefef svc 0x00efefef
> >
> > Creates a nice crash if one executes that code:
> > (XEN) CPU1: Unexpected Trap: Supervisor Call
> >
> > But unfortunatly that may not be a good choice either as in the future
>
> s/unfortunatly/unfortunately/
>
> > we may want to implement support for it.
> >
> > Julien suggested that we use a 4-byte insn instruction instead
> > of trying to work with one byte.
> >
> > As such on ARM 32 we use the udf instruction (see A8.8.247
> > in ARM DDI 0406C.c) and on ARM 64 use the AARCH64_BREAK_FAULT
> > instruction (aka brk instruction).
> >
> > We don't have to worry about Thumb code so this instruction
> > is a safe to execute.
> >
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> > Cc: Julien Grall <julien.grall@arm.com>
> > Cc: Stefano Stabellini <sstabellini@kernel.org>
> >
> > v3: New submission
> > v4: Instead of using 0xef, use specific insn for architectures.
> > ---
> > xen/arch/arm/mm.c | 17 ++++++++++++++++-
> > 1 file changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> > index 07e2037..438bed7 100644
> > --- a/xen/arch/arm/mm.c
> > +++ b/xen/arch/arm/mm.c
> > @@ -994,8 +994,23 @@ void free_init_memory(void)
> > {
> > paddr_t pa = virt_to_maddr(__init_begin);
> > unsigned long len = __init_end - __init_begin;
> > + uint32_t insn;
> > + unsigned int i, nr = len / sizeof(insn);
> > +
> > set_pte_flags_on_range(__init_begin, len, mg_rw);
> > - memset(__init_begin, 0xcc, len);
> > +#ifdef CONFIG_ARM_32
> > + /* udf instruction i.e (see A8.8.247 in ARM DDI 0406C.c) */
> > + insn = 0xe7f000f0;
> > +#else
> > + insn = AARCH64_BREAK_FAULT;
> > +#endif
> > + for ( i = 0; i < nr; i++ )
> > + *(__init_begin + i) = insn;
>
> __init_begin is char[], so you will only copy the first byte of the
> instruction.
>
> And because of nr = len / sizeof(insn) only 1/4 of the initmem will be
> poisoned.
>
> So this should be something like:
>
> uint32_t *p = (uint32_t *)__init_begin;
> for ( i = 0; i < nr; i++)
> *(p + i) = insn;
>
Yes of course!
> > +
> > + nr = len % sizeof(insn);
> > + if ( nr )
> > + memset(__init_begin + len - nr, 0xcc, nr);
>
> I am wondering if we should instead align __init_end to 4-byte. With a
> BUILD_BUG_ON in the code to check this assumption.
The __init_end is already aligned:
175 . = ALIGN(STACK_SIZE);
176 __init_end = .;
So we are good there, but I do like the BUILD_BUG_ON. Let me do that.
>
> Any opinions?
>
> > +
> > set_pte_flags_on_range(__init_begin, len, mg_clear);
> > init_domheap_pages(pa, pa + len);
> > printk("Freed %ldkB init memory.\n", (long)(__init_end-__init_begin)>>10);
> >
>
> Regards,
>
> --
> Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-09-19 14:20 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-16 16:38 [PATCH v4] Livepatch for ARM 64 and 32 Konrad Rzeszutek Wilk
2016-09-16 16:38 ` [PATCH v4 01/16] arm/x86/common: Add HAS_[ALTERNATIVE|EX_TABLE] Konrad Rzeszutek Wilk
2016-09-19 9:09 ` Jan Beulich
2016-09-19 9:26 ` Julien Grall
2016-09-19 14:04 ` Konrad Rzeszutek Wilk
2016-09-19 14:09 ` Julien Grall
2016-09-19 14:43 ` Konrad Rzeszutek Wilk
2016-09-16 16:38 ` [PATCH v4 02/16] livepatch: Reject payloads with .alternative or .ex_table if support is not built-in Konrad Rzeszutek Wilk
2016-09-16 16:38 ` [PATCH v4 03/16] arm: poison initmem when it is freed Konrad Rzeszutek Wilk
2016-09-19 9:35 ` Julien Grall
2016-09-19 14:19 ` Konrad Rzeszutek Wilk [this message]
2016-09-16 16:38 ` [PATCH v4 04/16] livepatch: Initial ARM64 support Konrad Rzeszutek Wilk
2016-09-19 10:26 ` Julien Grall
2016-09-19 14:33 ` Konrad Rzeszutek Wilk
2016-09-20 9:40 ` Julien Grall
2016-09-16 16:38 ` [PATCH v4 05/16] livepatch: ARM/x86: Check displacement of old_addr and new_addr Konrad Rzeszutek Wilk
2016-09-19 9:19 ` Jan Beulich
2016-09-19 13:12 ` Julien Grall
2016-09-16 16:38 ` [PATCH v4 06/16] livepatch: ARM 32|64: Ignore mapping symbols: $[d, a, x] Konrad Rzeszutek Wilk
2016-09-16 16:38 ` [PATCH v4 07/16] livepatch/arm/x86: Check payload for for unwelcomed symbols Konrad Rzeszutek Wilk
2016-09-19 9:27 ` Jan Beulich
2016-09-19 13:33 ` Julien Grall
2016-09-19 14:11 ` Jan Beulich
2016-09-19 14:13 ` Julien Grall
2016-09-19 14:48 ` Jan Beulich
2016-09-19 17:32 ` Konrad Rzeszutek Wilk
2016-09-20 7:00 ` Jan Beulich
2016-09-20 9:44 ` Julien Grall
2016-09-16 16:38 ` [PATCH v4 08/16] livepatch: Move test-cases to their own sub-directory in test Konrad Rzeszutek Wilk
2016-09-16 16:58 ` Konrad Rzeszutek Wilk
2016-09-16 16:38 ` [PATCH v4 09/16] livepatch: tests: Make them compile under ARM64 Konrad Rzeszutek Wilk
2016-09-19 13:35 ` Julien Grall
2016-09-16 16:38 ` [PATCH v4 10/16] livepatch: x86, ARM, alternative: Expose FEATURE_LIVEPATCH Konrad Rzeszutek Wilk
2016-09-19 13:47 ` Julien Grall
2016-09-16 16:38 ` [PATCH v4 11/16] xen/arm32: Add an helper to invalidate all instruction caches Konrad Rzeszutek Wilk
2016-09-19 14:24 ` Julien Grall
2016-09-16 16:38 ` [PATCH v4 12/16] bug/x86/arm: Align bug_frames sections Konrad Rzeszutek Wilk
2016-09-19 9:29 ` Jan Beulich
2016-09-19 14:34 ` Julien Grall
2016-09-19 14:35 ` Julien Grall
2016-09-19 20:19 ` Konrad Rzeszutek Wilk
2016-09-19 20:26 ` Konrad Rzeszutek Wilk
2016-09-20 9:46 ` Julien Grall
2016-09-16 16:38 ` [PATCH v4 13/16] livepatch: Initial ARM32 support Konrad Rzeszutek Wilk
2016-09-19 14:39 ` Julien Grall
2016-09-16 16:38 ` [PATCH v4 14/16] livepatch, arm[32|64]: Share arch_livepatch_revert_jmp Konrad Rzeszutek Wilk
2016-09-19 14:43 ` Julien Grall
2016-09-16 16:38 ` [PATCH v4 15/16] livepatch: arm[32, 64], x86: NOP test-case Konrad Rzeszutek Wilk
2016-09-16 16:38 ` [PATCH v4 16/16] livepatch: In xen_nop test-case remove the .bss and .data sections Konrad Rzeszutek Wilk
2016-09-19 9:32 ` Jan Beulich
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=20160919141928.GA9860@localhost.localdomain \
--to=konrad.wilk@oracle.com \
--cc=julien.grall@arm.com \
--cc=ross.lagerwall@citrix.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).