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 99CC6C02198 for ; Fri, 14 Feb 2025 12:45:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 022756B0082; Fri, 14 Feb 2025 07:45:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EED196B0085; Fri, 14 Feb 2025 07:45:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D66AD6B0088; Fri, 14 Feb 2025 07:45:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id B3F666B0082 for ; Fri, 14 Feb 2025 07:45:24 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 80EC645457 for ; Fri, 14 Feb 2025 12:45:13 +0000 (UTC) X-FDA: 83118520506.13.79B76B5 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) by imf28.hostedemail.com (Postfix) with ESMTP id 8CEC2C0006 for ; Fri, 14 Feb 2025 12:45:11 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="eQ1/CbWY"; spf=pass (imf28.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.177 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739537111; 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=AV91Ol/uGYlZ+kAk8FUPrqnABFWgsBeEvSHw1qGc9Ow=; b=YIgJJLl17uYN+Aw5o1ERP/r5/wdAI7VZ/mqgx95IJEEcytYrkaoC7ybPvLDPfHGIlWLuKO p2OCMFdHUIa0aQOQsppT3axOcL6KfIPcXIg6BKqchm4U47ncS6fsOgbwWsYzOJY0+/dOK8 VHFEeas0pBsYZpLejyliqA532myjcg0= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="eQ1/CbWY"; spf=pass (imf28.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.177 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739537111; a=rsa-sha256; cv=none; b=7goEOGSSLLV7Cixm/3S72IkQqkgTBn9MhlwL0j13zbwOb89d8QZXxuaNCGoDs0YO4DMf+x XHqDZ1WnAY69dEA8Ros6HSFmb/KBoTd2O5VBYEMrDAOA97GZrZps2VTllyCrCEy4Gv2yji KmlfszqhqNAGb0Lbr47SqdWVEtNKh5E= Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-220c8f38febso35514315ad.2 for ; Fri, 14 Feb 2025 04:45:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739537110; x=1740141910; 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=AV91Ol/uGYlZ+kAk8FUPrqnABFWgsBeEvSHw1qGc9Ow=; b=eQ1/CbWY3/xbRI7gNW1LDwOxi6uQkxJejBGUyNz/3/o0MIRKkoYlR0iHX6xW7liAjP 4sKifPOGW0JkGzg/y0vuqwp5OOvoFkFcE3Lt+3MNNmoN7PpBHrbepIe3ca3fOAw/Zrca n0At1DYrGVDbw996fA/6Ir6B4RyKrHxiGpHXwpDJyK0Kf1I7Vq4zgeX4pNpvn2uaKCF/ stQIvmOblPflbcIrgQk5y4FdMpDuKs71Ac/FwXyXJMMsnTuviGDpifIzyZmk4eKUf88O IFYtmSftxXLz+mqgniuO9HYl4vbOwErgGg6El+p7R74CJF0IQFLHq0PFCtLWGHnE+J48 aQnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739537110; x=1740141910; 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=AV91Ol/uGYlZ+kAk8FUPrqnABFWgsBeEvSHw1qGc9Ow=; b=V2+X1vbNkUfWCiUl/4Lg4auYzPVcwrOXBTk2TTAnbhFM8i/YNzJxK9C9eyOM/EyhlC YRmWNs3R357Zzt/mPFSUHk+CN4OkWLGdKQHOlIEeDe6zkaiR7sp3DLdnuOWsy7fVKhWw gSEz0fdAeQxe60YDwdxPgHDAuMp/JQ8oRxNH6et89kAUoba4byI9unfDvY7eZEc/fX2g FLOZwc7nbfO6Dm5/R423O6c9XrETpmN70gOdKRu4BoxfiaapsUu5rGuomlJbkgXCX9NJ 8rUKc43eF+nKthj+A8M9v1UWMWRPyRnF8xJTd7dF4HxmyHFoo8EuvZ3Mmxv0KvCkZiWA 1fzQ== X-Forwarded-Encrypted: i=1; AJvYcCW7M6LIvzGczv2tbjWNNFi49yzOXrFp3HQ/fIBExiLnnSZ32Ky9pHTduuJO/3xCi7CIkg9ge+ijPg==@kvack.org X-Gm-Message-State: AOJu0YxytS4cLYPPCJXWBhApfnqkG1wWnY6rtWjvj7SLCFNDYrY/Q9tb J3q7SJKBGQoNrmDvOO4lhPt6Ne0bbib7vHrpcgei/UB135Npd2OL X-Gm-Gg: ASbGncs8U6F7rij04mLCoV6HLcyh//I/hrYAZ7T9LzTefhsBBhHPSubYiDZOFwXlH1Z iIDZJ3lAdR+6O1DoozASxGBx34IJBL1nOKWf+iIQepZD9R/VXEIrf6lV+1x+60ym8WdgsSoQJt0 aNVzJwLChJtwZLeWxFaLhfNAL4SQXZi19UjeDVGLt9n6Dz6Hy1VqyX40MbmyKsNXrJvYOIKKr0f 3L3GQ3b5p/urApnHNKdSZhjLcJPMDH9OV6SRocF4BDwzDBNmi/miWx5pnzKXIcDWUdVXYxvByUv cdzgUeT2PtFLnU7x1a/3d91F9TDWut0lrqV4WKw= X-Google-Smtp-Source: AGHT+IE2e69StPZgPQBveZ5VZ37UHrxEJkVNnJNFO7ZcVLIcz2YwL+02E7YjNANvrPV/HbkC5GN3wg== X-Received: by 2002:a05:6a00:2e84:b0:730:79bf:c893 with SMTP id d2e1a72fcca58-7322c56f984mr16408464b3a.4.1739537110062; Fri, 14 Feb 2025 04:45:10 -0800 (PST) Received: from MacBook-Air-5.local ([1.245.180.67]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7324256e8aasm3030618b3a.70.2025.02.14.04.45.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Feb 2025 04:45:09 -0800 (PST) Date: Fri, 14 Feb 2025 21:44:59 +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-Server: rspam08 X-Rspamd-Queue-Id: 8CEC2C0006 X-Stat-Signature: s4eu3o3wimstdqnr4xyhyf1coudsykdf X-HE-Tag: 1739537111-964608 X-HE-Meta: U2FsdGVkX18YPiH4YmgeNfbW+MmFgsfckGx0/SyaKugityFg/k/wC89tnJalsp7VP7ZpyLHRz/6muIm5XM2KH7zJGb11ULOMN1Ze/I1UY5u957jGzD4smnJZTXKNZsw9XPorSvC2LAJTyTMMAPldLSPVPspZBUEu6rKaaZopbFwxBiEThZMiGf4aOzWUedPXKvchYlUYdW1IPPgo6iGpoRW+v22PNGgoKHKhvVk1MeJVDYdQIQQVsVXB6H/f7+sc2Mo7UxA8I+hIYhDJskYuDUue9WoDgOuYfMyEZUvb9yLGzkLcTK+ymcLdRAW/SuYgXhAJ4BJ5KPje4CKx5PMqf48YbWg/BhJJ+bKui9B2FNq7Fz8ppit2+oj4+O+fA3HbVWss2QgR2AgK8Wxq6nsA/80Y/jTOorf7nMzMQvrI2JLDliOoToKlwJgFQ/GvXcgFDem5SgY1ASGzhQIV0Xv7aM/Z/ynYfFRAqjDD8Tx8v5imwcKezDh3geKrN2R7gR7jk0iUBwHdts7Nd/DiYK6bmvDsYIoNSu3+7ZV/fZo+vf2atAxXxnnSjTusDmBtxqfNCHJTxshgJdo/Jis/jM/AzfCzrZeISbq3O4qjstHnBajWx9BLrCpA1DbQ/STgWvP8UBvHg1geJBI0qN3k5cu4QmisU8uZhOQNi5KzpQWxgAYh5W/3dnUnaVmsYxl7f+qsATtIGpKZkqg78W3tT8jcPmHRBb1AoebjYisADzkGmZNP0fie1QzaEh3L8Km1tDaq2oTp1a8ZuCP2QZNdL5efrDAx0keiQcSsiJka9UEHnaB94+FACXzMHHWHDVU4VwgW/Fyb3zPWt73Pvbidr2l/0B9IpqZ3N//Ahw1qb546+Sp2XXHyR/RjzVjJs64a0LEJg+5ko392QApWeaWCncNtXRQ1qmoad1XYeTds01XYI+UCczBfk8H3/1SHM6f+x5y1Kqw2RkSG0EQYXbTnnlD j1uUJsFu fptfCsImg8BiELOxns3ImcsQHDlfohUNbU24fFbYCojFB1l/R2tcOXjbfjAGg0T3J9/qKQaUzk7X+dME5pEtsLX1IB0pBDxcr4H3N+N/Ded3h+wr1tNsvB5aAXpEktQ1IALxXPn8mwFaZIn018HG34rBmCIhvmetOFZiiFu9q3JbALS6xO8OsgM0iTTtZLHDZGPcDa2L7SMqS04pltuNMlliLBaQUK50zkJbeZkciHHbtoCOtshGRMTZYgbWuY14vEOTDfdwjqUsOE89r6KXe8D9TH6MP/e90b9btXa+wsphla98SG4zT0lMtEGd6TL/JX/MEXTNJmbANDE8BAocOR6jGr227S9EXr1oHsejd3eVujhPj10Q7WWsCaZvl9V32dvpBvvTbQP49BvS6KawOjcP7qsLPhL1jfpgy0biM8TrfX3zDwFszY3oDzteMPT7aeNd/UthliYrXVfl4cwoieh/lsBEamm4sb9AQI4mfnrfGLhuu7njHU3n7cOS3D9/6YABN1RtdPbfMbYfXkfMDOUl1QINYYwi8hxZgwESSvks965j6sWQti0zTO/D85sZSPdhX 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 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)? -- 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 means > > > the code calls to exception handlers should at the same address for > > > booting kernel and target kernel.