linux-kernel - Re: [PATCH 0/2] Build ORC fast lookup table in scripts/sorttable tool

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-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <037BCC2F-FEF5-40AB-8F7B-7A966073113C@linux.alibaba.com>
Date:   Wed, 3 Jun 2020 21:47:47 +0800
From:   changhuaixin <changhuaixin@...ux.alibaba.com>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     changhuaixin <changhuaixin@...ux.alibaba.com>,
        linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org,
        bp@...en8.de, hpa@...or.com, luto@...capital.net,
        michal.lkml@...kovi.net, mingo@...hat.com, peterz@...radead.org,
        tglx@...utronix.de, x86@...nel.org, yamada.masahiro@...ionext.com
Subject: Re: [PATCH 0/2] Build ORC fast lookup table in scripts/sorttable tool



> On Jun 2, 2020, at 1:38 AM, Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> 
> On Sun, May 31, 2020 at 01:26:54PM +0800, changhuaixin wrote:
>>   It turned out to be an alignment problem. If sh_size of previous section
>>   orc_unwind is not 4-byte aligned, sh_offset of the following orc_lookup
>>   section is not 4-byte aligned too. However, the VMA of section orc_lookup
>>   is aligned to the nearest 4-byte. Thus, the orc_lookup section means two
>>   different ares for scripts/sorttable tool and kernel.
>> 
>>   Sections headers look like this when it happens:
>> 
>>   12 .orc_unwind_ip 00172124  ffffffff82573b28  0000000002573b28  01773b28
>>    2**0
>>                    CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
>>   13 .orc_unwind   0022b1b6  ffffffff826e5c4c  00000000026e5c4c  018e5c4c
>>    2**0
>>                    CONTENTS, ALLOC, LOAD, READONLY, DATA
>>   14 .orc_lookup   0003003c  ffffffff82910e04  0000000002910e04  01b10e02
>>    2**0
>>                    ALLOC
>>   15 .vvar         00001000  ffffffff82941000  0000000002941000  01b41000
>>    2**4
>>                    CONTENTS, ALLOC, LOAD, DATA
>> 
>>   Sorttable tool uses the are starting with offset 0x01b10e02 for 0x0003003c
>>   bytes. While kernel use the area starting with VMA at  0xffffffff82910e04
>>   for 0x0003003c bytes, meaning that each entry in this table used by kernel
>>   is actually 2 bytes behind the corresponding entry set from sorttable
>>   tool.
>> 
>>   Any suggestion on fixing this？
> 
> The VMA and LMA are both 4-byte aligned.  The file offset alignment
> (0x01b10e02) shouldn't matter.
> 
> Actually it looks like the problem is that the section doesn't have
> CONTENTS, so it's just loaded as a BSS section (all zeros).  The section
> needs to be type SHT_PROGBITS instead of SHT_NOBITS.
> 
> $ readelf -S vmlinux |grep orc_lookup
>  [16] .orc_lookup       NOBITS           ffffffff82b68418  01d68418
> 
> I tried to fix it with
> 
> diff --git a/scripts/sorttable.h b/scripts/sorttable.h
> index a36c76c17be4..76adb1fb88f8 100644
> --- a/scripts/sorttable.h
> +++ b/scripts/sorttable.h
> @@ -341,6 +341,7 @@ static int do_sort(Elf_Ehdr *ehdr,
> 			param.lookup_table_size = s->sh_size;
> 			param.orc_lookup_table = (unsigned int *)
> 				((void *)ehdr + s->sh_offset);
> +			w(SHT_PROGBITS, &s->sh_type);
> 		}
> 		if (!strcmp(secstrings + idx, ".text")) {
> 			param.text_size = s->sh_size;
> 
> 
> But that makes kallsyms unhappy, so I guess we need to do it from the
> linker script where .orc_lookup is created.
> 
> Linker script doesn't seem to allow manual specification of the section
> type, so this is the best I could come up with:
> 
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index db600ef218d7..49f4f5bc6165 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -826,6 +826,8 @@
> 		. += (((SIZEOF(.text) + LOOKUP_BLOCK_SIZE - 1) /	\
> 			LOOKUP_BLOCK_SIZE) + 1) * 4;			\
> 		orc_lookup_end = .;					\
> +		/* HACK: force SHT_PROGBITS so sorttable can edit: */	\
> +		BYTE(1);						\
> 	}
> #else
> #define ORC_UNWIND_TABLE

Thanks! It works.