linux-kernel - Re: [next] arm64: boot failed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220609101153.GB2187@willie-the-truck>
Date:   Thu, 9 Jun 2022 11:11:54 +0100
From:   Will Deacon <will@...nel.org>
To:     Kefeng Wang <wangkefeng.wang@...wei.com>
Cc:     Vasily Averin <vvs@...nvz.org>,
        Naresh Kamboju <naresh.kamboju@...aro.org>,
        Shakeel Butt <shakeelb@...gle.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        regressions@...ts.linux.dev, lkft-triage@...ts.linaro.org,
        linux-mm <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Catalin Marinas <catalin.marinas@....com>,
        Raghuram Thammiraju <raghuram.thammiraju@....com>,
        Mark Brown <broonie@...nel.org>,
        Roman Gushchin <roman.gushchin@...ux.dev>,
        Qian Cai <quic_qiancai@...cinc.com>
Subject: Re: [next] arm64: boot failed - next-20220606

On Thu, Jun 09, 2022 at 11:44:09AM +0800, Kefeng Wang wrote:
> On 2022/6/9 10:49, Vasily Averin wrote:
> > mem_cgroup_from_obj():
> > ffff80000836cf40:       d503245f        bti     c
> > ffff80000836cf44:       d503201f        nop
> > ffff80000836cf48:       d503201f        nop
> > ffff80000836cf4c:       d503233f        paciasp
> > ffff80000836cf50:       d503201f        nop
> > ffff80000836cf54:       d2e00021        mov     x1, #0x1000000000000            // #281474976710656
> > ffff80000836cf58:       8b010001        add     x1, x0, x1
> > ffff80000836cf5c:       b25657e4        mov     x4, #0xfffffc0000000000         // #-4398046511104
> > ffff80000836cf60:       d34cfc21        lsr     x1, x1, #12
> > ffff80000836cf64:       d37ae421        lsl     x1, x1, #6
> > ffff80000836cf68:       8b040022        add     x2, x1, x4
> > ffff80000836cf6c:       f9400443        ldr     x3, [x2, #8]
> > 
> > x5 : ffff80000a96f000 x4 : fffffc0000000000 x3 : ffff80000ad5e680
> > x2 : fffffe00002bc240 x1 : 00000200002bc240 x0 : ffff80000af09740
> > 
> > x0 = 0xffff80000af09740 is an argument of mem_cgroup_from_obj()
> > according to System.map it is init_net
> > 
> > This issue is caused by calling virt_to_page() on address of static variable init_net.
> > Arm64 consider that addresses of static variables are not valid virtual addresses.
> > On x86_64 the same API works without any problem.

This just depends on whether or not the kernel is running out of the linear
mapping or not. On arm64, we use the vmalloc area for the kernel image and
so virt_to_page() won't work, just like it won't work for modules on other
architectures.

How are module addresses handled by mem_cgroup_from_obj()?

> > Unfortunately I do not understand the cause of the problem.
> > I do not see any bugs in my patch.
> > I'm using an existing API, mem_cgroup_from_obj(), to find the memory cgroup used
> > to account for the specified object.
> > In particular, in the current case, I wanted to get the memory cgroup of the
> > specified network namespace by the name taken from for_each_net().
> > The first object in this list is the static structure unit_net
> 
> root@...t:~# cat /proc/kallsyms |grep -w _data
> ffff80000a110000 D _data
> root@...t:~# cat /proc/kallsyms |grep -w _end
> ffff80000a500000 B _end
> root@...t:~# cat /proc/kallsyms |grep -w init_net
> ffff80000a4eb980 B init_net
> 
> the init_net is located in data section, on arm64, it is allowed by vmalloc,
> see
> 
>     map_kernel_segment(pgdp, _data, _end, PAGE_KERNEL, &vmlinux_data, 0, 0);
> 
> and the arm has same behavior.
> 
> We could let init_net be allocated dynamically, but I think it could change
> a lot.
> 
> Any better sugguestion, Catalin?

For this specific issue, can you use lm_alias to get a virtual address
suitable for virt_to_page()? My question about modules still applies though.

Will