Re: [PATCHv4 1/5] x86/mm: split arch_mmap_rnd() on compat/native versions

[Andy Lutomirski <luto@amacapital.net>]

On Thu, Feb 9, 2017 at 5:55 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Mon, Jan 30, 2017 at 03:04:28PM +0300, Dmitry Safonov wrote:
>> I need those arch_{native,compat}_rnd() to compute separately
>> random factor for mmap() in compat syscalls for 64-bit binaries
>> and vice-versa for native syscall in 32-bit compat binaries.
>> They will be used in the following patches.
>>
>> Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
>> ---
>>  arch/x86/mm/mmap.c | 25 ++++++++++++++++---------
>>  1 file changed, 16 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c
>> index d2dc0438d654..42063e787717 100644
>> --- a/arch/x86/mm/mmap.c
>> +++ b/arch/x86/mm/mmap.c
>> @@ -65,20 +65,27 @@ static int mmap_is_legacy(void)
>>       return sysctl_legacy_va_layout;
>>  }
>>
>> -unsigned long arch_mmap_rnd(void)
>> +#ifdef CONFIG_COMPAT
>> +static unsigned long arch_compat_rnd(void)
>>  {
>> -     unsigned long rnd;
>> +     return (get_random_long() & ((1UL << mmap_rnd_compat_bits) - 1))
>> +             << PAGE_SHIFT;
>> +}
>> +#endif
>>
>> -     if (mmap_is_ia32())
>> +static unsigned long arch_native_rnd(void)
>> +{
>> +     return (get_random_long() & ((1UL << mmap_rnd_bits) - 1)) << PAGE_SHIFT;
>> +}
>> +
>> +unsigned long arch_mmap_rnd(void)
>> +{
>>  #ifdef CONFIG_COMPAT
>> -             rnd = get_random_long() & ((1UL << mmap_rnd_compat_bits) - 1);
>> -#else
>> -             rnd = get_random_long() & ((1UL << mmap_rnd_bits) - 1);
>> +     if (mmap_is_ia32())
>> +             return arch_compat_rnd();
>>  #endif
>
> I can't say that I'm thrilled about the ifdeffery this is adding.
>
> But I can't think of a cleaner approach at a quick glance, though -
> that's generic and arch-specific code intertwined muck. Sad face.

I can, but it could be considerably more churn: get rid of the
compat/native split and do a 32-bit/64-bit split instead.

>
> --
> Regards/Gruss,
>     Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.



-- 
Andy Lutomirski
AMA Capital Management, LLC