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 689B7C021A0 for ; Sat, 15 Feb 2025 14:05:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BC37A280005; Sat, 15 Feb 2025 09:05:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B72476B00A5; Sat, 15 Feb 2025 09:05:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A3A10280005; Sat, 15 Feb 2025 09:05:51 -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 8675A6B00A4 for ; Sat, 15 Feb 2025 09:05:51 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id DD10FB4B25 for ; Sat, 15 Feb 2025 14:05:50 +0000 (UTC) X-FDA: 83122352460.28.413C7A7 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by imf18.hostedemail.com (Postfix) with ESMTP id CEB681C0012 for ; Sat, 15 Feb 2025 14:05:48 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EPseUv73; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.172 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739628348; a=rsa-sha256; cv=none; b=cuyYOn+rVT3fCf+YJSFqPd9Qds471/q5gEJMc2AqEP/ZyR38xkz31okTDlak01GJgcngSd nyQc9M3miWYjiYOeDFvvhpGaUGfMCNG1JAv8sZnArCDIXKo7iLz2GtpOdMRbVVzgtRVodM vs0hFiTzMzHp8gZ5x+RCSCiMTIryrKs= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EPseUv73; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.172 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739628348; 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=J0EBfoneyQ2m5DKQOCwe2zek2SAqeGp/XPESUcXVWkQ=; b=OG2Hv7Ejnk6Oit7Uz8dVPA/4Z34BWfdEhv6gK1Vr6fp5E5riAjTnXsykgCAH5r7L/GUxZU XcdhHehbCFVm14kb1VsqBtMTkd2Em1zbOElUPGxw9O47fGRWYdY2msyJCLfEU5AyRy/mJn 91aE9wY8Dk7NlyM6AP6Q8TQ96xGqZBU= Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-220c665ef4cso45031505ad.3 for ; Sat, 15 Feb 2025 06:05:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739628347; x=1740233147; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=J0EBfoneyQ2m5DKQOCwe2zek2SAqeGp/XPESUcXVWkQ=; b=EPseUv73KgYlJ8aIX02PeWZI8M+LsNJb0vUbloRre7FK5rfW3eUIiJRkv6ccq70m8F RVYotsTTOaigR+iY1AtU89GnsLhT4mYgPuxgbHXIXl7IPIOng1YqZiTik0rZBIhqO9Sj Q8spnZFwx8/mQGYaekwZ3/soajATgLkw4HtYIV/UDSFEuijhP6s7tNcAWirqoDKiuEu7 rgxbgIG9nEytk/zoBbi4u9aJReAEvgXCxLxRSXdN2jCgVBHDTbo9ZW+k40AHFYdE2Y7s Ce4fw7beG0HHNht55PSFCHnarCpIWTkVRxfHTktYk7tfDmDb/vKRznsrtMeBKe4zZe62 3Fxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739628347; x=1740233147; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=J0EBfoneyQ2m5DKQOCwe2zek2SAqeGp/XPESUcXVWkQ=; b=P4EtiNb1rcLKdgM5HCujCK4sY6OOiLE7adsOFxmhCxG6WEpibT4IiVAKJOJJy3JZqT JYuAvHsZEscwBpBkodMQDrBP9op7wlNFbE/R2wkprkDFgYb2JYNtyeWrZxUfRpsWUhgs 3ckGbA5QkDCLd+QKMnge0ayxoFsU+WMRKHLpmCRbYER1RQOOVEk+mbNFjrldfstReALR NZdiZh0hoCVDyUdP0woMv7zvD5NxAehqSB6ISz6Px66Oa/CjV9XwsRZ29pHh6Br1lbea m7ol3IXoy8vdjBIWJULswLzAXF4Q9OMsgBqwzvtChSF2nRBBUtiHg6ii/pElbvYzq3lT 8qgg== X-Forwarded-Encrypted: i=1; AJvYcCU8jla/9JJgCKwfpv7sXIXYB2GdgFoa2ZKHOOcEKFcTpBMPnv5rq8TE0ZheQ6WGQ6jE/gK6p/eRSg==@kvack.org X-Gm-Message-State: AOJu0YxmrrwO9cqQTZ/pjekY03bO9hZ1PBWKYuAZ5nvnsyGKR9sJw3qm hwUWxP5+IqfgiLbu/Lm+Ap7aYbyCnFqJBJtb91ihV9eD/OcdqXbLekKHXe/p X-Gm-Gg: ASbGncvBlCIo19ShIv085Hjv9N75hNi8BmQF68QnZn/kZ7K22k9KelPdAezCL+9Go9M D3xcjRiDs+jZE1tb43b/HGv4XdAM3lNzQ4mN617DmxRj/VsOyuLJWlYPjb/mN8EJk8SxjNIUro7 qLtl9oGfroWN/k1lVikz+z1oKKzRgOkWtgym0FUJwlJA57QQrgYxEG+vyA9Fn/t/cXHu5LAplkx Gb/DEU1ZatStD9A84HPe6oIo8fsEqMqwYry8r6GymmWdgsDA8Pvbo4Z9CaTqLCt2koRI6Qp9dXC tfu3ec+6xFDMpDnaFTujhIEkUiRQ12Yg9g== X-Google-Smtp-Source: AGHT+IHiwcNhpRT7FDtJmA7aR6hz4/Zu8vY9uHoO6iE0CSHXcKq43K5Cs5Gy5oFq+I3HV/fZTOnkgw== X-Received: by 2002:a17:902:e841:b0:21f:860:6d0d with SMTP id d9443c01a7336-22103efb488mr57653765ad.5.1739628347291; Sat, 15 Feb 2025 06:05:47 -0800 (PST) Received: from MacBook-Air-5.local ([1.245.180.67]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-220ea7a9348sm29804825ad.211.2025.02.15.06.05.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Feb 2025 06:05:46 -0800 (PST) Date: Sat, 15 Feb 2025 23:05:34 +0900 From: "Harry (Hyeonggon) Yoo" <42.hyeyoo@gmail.com> To: Huacai Chen 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 Subject: Re: How does swsusp work with randomization features? (was: mm/slab: Initialise random_kmalloc_seed after initcalls) Message-ID: References: <20250212141648.599661-1-chenhuacai@loongson.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: CEB681C0012 X-Rspamd-Server: rspam12 X-Stat-Signature: jni3ua3dx9zjm3qea8w7d3hwg7quomrc X-HE-Tag: 1739628348-984010 X-HE-Meta: U2FsdGVkX1+A4+fVbd4Kf+iMGDjz874wTPVzr/rIxeqEnuaHlBmaQDzK1AwL3+FhDPgj4sgpsxoAf+5mk4w3uTi4G/zkrunI/gfrS2eea7SFCmIldPzuD0Vf13NPL8oxbReBrE8vN7Y2LhA2lT2mhdYyHYgPNszUEDdb4z1E55/N19o4eabjsx+3NPX4aQSUB36dzL87cLlyhUnQjmVU0jq3WV1DppubcHiVWjAbNF5ruMT4y8247mTLVsz0t8UqNn8VbcWqO/S4Yq4D+vZp0VifcJBPdDRLf5wbPh5ZHB2G45h15YMXGO/ra+fC9kEWfO/9J+8x7XOPIq+T7welT1ZsD9ve/d3FgoMnqF1QiovZp2jCvP5RVI2ODqvJxATixhU4yAA48TBEJmzPz5H3LpE74MniOO9BTq3KM+JLSs2vLeSh8JGd1COOfDidj62WrMWSfEbyJmFTMD0HZ76q9S0Ftog4TvLUKpsRdDomC4iUurt/gucxJ/rTC5LyfKP+T1voCXpsYGMKH15WML0jfscu2+dQGnyrQy5VbAVjlt+5xfPxJzH9ri0ufSm3jyv9IBQLMb0gd/bQKgyhzGDyE0Xf+GVjiBrUKCKIWnFgxGiMb6lo281HUK1q5ZCtBcuym7SkkXpf1FOAAco67XvaXsfDLNXHLif9R/tUR/sCN+RF0J7O/IsybWxclEFXo7jmB81WWgsUFqOUs5iyr1h7Bh3Zavv2+t0VHOHMtwtbJ7+pS5kP4+HnA7kIdieegMMk2tqPUijwGMW0QTaOpk97DUYdaI/d+ZlFhCR7fV9IL6YG2ht/szOlnBIN3upb/VJTeFBOPeLRStMv1xqcFzNK6IpBrZHVnqqJ7ZwcZcHIXsfzeLs4AWH2A2Em1/K49KdyLHX20i1vnIwLsAh/ovD1LI0HiRhTNxXsnHo6kxG8Z5Mtp26Tf/7+caSfmpV/PQsxMnF2kvmlsWhEevyJG9J xUwxHhuR 8S4Xnzn2X/k724r6Li9Eg6KUqeUjI3K86X08yTbzpmFpQoleWytoPG/y6QhAa7oJVcDvvOT3azy01w7YdcLKXhzrERKFNlbTeX9gytiFywbhIMQ65sXo0NGajQ9bCwAvtfbC2K1nTJvAfS9lk6kezkgWofSk9LE3mkviq3u/FeYwF6IfP5cPYw/PlQh9HS77GBMrc+A0BrbPlWxBfr60AZExynokEnAG+6Eh/+Vh2NPoErg58e7KbPYQj8kaXoMU1k7sjoM14EkbAvyQGw77QHsobk0NsevJODC6tYJYdw5/ceB6AIWLQeTWjDpwUiR6foBVW9YVRNKuQBdQkxDUzOrleYOGhia+I/T2Qlb94XwRk7NAGWwQVEJbzgpLqX78VdsOXE0A6/e8mueP4ZBIul+XCvRM0blnUD3aSd0khEweh/9jixjh9b2Bizote4T48NcPyXs/C+jopWns3awepkpO1Llc88lpQ9Zhiv1aeYC35A/v6h+lAOnTLp/4hLW/jJfS7KWe2umTpHyLiw9KHQ1hEPVLoHEUJS3caU/qazaMQiqngNj+ikOyDG3eAqWhd6oba9p0HRpBBWdgaZus78O/bN/8U75A7oqejqqYNBeqHEvQU9xsT6+Jhc+Macfr35mWG0BvxW74anv0= 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 05:53:29PM +0800, Huacai Chen wrote: > On Fri, Feb 14, 2025 at 8:45 PM 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 PM 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 PM Harry (Hyeonggon) Yoo > > > > > <42.hyeyoo@gmail.com> wrote: > > > > > > On Wed, Feb 12, 2025 at 11:17 PM Huacai Chen wrote: > > > > > > > > > > > > > > Hibernation assumes the memory layout after resume be the same 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 same as that > > > > > > before sleep? > > > > > > > > > > > > I don't understand how updating random_kmalloc_seed breaks resuming 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 kernel, > > > > > 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 randomized? > > > > > > > > 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 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 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. 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. 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... > 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... > 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? > 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