linux-kernel - Re: Documentation: livepatch: add section about arch-specific code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160818180610.GB8272@packer-debian-8-amd64.digitalocean.com>
Date:   Thu, 18 Aug 2016 14:06:10 -0400
From:   Jessica Yu <jeyu@...hat.com>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Josh Poimboeuf <jpoimboe@...hat.com>,
        Miroslav Benes <mbenes@...e.cz>,
        Jiri Kosina <jikos@...nel.org>,
        Chris J Arges <chris.j.arges@...onical.com>,
        Eugene Shatokhin <eugene.shatokhin@...alab.ru>,
        live-patching@...r.kernel.org, x86@...nel.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Documentation: livepatch: add section about arch-specific code

+++ Petr Mladek [18/08/16 11:57 +0200]:
>On Wed 2016-08-17 20:58:30, Jessica Yu wrote:
>> Document usage of arch-specific elf sections in livepatch as well
>> as implementation of arch-specific code.
>>
>> Signed-off-by: Jessica Yu <jeyu@...hat.com>
>> ---
>>  Documentation/livepatch/module-elf-format.txt | 20 ++++++++++++++++----
>>  1 file changed, 16 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/livepatch/module-elf-format.txt b/Documentation/livepatch/module-elf-format.txt
>> index eedbdcf..02bfafa 100644
>> --- a/Documentation/livepatch/module-elf-format.txt
>> +++ b/Documentation/livepatch/module-elf-format.txt
>> @@ -25,7 +25,8 @@ Table of Contents
>>         3.3.2 Required name format
>>         3.3.3 Example livepatch symbol names
>>         3.3.4 Example `readelf --symbols` output
>> -4. Symbol table and Elf section access
>> +4. Architecture-specific sections
>> +5. Symbol table and Elf section access
>>
>>  ----------------------------
>>  0. Background and motivation
>> @@ -46,7 +47,7 @@ architecture.
>>
>>  Since apply_relocate_add() requires access to a module's section header
>>  table, symbol table, and relocation section indices, Elf information is
>> -preserved for livepatch modules (see section 4). Livepatch manages its own
>> +preserved for livepatch modules (see section 5). Livepatch manages its own
>>  relocation sections and symbols, which are described in this document. The
>>  Elf constants used to mark livepatch symbols and relocation sections were
>>  selected from OS-specific ranges according to the definitions from glibc.
>> @@ -117,7 +118,7 @@ also possible for a livepatch module to have no livepatch relocation
>>  sections, as in the case of the sample livepatch module (see
>>  samples/livepatch).
>>
>> -Since Elf information is preserved for livepatch modules (see Section 4), a
>> +Since Elf information is preserved for livepatch modules (see Section 5), a
>>  livepatch relocation section can be applied simply by passing in the
>>  appropriate section index to apply_relocate_add(), which then uses it to
>>  access the relocation section and apply the relocations.
>> @@ -292,8 +293,19 @@ Symbol table '.symtab' contains 127 entries:
>>  [*] Note that the 'Ndx' (Section index) for these symbols is SHN_LIVEPATCH (0xff20).
>>      "OS" means OS-specific.
>>
>> +---------------------------------
>> +4. Architecture-specific sections
>> +---------------------------------
>> +Architectures may override arch_klp_init_object_loaded() to perform
>> +additional arch-specific tasks when a target module loads, such as applying
>> +arch-specific sections. On x86 for example, we must apply per-object
>> +.altinstructions and .parainstructions sections when a target module loads.
>> +These sections can be prefixed with ".klp.arch.$objname." so that they can
>                  ^^^
>
>I would personally use "must" instead of "can". Or replace "can be prefixed"
>with "are prefixed".

Agreed, poor word choice there. Let's just swap "can" with "must."

Jessica