search

dynup / kpatch

kpatch - live kernel patching
GNU General Public License v2.0
1.44k stars 300 forks source link

fair.o: changed section .data..read_mostly not selected for inclusion #1399

Open wardenjohn opened 2 weeks ago

wardenjohn commented 2 weeks ago

When I use a patch to build a livepatch, I found this error happens:

fair.o: changed section .data..read_mostly not selected for inclusion

I looked into the code of create-diff-object and found that if one section is taged as CHANGED but this sec->include is not set, this error will raise.

Which section will be included? I found the section and symbol will be included:

  1. standard element. eg, .shstrtab, .strtab, etc.
  2. string literal section. For example,.rodata.* section or .str section
  3. call back sections
  4. force sections
  5. debug sections

I am sorry that I have some base concept question to ask:

  1. for the section which will call kpatch_include_section to include, the symbol type is STT_SECTION and the section status is CHANGED. But why this problem raised? From my point of view, since this section is not a section as mentioned above, it seems to be a normal section. It changed, but why not included?
  2. I found kpatch-build have function to reorder symbols. What is the reason why we need to reorder the symbols?
  3. I found that kpatch-build need the information of some exported struct size link alt_instr size,jump_str size. I seems not to find the usage of these structer size in create-diff-object while create-diff-object read it **_group_size functions. How to use it?

Thanks for answering my question, and thank your time, again.

Regards, Wardenjohn

joe-lawrence commented 2 weeks ago

Hi @wardenjohn

  1. Why we don't include .data..read_mostly section changes? kpatch_verify_patchability() specifically looks for changes to any ".data" prefixed section (amongst others). Changes to data sections are not supported as kpatch can't safely apply those changes to a live system. For example, how to modify a static variable? There may be mutual exclusion issues, data type changes, etc.
  2. Why do we need kpatch_reorder_symbols()? kpatch-build generates a new elf output file comprised of original vs. patched object code differences. This new file may have altered section, relocations, symbol information, etc. This function sorts the symbols them as per ld linker (and probably ELF spec) expectations.
  3. How does kpatch-build use kernel struct sizes in special sections? Just look for the "group_size" variable across create-diff-object.c.
wardenjohn commented 2 weeks ago

Thank you joe @joe-lawrence ! I am still learning the techology of kpatch-build and still a long way to go. Hoping can become a member of this community as fast as possable! :)

wardenjohn commented 2 weeks ago

@joe-lawrence I have some futher question for answer.

For answer 1, kpatch_verify_patchability() will make sure .data.* section will not be included. However, changed section is not selected for inclusion is raise in this case. It seems that this section is changed but the include flag is not set. It is not the situation that kpatch_verify_patchability not allow any data section change.

In my scenario, this section's flag is not set to be include even it is changed. Is that a bug?

joe-lawrence commented 1 week ago

Hi @wardenjohn : can you (re)build this patch with kpatch-build -d debugging option, then create and attach a tarball of the following files from ~/.kpatch (most of these should be under ~/.kpatch/tmp/...)

Seeing the input kpatch would be helpful as well if you can post that. (GitHub should let you attach files directly in an issue comment.) Thanks.

wardenjohn commented 5 days ago

Hi joe, @joe-lawrence I will rebuild for a check. But I am not sure my organization if they allow me to up load the built object. I need some time to check.