Re: kern/54994: Critical bug in uarea_poolpage_alloc() for archs with __HAVE_CPU_UAREA_ROUTINES

[Jason Thorpe <thorpej%me.com@localhost>]

The following reply was made to PR kern/54994; it has been noted by GNATS.

From: Jason Thorpe <thorpej%me.com@localhost>
To: rin%netbsd.org@localhost
Cc: kern-bug-people%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost,
 netbsd-bugs%netbsd.org@localhost,
 gnats-bugs%netbsd.org@localhost
Subject: Re: kern/54994: Critical bug in uarea_poolpage_alloc() for archs with
 __HAVE_CPU_UAREA_ROUTINES
Date: Fri, 21 Feb 2020 07:52:45 -0800

 > On Feb 21, 2020, at 3:15 AM, rokuyama.rk%gmail.com@localhost wrote:
 >=20
 > Since low-level routines for these archs assume physically contignous
 > u-area, this results in a catastrophe; pages happens to follow the 1st
 > page of u-area will be randomly overwritten.
 
 I don't have an Alpha handy to run your test case, but I don't think =
 this is catastrophic on all platforms.  As far as I can recall, the =
 Alpha does not actually require a physically contiguous u-area.  MIPS is =
 the same in this regard (although it probably need to make sure it keeps =
 UPAGES wired TLB entries for the u-area when the direct-mapping isn't =
 used ... it certainly used to do that).  The comment in the Alpha's =
 cpu_uarea_alloc() is merely there to call out the requirement in order =
 to be able to use the direct-mapped region.
 
 Oh, turns out MIPS already has much more complex rules for when the =
 direct-mapped region is used, so I suspect it's fine as well.  I haven't =
 audited the rest.
 
 In any case, the short answer is: Only an issue if the PA of the u-area =
 is provided to the CPU, not an issue if it does everything with the VA =
 of the u-area.
 
 -- thorpej