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 2570EC021AA for ; Wed, 19 Feb 2025 18:09:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 82EFB280255; Wed, 19 Feb 2025 13:09:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7DECF280246; Wed, 19 Feb 2025 13:09:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A650280255; Wed, 19 Feb 2025 13:09:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 4D287280246 for ; Wed, 19 Feb 2025 13:09:55 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id CB6B781A88 for ; Wed, 19 Feb 2025 18:09:54 +0000 (UTC) X-FDA: 83137482708.17.E2F0C5D Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf13.hostedemail.com (Postfix) with ESMTP id B3ABA20002 for ; Wed, 19 Feb 2025 18:09:52 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=AYbhlB2S; spf=pass (imf13.hostedemail.com: domain of rafael@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rafael@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=1739988592; 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=N9vSWcUq0IGl/jxpCF6PvN75WrUJPDE//1NmUV7Xpys=; b=tB1taic4fycceshuhASTQsTekWolTCHPTwMzAgiHT/p7yU9EgeattbAdebxiHwyThr2iGW Od9J8Sv0lwgZqFmZFhMQYbT9/RERGo6G5K0a2eorvqnJJleMkwV/8Y2wCqo8Xl7/6SK6fH 3wzIurdzEvcNYPI3Wb7y8gQ2s14xSOc= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=AYbhlB2S; spf=pass (imf13.hostedemail.com: domain of rafael@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rafael@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739988592; a=rsa-sha256; cv=none; b=YVXHB9mmUs0bWYpiahtbkUtgIKPlST4o4pgCrnJ2yNkt/SjFG/2Kf68oTdnb8J8BldqbZu aOgBon+sdVGmccISxIvCHEH3ZIp1gIgSLYPp57sj0LVKxKsFzEKEK+dgxhy1ZdnY8eUs1Z hwAIe6I35JR/FuChDRfn0vbrRYTunig= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id B5D925C5BE3 for ; Wed, 19 Feb 2025 18:09:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4CCD3C4CEEC for ; Wed, 19 Feb 2025 18:09:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1739988591; bh=N9vSWcUq0IGl/jxpCF6PvN75WrUJPDE//1NmUV7Xpys=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=AYbhlB2SoBU/JhLkTCzTOjVE2/wh40dB0pBnwxCsu8YfqdwgNpA/bvcF5LLi1ZwDG v70YlBZKaK55WK5rfKRoTuc9deuT43KM/m4Pb0kMgO6f+qPlR9anJ8hyNi0OfhAdtv ZHbJ8q/rvUWJbQmF5MjwCpiF9F54khUdO/fhjIF+5a4BeTmzfpLxpyOTnntxqWqqZQ D84ShXzIMRE4MaMYuU3BaL1/DBAvQbn9Tzyf+CloTiTGrCsGKFGDnFPySYHiYy7fH6 cWpU7sX41F2P7/S9VbYdogVxpVfR+a6nkKuOtYBRgqtCbaR8yZqhXrEShYYr1xFwX2 ddjvgE+iz3gMQ== Received: by mail-oi1-f174.google.com with SMTP id 5614622812f47-3f3ff03c89dso31151b6e.2 for ; Wed, 19 Feb 2025 10:09:51 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCW0hG9ILtB5vPjj2l37d7o56Lh4pF3Rd8F4F3QZ74EDssnZnllJU8yAIxEpbRg+UX3yPyQ69+dZ3Q==@kvack.org X-Gm-Message-State: AOJu0YzQ+9zQi4b4ygjOP69vYLzv8z9GQgnQ14M8XIdq85mOsWP/7uEi 7b0iQGf5Smq9OdykKxcbnbzbScBqEPepnqQcKx0rAzPWy5zvas5rxSxTRZAFTx3tP7C00/Hkuy3 s8TB5jsMenZVU3/PbwY1HJMZQkTE= X-Google-Smtp-Source: AGHT+IEzRVlMusSMhWJrKyb/zQLVYBZSqkVptzLtiq0YDdKI0GR2lLsCO5YX7YYNCeBkDo7XSEe8XU/28DSCo8iH808= X-Received: by 2002:a05:6808:1316:b0:3f3:b6c2:a29 with SMTP id 5614622812f47-3f3eb0a4145mr12494123b6e.7.1739988590372; Wed, 19 Feb 2025 10:09:50 -0800 (PST) MIME-Version: 1.0 References: <20250212141648.599661-1-chenhuacai@loongson.cn> <202502190921.6E26F49@keescook> In-Reply-To: <202502190921.6E26F49@keescook> From: "Rafael J. Wysocki" Date: Wed, 19 Feb 2025 19:09:37 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AWEUYZk3yJjC2QFMzoCRuV9g3yUGclC0qBadjE9zX-9osdlpTZtdfn3fLdIXWJY Message-ID: Subject: Re: How does swsusp work with randomization features? (was: mm/slab: Initialise random_kmalloc_seed after initcalls) To: Kees Cook Cc: "Harry (Hyeonggon) Yoo" <42.hyeyoo@gmail.com>, Huacai Chen , 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 , GONG Ruiqi Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: B3ABA20002 X-Stat-Signature: ykboixjts86uto3dxghw5o9q4c41desp X-Rspam-User: X-HE-Tag: 1739988592-787617 X-HE-Meta: U2FsdGVkX19z8wO0FeW/K3lFt0RgGF87gyH+rxvXO8ZWEfsYTviBoi9IfASmjn55FXRwjsP0rB7q2AZttAqcM8BIIwL9WsA6Sal1TFf7lNX6ERlnjq1R/HfCXWKSLSceHnhPtLMz0UwKevaoppeVdCgBsYMDez2SPggmtSw3x2vsNA4pC/LMmvAxMoQbGfmE9yT7OP9RvnnWxBwneAimfcDRZvqVd2yS0Q8LLTnU4at4cTLNyrJpk/dxpSR//AkrRC9obXd4yJ7A2gfWZT3B8rY02+mwEXDNHMTBGw73fqpve27+7+zeoiH9zKFdDRVkTXq/GEH8yLSpSs6ut17GYeip5XsBjk1PvWno5mRgqMHcXHXspqJaewK3CZMnj1HfsbzqUTKzPdLWglxJkp3fNaKDtbGjCeVvd66v+j12D7b5NOK5ctLez1Reiv/6GibOmSTC5hgrpWUJhDs9PjhD8htlmdnD9SBH3clSzyqPeAzlMjOGBknPCbTTbjHoLh3HKl8XiXsEEKwVNQYD3x9K/vTUceI6+Zeav+6QTEko2/MfE0aBMguDUjbWXFEirGzwQf9ZMkz/m0SEGWsin3zNm9qO0UR+L5mNu8puRIcGAVRmyx+8m/EFyZdBKN19Hl3YqCBDDH6dcC6OYrDdIO0H0GMHrg+fpN/KgHNCAGgplWle7j1wMy/QhcBr7HNY2Z9ZgevHROlv2i0iIb4Lf6XxOU3Bx2C3rTKz1Pq5d+XU8f/4DvelGPgUpVNXsMeRBSgSlJCbsKXo8CRCfcDIMMfBBlyuQQcTY/USI8vJdJvywGvUq3N7SSx7oq2xcSJd8Ik8/BYcXzkP96GaDyoIQM5qA48lReXHzsBOSypqdIhLDJJnW/mzN7AXFfsh84WAS1hhQ/KjjJ3MbjQO5NWBEJDeO2AOrrqWVbmkhLtxiMEPRbOfzaDof3JgUHsVQEvoX+GIpd10BdDf6b1qtaWmFcl EQLK2kG+ Vic/QRTyK3fPxr0CIwdsVJVKQXcdFuYNyzQHk/mfb8TvwRwbl7n804VqwnhurvJzm6qMujXMV5aic/pcAxzxOSCOUGcehVs8nyHnp4Ar9mfYFCE/or4AFf/P3blzC2koIHageyQc6846FixvBa3abrJ3VIAnCW3g/bJsuROrt481InXl0ikfhEFjwCZGwMWJ8fHlkmlBwI3FyAOLEW96TyLKZ22f/02x8kTp+mVU1erbjGNUYSzbNXflX4ku1BW3GPV2/7Rvb+xT6M2gMyZjIWeQe5/Pk+6bQTP99hUouyzkxfZb5fsdsNIyZ89A7u7vzuzvb7pbEnLJYCUm0twtMrmoOLr4HH3tKN6QkYyVsWAF15mQEnX7TqNzwb0SzZA+omwj475YjXhWbHGuTUQF3EwiLkmWIJ95mj/7jbGyRcKk+jo3DE++BFr9Bp/teyNrmEWYN7vlGOrXr+ZGUh2oA2ZD7VcQ8iSoVPQFL06xaJt4qo4c= 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 Wed, Feb 19, 2025 at 6:25=E2=80=AFPM Kees Cook wrote: > > On Fri, Feb 14, 2025 at 09:44:59PM +0900, Harry (Hyeonggon) Yoo 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 sam= e as that > > > > > > > before sleep, but CONFIG_RANDOM_KMALLOC_CACHES breaks this as= sumption. > > > > > > > > > > > > Could you please elaborate what do you mean by > > > > > > hibernation assumes 'the memory layout' after resume be the sam= e as that > > > > > > before sleep? > > > > > > > > > > > > I don't understand how updating random_kmalloc_seed breaks resu= ming from > > > > > > hibernation. Changing random_kmalloc_seed affects which kmalloc= caches > > > > > > newly allocated objects are from, but it should not affect the = objects that are > > > > > > already allocated (before hibernation). > > > > > > > > > > When resuming, the booting kernel should switch to the target ker= nel, > > > > > if the address of switch code (from the booting kernel) is the > > > > > effective data of the target kernel, then the switch code may be > > > > > overwritten. > > > > > > > > Hmm... I'm still missing some pieces. > > > > How is the kernel binary overwritten when slab allocations are rand= omized? > > > > > > > > Also, I'm not sure if it's even safe to assume that the memory layo= ut 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 th= e > > > > (architecture-independent) assumptions are for swsusp to work, and > > > > 2) how architectures dealt with other randomization features like k= ASLR... > > > > > > > [+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 when > > > 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 conditional= ly > > not select ARCH_SUPPORTS_SLAB_RANDOM if hibernation's enabled > > (at cost of less hardening)? > > I find this whole thread confusing. :) Hibernation should already do > whatever it need to to get out of the way of the kernel it is restoring > to memory. The random locations shouldn't matter at all: they're all > stored in the image. I am not a hibernation expert, but my understanding > is that the "resume" kernel moves itself out of the way to restore the > KASLR-ed hibernation image and puts everything back exactly as it was. > Randomization should not matter at all: it's just simply "put everything > back where it was". Exactly. > Yes, the tricky part is the "move itself out of the way", but that's > required for any kernel that support being relocatable (a prerequisite > for KASLR), and KASLR is just an aggressive form of "the relocatable > kernel might be anywhere" beyond just different boot loaders putting it > in a handful of different potential offsets. Right. Thanks!