Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

changed section .rela.rodata not selected for inclusion #702

Closed
joe-lawrence opened this issue May 4, 2017 · 1 comment · Fixed by #808
Closed

changed section .rela.rodata not selected for inclusion #702

joe-lawrence opened this issue May 4, 2017 · 1 comment · Fixed by #808

Comments

@joe-lawrence
Copy link
Contributor

patch.txt

I'm testing a patch (see attached) for CVE-2014-3690 against RHEL7.3 GA + kernel-3.10.0-200.el7.x86_64 (rebuilt by RHEL7.3 GA toolset) and was running into the following kpatch-build error:

Using cache at /root/.kpatch/src
Testing patch file
checking file arch/x86/kvm/vmx.c
Reading special section data
Building original kernel
Building patched kernel
Extracting new and modified ELF sections
ERROR: vmx.o: 1 unsupported section change(s)
vmx.o: new function: vmx_set_constant_host_state
vmx.o: changed function: prepare_vmcs02.constprop.94
vmx.o: changed function: vmx_create_vcpu
vmx.o: changed function: vmx_vcpu_run
vmx.o: changed section .rela.rodata not selected for inclusion
/usr/local/libexec/kpatch/create-diff-object: unreconcilable difference
ERROR: 1 error(s) encountered. Check /root/.kpatch/build.log for more details.

readelf does indeed show a difference in this section between the original and
patched object files:

% readelf -x 395 $ORIG

Hex dump of section '.rela.rodata':
  0x00000000 00000000 00000000 01000000 c8010000 ................
  0x00000010 b9010000 00000000                   ........


% readelf -x 395 $PATCHED

Hex dump of section '.rela.rodata':
  0x00000000 00000000 00000000 01000000 c8010000 ................
  0x00000010 e9010000 00000000                   ........
             ^
@telala
Copy link

telala commented Jan 10, 2018

got the same problem:
patch:

static void __noclone vmx_vcpu_run(struct kvm_vcpu *vcpu)
 {
        struct vcpu_vmx *vmx = to_vmx(vcpu);
        unsigned long debugctlmsr, cr4;
       +       unsigned long vmx_return_new = 0;


        /* Record the guest's net vcpu time for enforced NMI injections. */
        if (unlikely(!cpu_has_virtual_nmis() && vmx->soft_vnmi_blocked))
@@ -8534,6 +8601,7 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu *vcpu)
        if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP)
                vmx_set_interrupt_shadow(vcpu, 0);



    +   vmcs_writel(HOST_RIP, vmx_return_new);
        atomic_switch_perf_msrs(vmx);
        debugctlmsr = get_debugctlmsr();

kpatch-build output:
Using source directory at /data/kvm3.0_kernel
chenxg: here....
Testing patch file(s)
Reading special section data
Building original kernel
Building patched kernel
Extracting new and modified ELF sections
ERROR: vmx.o: 1 unsupported section change(s)
vmx.o: changed function: vmx_vcpu_run
vmx.o: changed section .rela.rodata not selected for inclusion
/data/kpatch/kpatch-build/create-diff-object: unreconcilable difference
ERROR: 1 error(s) encountered. Check /root/.kpatch/build.log for more details.

jpoimboe added a commit to jpoimboe/kpatch that referenced this issue Mar 22, 2018
kpatch_include_symbol() is confusing.  Refactor it:

- Remove the "inclusion tree" debug messages.  I never use them, and
  they just help make the code more confusing and the debug output more
  cluttered.

- Split it up into two functions: kpatch_include_symbol() and
  kpatch_include_section(), so that kpatch_include_section() can be used
  elsewhere.

- Call kpatch_include_section() from kpatch_include_standard_elements().
  This covertly fixes dynup#702, by also including the .rela.rodata section.

- Add a bunch of comments to clarify some of the trickier points.

Fixes dynup#702.
Fixes dynup#807.

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants