From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f178.google.com (mail-qk1-f178.google.com [209.85.222.178]) (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 E95253FFABB for ; Wed, 29 Apr 2026 16:14:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777479254; cv=none; b=XTnDQQzLA7I131WVlGEvhIpdUfgsAwqgZPrt5Az2LlZjKNHaDPzCPZyN/yY7eGLzbNf+TvWsa+wL75dRn1ikqMiyYmEMAIBXmsqleOqEc9uU3h91o79COKgqKdDk2fGex6LtL/WAoycE2tTZmcwqaqKcOlaignE/laGHMffEa7I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777479254; c=relaxed/simple; bh=QIUvdq75lFARum0k0kDOdaUv3IFA90teUppVmMvzJ/g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=eb8p7pgTLyJw19n0NOmbPRA6HW2cNUp8SeqjSZFARoGDnnHOXGjvRcMft5DytHx9RTNGEW0MtiRW3x86ZARMQSj+y0s+6iwKG9spAlxwngHg6foFo5y4h1EW8DIbZtmWgwUpxPTwNzRnkHSAnOh/3154JiDZXFpb2uJztidUvX8= 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=P6gaUGVt; arc=none smtp.client-ip=209.85.222.178 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="P6gaUGVt" Received: by mail-qk1-f178.google.com with SMTP id af79cd13be357-8d7e7f48499so1388406885a.1 for ; Wed, 29 Apr 2026 09:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; t=1777479238; x=1778084038; darn=vger.kernel.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=JQwXlv6d4SrpAwunOCAy3T3SkF7dwQSFYcS5dAIRLRw=; b=P6gaUGVt4DL4MaxesXHAsm1WRtPsjCE96KoMA806ZhpJiTxloitgveQ6S0W55/jAjC m3xxc6ak3Jv6S8Bac6jq2JH5eoiHQjs99UvHkqo8TozdXj0yIfYVjvdXKD2/kbyzB+5K D7Dh30hlJhrvxm0dpoeovS6qcPrvH6gAg2gv4OyCX+5FievTIubmsiKHRK9VQ21+iYuw /jQ6Xp5ZBhrYWFehn640+I0NoF4HVMYVF0HewxvqKQ4Qn2HIZN7MFCctg939Yv4nTsVo 8XyqtjG+lf8RBaPcYt0oz4LjY2sM5DHZXLlHauQl9nfuHhdhdhIRVIOWZpt/o3/of3Tj XyLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777479238; x=1778084038; h=in-reply-to:content-transfer-encoding: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=JQwXlv6d4SrpAwunOCAy3T3SkF7dwQSFYcS5dAIRLRw=; b=pt6kXj/zaX5rR8lh7Ln9CjbAA4TbvHJHer8entbyd4ICR0vgFYQHYiOKtQrQPugCzC TWQrui4aHV9tGpRnQ8thopqiZGyo+14Nl7lN90p4A5TfWOZ1mynZGqAiQkj4mkA8Ue0C TAlbPsO9cYcRTyELv4mFLmH0W9olRCpGyBHCAERZGHzkGy3niKaOK6f+EYFENvVRR9FW TnCKr+xEXpox7lJTVj9mH41TMP82DPAjfv3eFf5G67XOXpfUY/BcstgYxlW4adDb31MQ 90NjyaXUpWhI2Itf0UgNng2cR8Ogb0mz8CLmfxJC+DGu3l0A1uM6sTPLdsJsXnnDeWsm 6qOg== X-Forwarded-Encrypted: i=1; AFNElJ+H5vIJgVEd+YCuHAWfAoxbcdWcBLWIbPN1rboIvonANNoN+/Jjpo7VqODV5E2Sr4aPsz9hkGyg1aZqsMU=@vger.kernel.org X-Gm-Message-State: AOJu0YzVYWnQhD3JBrK6194iivyNVdqQ9RWHgxgJpaSdO6Xacl8C4HV9 sKUpDEQVv7jW90LQltoZJGfHeAMnSbAbt2sWr0+i6ihP3MYbFH4SaSnvsusatFK0QXo= X-Gm-Gg: AeBDietdA+dHodZDTx9bVgUU506yK80wDaZkhaM+ORZ2JleNUOxOa3WXFd/MFxELBt0 GjKpJ+WBEuh2rYgZUs+HARCuUGl+I9iPGTTCE4clGnUIxSFHkDaRyrWhM+9SMD8EfEV+xvEXn3M YegCClNYcOszMWyaMLHK3iA5xZjwb3l/UQWl9ZNXXaRzO7u64ql++tFYihPOhQXito2vMpmevXR /vRWYZdY5WFCIK6dRaGQW8bfJHBX5mASP4N1pBHrDZNXleAAg2QJes5Qn0EOis7Rof6EWoTxqni i6CUpN2SxOB57MOI0c69+hbSWyzf0DxJIHqS6dHe4qWBWLadc1k0HXC/KT2tPE3YmtT7Y0kU/nf MxHvMsyYZEZ/TvQABkRhzEKYPjhQaGTMuxXxg//ccM69G0YQyPfagPify6erU7T5AbkiqbBwXE1 g77iCgxxs6sutPultlay5xCryVQPZ+WKgLSdzbUJYm1A8a1vGb9duTgTQuiCLtMBusluJ347l5 X-Received: by 2002:a05:620a:472b:b0:8cd:9033:172a with SMTP id af79cd13be357-8f8f3a204a5mr643580085a.3.1777479238360; Wed, 29 Apr 2026 09:13:58 -0700 (PDT) Received: from plex ([71.181.43.54]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8f93f5826f7sm235640585a.30.2026.04.29.09.13.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Apr 2026 09:13:57 -0700 (PDT) Date: Wed, 29 Apr 2026 16:13:55 +0000 From: Pasha Tatashin To: David Woodhouse Cc: Alexander Graf , Pasha Tatashin , linux-kernel@vger.kernel.org, kexec@lists.infradead.org, kvm@vger.kernel.org, linux-mm@kvack.org, kvmarm@lists.linux.dev, rppt@kernel.org, pratyush@kernel.org, pbonzini@redhat.com, seanjc@google.com, maz@kernel.org, oupton@kernel.org, alex.williamson@redhat.com, kevin.tian@intel.com, rientjes@google.com, Tycho.Andersen@amd.com, anthony.yznaga@oracle.com, baolu.lu@linux.intel.com, david@kernel.org, dmatlack@google.com, mheyne@amazon.de, jgowans@amazon.com, jgg@nvidia.com, pankaj.gupta.linux@gmail.com, kpraveen.lkml@gmail.com, vipinsh@google.com, vannapurve@google.com, corbet@lwn.net, loeser@linux.microsoft.com, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, roman.gushchin@linux.dev, akpm@linux-foundation.org, pjt@google.com, "Petrongonas, Evangelos" , kpsingh@kernel.org, jackmanb@google.com Subject: Re: [RFC] proposal: KVM: Orphaned VMs: The Caretaker approach for Live Update Message-ID: References: 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On 04-29 09:40, David Woodhouse wrote: > On Wed, 2026-04-29 at 10:13 +0200, Alexander Graf wrote: > > I would prefer we only attach the whole caretaker and all of its > > specialties right around the point when live update happens. Why keep it > > dangling and active forever? That way you can also late load the kernel > > module that contains it, so you can be sure it's an up to date version. > > "Why keep it dangling and active forever?" > > I've always wanted to tie this to address space isolation. > > The only way to truly stay in front of the constant stream of new > speculation vulnerabilities has been to just make sure there's nothing > sensitive accessible in the address space at all. Hence all the work on > secret hiding, XPFO, proclocal, etc. — and hence the occasional > researcher finding their shiny new (5-year-old) vulnerability and being > confused when it doesn't leak anything *interesting* in certain > environments. > > I'd like to see the inner KVM_RUN loop switch to a completely separate > address space, in which there's a kind of caretaker which can handle > the bare minimum of interrupts and timers and the most common exits, > and which *relatively* rarely has to come back into the real Linux > address space. > > And once you have that caretaker running in its own address space... > why not just let it keep going while Linux does its kexec? Yep, this captures one of the benefits of having a permanently attached Caretaker. By establishing that isolated execution environment for the inner KVM_RUN loop to mitigate speculation vulnerabilities, we naturally get the hardware-enforced boundary required to survive the kexec gap. The Live Update capability is effectively a byproduct of achieving true Address Space Isolation. +CC KP and Brendan