NetBSD Problem Report #56819

From mlelstv@serpens.de  Sat May  7 11:07:46 2022
Return-Path: <mlelstv@serpens.de>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 7FEFB1A923B
	for <gnats-bugs@gnats.NetBSD.org>; Sat,  7 May 2022 11:07:46 +0000 (UTC)
Message-Id: <20220507110737.B49CB73332@serpens.de>
Date: Sat,  7 May 2022 13:07:36 +0200 (MEST)
From: mlelstv@netbsd.org
Reply-To: mlelstv@netbsd.org
To: gnats-bugs@NetBSD.org
Subject: netbsd32 compat does not handle sign-extended addresses
X-Send-Pr-Version: 3.95

>Number:         56819
>Category:       kern
>Synopsis:       netbsd32 compat does not handle sign-extended addresses
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat May 07 11:10:00 +0000 2022
>Last-Modified:  Sat May 07 15:05:01 +0000 2022
>Originator:     Michael van Elst
>Release:        NetBSD 9.2_STABLE
>Organization:

>Environment:


System: NetBSD victory.netbsd.org 9.2_STABLE NetBSD 9.2_STABLE (GENERIC64) #16: Fri Jan 21 02:56:58 CET 2022 mlelstv@gossam:/home/netbsd9/obj.evbarm64-el/home/netbsd9/src/sys/arch/evbarm/compile/GENERIC64 evbarm
Architecture: aarch64
Machine: evbarm
>Description:

32bit programs running on a 64bit aarch system may generate warnings like:

netbsd32_mmap: retval out of range: 0xffffffffff546000

The resulting address is compared against 32bit unsigned int to
produce that warning message, the truncated value is still returned
to userland.

-current prints the message only when mmap returned success. So
these could be junk return values from a failed mmap in netbsd-9.

>How-To-Repeat:

Run a 32bit program on aarch64 that calls mmap and gets a mapping
beyond 2GB.

>Fix:


>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/56819: netbsd32 compat does not handle sign-extended
 addresses
Date: Sat, 7 May 2022 13:54:12 +0200

 On Sat, May 07, 2022 at 11:10:00AM +0000, mlelstv@netbsd.org wrote:
 > Run a 32bit program on aarch64 that calls mmap and gets a mapping
 > beyond 2GB.

 How could that ever happen? Can you provide a sample program or point
 at one that makes it happen?

 Maybe the MD parts of ASLR are broken for aarch64?

 Martin

From: Michael van Elst <mlelstv@serpens.de>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, mlelstv@netbsd.org
Subject: Re: kern/56819: netbsd32 compat does not handle sign-extended
 addresses
Date: Sat, 7 May 2022 15:28:23 +0200

 On Sat, May 07, 2022 at 11:55:02AM +0000, Martin Husemann wrote:
 > The following reply was made to PR kern/56819; it has been noted by GNATS.
 > 
 > From: Martin Husemann <martin@duskware.de>
 > To: gnats-bugs@netbsd.org
 > Cc: 
 > Subject: Re: kern/56819: netbsd32 compat does not handle sign-extended
 >  addresses
 > Date: Sat, 7 May 2022 13:54:12 +0200
 > 
 >  On Sat, May 07, 2022 at 11:10:00AM +0000, mlelstv@netbsd.org wrote:
 >  > Run a 32bit program on aarch64 that calls mmap and gets a mapping
 >  > beyond 2GB.
 >  
 >  How could that ever happen? Can you provide a sample program or point
 >  at one that makes it happen?
 >  
 >  Maybe the MD parts of ASLR are broken for aarch64?


 A 32bit process running on an aarch64 system has a 4GB address space,
 the "cut" (VM_MAXUSER_ADDRESS32) is at 0xfffff000, i.e. only the last
 page doesn't exist. This is different from a native 32bit arm process
 where the "cut" is at 2GB, so "negative" addresses are not used.

 pmap doesn't work, but procfs shows e.g.:

 0x980000 0x987000 r-x r-x COW NC 1 0 0
 0x996000 0xa57000 rw- rw- COW NNC 1 0 0
 0xed200000 0xed213000 r-x r-x COW NC 1 0 0
 0xed213000 0xed222000 --- --- COW NC 1 0 0
 0xed222000 0xed223000 rw- rw- COW NNC 1 0 0
 0xeec00000 0xeec10000 rw- rw- COW NNC 1 0 0
 0xeec10000 0xeee00000 rw- rw- COW NC 1 0 0
 0xeeef4000 0xeef34000 rw- rw- COW NNC 1 0 0
 0xeef34000 0xef020000 rw- rw- COW NNC 1 0 0
 0xef020000 0xef1bb000 r-x r-x COW NC 1 0 0
 0xef1bb000 0xef1ca000 --- r-x COW NC 1 0 0
 0xef1ca000 0xef1d4000 rw- rw- COW NNC 1 0 0
 0xef1d4000 0xef1f0000 rw- rw- COW NNC 1 0 0
 0xef1f0000 0xef1f2000 r-x r-x COW NC 1 0 0
 0xef1f2000 0xef201000 --- r-x COW NC 1 0 0
 0xef201000 0xef202000 rw- rw- COW NNC 1 0 0
 0xef202000 0xef20e000 rw- rw- COW NNC 1 0 0
 0xfbeff000 0xff756000 --- --- COW NC 1 0 0
 0xff756000 0xfff50000 rw- rw- COW NC 1 0 0
 0xfff50000 0xfff55000 rw- rw- COW NNC 1 0 0
 0xfff55000 0xfff56000 rw- rw- COW NNC 1 0 0


 The assumption is that the 64bit kernel sees the addresses
 sign extended on some level and passes an unsigned value (vaddr)
 from the ranges

 0x0000000000000000 .. 0x000000007fffffff
 0xffffffff80000000 .. 0xfffffffffffff000

 to the compat routine.



 Greetings,
 -- 
                                 Michael van Elst
 Internet: mlelstv@serpens.de
                                 "A potential Snark may lurk in every tree."

From: Martin Husemann <martin@duskware.de>
To: Michael van Elst <mlelstv@serpens.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/56819: netbsd32 compat does not handle sign-extended
 addresses
Date: Sat, 7 May 2022 16:20:25 +0200

 On Sat, May 07, 2022 at 03:28:23PM +0200, Michael van Elst wrote:
 > A 32bit process running on an aarch64 system has a 4GB address space,
 > the "cut" (VM_MAXUSER_ADDRESS32) is at 0xfffff000, i.e. only the last
 > page doesn't exist. This is different from a native 32bit arm process
 > where the "cut" is at 2GB, so "negative" addresses are not used.

 I'm not sure I follow - on sparc we have a full 4G adress space for both
 native 32bit and compat32 userland and haven't experienced the problem
 so far (but ASLR has some MD quirks for 32bit userland IIRC).

 #define VM_MAXUSER_ADDRESS32        ((vaddr_t)(0x00000000ffffffffL&~PGOFSET))

 Martin

From: Michael van Elst <mlelstv@serpens.de>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/56819: netbsd32 compat does not handle sign-extended
 addresses
Date: Sat, 7 May 2022 17:01:52 +0200

 On Sat, May 07, 2022 at 04:20:25PM +0200, Martin Husemann wrote:
 > On Sat, May 07, 2022 at 03:28:23PM +0200, Michael van Elst wrote:
 > > A 32bit process running on an aarch64 system has a 4GB address space,
 > > the "cut" (VM_MAXUSER_ADDRESS32) is at 0xfffff000, i.e. only the last
 > > page doesn't exist. This is different from a native 32bit arm process
 > > where the "cut" is at 2GB, so "negative" addresses are not used.
 > 
 > I'm not sure I follow - on sparc we have a full 4G adress space for both
 > native 32bit and compat32 userland and haven't experienced the problem
 > so far (but ASLR has some MD quirks for 32bit userland IIRC).
 > 
 > #define VM_MAXUSER_ADDRESS32        ((vaddr_t)(0x00000000ffffffffL&~PGOFSET))


 Somewhere the 32bit address space seems to be signed for arm but not
 for sparc.


 Greetings,
 -- 
                                 Michael van Elst
 Internet: mlelstv@serpens.de
                                 "A potential Snark may lurk in every tree."

>Unformatted:

Home	PR Database Search