From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.global.frontbridge.com", Issuer "Microsoft Secure Server Authority" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 6E0BFB6EF3 for ; Fri, 25 May 2012 06:05:29 +1000 (EST) Received: from mail163-va3 (localhost [127.0.0.1]) by mail163-va3-R.bigfish.com (Postfix) with ESMTP id 141F52205C2 for ; Thu, 24 May 2012 20:05:15 +0000 (UTC) Received: from VA3EHSMHS027.bigfish.com (unknown [10.7.14.239]) by mail163-va3.bigfish.com (Postfix) with ESMTP id 583B820004F for ; Thu, 24 May 2012 20:05:12 +0000 (UTC) From: Wrobel Heinz-R39252 To: "linuxppc-dev@lists.ozlabs.org" Subject: module loading issue/flaw in busy memory situation? Date: Thu, 24 May 2012 20:05:19 +0000 Message-ID: <192298D25D96A042975E372855100DB70FC8C5@039-SN2MPN1-011.039d.mgd.msft.net> Content-Type: multipart/alternative; boundary="_000_192298D25D96A042975E372855100DB70FC8C5039SN2MPN1011039d_" MIME-Version: 1.0 List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --_000_192298D25D96A042975E372855100DB70FC8C5039SN2MPN1011039d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, let's assume a module gets loaded into an already busy system, and the ".in= it.text" section with the __init function gets loaded into one memory regio= n, and the normal ".text" section gets loaded into a totally different memo= ry region. Now assume that both regions are >32MB apart in addressing, so that a call = from the __init .init.text function to any function in .text requires a tra= mpoline as set up by the do_plt_call() function in arch/kernel/module*.c So far so good for user code. Now assume that the __init function is not trivial and will require registe= r save/restore functions in prologue/epilogue with such calls generated by = gcc, e.g., the __init function calls _rest32gpr_28_x() in the epilogue. Thi= s restore functions however is in the .text section due to the static link = of the normal libs. Now we have the __init function calling the trampoline, which is destroying= r11. The trampoline is then jumping to the register restore function which= relies on r11 still being intact, which it now isn't anymore. Net result is a crash because the trampoline ABI conflicts with the registe= r restore ABI and you get a case of garbage in leading to garbage out. This situation has apparently occurred based on the debug results I have he= re. In the general case of module development it seems unpredictable if gcc wil= l actually call a register restore function from the __init function, or if= the sections get loaded to require a trampoline, so for any non-trivial fu= nction in non-trivial memory setups, a crash would have to be expected, dep= ending on the time of day and moon phase when the module gets loaded. Is this a fundamental flaw in the interaction of the module section use spe= cification and the module load mechanism with the ABI definition? Or am I missing some incorrect setup or requirement for __init functions th= at I should deal with? Thanks, Heinz --_000_192298D25D96A042975E372855100DB70FC8C5039SN2MPN1011039d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

let’s assume a module gets loaded into an alre= ady busy system, and the “.init.text” section with the __init f= unction gets loaded into one memory region, and the normal “.textR= 21; section gets loaded into a totally different memory region.<= /p>

Now assume that both regions are >32MB apart in a= ddressing, so that a call from the __init .init.text function to any functi= on in .text requires a trampoline as set up by the do_plt_call() function i= n arch/kernel/module*.c

So far so good for user code.

Now assume that the __init function is not trivial a= nd will require register save/restore functions in prologue/epilogue with s= uch calls generated by gcc, e.g., the __init function calls _rest32gpr_28_x() in the epilogue. This restore functions however is in the .text section due to the static link of the no= rmal libs.

Now we have the __init function calling the trampoli= ne, which is destroying r11. The trampoline is then jumping to the register= restore function which relies on r11 still being intact, which it now isn&= #8217;t anymore.

Net result is a crash because the trampoline ABI con= flicts with the register restore ABI and you get a case of garbage in leadi= ng to garbage out.

This situation has apparently occurred based on the = debug results I have here.

In the general case of module development it seems u= npredictable if gcc will actually call a register restore function from the= __init function, or if the sections get loaded to require a trampoline, so= for any non-trivial function in non-trivial memory setups, a crash would have to be expected, depending on the time of= day and moon phase when the module gets loaded.

Is this a fundamental flaw in the interaction of the= module section use specification and the module load mechanism with the AB= I definition?

Or am I missing some incorrect setup or requirement = for __init functions that I should deal with?

Thanks,

Heinz

--_000_192298D25D96A042975E372855100DB70FC8C5039SN2MPN1011039d_-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "demumfd002.nsn-inter.net", Issuer "VeriSign Class 3 Secure Server CA - G3" (not verified)) by ozlabs.org (Postfix) with ESMTPS id A33CDB6EE6 for ; Fri, 25 May 2012 18:14:13 +1000 (EST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q4P7uOT3012404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 25 May 2012 09:56:24 +0200 Received: from mango.dwdm.mu.nsn-intra.net ([10.148.33.2]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q4P7uNIm009778 for ; Fri, 25 May 2012 09:56:24 +0200 Message-ID: <4FBF3B17.1040106@nsn.com> Date: Fri, 25 May 2012 09:56:07 +0200 From: Steffen Rumler MIME-Version: 1.0 To: linuxppc-dev@lists.ozlabs.org Subject: Re: module loading issue/flaw in busy memory situation? Content-Type: text/plain; charset=ISO-8859-15; format=flowed List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi, The basic question is, has the GPR r11 a dedicated function (to point to the previous stack frame) or is it still a volatile GPR, according to EABI definition ? In the case of a dedicated function was assigned, the trampoline code generation in arch/powerpc/kernel/module_32.c must be corrected. I'd suggest to use r12 instead of r11, in this case. Best Regards Steffen