From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-91146-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 17386 invoked by alias); 19 Mar 2018 13:17:44 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 17373 invoked by uid 89); 19 Mar 2018 13:17:43 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=
X-HELO: mx1.redhat.com
Subject: Re: [PATCH] Fix i386 memmove issue [BZ #22644]
To: Andreas Schwab <schwab@suse.de>,
 Andrew Senkevich <andrew.n.senkevich@gmail.com>
Cc: "H.J. Lu" <hjl.tools@gmail.com>, libc-alpha <libc-alpha@sourceware.org>,
 Max Horn <max@quendi.de>, thomas@grindinggear.com
References: <CAMXFM3s5b2a6o_CMS0cJ35oE3SuJUHssqLAUY94LSZhEEtG71A@mail.gmail.com>
 <mvm606ts2w6.fsf@suse.de>
 <CAMXFM3vqw7eiUT1XYVZWyW=eJkgEpjNc74A8mbmdKuR_hywN3w@mail.gmail.com>
 <CAMe9rOo4Ys=ScEKKnuv5XvYqTHjvFxSkXjch8ya8sX7dfP+q4Q@mail.gmail.com>
 <CAMXFM3vA=-LSK5VtKhhbs0g9faBdG0GjoAbNb6OPEbSt8dAA7A@mail.gmail.com>
 <mvmlgeojjmi.fsf@suse.de>
From: Florian Weimer <fweimer@redhat.com>
Message-ID: <597954a1-85da-e524-1454-27c46af57413@redhat.com>
Date: Mon, 19 Mar 2018 13:17:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <mvmlgeojjmi.fsf@suse.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-SW-Source: 2018-03/txt/msg00453.txt.bz2

On 03/19/2018 02:11 PM, Andreas Schwab wrote:
> On Mär 19 2018, Andrew Senkevich<andrew.n.senkevich@gmail.com>  wrote:
> 
>> +static void
>> +do_test2 (void)
>> +{
>> +  uint32_t num = 0x20000000;
>> +  uint32_t * large_buf;
>> +
>> +  large_buf = mmap ((void*)0x70000000, num, PROT_READ | PROT_WRITE,
>> +     MAP_PRIVATE | MAP_ANON | MAP_FIXED, -1, 0);
> Since you are using MAP_FIXED this may overwrite an existing mapping.

Leading to a hard-to-debug crash, maybe sporadically due to ASLR.  Yes, 
I have this concern as well.

There was a long, long Linux thread about a non-overriding MAP_FIXED 
variant, but as far as I can see, this has not been merged.  Maybe it 
would have helped here.

Is it very difficult to split out this test into a separate test file? 
Then link the whole thing statically, as non-PIE, and keep using 
MAP_FIXED.  This should make it quite likely that you don't override 
anything valuable.

Or you could parse /proc/self/maps to make sure that you don't override 
an existing mapping.  Yuck.

Thanks,
Florian