On 2020년 03월 09일 23:01, Matthew Wilcox wrote: > On Mon, Mar 09, 2020 at 06:12:03PM +0900, Jaewon Kim wrote: >> On 2020년 03월 08일 21:36, Matthew Wilcox wrote: >>> 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. >> Although up to 10 times within 5 secs is not many, I think those log may remove >> other important log in log buffer if it is the system which produces very few log. >> In my Android phone device system, there seems to be much more kernel log though. > I've never seen the logs on my android phone. All that a ratelimit is > going to do is make the attacker be more patient. > >>> 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. >> In Android phone device system, we cannot get sysadmin permission if it is built >> for end user. And it is not easy to reproduce this symptom because it is an user's app. >> >> Anyway let me try pr_devel_ratelimited which is disabled by default. I hope this is >> good enough. Additionally I moved the code from mm.h to mmap.c. > https://source.android.com/devices/tech/debug/ftrace I am not sure if an end user can enable a trace point which is not writable. Anyway I created trace mmap.h file and changed printk to trace_vm_unmapped_area without ratelimited. If there is no objection, I am going to resubmit whole patch as v2. Thank you for your comment. --- a/mm/mmap.c +++ b/mm/mmap.c @@ -47,6 +47,8 @@ #include <linux/pkeys.h> #include <linux/oom.h> #include <linux/sched/mm.h> +#define CREATE_TRACE_POINTS +#include <trace/events/mmap.h> #include <linux/uaccess.h> #include <asm/cacheflush.h> @@ -2061,10 +2063,15 @@ unsigned long unmapped_area_topdown(struct vm_unmapped_area_info *info) */ unsigned long vm_unmapped_area(struct vm_unmapped_area_info *info) { + unsigned long addr; + if (info->flags & VM_UNMAPPED_AREA_TOPDOWN) - return unmapped_area_topdown(info); + addr = unmapped_area_topdown(info); else - return unmapped_area(info); + addr = unmapped_area(info); + + trace_vm_unmapped_area(addr, info); + return addr; } >
