From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B5056C02198 for ; Sun, 16 Feb 2025 05:08:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CCDE228001C; Sun, 16 Feb 2025 00:08:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C7D8B28001A; Sun, 16 Feb 2025 00:08:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B44B428001C; Sun, 16 Feb 2025 00:08:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 97D0D28001A for ; Sun, 16 Feb 2025 00:08:47 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 066CF122826 for ; Sun, 16 Feb 2025 05:08:47 +0000 (UTC) X-FDA: 83124627894.28.4E00F89 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf15.hostedemail.com (Postfix) with ESMTP id 01FB9A0007 for ; Sun, 16 Feb 2025 05:08:44 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=aRQ5cIQQ; spf=pass (imf15.hostedemail.com: domain of chenhuacai@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chenhuacai@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739682525; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=TjMHj92f3aH5T5tcN0AWk+5u5VvS/UjV5tTtkNWW/KU=; b=5WrtoZRnAi+4JjIK0tNIdqIoqYP58uwtOnZFBTiv6SHdpL7Tei4WLvlQJCO3tNwwgS8jL6 9ayPJD8HnoId0EI1eTzr9EdLGcMeNscAtlPXOk5F5jcEA/4sYmEZ957QL+6/xTCTh8gHZX DRdixI6a1K8hdsUZEtCQOikIAATtK14= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=aRQ5cIQQ; spf=pass (imf15.hostedemail.com: domain of chenhuacai@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chenhuacai@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739682525; a=rsa-sha256; cv=none; b=KOvopWYaxb448erV1Ee4hBNk8pPMb3QJkquPOd12bvGo0HjV/5jPNcmc4FT0T84u5V//DC ynz5rLaRal+wxv+MVBW6q8RiVuQOZ6uXmoFnFzJu/tE+vsGNGj+OBIdZivifC0Qs+P6lnn k41k2GX92nCaOVin5qGnpfABlWI2DAw= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 6A72E5C546D for ; Sun, 16 Feb 2025 05:08:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5D78DC4CEE9 for ; Sun, 16 Feb 2025 05:08:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1739682523; bh=TjMHj92f3aH5T5tcN0AWk+5u5VvS/UjV5tTtkNWW/KU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=aRQ5cIQQbUcCNuPYP8w+LHwJxNAcAx9aARni4FLB8wYgy+W2pPpi0R5rXEa/Wwrs1 xey0wH7u3eVEM+uliFQHM8gKlTKOFJ8beRMPfZvPDqwAjZUJ0vCZqL+Z7kl2t7hxr1 tyY0glmZin0Reir7ibYDR+BOEHTrwBy+5FKrxa/5htyWn7oZimqf5/vkRWLgImYUgw wSjsBat66nelICFL2ri3gvdehwDaBZAQle4wYiUQDKyLROc0zqkLF5TJ9OU1LStqNi cK8jWQI+VVWGMr/LtnVQj3o+RmVUuecAky/55POv04DYBS1mbu4Icdlbjj2mt/mlMx iPsGXFwnBO4IQ== Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-abb7aecd39fso131931766b.0 for ; Sat, 15 Feb 2025 21:08:43 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCXiLOVXlXvFfcDZuzR6RKinx/16GLvxlSDWLhjzTKEYyLRS9pneX5OJA4i06XEhvb2MHhQAK0eKkQ==@kvack.org X-Gm-Message-State: AOJu0YwWoKLiSySIqUXk6Xz3gp1cmDrPqdmxr8kOGACn581PB6+Bhcwn trSvFlhgHUnEL50rAuy0L39MIl6PoEE1Kcye1ZuSGDtNueypW6FFcn86frezR/nITJZsWnwkpSf 1K5rEZJKVSsJoYUnIL7PwZ6O1eCU= X-Google-Smtp-Source: AGHT+IG0uKd25dY1QefQSYqIH7OdcvhKYoVhskTkARo2TPH/qMDXTbbtCOZRrar1d9hRbIVAtnHQspupRqZZZjzgpwc= X-Received: by 2002:a17:906:c14c:b0:aba:620a:acf7 with SMTP id a640c23a62f3a-abb708aaf52mr569004266b.10.1739682521939; Sat, 15 Feb 2025 21:08:41 -0800 (PST) MIME-Version: 1.0 References: <20250212141648.599661-1-chenhuacai@loongson.cn> In-Reply-To: From: Huacai Chen Date: Sun, 16 Feb 2025 13:08:30 +0800 X-Gmail-Original-Message-ID: X-Gm-Features: AWEUYZk9z8Ky-eeelh-PyAQijbE-EnoVcqWYGSYclbdmVVJgV2PTlUciZ2MX3Q4 Message-ID: Subject: Re: How does swsusp work with randomization features? (was: mm/slab: Initialise random_kmalloc_seed after initcalls) To: "Harry (Hyeonggon) Yoo" <42.hyeyoo@gmail.com> Cc: Huacai Chen , Andrew Morton , linux-mm@kvack.org, "Rafael J . Wysocki" , Pavel Machek , linux-pm@vger.kernel.org, GONG Ruiqi , Xiu Jianfeng , stable@vger.kernel.org, Yuli Wang , Vlastimil Babka , Christoph Lameter , David Rientjes , Roman Gushchin , Pekka Enberg , Joonsoo Kim , Kees Cook , GONG Ruiqi Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: 8b6m1yo3ogk457txrptjtaz3dz16mp5d X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 01FB9A0007 X-HE-Tag: 1739682524-756321 X-HE-Meta: U2FsdGVkX1/oKHg3pimAKQXt8hDHEHZzhuBOW82t4PJX2s4cBKDPHMngLWPA1zszf/lxXI1yWj0ES4wxITAHRcUn5ddHPwV0mP9JUdEqgW4ulrWcSCP+PcQG2/5F8dkx9PoU1UsO74BlpDGI4CvWVWtLJUWToonP5OXUdopgi+UsuBIA7kDNvtrHkAV3633alxMC3vXA2BEgKWx2GW0JqqGyhPB6f4tPjs7Y+oGeR1gHa6ASqxsI1MQ7D6FJZCrRsFxbRF7OO5sZWzFChdj4+tt6lblsJavvKS/2HuVeMJl7leYV10CMX3Li1wv7EGXJIg6f20FT51JzO8F8gsHWmpFQRW1huP55ZRrKHtpdyP6/3PL94bkwIVYdHhjnLzQV+eN56gXvKHHuu/6cBoWisJB4zsoMp6zyJj3SNDXAGjw4UIJ2J3JLsDHZTXpXkusEEAOjHtrAkCuXDlHj4IVICGTcQnoahjEXY61RwPgaQAzoXGYiuSPViM0lLuTeHd0xdw7z1B2aB1G95mG1zJolMI87KKBZOUhkfgWKjZAEktdW5psUp6OLqK4l9H55OVxi1tx3sUSeuTOqwe0o842dPsaRxlIMc1AhIA7gv2vm6X6c8VvXBj7aLTZiPo8hpY8m44uufaXMaQF1ClwwS1PR4o/omNNIXLM0VU+b6m9Xm3D6ImynDXegL1CpP+Ka1ZpGEvGtCqKvW3cWkuNqAAIL9t2S5af1AZn9WX9eK/vP5QZrnIlvHQf7vTToEbPafZSlE9ZS2koG97hfpN/irEPz/a68vw4yZdUkE4awo5Wsb6isxM4KfhefHtGmX6phH0kmQFrf3d/A1sn71UXzH3RCoruDNcEvQocqz32X6dBmvZr/hF/ya3hO5qPxfvEWcoV+7ZGARO7gjsXYpaSZ6ZYr1sV52yvVfZFQA7+wL/cZ9N70P/+z7+W6aCIPWvZgyY4K/IweX9RL/FRyAalHoyr 93F8WYNV XMY+K33xuWPoxiOsW5ffwD5iShSEw9R7iDb/k1Cty2n6Rzh6ROpfyXpvHsVAwwxVibfbuYrN+ptLoM0QYISejaMHAMYLkoS7kLw8/GV93PrMF7vStMtoT178stOHpTpsTGzfkxdNA8J9gdpqqmXnVg5x/slHlAUturR77xzh4Z/SYO+p3/Q/5YD+GnGcmhXC5Ru9Pc2zOppsB6aY1sUwzx6XCCW4cEvegwzq+e8pjCsYqEueVmNE2hHpDACVaO3Nxt75q8tw52/b23Owl0+Lg3Wr2XYUVj2LJxdkg5bRAIoYSpnj0OGXErDBZYcuFK9TwqK84ZP0ZrttQuoLEdYzVIkwsLEn5+fj/Gnl0n1c9mZfYX2WZQdkUxkObDagdUaSxXdLmTYEDQ3xt7IQiEqjibvMAgyRMl0Loqp7H/8Ck7LnQUSa6fbwgUMuVlKgWR607lPqpZ4A4WY0wcPEREvCxjyrukg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Sat, Feb 15, 2025 at 10:05=E2=80=AFPM Harry (Hyeonggon) Yoo <42.hyeyoo@gmail.com> wrote: > > On Sat, Feb 15, 2025 at 05:53:29PM +0800, Huacai Chen wrote: > > On Fri, Feb 14, 2025 at 8:45=E2=80=AFPM Harry (Hyeonggon) Yoo > > <42.hyeyoo@gmail.com> wrote: > > > > > > On Fri, Feb 14, 2025 at 06:02:52PM +0800, Huacai Chen wrote: > > > > On Fri, Feb 14, 2025 at 5:33=E2=80=AFPM Harry (Hyeonggon) Yoo > > > > <42.hyeyoo@gmail.com> wrote: > > > > > > > > > > On Thu, Feb 13, 2025 at 11:20:22AM +0800, Huacai Chen wrote: > > > > > > Hi, Harry, > > > > > > > > > > > > On Wed, Feb 12, 2025 at 11:39=E2=80=AFPM Harry (Hyeonggon) Yoo > > > > > > <42.hyeyoo@gmail.com> wrote: > > > > > > > On Wed, Feb 12, 2025 at 11:17=E2=80=AFPM Huacai Chen wrote: > > > > > > > > > > > > > > > > Hibernation assumes the memory layout after resume be the s= ame as that > > > > > > > > before sleep, but CONFIG_RANDOM_KMALLOC_CACHES breaks this = assumption. > > > > > > > > > > > > > > Could you please elaborate what do you mean by > > > > > > > hibernation assumes 'the memory layout' after resume be the s= ame as that > > > > > > > before sleep? > > > > > > > > > > > > > > I don't understand how updating random_kmalloc_seed breaks re= suming from > > > > > > > hibernation. Changing random_kmalloc_seed affects which kmall= oc caches > > > > > > > newly allocated objects are from, but it should not affect th= e objects that are > > > > > > > already allocated (before hibernation). > > > > > > > > > > > > When resuming, the booting kernel should switch to the target k= ernel, > > > > > > if the address of switch code (from the booting kernel) is the > > > > > > effective data of the target kernel, then the switch code may b= e > > > > > > overwritten. > > > > > > > > > > Hmm... I'm still missing some pieces. > > > > > How is the kernel binary overwritten when slab allocations are ra= ndomized? > > > > > > > > > > Also, I'm not sure if it's even safe to assume that the memory la= yout is the > > > > > same across boots. But I'm not an expert on swsusp anyway... > > > > > > > > > > It'd be really helpful for linux-pm folks to clarify 1) what are = the > > > > > (architecture-independent) assumptions are for swsusp to work, an= d > > > > > 2) how architectures dealt with other randomization features like= kASLR... > > > > > > > > > > [+Cc few more people that worked on slab hardening] > > > > > > > I'm sorry to confuse you. Binary overwriting is indeed caused by > > > > kASLR, so at least on LoongArch we should disable kASLR for > > > > hibernation. > > > > > > Understood. > > > > > > > Random kmalloc is another story, on LoongArch it breaks smpboot whe= n > > > > resuming, the details are: > > > > 1, LoongArch uses kmalloc() family to allocate idle_task's > > > > stack/thread_info and other data structures. > > > > 2, If random kmalloc is enabled, idle_task's stack in the booting > > > > kernel may be other things in the target kernel. > > > > > > Slab hardening features try so hard to prevent such predictability. > > > For example, SLAB_FREELIST_RANDOM could also randomize the address > > > kmalloc objects are allocated at. > > > > > > Rather than hacking CONFIG_RANDOM_KMALLOC_CACHES like this, we could > > > have a single option to disable slab hardening features that makes > > > the address unpredictable. > > > > > > It'd be nice to have something like ARCH_SUPPORTS_SLAB_RANDOM which > > > some hardening features depend on. And then let some arches condition= ally > > > not select ARCH_SUPPORTS_SLAB_RANDOM if hibernation's enabled > > > (at cost of less hardening)? > > > > This is not good, my patch doesn't disable RANDOM for hibernation, it > > just delays the initialization. When the system is running, all > > randomization is still usable. > > I think at least we need a rule (like ARCH_SUPPORTS_SLAB_RANDOM) > for slab hardening features that prevents breaking hibernation > in the future. Without rules, introducing new hardening features could > break hibernation again. I don't think so, even if on LoongArch, hibernation and various RANDOM infra can co-exist (need some adjustment). Even if hibernation cannot be used together with kASLR, we don't disable it at build time but at run time. This means we can choose hibernation or kASLR with a single kernel image. > > But I'm not yet convinced if it's worth the complexity of hacking slab > hardening features (for security) just to make hibernation work on > some arches, which have already disabled kASLR anyway... I don't think this patch is an ugly hack, it is a proper adjustment. Random kmalloc can still work with hibernation, delaying the seed initialization only makes that random kmalloc doesn't work (fallback to predictable kmalloc) for a very short time during the boot phase. And again, kASLR is disable at run time rather than build time. > > > For SLAB_FREELIST_RANDOM, I found that it doesn't break hibernation > > (at least on LoongArch), the reason is: > > 1. When I said "data overwritten" before, it doesn't mean that every > > byte shouldn't be overwritten, only some important parts matter. > > 2. On LoongArch, the important parts include: switch code, exception > > handlers, idle_task's stack/thread_info. > > 3. switch code and exception handlers are protected by automatically > > disabling kASLR from arch-specific code, idle_task's stack/thread_info > > is protected by delaying random seeds (this patch). > > > > Why SLAB_FREELIST_RANDOM doesn't corrupt idle_task's > > stack/thread_info? Because the scope of randomization of > > SLAB_FREELIST_RANDOM is significantly less than RANDOM_KMALLOC_CACHES. > > When RANDOM_KMALLOC_CACHES enabled, > > You mean when SLAB_FREELIST_RANDOM enabled? > Assuming that... Yes. > > > the CPU1's idle task stack from > > the booting kernel may be the CPU2's idle task stack from the target > > kernel, and CPU2's idle task stack from the booting kernel may be the > > CPU1's idle task stack from the target kernel > > What happens if it's not the case? SLAB means "objects with the same type", right? So it is probably the case. Yes, there is a very very low possibility that not the case, but... In theory x86_64 also has a low possibility that the idle task's stack or other metadata be overwritten, then should we also disable random kmalloc for x86_64? On the other hand, if we really need to handle this theoretic possibility about SLAB_FREELIST_RANDOM now, we can simply move init_freelist_randomization() after all initcalls, too. Huacai > > > but idle task's stack > > from the booting kernel won't be other things from the target kernel > > (and won't be overwritten by switching kernel). > > What guarantees that it won't be overwritten? > To me it seems to be a fragile assumption that could be broken. > > Am I missing something? > > -- > Harry