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 DD103C021A0 for ; Sat, 15 Feb 2025 09:53:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0031F6B0096; Sat, 15 Feb 2025 04:53:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EF58F6B0098; Sat, 15 Feb 2025 04:53:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DBEC9280005; Sat, 15 Feb 2025 04:53:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id BE08A6B0096 for ; Sat, 15 Feb 2025 04:53:46 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id D4F291A1885 for ; Sat, 15 Feb 2025 09:53:45 +0000 (UTC) X-FDA: 83121717210.05.B53C590 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf10.hostedemail.com (Postfix) with ESMTP id D7EE1C0006 for ; Sat, 15 Feb 2025 09:53:43 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="oA0pkx0/"; spf=pass (imf10.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=1739613224; 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=XRON9YpZit+13IZCBmcmH3X3m0W/5w3xJWfXTOVxWqk=; b=AMNAwYzpUKHxPib7yggDxeQRH15RjtcW/fgM2LUgy5Je7E+PysokW9JqH7b1CKjqgAGByD WnA8l5NnBWypCSN12IGhQbG1teGh3qLJwTqhFznK3FwfIinFa/SAmgQ8+TuwqXskp0TgF/ 2dmPTcDdrAZXrWZuTTsB/lEEiin2FdE= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="oA0pkx0/"; spf=pass (imf10.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=1739613224; a=rsa-sha256; cv=none; b=O7oMSknymCITUTGBV+txiLux6Wrj0lkBppB89EOCiK39PY1zRBDkUqQKa/UMAKZ5S/hLXL v/NutdVAKn5UPXmiy9otwxhmVXLFJIG8fnHGBjCmSHdNjnpPuU2qKCTxXbmQpttp1MuiCI 4g861M2LDU51bqXo6lAOx92ewZDJnAs= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 4CA155C28A6 for ; Sat, 15 Feb 2025 09:53:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1FCE2C4CEF3 for ; Sat, 15 Feb 2025 09:53:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1739613222; bh=XRON9YpZit+13IZCBmcmH3X3m0W/5w3xJWfXTOVxWqk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=oA0pkx0/MESTfEIvJadmKD6VCVArPKOcSHHrGsAU7Vm+LvyVk/GWxzfItTXt3Y4PR G3GLXz0+2L1uxKP2wCfGO52RAuJ8PYKJIrNP61lwQxHONcPt6zQ/+URxu4DcleZNav SpfM4qWOhYMADuy4jLX/1kTWLAPIoOKcBHBOTpGBSkRzPM88q2TBCi3CI5gQBngoF5 eo8p4hhpRFCWA2dNmWu+NTBSInQrdNWwaND5N5Hv9rUAnxumaKzsyDetNB7wLqsPGO vf92XVxvTFWexrGXEmbcvCzr3+8Pbt7N0NRoJycH3iToTW5YeX3X+4jC51lgL86AGz xNHJ8J5NGeevg== Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-5ded1395213so4311252a12.2 for ; Sat, 15 Feb 2025 01:53:42 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCVXyN6CdFmBjXzcBk86V2BMtyh8MLT182JdQEeZi/qMcvSqpEbCnjjtAyYJAEexWyiMsmhhwwe/WA==@kvack.org X-Gm-Message-State: AOJu0YweMPCON9IN+vUO0xn1q5Ys52dWvgg7h8R8p0Me1ZzTwszu6pQc IkyG1ZsCo+cbA3zTPRjHnOOpy771EoOczFDN96l6oNciQoy6iCBKz+r5gIxgln/3eKF3pT30SSG okTXZo+saX6UNfYAa4MxuxVxdcP4= X-Google-Smtp-Source: AGHT+IFQkktP4/XZXdQKDzrldOcGrW+VT8uHPIAcZrza8zIIRSr6WzGkT3I/FT6WmfK75v5Ts1MUFtLaUBNk+lVlKwg= X-Received: by 2002:a17:906:3158:b0:ab7:b8eb:f725 with SMTP id a640c23a62f3a-abb70a7a54emr190367866b.7.1739613220431; Sat, 15 Feb 2025 01:53:40 -0800 (PST) MIME-Version: 1.0 References: <20250212141648.599661-1-chenhuacai@loongson.cn> In-Reply-To: From: Huacai Chen Date: Sat, 15 Feb 2025 17:53:29 +0800 X-Gmail-Original-Message-ID: X-Gm-Features: AWEUYZn1B4iVF_hrPKrMzEuFIJf7ie2bWNy-5mfqJDkWYIXZqn6mcTtrKk52_Ko 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-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: D7EE1C0006 X-Stat-Signature: sodp81crr8wxqjjgf5bb6oty5i5f54nn X-Rspam-User: X-HE-Tag: 1739613223-4092 X-HE-Meta: U2FsdGVkX1+CZJZKpfu9zeH8XuCbZRAEe+D+Dg6xV91UNMdivVoZgZiE2OWt1s5jRq0kYAFk7hkaFt695gDspp73F50NNlQelKbYkualvsiIyE+UVehYAQ39UrlNDBE+/ZZb8Oj46SfCpdqk2e5sBkphrMnD+f5UybEq9MO4/0tcJ3q4Fn6mK4IXGSlTwwenCunPRqg1mMdf0NoSWFLyejupQV+BIik0VkKaNy1tjkabdk47RKa/VBaOBjsEVzfGMft5AhR0raUGTPAEdX11CxWdVSHt9fhYoDenllnvQ8MhamekBDyNKREeop8kwFb0DUUOpYa3prtsFkuLzNF1DDQqB5HAAU0kC3QBkkQs16UmbZ6tgge/DixWHnl/SCbx/X4qncZiK33mHUK02/+8TL0An13qkibXBiYM49k+SweQ5uxuzH3DXm8mlMPLexfIe2DD9Nt88hVtt/EJ4b2lfSxB1sgLGTY0JWGpAtFehKjcPW/LId6ZOKSkB1tkXdpMwI5CjY3hdMaU5FP5Lu/ZEdXLKaxNkZileHCxD1kPuiUDTIvkQNh1aMMRDatj0XjdBMdrWZV+9ZGGXZtG1F6chY0Zazxm37slzMydbzmMN1U17GlSLNP0TCvD8M+rQpwJPpnx6mqu95EjaxSNKS3rz0aYAmlEZwb4BR1Inamx4CbYPLVF1R1vFM2sUk+ixbf/Fi7eZooxJvS4gxtJDi0hVozX2yvEUx9+RP7JVdsjHr7RrCoWZ79uguGJkonYz6nc2kfgY7jeGatVeWZ1j/AW8H3d6/9UWMp9VllPCarwAJ5mt5bUHV273QhbGqxKaxg7E3Vl8l0iNtQP3id770YMm/LUX0FNWdWY7bwCRRD1mAoQXCUrTd7CG0nG86CH5nv9I5lJYbHSWeO4KnYpGmS/Ofmv7UIkuc5AYy9tTL6MYrKs1mfRK/+sg0yGiuHO5Bp6Mp2HqTUNafw+yKNObU+ lNxLTqdW 2H09H9/DYTmEocdTWtyZudTAy0T3tcJ8ithR4eu4j1aE4yjKaQjkSAN4866KPAZWmI+OxFx0P8awrT341gtHgdUM9+M7YHj7hwoVWShuw6RnsWZEDP0MfePvbHyeL5Fva8u+7XOjYyFT/8IBnMZ7Rk2qenYVYr28HsKxqNUgDpRDSIo5ZWzHd5ufBUawqLjVCvbCCpLlxXXG66HW6ee5kvCxqrXtHcV3Xs+Ux6PzdQm2/Z/mK4gzJX5rDFmZ5kxuMIYjxlqQHsW6sQ8zLxigHLiPA31MnLZ7UzTMDqxF4W2mxrjJ/wrLuUt3ZKgErEM5LoMlfb1XbFJwQ68WEaskenFoorOOiDxfaz+KWo8aJKrdoYk9NPU/b9s1MBTyg0QJennakD557oS/pY26Qga3R0VUab83i7UW3WE+sm+QtRTjJw6300CR5kchVEcOhf9ppnL5oh87OOLoJzgZJPLGBUH9nCg== 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 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 same = as that > > > > > > before sleep, but CONFIG_RANDOM_KMALLOC_CACHES breaks this assu= mption. > > > > > > > > > > Could you please elaborate what do you mean by > > > > > hibernation assumes 'the memory layout' after resume be the same = as that > > > > > before sleep? > > > > > > > > > > I don't understand how updating random_kmalloc_seed breaks resumi= ng from > > > > > hibernation. Changing random_kmalloc_seed affects which kmalloc c= aches > > > > > newly allocated objects are from, but it should not affect the ob= jects that are > > > > > already allocated (before hibernation). > > > > > > > > When resuming, the booting kernel should switch to the target kerne= l, > > > > 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 random= ized? > > > > > > Also, I'm not sure if it's even safe to assume that the memory layout= 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, and > > > 2) how architectures dealt with other randomization features like kAS= LR... > > > > [+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 conditionally > 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. 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, 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, 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). Huacai > > -- > Harry > > > 3, When CPU0 executes the switch code, other CPUs are executing > > idle_task, and their stacks may be corrupted by the switch code. > > > > So in experiments we can fix hibernation only by moving > > random_kmalloc_seed initialization after smp_init(). But obviously, > > moving it after all initcalls is harmless and safer. > > > > > > Huacai > > > > > > For LoongArch there is an additional problem: the regular kernel > > > > function uses absolute address to call exception handlers, this mea= ns > > > > the code calls to exception handlers should at the same address for > > > > booting kernel and target kernel.