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

Groups > linux.kernel > #1464864 > unrolled thread

[PATCH v3 3/3] Documentation: livepatch: add section about arch-specific code

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

  [PATCH v3 3/3] Documentation: livepatch: add section about arch-specific code Jessica Yu <jeyu@redhat.com> - 2016-08-18 03:00 +0200
    Re: [PATCH v3 3/3] Documentation: livepatch: add section about  arch-specific code Petr Mladek <pmladek@suse.com> - 2016-08-18 12:00 +0200
      Re: Documentation: livepatch: add section about arch-specific code Jessica Yu <jeyu@redhat.com> - 2016-08-19 04:00 +0200

#1464864 — [PATCH v3 3/3] Documentation: livepatch: add section about arch-specific code

Document usage of arch-specific elf sections in livepatch as well
as implementation of arch-specific code.

Signed-off-by: Jessica Yu <jeyu@redhat.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
+be easily identified when iterating through a patch module's Elf sections
+(See arch/x86/kernel/livepatch.c for a complete example).
+
 --------------------------------------
-4. Symbol table and Elf section access
+5. Symbol table and Elf section access
 --------------------------------------
 A livepatch module's symbol table is accessible through module->symtab.
 
-- 
2.5.5

[toc] | [next] | [standalone]

#1465062 — Re: [PATCH v3 3/3] Documentation: livepatch: add section about arch-specific code

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@redhat.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".

Otherwise, it looks fine.

Reviewed-by: Petr Mladek <pmladek@suse.com>

Best Regards,
Petr

[toc] | [prev] | [next] | [standalone]

#1465856 — 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@redhat.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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web