From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f169.google.com (mail-yw1-f169.google.com [209.85.128.169]) (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 1FF9926D4F7 for ; Wed, 6 May 2026 16:34:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778085255; cv=none; b=DENj+5AOKjen75SeAjZ2gb4sCQnK5gcVA/VtYH4jLJJrCnGdwE2W6NgEMrYZcE8Wp6WbAljmeYoMzlBIyEFcRAuV+RoX00ePOMZEKa4H5UbFm3L35HlQEWtNkqkh0rnsdq4GQeszjoUY7NAcFPTo4H+bCnCp1dG1R7IZcrTvr2k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778085255; c=relaxed/simple; bh=36DQH5a2Mu7BvPpl2TGzbw/B2MFAo6jL8FJ6Tk37FQA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gwkhxiDZSabTZkcQdTaCcTHBqMgtIuc9uhFY/Q2+MssHZbMDveYgB4hpkxX1ZA4Rq+rj25DGRvqtDQEvMZnbp93ie4sAtUPQatyxJvRfuEEWCruoXRGILjLNI81ceVz6leesecw8Rm4d2oeBeKKOLg/GxYq3yozb2MH+uvf4DwM= 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=ZXHnqXQF; arc=none smtp.client-ip=209.85.128.169 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="ZXHnqXQF" Received: by mail-yw1-f169.google.com with SMTP id 00721157ae682-7bdaa68cf81so21586697b3.3 for ; Wed, 06 May 2026 09:34:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; t=1778085253; x=1778690053; 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=OSINYmJ3vJWPFl8vzHtHzlEblnGus+VWg6G+vnhXyiw=; b=ZXHnqXQFukSyOSZOeDwsCb5JX7l67tw34Gr9YX4lQqWIyo+4q46sxRb/zV43TGo4Wl X5uOIRNhfX40P4MVWG0Vb1hKnsDkERcTVl5KdVR3jKFfgD6TWBWv62k/AbjHqsrprNYN 9/tCJKrbUl4hGf4GPwAOQw+0WJcA5FE2P5unhdB609qs3/yoNDcredqsmblXlr6YjdEk DUHtp93RcufDlF6dUPY92dVnbmE8ggyOgzU8jXbQKq34cJLT27ImQSF/2ea3qAIEDIRm N1LCSBlTrxzUIWDoRNSf9e3hebw6CWUaJrx1wmifYwI6tN17EWXK2DfONibxvE29+2V4 VOGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778085253; x=1778690053; 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=OSINYmJ3vJWPFl8vzHtHzlEblnGus+VWg6G+vnhXyiw=; b=WLGN6GK34tZJy2Yfl5szlo7IcSePqhkQ1EizTmHAbjjhl+GDrUnD2fw+0W9bI+Y/qA 1pFHOGqjqGcdchWcOvTvUaQUJLESljlqYJnmgfta4zbNOjbmESeYqpO/qQzelDuxa/fJ tQzDidPSAFpLk5YisUqm4cLJaWhf+Bji+flMIescceqanX3omut6+OhhMucLevY4wJv6 zXUFey7rT7XjhuVNqXinTrgymwSQMEPzyHqQH094jjudfiQt4qH9dIAFNEZu0shSQ9/7 XFcrDvYk6Udm3TsF/8IQ+K9qWrlHAMYWyTHAagZc3Zbt64ewitc4fk5m6YHhJJgNwTZp gnRw== X-Forwarded-Encrypted: i=1; AFNElJ+8p1xDINK2IfjhJpag0tpv9Uz+kotPv25Z8C8s5/rfTLS+0fk4SSbnwlq+pFAdbrP2Dkgb4ysJz9CoTqg=@vger.kernel.org X-Gm-Message-State: AOJu0YykBtOse/f3qlja0FiVl+j2kTWI6xKAVDE7C282ufaaXeXXD5Ur Des0GhueOrNvnifV9hbzxym3Hqw8sOc603oHmy5lq2Dsa7iQobIrGOf/8wzcpI3XaEo= X-Gm-Gg: AeBDiesaj74wuOA3BkOlyteo4lFQ9kTD0/A4ppK/rQ5jOfcLbetOqbHO9nsCnrX6Vae OUkub2vwMlNqR8tN0r/pCHmqd//znqrG/K+FE2afE/F+Hn4Sh2gK//bVu/vXZW8qyOkrx9MxWE9 j+WCqEGIGuC2kR6W9SPeb/i+D0vLT6BjEAXOxO2OT2ee6nAlxMYzljMAbrT3joOkB5Rnz390f1C vtr3LtXz3GLIB0yDoUgchLgGdWpWO1KKddSxz2BVwdo7Yi/c4n5sFeDn/fuoc6wI071as192Nnq izG7o83hclN9GfCerCvODoESMd5tmBYq7uP5EDijzKeRK9RTrKNq4k2KXym48ETG+xxL+7tc/ec Ow0MLIDJUhppCKn10FkalkV1I8rR0o5uM3XGIZDH4uLD9dowBED8xQBIxlNHsbrWoo7G/7d84Hl bPRnbklLvdtjECSM9buBUaSqh8m2YjXZBzUiCLT2GCTrKPNtovSCoET5jCRhXuX5QhZqtrQOeWJ icaBiRVWAdxR1k0dU2N5HECi13W08afD08HY6El X-Received: by 2002:a05:690c:8e07:b0:7bd:d145:3af9 with SMTP id 00721157ae682-7bdf5f265b3mr41479677b3.47.1778085252743; Wed, 06 May 2026 09:34:12 -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-7bd6654cc7csm83105227b3.13.2026.05.06.09.34.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 May 2026 09:34:12 -0700 (PDT) Date: Wed, 6 May 2026 12:34:10 -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> <2vxzfr44zf94.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: <2vxzfr44zf94.fsf@kernel.org> On 05-06 18:15, Pratyush Yadav wrote: > On Wed, May 06 2026, Pasha Tatashin wrote: > > > 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. > > Oh yes, sure. I am not arguing for taking this series. I just figured > this would be a good point to have this discussion. > > > > > 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!), > > I was looking at LUO code and realized that we do not separate outgoing > and incoming sessions when dealing with preserve/retrieve/finish ioctls. > So you can create a session, preserve a FD, and then immediately call > finish or retrieve without doing a kexec. Of course, LUO file handlers > aren't able to cope with it. Oh, this makes sense, please add a self-test for that as well :-) > > So for example, you can preserve a memfd and then immediately call > finish. This will call memfd_luo_finish(), where it will try to > kho_restore_vmalloc(). That fails with a bit WARN splat. And then later > it calls kho_restore_free() which also fails in a similar fashion. > > You can do the same thing with retrieve(), but that also fails early and > loudly and does not cause any problems. > > I am working on a fix for it. Should have something out shortly. > > > 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. > > I am not arguing that we shouldn't fix the logic bugs. Of course we > should. > > My point is that this sanity check acts as another layer of defence. > Bugs happen, but the earlier we catch them the better and this sanity > check helps us do exactly that. > > For example, if we did not have these sanity checks, the loud errors I > described above would be replaced by silent use-after-free, double-free, > struct page corruption, or other problems. > > So I would like to understand why you _don't_ want to have this line of > defence. What's the problem? If you are worried about performance, we > can go and measure it. If the overhead is too high this can be behind a > debug config. Most likely, there is no performance cost, because when we free preserved memory, we still need to do a KHO restore. The only difference is that it may occur after a blackout not during blackout. Anyway, if you would like to add this sanity check, please send it out, and we can review and discuss how it looks. > > > > >> > >> 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 > > -- > Regards, > Pratyush Yadav