From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oa1-f50.google.com (mail-oa1-f50.google.com [209.85.160.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4358A3AB274 for ; Wed, 29 Apr 2026 16:44:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.160.50 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777481059; cv=pass; b=n8fR91UWZYGfRjLPaDGPHyuOuv5lYQ1ERKywnhWpWyfqiRFsdU1bpfAerWsQp3We1tSkh4CH2BDukSgZt5kvsNVeTYBwWHJ+OfjKW57N+yuQj1NbwTes+i752USOTNl9QTQfCRyJvek4zNHsWRU5+A+J7B3U4mQwmmzBU2gRB08= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777481059; c=relaxed/simple; bh=lzm3vRpDFy8AEcM2mHbRYMhUPOKAAdECIl6UOorrAdo=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=iEimWHGe8tC7/6ELZTfI8/7koDyQhI199F/+wzTnF9B4skuKLznFZblhqMmkxoNaRo7bJmWKyj09WfH7XzkZYkc0poMFzzh5bOeBWiB+pf4+hIAWLkVrCBvsKZEbJ0mYQfxhqL8ZYKRl6Gpv86rG1lx+1qdAWVWqaBoTK/uuA6w= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ox1ppIlM; arc=pass smtp.client-ip=209.85.160.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ox1ppIlM" Received: by mail-oa1-f50.google.com with SMTP id 586e51a60fabf-41708f6c3feso10651fac.3 for ; Wed, 29 Apr 2026 09:44:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1777481057; cv=none; d=google.com; s=arc-20240605; b=Ju5Qr+lQ6e5YQPJ7tnAMYNUUbu/XhpOSlY+UWnPldSsvosOtbXFI/aHA71c4p5MK8Q +J3dLT/bkh1XtEu0ynMjlFBP0/veEFoZZgE8x8nUO3NC/Z6902qUAgt7pdQZVnCN1OB0 eOy+2+PF6nePmYeqj8vgCEl1NxYqnkJ8B6nADyURDK/C8cFI/TYo0ZtckQFvzxmbqsBL gyouWUrRZgvqtXWaOq2zgxIe7LgWLnpPmCj7vurFFYVAKvT+SnotFHEYdMSgdtb6DZro 0lVF+dKTiEYA/s99ylnjnztDtoRxKxbH4TM8F3AbYSys7yRE8eOKnTUMuG5CM/fLpPi4 XwhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Wk1Du/x2eww8W9cqGB9R2cmn0/7nSJynF16tBb+L3dE=; fh=TFHLVY1uUoNXHu0eM4RZsuvBcG2gB+FMT6+xFYQAMCc=; b=d3zWNFbQlI5N0fO892XzzdgQ0LTahKE0yNvCAiY6nAOs9+u+pGetKITK7oDEdiVreU 0Ftwt+P/W5gPVx4K/zCn+SJ5F59Mv2PhCX1bemHTW1dvL/gF3+gAaIqTRWcHcwEm6S7A PT5ABis8wckat4o7w4jEacWN+BKu+FjitVxk7I2CKJfgDv7FwRMioBn1Bflzd+f4LO/7 tfuYBus1xXYENaBLj4ggD/+cMQGMh6hqy1QvPA1+kPpyw0l2GtW/vKQLHhsfZWI3WzKB uwHa+vansfHdKEqLePmi1+1qYuJOjxCVYR4Y4Ffn3qctRiPhj3ZC+HM1Ii3O/gRkAxph xhEw==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777481057; x=1778085857; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Wk1Du/x2eww8W9cqGB9R2cmn0/7nSJynF16tBb+L3dE=; b=ox1ppIlMoE3akwytK5WLrK2TVLnt8sZwX08vKdskycOQ+W7TN7lta2tll8tac7YmXi UnFBgNKiytqMfTcDqmWn1K1Kc0tHem803UapQW05xopdoXFMpZvYWPNFxlJthHfdcsNk Gef7hw76NLstZdP/zECEZXkZNC54uWrPggvtehpZHywL+jQkqqJDb1EgDjAU4+4fvmqu WJ9eZoNGkZ0Rpzk8T7gTSU6uNNN3s1uyobtkJ9wk62IsNmGbp/P2reNP9Hy4lMT1ZFDG ZoAP0+gNz9emebdd3n48OH/OY94tucaZ5jsH8j30R2A5cLVUiYfdlAcUqS/4A1YxOnCj KOXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777481057; x=1778085857; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Wk1Du/x2eww8W9cqGB9R2cmn0/7nSJynF16tBb+L3dE=; b=H3U5xj4iLFKseUKNQfhzq0iBXtr1QMtRNqtk/R+9FByYb5CWGmQTYrbKjl0bLEDoUu lcBVt59IueaT1BdEgmoweKEbQ2fVkw2zou1M4SUVnclaKEqxlqlCWHpSCfTFLPoD+kgS 72jBLaSBCHD6BnSep5Qny/h6SPO2NgFE4Swcc0MJuA2KxlF8wd/ihswkyLgyVSdIgHV2 MT1PzDEoYLUyGSX1+FP1i1j8n3D0a5OA3Z7VB6IaAw6dIFNZGUQKiokr00FKvDEZumXY jwmmwpCIwOYES0cQQiAKGXHhCMc+pXK0V1eZbc+w7oLLzyfF+lxjhjuAf2fbIOSKCogb QvgQ== X-Forwarded-Encrypted: i=1; AFNElJ9q9dRyU8+j100DxYoMBWqrnHD6aXYyjAH/sdo9YsEyDWxwfxQHdBIxl6/OxZxkuq/2VFtqUiVPTIUfyGI=@vger.kernel.org X-Gm-Message-State: AOJu0YwEy657ksIgM6qRa0WPrU87+xeaGnPhOIC2IC7ItcpyH54ZYT1+ 6og6XwhlGPhVIT6OyVsqmJaImDtlHAsMpb6YOEBId/Lux1NX9D0XIwEGnyiBXeV1e8H/GIyTd4C +5NWAhby4B/N/2GpLfBTw2rCihIEW9Hs= X-Gm-Gg: AeBDiesy6CXG9+aBdXenTQQ4WDhbJpJDoItx8U4bKb8Ge1y1XQs59LcyzrTibTTfRAC mLVkJ1iu3Vkn04HcN9qQOm0RWJIoAd3fkRW2G+g3VcGdnkl3RfK7lV7ocThWsONwBt1EzQfqx2r feX2cHQqoGLGsZ3q7gM0XcatpzaHoXOoZ72sLGoA9zpri1O8hXtHdp01ZhepdsRQZ80IbzMv0b8 IoJuig4BPE4bzjX6KMTqZbAzO2jd3lYHw+kXbrvrOLembL7lRMolcvSz+mDzLpt8CzeLYa9JiG1 dBhhyfyUYbJ2PtuYBQx4vld+F1H3xsYJc9bUU4txyXso2a4B X-Received: by 2002:a05:6871:582a:b0:42c:6ea:3227 with SMTP id 586e51a60fabf-4340aae188cmr2594708fac.19.1777481057078; Wed, 29 Apr 2026 09:44:17 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260429000623.3356606-1-avagin@google.com> <7c2681ee-a53c-402c-8947-e7a74f8720c8@intel.com> In-Reply-To: <7c2681ee-a53c-402c-8947-e7a74f8720c8@intel.com> From: Andrei Vagin Date: Wed, 29 Apr 2026 09:44:05 -0700 X-Gm-Features: AVHnY4LOIJsAAHwdw0aMFR3Yh66nYh4fPiFWcrTPgmM0OEH19ZvLOJE3i9upzgY Message-ID: Subject: Re: [PATCH] Revert "x86/fpu: Refine and simplify the magic number check during signal return" To: "Chang S. Bae" Cc: Andrei Vagin , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , linux-kernel@vger.kernel.org, criu@lists.linux.dev, x86@kernel.org, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 29, 2026 at 12:27=E2=80=AFAM Chang S. Bae wrote: > > On 4/28/2026 5:06 PM, Andrei Vagin wrote: > > > > The reverted commit broke applications that construct signal frames in > > userspace (such as CRIU and gVisor) if the frame's xstate size is > > smaller than the kernel's fpstate->user_size. > > In the extended state area, the sigframe embeds the hardware-defined > XSAVE format. If CPU A and CPU B support different XSTATE features, the > layout (size and offsets) differ across systems. However, within a > system, the layout is invariant. Userspace can query CPUID to obtain the > exact offset and sizes, which effectively defines the ABI. > > On top of the XSAVE data, the kernel appends metadata (e.g. the xstate > size and magic values). In particular fpstate->user_size is written by > save_sw_bytes() at signal delivery. On sigreturn, the kernel validates > this, which is a symmetric and straightforward check. First of all, the reverted change broke backward compatibility for user-space. There are at least two projects (gVisor and CRIU) that worked correctly before this change. With the reverted commit, they run into silent memory corruption. We usually try to avoid breaking user-space like this without strong justification. As for layout compatibility, in most cases CPU A (older) and CPU B (newer) have compatible XSAVE layouts in terms of saving states on A and restoring them on B. CPU B may feature new extended hardware states, but the layout for previously supported components remains the same. CRIU relies on this fact to allow users to migrate processes from older to newer CPUs. CRIU can check whether XSAVE states align across machines. > > Because the format is hardware-defined, arbitrary size mismatches should > not be allowed. The sigframe should match the CPU-defined XSAVE layout. > So the change in fact strengthens the sanity check. > > > Furthermore, this introduces a critical issue for checkpoint/restore > > tools like CRIU. If a process is checkpointed while inside a signal > > handler, its stack contains a signal frame formatted according to the > > source host's xstate capabilities. If that process is later restored o= n > > a destination host with larger xstate capabilities (e.g., a newer CPU > > with more features enabled, resulting in a larger fpstate->user_size), > > the kernel will look for FP_XSTATE_MAGIC2 at the destination host's > > larger user_size offset instead of the offset encoded in the frame's > > fx_sw->xstate_size. This causes the magic2 check to fail, forcing > > sigreturn to silently fall back to "FX-only" mode. > > It seems that userspace could translate the XSAVE buffer from CPU A's > format to CPU B's format during restore. If so, the frame can be > consistent with the destination system without modifying > fx_sw->xstate_size, and the kernel-side validation would continue to > work as intended. When checkpointing a process, CRIU cannot determine whether it is currently executing within a signal handler, and it cannot find signal frames on a user stack. In fact, there could be multiple nested signal frames stacked on top of each other if a process triggered additional signals while executing in an earlier handler. Even if CRIU were somehow able to locate these frames, extending them would be impossible. The target application stack is not under our control, and other user stack data or local variables reside immediately after the frame. Thanks, Andrei