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 3E8CDC021A4 for ; Fri, 14 Feb 2025 10:03:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CEF4F6B0095; Fri, 14 Feb 2025 05:03:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C9F426B0096; Fri, 14 Feb 2025 05:03:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B66D46B0098; Fri, 14 Feb 2025 05:03:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 960706B0095 for ; Fri, 14 Feb 2025 05:03:08 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 41518C2164 for ; Fri, 14 Feb 2025 10:03:08 +0000 (UTC) X-FDA: 83118112056.25.E73A466 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf07.hostedemail.com (Postfix) with ESMTP id 445D240005 for ; Fri, 14 Feb 2025 10:03:06 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=NBUzqpiZ; spf=pass (imf07.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=1739527386; 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=jO4jhFQ85OnGWdW5dvqK63uV1QT1n3kqXLhiHck4gg4=; b=fdmAHejLRtecyR3LDOnar538KoFlYtQHWhpr+KDCDQ5k5Eh+5UpX68BGo4qZQWcZkXMMR0 c8A13LXxFlEvU71O1uSOqbOqLOXAuwyQfkYepII4M1fnSCaC/+/boKwgSxjjiObsYjoYcS QmgrpzP9W5Dt2rddZ5gD/7TLNwM6YHw= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=NBUzqpiZ; spf=pass (imf07.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=1739527386; a=rsa-sha256; cv=none; b=yVlkzaX1cU4d+XtE0loRkC71rFWqkQ159mpQ1W4X2n/LztuEltN6v4ljH1m/ZsARW8tfcp KI7gbulOIhBaiKl8C9WnmxV4mSRr3sYEfxf9RsDjvcRKwqmF39XQIO+1O+R3DySqAxNKpX uGI33Kmw/iuE4DpnwmKhRA1rUSRm778= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 9A92A5C5A32 for ; Fri, 14 Feb 2025 10:02:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 94072C4CEEA for ; Fri, 14 Feb 2025 10:03:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1739527384; bh=jO4jhFQ85OnGWdW5dvqK63uV1QT1n3kqXLhiHck4gg4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=NBUzqpiZM2kg4A4aIeNUBUOibeqSOVdTCCgLV7S9YEmAYGt0NjfihqdFPpBOv0s0W jHiJpvv422oeAnxPw9TgpAFL6ICc1RXReG+91+C3kqltaHlwiD83sE0iG0GzYL25Se blcuqwNMeJwYvQyxs1zgwx6Rro5vOwC6vuoiusWrnlvGszdUg7AcL1Kt9BQmDKdjJ4 +tlmYpT+SkOSAa8HJqIo9OJVccxvkB+1QKjFtTK1LLcqSWCpF9lSH5NjFMBNwJUlzE jnzVUo05iIxhqGda+jA0qwijumlXdQZ1Fdr7ca+Cy0eyaPRi0mZb54o9rzVenriGTS 8022g8FGeOiBw== Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-aaf3c3c104fso301428866b.1 for ; Fri, 14 Feb 2025 02:03:04 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCXy+7w1QVGcnZIdbdevZzfifd8GUgjXe5Ff+TUAsnD5TUHcO2YPLA04Hm/wEJRcm5WWRYEIYxiURw==@kvack.org X-Gm-Message-State: AOJu0Ywx/fiN3jP1sD5VtcXw7OvE1/3l+Bo5HvNHseLy0QMlhvDDe7mc w1OzKpL1Mo2qCkApDZoIrBSPgVX3uNwaPeAu1PTiPvgi2+j6sqh86iaV/+9nJHPEEQU/V076BAg HDZxxBdt/mb+TVqXCm1VNs2DI35Q= X-Google-Smtp-Source: AGHT+IF+gf9jQe7+2YADT4xx62KGGZLtUQx0JukYMtr4LvBbe4Kkbx3IFmzUu9eWSkMmaKUi5YdGeXvyYy9vwpY3NL4= X-Received: by 2002:a17:907:7b06:b0:aa6:7737:1991 with SMTP id a640c23a62f3a-ab7f334aa67mr1128081866b.2.1739527382895; Fri, 14 Feb 2025 02:03:02 -0800 (PST) MIME-Version: 1.0 References: <20250212141648.599661-1-chenhuacai@loongson.cn> In-Reply-To: From: Huacai Chen Date: Fri, 14 Feb 2025 18:02:52 +0800 X-Gmail-Original-Message-ID: X-Gm-Features: AWEUYZm7CELBuJgCgpXlQjQwq3zKmA4KOCzMtVj82ho-oFkUscdkn1NgvHwjb6Q 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 445D240005 X-Stat-Signature: byo9wpmquhuekrmq9pbwgn8b1hat8s1p X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1739527386-802865 X-HE-Meta: U2FsdGVkX18nAV2cP69OBH3wpHrjO6ymN/7XLMb6XQV6yhBPUfjlsJhYFm6/bASRXRjjsSlZnUZCTNNfzwlGOaGELg8CzRmXlxfMTSEe/m0xWzXrYLA6ypu4zwFS+nLu7W6AWkXSojbVTk6qj2b58U31EGKJbae9S2Somj7cmjdxRF2HaJ1CrNDuvsCKksl0bU8y+A54dPj7Hdk65Wx2GhT+9VdxOTtWf01hgC/808K3OiN8ROrKM0qpjFNa7QUCQgZAYO/7i7K9Sfb3tO59glWjfH41Bsl5Pa0G5wGC9g2/1wfWHoHbAB+KMahT3hLuyNDx9+EuIAh6rer2QuA3swgZDlDc8ol21xQFE2q0Xa1cersXop57QEIU87D0bejGObnufHq753aFfSlVSyp2reeGQBl2aT1UFFiY8CxYS6Yer0xbdCvn/V0jlkj+x5Z4/x6hu8ytiN8hb6kALAa8Qc0/caJHPCk1agaDg00pmLvxFo23kOyYuKJxyAFOnnjg+vNyUAqH7XzTBoNBKfyRqCcLWXsCh0vAGQfEYWvKX7FQgnXYosPH0N8O6VBYqHNTEaAiY6a85/PrognS0l019pFme+iLnw8uqrAxAHui+NllkKr8iAnH8pa82zexjI4lMUCUSwPqWy6aqSox1NWnQCnzS+zE75mREakjUzEiiBd+LGUTJYG05pP4jcOz3KlU4vnpujezcZ44p4L1dlDZ+PKLcEg2vVUHDZD2WQL/CMAfkh8Q28CaZiW4o8eXIIcNlReFIWDIORScMLRnQRN5m9ZGqkjTH31hBqRyPK3V6NKlyNN46BS4yUNr1lIQ4Q3LwrY5Fgt2rSyWh5zxSR83MUn09co2nXx9HfL9mXWYjwiIAv05XZAVhQVxN3AR7eGMZ8LtsEzf/Qfnr+3KUcXMrZyvtZ1VkPkhl/VdHknSgx/VOErxB5Ca2IkNYOjh7sjTpx1SSb635mw8uCCbGyC gEHOheRB pfPhm2LhuFXN+JefHmgloxRnFFFzHh9qmizTJlY2vjUNVG996ViKo7wa3fHw99U9Vp3znb241Wh6HB1RF3MSeXkmmysOjZB+tVOG6Ax61aatDysHtu7by1qF4jXTV5tJ0gAnFIcgAAFldxa384yIypFX9VNvCU/nFo7qnk7jqtuEhHSzFTPeI+/7kn2mc6m+liCRMv5rKRXaLos7TRqFhFn8pye2VzwMxJsgyqpoMoqw5GQU3jWzdaV/ckNiSg50vAVSVQTE6Jnp50oTRyhnHsM/heyBPBWWZmNhAPLVLRsffTbJ0NeG0G3zKmjKkpeaACjGE2qStAcRnZmJii5iM3S5Hi2js8kOjAUDtkgusUZdT57/ISfj5BCWKYTUowyf0t0ctdWrzL/mjIQcji8hi9fuS78QaakS1TBlHhEVgCLUZO9uWGfctJmeNj+nOoxEiSOMoFOL6kiZRHcC0k5Mof0l8Aw== 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 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 t= hat > > > > before sleep, but CONFIG_RANDOM_KMALLOC_CACHES breaks this assumpti= on. > > > > > > Could you please elaborate what do you mean by > > > hibernation assumes 'the memory layout' after resume be the same as t= hat > > > before sleep? > > > > > > I don't understand how updating random_kmalloc_seed breaks resuming f= rom > > > hibernation. Changing random_kmalloc_seed affects which kmalloc cache= s > > > newly allocated objects are from, but it should not affect the object= s 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..= . I'm sorry to confuse you. Binary overwriting is indeed caused by kASLR, so at least on LoongArch we should disable kASLR for hibernation. 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. 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. > > -- > Harry