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: <afa2c3be-3c08-5c0b-1cdf-2bb843498cbb@csgroup.eu>
Date:   Thu, 3 Feb 2022 06:58:53 +0000
From:   Christophe Leroy <christophe.leroy@...roup.eu>
To:     Luis Chamberlain <mcgrof@...nel.org>
CC:     Jessica Yu <jeyu@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "kgdb-bugreport@...ts.sourceforge.net" 
        <kgdb-bugreport@...ts.sourceforge.net>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>
Subject: Re: [PATCH v3 3/6] modules: Introduce data_layout



Le 03/02/2022 à 00:48, Luis Chamberlain a écrit :
> On Sat, Jan 29, 2022 at 05:02:07PM +0000, Christophe Leroy wrote:
>> diff --git a/kernel/module.c b/kernel/module.c
>> index 163e32e39064..11f51e17fb9f 100644
>> --- a/kernel/module.c
>> +++ b/kernel/module.c
>> @@ -81,6 +81,8 @@
>>   /* If this is set, the section belongs in the init part of the module */
>>   #define INIT_OFFSET_MASK (1UL << (BITS_PER_LONG-1))
>>   
>> +#define	data_layout core_layout
>> +
>>   /*
>>    * Mutex protects:
>>    * 1) List of modules (also safely readable with preempt_disable),
>> @@ -2451,7 +2454,10 @@ static void layout_sections(struct module *mod, struct load_info *info)
>>   			    || s->sh_entsize != ~0UL
>>   			    || module_init_layout_section(sname))
>>   				continue;
>> -			s->sh_entsize = get_offset(mod, &mod->core_layout.size, s, i);
>> +			if (m)
>> +				s->sh_entsize = get_offset(mod, &mod->data_layout.size, s, i);
>> +			else
>> +				s->sh_entsize = get_offset(mod, &mod->core_layout.size, s, i);
>>   			pr_debug("\t%s\n", sname);
> 
> Huh why is this branching here, given you just used mod->data_layout in
> all other areas?

The module text remains in core_layout, so the text section still needs 
core_layout. In the masks[][] table, it corresponds to the first line, 
which has flag  SHF_EXECINSTR. In the loop that's when 'm' is 0.

In the following switch/case, case 0 still uses core_layout.

> 
>> @@ -3468,6 +3474,8 @@ static int move_module(struct module *mod, struct load_info *info)
>>   		if (shdr->sh_entsize & INIT_OFFSET_MASK)
>>   			dest = mod->init_layout.base
>>   				+ (shdr->sh_entsize & ~INIT_OFFSET_MASK);
>> +		else if (!(shdr->sh_flags & SHF_EXECINSTR))
>> +			dest = mod->data_layout.base + shdr->sh_entsize;
>>   		else
>>   			dest = mod->core_layout.base + shdr->sh_entsize;
>>   
> 
> Likewise here.

Same here, the section with flag SHF_EXECINSTR is a text section, it 
stays in core_layout.

Christophe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ