lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <69a1443e73dc1c10a23cf0632a507c01eece9760.camel@intel.com>
Date: Tue, 11 Feb 2025 18:29:26 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "Zhao, Yan Y" <yan.y.zhao@...el.com>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "seanjc@...gle.com" <seanjc@...gle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] KVM: selftests: Wait mprotect_ro_done before write to RO
 in mmu_stress_test

On Tue, 2025-02-11 at 09:42 +0800, Yan Zhao wrote:
> > Is this a fix for the intermittent failure we saw on the v6.13-rc3 based kvm
> > branch? Funnily, I can't seem to reproduce it anymore, with or without this
> > fix.
> Hmm, it can be reproduced in my SPR (non TDX) almost every time.
> It depends on the timing when mprotect(PROT_READ) is completed done.
> 
> Attached the detailed error log in my machine at the bottom.

I must be getting lucky on timing. BTW, in the above I actually meant on either
the new or old *kernel*.

>  
> > On the fix though, doesn't this remove the coverage of writing to a region
> > that
> > is in the process of being made RO? I'm thinking about warnings, etc that
> > may
> > trigger intermittently based on bugs with a race component. I don't know if
> > we
> > could fix the test and still leave the write while the "mprotect(PROT_READ)
> > is
> > underway". It seems to be deliberate.
> Write before "mprotect(PROT_READ)" has been tested in stage 0.
> Not sure it's deliberate to test write in the process of being made RO.
> If it is, maybe we could make the fix by writing to RO memory a second time
> after mprotect_ro_done is true:

That could work if it's desirable to maintain the testing. I would mention the
reduced scope in the log at least. Maybe Sean will chime in.

Also, I think it needs:

Fixes: b6c304aec648 ("KVM: selftests: Verify KVM correctly handles
mprotect(PROT_READ)")

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ