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]
Date:   Mon, 23 Oct 2023 17:00:38 -0700
From:   Pawan Gupta <>
To:     Dave Hansen <>
Cc:     Josh Poimboeuf <>,
        Thomas Gleixner <>,
        Ingo Molnar <>, Borislav Petkov <>,
        Dave Hansen <>,,
        "H. Peter Anvin" <>,
        Peter Zijlstra <>,
        Andy Lutomirski <>,
        Jonathan Corbet <>,
        Sean Christopherson <>,
        Paolo Bonzini <>,,,,,,,
        Alyssa Milburn <>,
        Daniel Sneddon <>,
Subject: Re: [PATCH 2/6] x86/entry_64: Add VERW just before userspace

On Mon, Oct 23, 2023 at 03:45:41PM -0700, Dave Hansen wrote:
> On 10/23/23 15:30, Pawan Gupta wrote:
> >>>>>  	/*
> >>>>>  	 * iretq reads the "iret" frame and exits the NMI stack in a
> >>>>>  	 * single instruction.  We are returning to kernel mode, so this
> >>>> This isn't needed here.  This is the NMI return-to-kernel path.
> >>> Yes, the VERW here can be omitted. But probably need to check if an NMI
> >>> occuring between VERW and ring transition will still execute VERW after
> >>> the NMI.
> >> That window does exist, though I'm not sure it's worth worrying about.
> > I am in favor of omitting the VERW here, unless someone objects with a
> > rationale. IMO, precisely timing the NMIs in such a narrow window is
> > impractical.
> I'd bet that given the right PMU event you could make this pretty
> reliable.  But normal users can't do that by default.  That leaves the
> NMI watchdog which (I bet) you can still time, but which is pretty low
> frequency.
> Are there any other NMI sources that a normal user can cause problems with?

Generating recoverable parity check errors using rowhammer? But, thats
probably going too far for very little gain.

> Let's at least leave a marker in here that folks can grep for:
> 	/* Skip CLEAR_CPU_BUFFERS since it will rarely help */


> and some nice logic in the changelog that they can dig out if need be.
> But, basically it sounds like the logic is:
> 1. It's rare to get an NMI after VERW but before returning to userspace
> 2. There is no known way to make that NMI less rare or target it
> 3. It would take a large number of these precisely-timed NMIs to mount
>    an actual attack.  There's presumably not enough bandwidth.

Thanks for this.

> Anything else?

4. The NMI in question occurs after a VERW, i.e. when user state is
   restored and most interesting data is already scrubbed. Whats left is
   only the data that NMI touches, and that may or may not be

Powered by blists - more mailing lists