Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1644659 > unrolled thread
| Started by | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| First post | 2017-05-18 17:10 +0200 |
| Last post | 2017-05-18 17:20 +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.
Re: [PATCH v2] misc: sram-exec: Use aligned fncpy instead of memcpy Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-05-18 17:10 +0200
Re: [PATCH v2] misc: sram-exec: Use aligned fncpy instead of memcpy Dave Gerlach <d-gerlach@ti.com> - 2017-05-18 17:20 +0200
| From | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2017-05-18 17:10 +0200 |
| Subject | Re: [PATCH v2] misc: sram-exec: Use aligned fncpy instead of memcpy |
| Message-ID | <tIvdU-4qH-15@gated-at.bofh.it> |
On Mon, Apr 10, 2017 at 09:52:47AM -0500, Dave Gerlach wrote:
> Currently the sram-exec functionality, which allows allocation of
> executable memory and provides an API to move code to it, is only
> selected in configs for the ARM architecture. Based on commit
> 5756e9dd0de6 ("ARM: 6640/1: Thumb-2: Symbol manipulation macros for
> function body copying") simply copying a C function pointer address
> using memcpy without consideration of alignment and Thumb is unsafe on
> ARM platforms.
>
> The aforementioned patch introduces the fncpy macro which is a safe way
> to copy executable code on ARM platforms, so let's make use of that here
> rather than the unsafe plain memcpy that was previously used by
> sram_exec_copy. Now sram_exec_copy will move the code to "dst" and
> return an address that is guaranteed to be safely callable.
>
> In the future, architectures hoping to make use of the sram-exec
> functionality must define an fncpy macro just as ARM has done to
> guarantee or check for safe copying to executable memory before allowing
> the arch to select CONFIG_SRAM_EXEC.
>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
> Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> Acked-by: Tony Lindgren <tony@atomide.com>
Can you rebase this and resend as it doesn't apply to the tree right now
:(
thanks,
greg k-h
[toc] | [next] | [standalone]
| From | Dave Gerlach <d-gerlach@ti.com> |
|---|---|
| Date | 2017-05-18 17:20 +0200 |
| Message-ID | <tIvnz-4vr-7@gated-at.bofh.it> |
| In reply to | #1644659 |
On 05/18/2017 10:01 AM, Greg Kroah-Hartman wrote:
> On Mon, Apr 10, 2017 at 09:52:47AM -0500, Dave Gerlach wrote:
>> Currently the sram-exec functionality, which allows allocation of
>> executable memory and provides an API to move code to it, is only
>> selected in configs for the ARM architecture. Based on commit
>> 5756e9dd0de6 ("ARM: 6640/1: Thumb-2: Symbol manipulation macros for
>> function body copying") simply copying a C function pointer address
>> using memcpy without consideration of alignment and Thumb is unsafe on
>> ARM platforms.
>>
>> The aforementioned patch introduces the fncpy macro which is a safe way
>> to copy executable code on ARM platforms, so let's make use of that here
>> rather than the unsafe plain memcpy that was previously used by
>> sram_exec_copy. Now sram_exec_copy will move the code to "dst" and
>> return an address that is guaranteed to be safely callable.
>>
>> In the future, architectures hoping to make use of the sram-exec
>> functionality must define an fncpy macro just as ARM has done to
>> guarantee or check for safe copying to executable memory before allowing
>> the arch to select CONFIG_SRAM_EXEC.
>>
>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>> Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
>> Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>> Acked-by: Tony Lindgren <tony@atomide.com>
>
> Can you rebase this and resend as it doesn't apply to the tree right now
> :(
>
Resent as v3 based on v4.12-rc1 and with Acks from v2 added, thanks.
Regards,
Dave
> thanks,
>
> greg k-h
>
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web