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-next>] [day] [month] [year] [list]
Date:	Tue, 21 Jun 2011 01:10:57 -0700
From:	Deep Debroy <ddebroy@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: code sections beyond .text skipped from alternatives_smp_module_add

In x86-64, I am running into a scenario with certain kernel modules
where the patching of lock prefix instructions in sections other than
.text (e.g. .exit.text) is not occurring even though the .smp_locks
relocations in the .ko file specify instructions in sections other
than .text for patching. For example (down in the bottom), in
net/bluetooth/rfcomm.ko, we have a couple of entries in .exit.text for
patching. However, when I look in the memory page containing the
.exit.text section in a uni processor system, it doesn't appear the
lock prefix instructions in .exit.text were patched with NOPs the same
way other instructions from the .text section in the same page
underwent patching. This creates a subtle inconsistency where a page
contains the end of the .text section along with the .exit.text
section - lock prefixes in instructions from the former section gets
patched per .smp_locks entries while that doesn't happen for the
latter within the same page.

Looking at the code, in module_finalize for x86, only .text seems to
be getting picked for the patching of lock prefixes while other
sections such as .exit.text or .init.text are not. Is there a reason
we skip the other *.text code sections from the lock patches? Would
making the application of the patching of lock prefixes generic across
all code sections (rather than just .text) make sense?

Thanks,
Deep

            for (s = sechdrs; s < sechdrs + hdr->e_shnum; s++) {
                    if (!strcmp(".text", secstrings + s->sh_name))
                            text = s;
                    ...
                    if (!strcmp(".smp_locks", secstrings + s->sh_name))
                            locks = s;
                    ...
            }

            if (locks && text) {
                    void *lseg = (void *)locks->sh_addr;
                    void *tseg = (void *)text->sh_addr;
                    alternatives_smp_module_add(me, me->name,
                                                lseg, lseg + locks->sh_size,
                                                tseg, tseg + text->sh_size);
            }



> objdump -r kernel/net/bluetooth/rfcomm/rfcomm.ko

RELOCATION RECORDS FOR [.smp_locks]:
OFFSET           TYPE              VALUE
0000000000000000 R_X86_64_64       .text+0x00000000000000ac
0000000000000008 R_X86_64_64       .exit.text+0x0000000000000023
0000000000000010 R_X86_64_64       .exit.text+0x0000000000000034
0000000000000018 R_X86_64_64       .text+0x0000000000000619
0000000000000020 R_X86_64_64       .text+0x000000000000061d
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ