[dpdk-dev] section mismatch warnings
Thanks Neil and Sergio for your info. The mismatch warning did not show up with normal kernel but in the kernel with PAX grsecurity patches as PaX team enhanced writeable function pointer detection in patches out in this link. http://en.wikibooks.org/wiki/Grsecurity/Configuring_and_Installing_grsecuri ty#Compilation_Differences --- the extra section mismatches are due to my Pax changes, i explicitly added detection for writeable function pointers which are potential exploit targets, just to know how many of them there are. we've been eliminating some of them already but this work will never finish. as for what they are in general, a mismatch means an unwanted reference from one section to another. say, accessing init code or data from normal code/data is not good since init sections are freed up on boot, so any reference to them must not exist from permanent sections. --- To reproduce, you just need to patch any supported kernel with grsecurity patches then compile dpdk with it. https://grsecurity.net/download.php Thanks, Michael On 10/7/14 9:46 AM, "Neil Horman" wrote: >On Mon, Oct 06, 2014 at 06:42:04PM +0000, Michael Hu (NSBU) wrote: >> Hi Everyone, >> >> When we enable kernel config CONFIG_DEBUG_SECTION_MISMATCH=y and >>compile DPDK 1.7 with 3.14.17 kernel + gcc 4.8.2, we got lots of >>warnings like these. >> Do we have plan to fix them? If so, please advise on which version. >>Thanks. >> >Seems erroneous. These errors come from referencing symbols between >incompatible sections (e.g. A static function reading a variable that is >in an >__initdata section). But theres nothing like that going on in any of >these >symbols referenced below (and the kernel version shouldn't matter, as >this is >all dpdk internal). It could be old objects in your build from a DPDK >version >where the symbols were in different sections. Do a make clean; git clean >-f -d >Then reconfigure and rebuild. I expect your issue will go away. > >Neil > >> >> >> == Build lib/librte_eal/linuxapp/kni >> cut: /proc/version_signature: No such file or directory >> LD >>/git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/built-i >>n.o >> CC [M] >>/git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio >>.o >> Building modules, stage 2. >> MODPOST 1 modules >> WARNING: >>/git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio >>.o(.data+0x20): Section mismatch in reference from the variable >>igbuio_pci_driver to the function .text:igbuio_pci_probe() >> >> WARNING: >>/git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio >>.o(.data+0x28): Section mismatch in reference from the variable >>igbuio_pci_driver to the function .text:igbuio_pci_remove() >> >> WARNING: >>/git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio >>.o(.data+0x130): Section mismatch in reference from the variable >>dev_attr_max_vfs to the function .text:show_max_vfs() >> >> WARNING: >>/git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio >>.o(.data+0x138): Section mismatch in reference from the variable >>dev_attr_max_vfs to the function .text:store_max_vfs() >> >> CC >>/git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio >>.mod.o >> LD [M] >>/git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio >>.ko >> INSTALL-MODULE igb_uio.ko >> >> LD >>/git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/built-in.o >> CC [M] >>/git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/ixgbe_main. >>o >> CC [M] >>/git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/ixgbe_api.o >> CC [M] >>/git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/ixgbe_commo >>n.o >> CC [M] >>/git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/ixgbe_ethto >>ol.o >> CC [M] >>/git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/ixgbe_82599 >>.o >> CC [M] >>/git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/ixgbe_82598 >>.o >> CC [M] >>/git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/ixgbe_x540. >>o >> CC [M] >>/git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/ixgbe_phy.o >> CC [M] >>/git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/kcompat.o >> CC [M] >>/git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/e1000_82575 >>.o >> CC [M]
[dpdk-dev] dpdk starting issue with descending virtual address allocation in new kernel
Thanks for the info, Bruce. We are using 64bit system. The kernel config that affect this behavior is CONFIG_PAX_RANDMMAP where it is defined as --- config PAX_RANDMMAP bool "Randomize user stack and mmap() bases" default y if GRKERNSEC_CONFIG_AUTO depends on PAX_ASLR select PAX_RANDUSTACK help By saying Y here the kernel will randomize every task's userland stack and use a randomized base address for mmap() requests that do not specify one themselves. The stack randomization is done in two steps where the second one may apply a big amount of shift to the top of the stack and cause problems for programs that want to use lots of memory (more than 2.5 GB if SEGMEXEC is not active, or 1.25 GB when it is). As a result of mmap randomization all dynamically loaded libraries will appear at random addresses and therefore be harder to exploit by a technique where an attacker attempts to execute library code for his purposes (e.g. spawn a shell from an exploited program that is running at an elevated privilege level). Furthermore, if a program is relinked as a dynamic ELF file, its base address will be randomized as well, completing the full randomization of the address space layout. Attacking such programs becomes a guess game. You can find an example of doing this at http://pax.grsecurity.net/et_dyn.tar.gz and practical samples at http://www.grsecurity.net/grsec-gcc-specs.tar.gz . NOTE: you can use the 'chpax' or 'paxctl' utilities to control this feature on a per file basis. --- With this config, DPDK seems not able to start due to change in mmap. Please refer to mmap patches in (search CONFIG_PAX_RANDMMAP) https://grsecurity.net/stable/grsecurity-3.0-3.14.18-201409082127.patch Thanks, Michael On 9/11/14 2:53 AM, "Richardson, Bruce" wrote: >> -Original Message- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Michael Hu (NSBU) >> Sent: Wednesday, September 10, 2014 11:41 PM >> To: dev at dpdk.org >> Subject: [dpdk-dev] dpdk starting issue with descending virtual address >> allocation in new kernel >> >> Hi All, >> >> We have a kernel config question to consult you. >> DPDK failed to start due to mbuf creation issue with new kernel 3.14.17 >>+ >> grsecurity patches. >> We tries to trace down the issue, it seems that the virtual address of >>huge page >> is allocated from high address to low address by kernel where dpdk >>expects it to >> be low to high to think it is as consecutive. See dumped virt address >>bellow. It is >> first 0x71042140, then 0x71042120. Where previously it would be >> 0x71042120 first , then 0x71042140. But they are still >>consecutive. >> >> Initialize Port 0 -- TxQ 1, RxQ 1, Src MAC 00:0c:29:b3:30:db >> Create: Default RX 0:0 - Memory used (MBUFs 4096 x (size 1984 + >>Hdr 64)) + >> 790720 = 8965 KB >> Zone 0: name:, phys:0x6ac0, len:0x2080, >> virt:0x71042140, socket_id:0, flags:0 >> Zone 1: name:, phys:0x6ac02080, len:0x1d10c0, >> virt:0x710421402080, socket_id:0, flags:0 >> Zone 2: name:, phys:0x6ae0, len:0x16, >> virt:0x71042120, socket_id:0, flags:0 >> Zone 3: name:, phys:0x6add3140, len:0x11a00, >> virt:0x7104215d3140, socket_id:0, flags:0 >> Zone 4: name:, phys:0x6ade4b40, len:0x300, >> virt:0x7104215e4b40, socket_id:0, flags:0 >> Zone 5: name:, phys:0x6ade4e80, len:0x200, >> virt:0x7104215e4e80, socket_id:0, flags:0 >> Zone 6: name:, phys:0x6ade5080, len:0x10080, >> virt:0x7104215e5080, socket_id:0, flags:0 >> Segment 0: phys:0x6ac0, len:2097152, virt:0x71042140, >>socket_id:0, >> hugepage_sz:2097152, nchannel:0, nrank:0 >> Segment 1: phys:0x6ae0, len:2097152, virt:0x71042120, >>socket_id:0, >> hugepage_sz:2097152, nchannel:0, nrank:0 >> Segment 2: phys:0x6b00, len:2097152, virt:0x71042100, >>socket_id:0, >> hugepage_sz:2097152, nchannel:0, nrank:0 >> Segment 3: phys:0x6b20, len:2097152, virt:0x710420e0, >>socket_id:0, >> hugepage_sz:2097152, nchannel:0, nrank:0 >> Segment 4: phys:0x6b40, len:2097152, virt:0x710420c0, >>socket_id:0, >> hugepage_sz:2097152, nchannel:0, nrank:0 >> Segment 5: phys:0x6b60, len:2097152, virt:0x710420a0, >>socket_id:0, >> hugepage_sz:2097152, nchannel:0, nrank:0 >> Segment 6: phys:0x6b80, len:2097152, virt:0x71042080, >>socket_id:0, >> hugepage_sz:2097152, nchannel:0, nrank:0 >> Segment 7: phys:0x6ba0, len:2097152, virt:0x71042060, >>socket_id:0, >> hugepage_
[dpdk-dev] dpdk starting issue with descending virtual address allocation in new kernel
Hi All,
We have a kernel config question to consult you.
DPDK failed to start due to mbuf creation issue with new kernel 3.14.17 +
grsecurity patches.
We tries to trace down the issue, it seems that the virtual address of huge
page is allocated from high address to low address by kernel where dpdk expects
it to be low to high to think it is as consecutive. See dumped virt address
bellow. It is first 0x71042140, then 0x71042120. Where previously it
would be 0x71042120 first , then 0x71042140. But they are still
consecutive.
Initialize Port 0 -- TxQ 1, RxQ 1, Src MAC 00:0c:29:b3:30:db
Create: Default RX 0:0 - Memory used (MBUFs 4096 x (size 1984 + Hdr 64))
+ 790720 = 8965 KB
Zone 0: name:, phys:0x6ac0, len:0x2080,
virt:0x71042140, socket_id:0, flags:0
Zone 1: name:, phys:0x6ac02080, len:0x1d10c0,
virt:0x710421402080, socket_id:0, flags:0
Zone 2: name:, phys:0x6ae0, len:0x16,
virt:0x71042120, socket_id:0, flags:0
Zone 3: name:, phys:0x6add3140, len:0x11a00,
virt:0x7104215d3140, socket_id:0, flags:0
Zone 4: name:, phys:0x6ade4b40, len:0x300,
virt:0x7104215e4b40, socket_id:0, flags:0
Zone 5: name:, phys:0x6ade4e80, len:0x200,
virt:0x7104215e4e80, socket_id:0, flags:0
Zone 6: name:, phys:0x6ade5080, len:0x10080,
virt:0x7104215e5080, socket_id:0, flags:0
Segment 0: phys:0x6ac0, len:2097152, virt:0x71042140, socket_id:0,
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 1: phys:0x6ae0, len:2097152, virt:0x71042120, socket_id:0,
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 2: phys:0x6b00, len:2097152, virt:0x71042100, socket_id:0,
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 3: phys:0x6b20, len:2097152, virt:0x710420e0, socket_id:0,
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 4: phys:0x6b40, len:2097152, virt:0x710420c0, socket_id:0,
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 5: phys:0x6b60, len:2097152, virt:0x710420a0, socket_id:0,
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 6: phys:0x6b80, len:2097152, virt:0x71042080, socket_id:0,
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 7: phys:0x6ba0, len:2097152, virt:0x71042060, socket_id:0,
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 8: phys:0x6bc0, len:2097152, virt:0x71042040, socket_id:0,
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 9: phys:0x6be0, len:2097152, virt:0x71042020, socket_id:0,
hugepage_sz:2097152, nchannel:0, nrank:0
---
Related dpdk code is in
dpdk/lib/librte_eal/linuxapp/eal/eal_memory.c :: rte_eal_hugepage_init()
for (i = 0; i < nr_hugefiles; i++) {
new_memseg = 0;
/* if this is a new section, create a new memseg */
if (i == 0)
new_memseg = 1;
else if (hugepage[i].socket_id != hugepage[i-1].socket_id)
new_memseg = 1;
else if (hugepage[i].size != hugepage[i-1].size)
new_memseg = 1;
else if ((hugepage[i].physaddr - hugepage[i-1].physaddr) !=
hugepage[i].size)
new_memseg = 1;
else if (((unsigned long)hugepage[i].final_va -
(unsigned long)hugepage[i-1].final_va) != hugepage[i].size) {
new_memseg = 1;
}
Is this a known issue? Is there any workaround? Or Could you advise which
kernel config may relate this this kernel behavior change?
Thanks,
Michael
