From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (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 8951F48125E for ; Wed, 6 May 2026 15:23:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778081016; cv=none; b=g2lsFj2pNR5VdErYX+3x6ChTl+2f0urddGijloWw+ijxIvKC2VTX/4QUvY6FK28BDEidsGi+U3sB4wUNWyGbuNFDnq2wFRHDx137fcg/u9nREZKPvH4XrSOxVASMrb9UkdzvfNgxQ9E3DpAcmisPKQRe8UNmprZSw8TT4gj3+gc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778081016; c=relaxed/simple; bh=VG2/sxvDjWN0rZSNS6U6OvyRizkEs6ISsawgP8gZVvQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=AEji2c3bYyuQAPi4XiZSvyWqnSa8hkIo5stmwm0CqN8i9PubUrhV5ejHPZjzEb1i0LrBCoZ4gWeEv6J2VPW41Y3F2DaooqaQogC6HXA6njrTd8RSaIggMugxHCRztY/gqB4bfkPjHIPRKxulFKN/bDpVhroIasKS+4IBhT/JSfs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=KVq/jX+8; arc=none smtp.client-ip=209.85.128.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="KVq/jX+8" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-488b8bc6bc9so41969615e9.3 for ; Wed, 06 May 2026 08:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1778081010; x=1778685810; 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=cTseNJ/2nD6TjREZvOS9tCHIBcGxqDugB7fH5uhKP20=; b=KVq/jX+8jGFcDSTCIMI4Nq9UKHzTdL/znWuSo3hlPwFur+13j4c2yMQ1GjvUr9tAnN Px0YGmpBmX7uk3LgxNS+cuzO2LS97PkHwpXew/7Q9INJK6q80OyjlWK2bgqJPhIhC1L5 A/po+HgSFsS80A2Y9qM3w5HTkZU3Ju/QPdcby2CPs3SHQVN4wZuY6cTeb90mEufLdO87 1JE4w/vVxbKjlvQ2EiOY6++B/PZA6wsE8QDCErzTe55tfOtiYrTLw7zr/241DcwTWFaL rm9xiIRI0rBuFJ9rTc6fUE5IQBNoQYWVvANEJeKLUcoSphw5q2l57pIhYhh8c0Xm0JKb R7BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778081010; x=1778685810; 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=cTseNJ/2nD6TjREZvOS9tCHIBcGxqDugB7fH5uhKP20=; b=gV26orMmxo0Wd10Gm0VzaCE6i/q4IwzJkQA5K5mxg01wtElipcaKqwzW4cmvaJWTGT KNp0pAPoG138SylDByEMvGhckD2GKDHNMDxe0amBvYfSuW3iloGlu1Z+nFMAQ142PFNI WO/4KoykB+00/h93B3wTjw7AEJQdt4ywY/xS6yIsMuiluzfmNSEM3Eh8LIhEyyUuvZtj WIU1GVLXKDJS4YDFxV0y4DCaLuT9tFrI4MPKK8yfuQU/oPHXX9o3SzPesZiZeTY5P8ST 3Xm0nD0CBRhadhQR0fQrWGuA7Mac498Nkkc+Tcg2HrgFhkW42xs0WLndLu6NcKftDXiM 5xxQ== X-Forwarded-Encrypted: i=1; AFNElJ/hY2MYr7CPHgz4RoDuCyyQyvJnKELm8OlH6mZY+iYe0y4GwVg42x52zZ7Lmu6v8hXguh4Ba/Y68mgXBLk=@vger.kernel.org X-Gm-Message-State: AOJu0YyVBP9T9gHsQfkU3gosyxNU14L1Zkgo4KNEM9qdHW/QYFc6D8pA yq5fLA0DRvzoGDvia1F3WmNyVeUY2DbT6pfU+uOqcec+BQExpK2GBDwMyDCpc2zZUw== X-Gm-Gg: AeBDievFpk2MJDedxAq/pchqXJ134omS1LJFBm30YCEeOuaeJroYT7vz+TKqTxw3ilY bx0DudbscL3alRWOtUD6TgClzwQGpF/NxtbFRZHoYfs3zvkKUe9VIMN5FMyjtpVQBuF8ZEsQenh y34O16qIiQnOh3KfoMQcWS5JuA3m0crira5rnMfspwiuDa1BYFhiRE2h8u+EehKZBambJeHhE0l 1MRNXGU52sYf+OIvI9f7woBdOQL1vdqrh8fWBilurSi0qIFlgIQtZiLu9rcrwzPiBttyyCoz1dY C3LAhaquDKPOEM3vLEjAl44nkVc1X+efhJ3RSCjoMKNnGKKzxA7BDYZbfyNxSPGBMobJEw2Xk0y s+gdKoXgSnogBB3uoYtGM3ZkriooJ7myAAAIhheC7cjE2CWw3JehYUgOFrrrkRBSKTL1PsgdgFt uQVTRHpHYYFXpUDlH+qLqPcHlZIObyyr150KFyb0oj6kSTO6ylb74E2TUaMNiPwgXaAgoTxqa4O Uk2UHBJIAMto3ve X-Received: by 2002:a05:600d:10:b0:489:a4:e555 with SMTP id 5b1f17b1804b1-48e51f36fc6mr55916045e9.21.1778081009725; Wed, 06 May 2026 08:23:29 -0700 (PDT) Received: from google.com (197.183.140.34.bc.googleusercontent.com. [34.140.183.197]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48e538acf23sm52766815e9.8.2026.05.06.08.23.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 May 2026 08:23:29 -0700 (PDT) Date: Wed, 6 May 2026 16:23:26 +0100 From: Vincent Donnefort To: Mostafa Saleh Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, catalin.marinas@arm.com, will@kernel.org, maz@kernel.org, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, tabba@google.com Subject: Re: [PATCH] KVM: arm64: Harden clock for nvhe/pKVM Message-ID: References: <20260430103724.2151625-1-smostafa@google.com> 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 Wed, May 06, 2026 at 04:10:20PM +0100, Mostafa Saleh wrote: > On Wed, May 6, 2026 at 4:03 PM Vincent Donnefort wrote: > > > > On Thu, Apr 30, 2026 at 10:37:24AM +0000, Mostafa Saleh wrote: > > > Sashiko(locally) reports possiblity of division by zero and > > > out-of-bounds bitwise shift in trace_clock_update(). > > > > > > Although the clock update is untrusted, we should at least have some > > > basic checks to avoid the clock value getting out of sync if the host > > > is buggy. > > > > I am not sure about the gain here. The host can still write values that will > > make it out of sync anyway. > > > > The timestamp is ultimately fed and read by the host. > > > > This is not about having the clock in sync, but to avoid executing > undefined behavior, such as division by zero or large shifts in cases > if the host is buggy and not malicious. > That was reported by Sashiko > https://sashiko.dev/#/patchset/20260501111928.259252-1-smostafa%40google.com > > Thanks, > Mostafa I would then reword that to make it clear it just prevents the host triggering UB on the hypervisor. It doesn't really harden much, which is fine because that data isn't relevant for the hypervisor. Other than that: Reviewed-by: Vincent Donnefort > > > > > > > Signed-off-by: Mostafa Saleh > > > --- > > > arch/arm64/kvm/hyp/nvhe/clock.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/arch/arm64/kvm/hyp/nvhe/clock.c b/arch/arm64/kvm/hyp/nvhe/clock.c > > > index 32fc4313fe43..a7fc61976fd0 100644 > > > --- a/arch/arm64/kvm/hyp/nvhe/clock.c > > > +++ b/arch/arm64/kvm/hyp/nvhe/clock.c > > > @@ -35,6 +35,9 @@ void trace_clock_update(u32 mult, u32 shift, u64 epoch_ns, u64 epoch_cyc) > > > struct clock_data *clock = &trace_clock_data; > > > u64 bank = clock->cur ^ 1; > > > > > > + if (!mult || shift >= 64) > > > + return; > > > + > > > clock->data[bank].mult = mult; > > > clock->data[bank].shift = shift; > > > clock->data[bank].epoch_ns = epoch_ns; > > > -- > > > 2.54.0.545.g6539524ca2-goog > > >