Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1385529 > unrolled thread

Re: [PATCH 1/2] ARM: PIE infrastructure

Started byAlexandre Belloni <alexandre.belloni@free-electrons.com>
First post2016-04-23 01:20 +0200
Last post2016-04-27 21:50 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH 1/2] ARM: PIE infrastructure Alexandre Belloni <alexandre.belloni@free-electrons.com> - 2016-04-23 01:20 +0200
    Re: [PATCH 1/2] ARM: PIE infrastructure Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-04-27 21:50 +0200

#1385529 — Re: [PATCH 1/2] ARM: PIE infrastructure

FromAlexandre Belloni <alexandre.belloni@free-electrons.com>
Date2016-04-23 01:20 +0200
SubjectRe: [PATCH 1/2] ARM: PIE infrastructure
Message-ID<rqSwG-1vv-17@gated-at.bofh.it>
On 04/04/2016 at 11:00:52 +0100, Russell King - ARM Linux wrote :
> > +	/* Copy chunk specific code/data */
> > +	fncpy((char *)chunk->addr, code_start, code_sz);
> 
> Sorry, NAK.  This abuses fncpy().  There is extensive documentation on
> the proper use of this in asm/fncpy.h, and anything that does not
> conform, or which uses memcpy() to copy functions, gets an immediate
> NAK from me.  fncpy() exists to avoid people doing broken things, and
> it's written in such a way to help people get it right.

Well, do you want me to iterate and use fncpy on all the functions from
the generated binary?

I'm not sure this is necessary as the generated binary is self contained
and doing so will force me to also ensure the offsets are kept the same.
Doing only one copy is much more convenient. However, I still need to
ensure the destination address is properly 8-byte aligned and the
flush_icache_range().
I understand this is abusing fncpy() but it does want I need (still, I'm
planning to avoid the BUG() by always passing a properly aligned
destination address).

I've fixed the issue with big endian that was reported byt the kbuild
test robot and I'd like a bit more advice on how to go forward, thanks!

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[toc] | [next] | [standalone]


#1389533

FromRussell King - ARM Linux <linux@arm.linux.org.uk>
Date2016-04-27 21:50 +0200
Message-ID<rsDDc-6TR-5@gated-at.bofh.it>
In reply to#1385529
On Sat, Apr 23, 2016 at 01:15:03AM +0200, Alexandre Belloni wrote:
> Well, do you want me to iterate and use fncpy on all the functions from
> the generated binary?

No, because that will break the image too.

> I'm not sure this is necessary as the generated binary is self contained
> and doing so will force me to also ensure the offsets are kept the same.
> Doing only one copy is much more convenient. However, I still need to
> ensure the destination address is properly 8-byte aligned and the
> flush_icache_range().

What you need to do is to immitate being an ELF loader - in other words,
copy the blob according to the alignment rules of the blob (which may be
greater than 8-byte alignment) and use the symbol table to find the
functions and the type of the function (ARM vs ELF).

> I understand this is abusing fncpy() but it does want I need (still, I'm
> planning to avoid the BUG() by always passing a properly aligned
> destination address).

Yea yea yea, such arguments don't wash with me, sorry.  The "but it does
what I need" is total bollocks, sorry.  fncpy() is designed for a
purpose, and what you're doing is an abuse of it, one which I will not
stand for for the sake of long term maintainability.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web