On Sun, Mar 08, 2020 at 06:58:47PM +0900, Jaewon Kim wrote: > On 2020년 03월 08일 10:58, Matthew Wilcox wrote: > > On Sat, Mar 07, 2020 at 03:47:44PM -0800, Andrew Morton wrote: > >> On Fri, 6 Mar 2020 15:16:22 +0900 Jaewon Kim <jaewon31.kim@xxxxxxxxxxx> wrote: > >>> Even on 64 bit kernel, the mmap failure can happen for a 32 bit task. > >>> Virtual memory space shortage of a task on mmap is reported to userspace > >>> as -ENOMEM. It can be confused as physical memory shortage of overall > >>> system. > > But userspace can trigger this printk. We don't usually allow printks > > under those circumstances, even ratelimited. > Hello thank you your comment. > > Yes, userspace can trigger printk, but this was useful for to know why > a userspace task was crashed. There seems to be still many userspace > applications which did not check error of mmap and access invalid address. > > Additionally in my AARCH64 Android environment, display driver tries to > get userspace address to map its display memory. The display driver > report -ENOMEM from vm_unmapped_area and but also from GPU related > address space. > > Please let me know your comment again if this debug is now allowed > in that userspace triggered perspective. The scenario that worries us is an attacker being able to fill the log files and so also fill (eg) the /var partition. Once it's full, future kernel messages cannot be stored anywhere and so there will be no traces of their privilege escalation. Maybe a tracepoint would be a better idea? Usually they are disabled, but they can be enabled by a sysadmin to gain insight into why an application is crashing.
