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 09CB2C021B2 for ; Tue, 25 Feb 2025 11:35:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 615806B007B; Tue, 25 Feb 2025 06:35:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C3586B0082; Tue, 25 Feb 2025 06:35:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4B247280001; Tue, 25 Feb 2025 06:35:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 302C26B007B for ; Tue, 25 Feb 2025 06:35:30 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D6C9F1611BD for ; Tue, 25 Feb 2025 11:35:29 +0000 (UTC) X-FDA: 83158261578.19.90FE68C Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf20.hostedemail.com (Postfix) with ESMTP id E64201C0002 for ; Tue, 25 Feb 2025 11:35:27 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="qh0x9/uf"; spf=pass (imf20.hostedemail.com: domain of chenhuacai@kernel.org designates 172.105.4.254 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=1740483328; 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=KXFZfcc7XbnsLiwkxI328DODcNjmY7AfOm4ZSVUusbs=; b=XjiRe60/vtxoMvVFZHNk6XL7JKMvi0yZzAfj4TE1BJHCA7xHZw3vQeZC+nwDL9RjSee6zu 4VyROD5W+O8EAbVdYECrk1bI/bKfc1QkTt/AaEX5QOZa1/lYyfCTOGw61/xlyxFR4nxln6 88zG0H7WHjjq2flwNuyDNs36kiW+7Rc= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="qh0x9/uf"; spf=pass (imf20.hostedemail.com: domain of chenhuacai@kernel.org designates 172.105.4.254 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=1740483328; a=rsa-sha256; cv=none; b=2ksvoccOThNzx3mXN3imHOJFqTfbB0Sg4c2l4JCfYCISP594pIuWVmg3l+WXx9KA9TOxPK Vrq8xg8Qk0O5Z8dHuCN+XJYUciq5b5YoCb3+Mazd4YjJkAnACiU09aZWQJQpCjlc0EvrAR vrOH81Y6bn3V/wff3RpQoVOySi5l9fY= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 69D6F6126B for ; Tue, 25 Feb 2025 11:35:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6CB6FC4AF0B for ; Tue, 25 Feb 2025 11:35:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1740483326; bh=KXFZfcc7XbnsLiwkxI328DODcNjmY7AfOm4ZSVUusbs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=qh0x9/uf4R1sR0/Rl8ln53jCjkTU97MmFMxgzZy7UrSI403zrugaLWC1UjXnrlA94 rAZ42ro7SyRS4zmyMR3+bA42+oMhF1bPTddNAw6wPkj3xxtuuN0smK79b8+628veAk 2n2ngsoqvnsco/aD8N4ndLd7pW6IXwct8SQqEwcUacyuL4nh46znKa5VDg8YIcyxIm DB/XtsGhQFRCdB5iSIpHNuQ6JTr6tmudCXMFmJwUrPWcuKJPEnMtisZC8XLpaX3LTm Pr0xStRQmAKAtQlgNdcCwAeoRnARbRSK1pxRzbJuhjuB3VKewMB1qeanLMVutqMTUW S5HRvaqlQscvw== Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-abb7520028bso733131966b.3 for ; Tue, 25 Feb 2025 03:35:26 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCXafKQHAmXMI2Ay8PGZmai0wwo+DYlkimUl1HekgVWhuSzjkojsGk+n3e5GaglT6CjtFZIQ8WTQcA==@kvack.org X-Gm-Message-State: AOJu0YwWIZs+w6IfrRok/gcnfO4m6qMSTulZhjaaZb8wlW0YswV2H1/+ h/d6cUolj60j3qVUh5s3zNtC5DtcaMjUEaUssUDdgCriAsq/knh8iXF8mw4hkxfDNWZ6sHm6ONr +7xXjD2995HJ8w6QcO1+UeDEI/pw= X-Google-Smtp-Source: AGHT+IHpNm5R6d1kXnggyLRBiCFLHj7c8aZbt3rfulQuZsViVrgOnfz9UD3ihQBKZctEaUuFInNweAbCbQHy84PcLNQ= X-Received: by 2002:a17:906:110d:b0:abe:cccf:ac88 with SMTP id a640c23a62f3a-abecccfb0a7mr357469566b.54.1740483324943; Tue, 25 Feb 2025 03:35:24 -0800 (PST) MIME-Version: 1.0 References: <20250212141648.599661-1-chenhuacai@loongson.cn> <202502190921.6E26F49@keescook> In-Reply-To: From: Huacai Chen Date: Tue, 25 Feb 2025 19:35:13 +0800 X-Gmail-Original-Message-ID: X-Gm-Features: AQ5f1Jp9_oaXVTIfpV_aoA35urmG2ZqS7ChPrwpnZ1qyFh1PmoCPuWDgFLWstUE Message-ID: Subject: Re: How does swsusp work with randomization features? (was: mm/slab: Initialise random_kmalloc_seed after initcalls) To: "Rafael J. Wysocki" Cc: Kees Cook , "Harry (Hyeonggon) Yoo" <42.hyeyoo@gmail.com>, Huacai Chen , Andrew Morton , linux-mm@kvack.org, 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-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: E64201C0002 X-Stat-Signature: kktom67kgi934tnrctqo8wq83r7seksb X-HE-Tag: 1740483327-948042 X-HE-Meta: U2FsdGVkX182js8uhmdQptu7c+tU483owBmK8rHAvPQN6iTHfvOfPvqw2lOcefy3je6KuIWY8s/V+OIUoTBT2cHAvipnQvt82hFeK/UIgpA1IkUggx5g/Fbtno/QDPD+KkOpEXId3vzW9uICi+hp00SnDDfibZIcnE8yuL/Y4AuRN/dI5Y8Lt2sFEwrJwsFDZ6kb1qCPHiOdTC3zAZdXSX5uEVoGqo1AJR4DcMFUO2b853+gdqt2zxG1iMWcer3fSWkNPdjpbCBaAD0xJeZERQBFtI3ysBquzM81rDMNhgaxD754TpjJspJSIlROeGP13c7sIONjAg99Xa8FkBw5hC5xTHDaeCZ5ZlWPnJ3cLz9EqmdHdfrjKIst4FPQEYukLi7YmXB9yv6pwXxrCo2XXm/yeFoPl1Csno2mrxUzSQKK1+/rB+MZtwKKHoWiu7x6Tq5u6hd2Fu+Em9h+aMfbI5dZI27ENqvLgWiv66uDGQwHi5L8XFRygM7q1sGa0SyXXcPWB8NO8wxcmZkLhovRPiXQxzzLmlUxDwvWUx70ZhbqsU173QB58Ef/WXT3j+0jFSrfo017LI9Nud/fIvl/nyMEjdXvpPI5StedILC0wOM66ztBIMIZd2RJOiYcSgvnAkrahrvEW8U4GwMRHQz6Z3emj/oP2V1FYaUGI6n9JoMnPnyZ+XeqSnBxJ5zSjQXQzODXqMO+3EJLyn3F/o3PPxOJ1rgw00o3o/BzhdHYKKMetA1zs6me/7Sm6wD1l6wuAR3n20jDRMjOuQ3nSW7TC1Btb6lMVx6STxJsiP9WQVvEZOFCnrsqVciE2q5hba84FWFDM50oleAHxe8yydJdFbOi1JPZliCwksrfA3ztO4z/zbqhQl7nPqBUbHRTPplxOkOGlvC7V8LP9unaYNZBisYfwJFkcX5hkYUEDJ9gVQX2yRC0ZEnIvxRsgjP8yeeg59yMANd5oILAvcy+XNj GmqDWgrQ ahQ1LG/qK2JxCg/9zWYjgJknBI3pA9YlNWdeL3e2gL2ba3X7Smj6MGbODrttIfrnQOhd6bhCh2bCKIecRNnd+Du/ZNYZ9jqMDisyWYz/7U/msDKnc2w7a5l7rRPpJb21cKLUrVkLUI5GeBEJBj89G/IdQnbu1d0NNrvHP3B/Nyfh7C1vg+S1H3VsaLwjIslJSQK8rYAKINkOrW9WLcH64TvXax4Xx3sJ/lgL/0dD0bW3KSyr5e4MlfqGCrRb2jQf+LttZ6t1Gkko+fuMg+x/qrriVd4nVOcorCx9YQ3NmM5A+lEjSigcYsVusajgcoeKyABn7/vw1+F7c7V74YYzBIqu98YtNxB9eJWt2ZeaxoAVpgdtZYP5lLg2c/eY4P2pkpl5i9IN+x7AtZoE7f5BAN8lm6g7chpgF3T/CesoEA0qITCZZF1DOo6wr3ZIXqkBPulJybJnqIwK5WXv3BNLM7XXUZxtrWIdRmSRTQDhaKNX1ALs= 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: Hi, Harry, Kees, and Rafael, On Thu, Feb 20, 2025 at 2:09=E2=80=AFAM Rafael J. Wysocki wrote: > > 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 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)? > > > > 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 understandin= g > > 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 everythin= g > > 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. I have investigated deeper, and then found it is an arch-specific problem (at least for LoongArch), and the correct solution is here: https://lore.kernel.org/loongarch/20250225111812.3065545-1-chenhuacai@loong= son.cn/T/#u But I don't know how to fix arm64. Huacai > > Right. > > Thanks!