From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) (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 8DDF42DAFA9 for ; Wed, 6 May 2026 15:05:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778079936; cv=none; b=Rf27KC8FkLMZExsQ6B5p3g+DCzTtvOQwLEcustKiFi7EPRjHmKDGjkzEgUPguzrNSKzy5AikdBB/AK6/Fz3aw1BXX+jAllaiIxUyPVCvurzca5Da+H4OGFpGqUEbe+h1gcruqa3d3bWK1EOThoySon32iDCK841+dytf9tupAnE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778079936; c=relaxed/simple; bh=rnsqh4cJ3pQpvRwZiehxpvqnXsIPnubLyEcmfYFAUSI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JQJxcd5p6qkodpb6ASNPdxTLZ/h9L1UVgPDTbSDnjurBihDAOI2gfxq4uN4K1JfWPZHfWVxmkhBrKgO1q3qg93QRXCl5rFEykQf450wYDAMnQISLqAbjXyDX4uxOd0ZD6B6yG8JW8ncq8cjHYaf2bJoVnFlfJpv3NKzOW/r55u4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=soleen.com; spf=pass smtp.mailfrom=soleen.com; dkim=pass (2048-bit key) header.d=soleen.com header.i=@soleen.com header.b=fB/veIDH; arc=none smtp.client-ip=209.85.128.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=soleen.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=soleen.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=soleen.com header.i=@soleen.com header.b="fB/veIDH" Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-799001d73bdso58211587b3.0 for ; Wed, 06 May 2026 08:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; t=1778079934; x=1778684734; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=pGancg+Hm6RuQ5CrvC9iAES266oQrizaBXy/zKyB4a8=; b=fB/veIDH93e0JBS+3tLF+WBEOsgKPsh25CIjZCeXpau4WEOQqhyxq0WsI4u9A5HcX8 IFRZrM9RRgrFm3+xdZdV1mxNpxCbMxhfTb7Vah5VlJGuBYf5OL82vkxUTMJkBihnADvJ IduR8KhoOnoIDS9saCUF+P7OYv1yhbIEjZzh1+wWMGEjqZyyQ4E4HRtXaHf24+JnpeaE DBzhGw9LH2qkjTT2TvW1B+fJOFrLkC/3CZdG1k+yki4nr9yThbvEN/M1V+MC90/vp51s WwheaoE00Q4jf9hvjL+hI7MWe8PiKOO9pTGaOlaz+cCnQmVBJen5VIn4uNdLwqxoPsfo AMlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778079934; x=1778684734; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pGancg+Hm6RuQ5CrvC9iAES266oQrizaBXy/zKyB4a8=; b=XVPbNr5HTTZGc9GJFcX76HhAWQyjeNl8Q/okrDrxRf0tWViXBWeQXdRh+Zpq+3jmpa lxLy8IMk3d8cT3NKpVnD3HNpI6+ahTv59BxT/nPeNTGbo42CNe+zmGal2CyvqRomlBGM cBLUvOeWxyEMbRGLn3MIVXU2BCYGv63gAN3kTk/csZ2YRXLcFlsSuDihZ/H5AKmO8ZUJ m1DJk9iZpB+JC2qutOtr9uUcwb9zFjmV1Y0iCBooA6V7+KiOrVni1W9yywj5FVDZLFnF q8F1H5Q3I/iTPxt77LU8JI8Jh9JMOpUTPFL2hogqoSPx7Hv3cNmW4dpwKew1pCSQi9RE mBgw== X-Forwarded-Encrypted: i=1; AFNElJ9Y9UyiFMwy/v8LeDEPYhIeTACQ1ovvHELiiDcjtzkpjutgC0ZWozOUCq5RINxENEc7wWws87PIx5FYuHM=@vger.kernel.org X-Gm-Message-State: AOJu0Yws6a9kOJI1r7H6jobJNsobNJJMMWy/tF82nS5UKAssZqlPteaF uPx7Yn0yJbVaKfKqZ4zGsCfZPrufmXiHeKDBj8yHpnCPtRokt5PxA2ybcLs9aTBhNdg= X-Gm-Gg: AeBDieubZ1SZJIj2gKpyEmEsQF17caAdQ7DSRxCBSuKrTj8dCKOFdiTot//+hpRu8CK YvotiCraZI0wGDvhGPFy/LclJ/7KHLEHDPz0BI2R85OIErSD0UWi0PsGObsG9bNRyIkHsQQ28pA OFA06ziLG98rEjVUrcNgQSgMl/bjDiY1HAODeEK+YHA/zCDpmhVWE6Ymr8UmD3a0JhCZ/bCAvXl EDBMAhfPPd5DQ2yXcu8btIzH96yAXSFysu9Tl7cw7gLLyNgWTWnGB70Wiyp2h+YQd3Nn1VSM0iY DHoYrrt123+K4JEhIqWwvlkwONHGa39sd1n/VROyypCaaJE0A+C+m6hfXbDlKZxmYVP54bj0RI7 mcVk14gOJIPbmKZCOGmqwxVWyTCBb1JVfP52GUFSGhcqo/RcBef2lCsfKGuZHNyV9aYPRzKHuH1 6WtIsnDtQxMtt6cVPGozMpcLVJDcTIlfmKLRIDc5nq6d8AiFWipMijKrawDp2g2Z0NcqtFeoyEz 7G3wV1BY2h+2ScZr128OZgvj0b6bNrRWG6VC/+8 X-Received: by 2002:a05:690c:f13:b0:7bd:4792:66f0 with SMTP id 00721157ae682-7bdf5f24c83mr42505907b3.46.1778079934356; Wed, 06 May 2026 08:05:34 -0700 (PDT) Received: from google.com (57.233.150.34.bc.googleusercontent.com. [34.150.233.57]) by smtp.gmail.com with ESMTPSA id 00721157ae682-7bd665694b8sm79860377b3.21.2026.05.06.08.05.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 May 2026 08:05:33 -0700 (PDT) Date: Wed, 6 May 2026 11:05:32 -0400 From: Pasha Tatashin To: Pratyush Yadav Cc: Pasha Tatashin , Cris Jacob Maamor , Mike Rapoport , Alexander Graf , Andrew Morton , Greg Kroah-Hartman , kexec@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/5] liveupdate: validate restored LUO metadata Message-ID: References: <20260501094637.38650-1-crisjacobmaamor@gmail.com> <20260501173053.73116-1-crisjacobmaamor@gmail.com> <2vxzse84zzag.fsf@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2vxzse84zzag.fsf@kernel.org> On 05-06 11:02, Pratyush Yadav wrote: > Hi Pasha, > > On Fri, May 01 2026, Pasha Tatashin wrote: > > > On 05-02 01:30, Cris Jacob Maamor wrote: > >> LUO restores metadata from KHO/FDT during liveupdate. The restored > >> metadata contains physical addresses and count fields used to access and > >> walk preserved session, file set, and FLB arrays. > >> > >> This series adds a non-consuming KHO preserved-range check and uses it > >> before phys_to_virt() on restored metadata addresses. It also rejects > >> restored counts above LUO_SESSION_MAX, LUO_FILE_MAX, and LUO_FLB_MAX > >> before traversal. > >> > >> As far as I can tell, this is root/admin-only; I do not have evidence > >> that a normal unprivileged user can trigger it directly. > >> > >> Changes since v1: > >> - Dropped RFC marking. > >> - Added changelog text to each patch. > >> - No code changes. > >> > >> Cris Jacob Maamor (5): > >> kexec: handover: add helper to check preserved page ranges > >> liveupdate: validate LUO FDT physical address before mapping > >> liveupdate: validate restored LUO session metadata > >> liveupdate: validate restored LUO file set metadata > >> liveupdate: validate restored LUO FLB metadata > > > > I have replied separately in the security report to clarify that this is > > not a bug. The behavior follows the ABI specification exactly: we use > > the PA addresses and ranges provided by the KHO FDT tree. > > > > NAK > > I really do think we should do a restore-only variant for the > kho_alloc_preserve() family of allocators and use it everywhere. It That is unrelated to the provided patch series. The author of this series reported this as a security issue to the Linux security ML, and submitted this series at their request. This is not a security issue, and in fact, it is not an issue at all. A restore-only variant can be added, but I do not see a reason for LUO to use it. > would prevent problems in the future. Not because the previous kernel is > malicious, but because we might have bugs and the KHO page magic sanity > check acts as a defense in depth. > > For example, I am currently looking at a LUO bug where LUO does not > track if a session is outgoing or incoming. So you can do a retrieve() > or finish() on an outgoing session. A lot of nastiness is saved because > of the page magic check. Things like kho_restore_vmalloc() or > kho_restore_folio() fail early and loudly. I am not sure what bug you are looking at (please share the details!), but the fix absolutely should be to use outgoing/incoming sessions properly, and if we mixed them up somewhere, THAT should be fixed. Using KHO restore is not going to help much; however, I agree it can add some extra scrutiny (i.e., similar to an ASSERT), but it is not really something that would help improve correctness in any meaningful way. The correctness should lie in the LUO logic using incoming as incoming, and outgoing as outgoing. > > If we want to squeeze out more performance later down the line we can > move it behind a debug config, but having this usage pattern of always > restoring before using is going to be a lot more sane than just using > physical addresses willy nilly. > > The approach this series takes with kho_is_preserved() is the wrong > design. But a kho_restore() or something similar (maybe we can find a > better name?) is really where we should be going. > > -- > Regards, > Pratyush Yadav