[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230925182834.GA8247@openwall.com>
Date: Mon, 25 Sep 2023 20:28:34 +0200
From: Solar Designer <solar@...nwall.com>
To: Andrew Cooper <andrew.cooper3@...rix.com>
Cc: oss-security@...ts.openwall.com,
"Xen. org security team" <security-team-members@....org>
Subject: Re: Xen Security Advisory 439 v1 (CVE-2023-20588) - x86/AMD: Divide speculative information leak
On Mon, Sep 25, 2023 at 06:10:05PM +0100, Andrew Cooper wrote:
> On 25/09/2023 5:36 pm, Solar Designer wrote:
> > While I am at it, here's the corresponding mitigation in Linux kernel:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=77245f1c3c6495521f6a3af082696ee2f8ce3921
>
> Not really. That patch entirely misunderstood the vulnerability. I
> went through several rounds of getting AMD to better-understand their bug.
>
> Linux's fix was rewritten in
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f58d6fbcb7c848b7f2469be339bc571f2e9d245b
> and this implements the same logic as I implemented in Xen.
Oh wow. Thank you for correcting me (and correcting AMD first?)
> It's worth noting that because AMD did not allocate a $FOO_NO CPUID bit,
> there's no ability for a VM to figure out that it might move to
> vulnerable hardware and therefore should engage the workaround. The
> best a VM can do is best-effort based on whether it looks like it's
> booting on a Zen1 system.
Maybe directly probing for the bug is an option? Perhaps can be done
within one thread (where the bug doesn't have security impact, but is
detectable anyway, no)?
> Also the cross-thread nature is also poorly reported in public.
Right, I couldn't find it mentioned anywhere other than your advisory.
Do you know if only the quotient leaks, or also the remainder? In the
below, I assume the remainder leaks as well.
I'm concerned it could affect some cryptographic code, in particular
(but in a very minor way) typical implementations of Argon2. There's a
3-year-pending pull request to the upstream/reference Argon2
implementation that I think would avoid the issue there (by optimizing
out the divides):
https://github.com/P-H-C/phc-winner-argon2/pull/306
but there are many other implementations and I guess (almost?) all use
the programming language's modulo division operation as-is. Luckily,
the severity is minor - this would only affect the cache-timing unsafe
flavors, providing an extra (more direct and maybe more reliable?)
side-channel, and this only matters when the attacker has a copy of or
has guessed the salts (the same as for other cache-timing unsafe
password hashes/KDFs). So in terms of threat models and attack vectors,
no change at all, but real-world (in)feasibility of otherwise-similar
attacks can vary. No big deal, just something to improve where we can.
For others reading just the list postings and for archival, this newer
Linux kernel commit is:
> author Borislav Petkov (AMD) <bp@...en8.de> 2023-08-11 23:38:24 +0200
> committer Borislav Petkov (AMD) <bp@...en8.de> 2023-08-14 11:02:50 +0200
>
> x86/CPU/AMD: Fix the DIV(0) initial fix attempt
>
> Initially, it was thought that doing an innocuous division in the #DE
> handler would take care to prevent any leaking of old data from the
> divider but by the time the fault is raised, the speculation has already
> advanced too far and such data could already have been used by younger
> operations.
>
> Therefore, do the innocuous division on every exit to userspace so that
> userspace doesn't see any potentially old data from integer divisions in
> kernel space.
>
> Do the same before VMRUN too, to protect host data from leaking into the
> guest too.
>
> Fixes: 77245f1c3c64 ("x86/CPU/AMD: Do not leak quotient data after a division by 0")
> Signed-off-by: Borislav Petkov (AMD) <bp@...en8.de>
> Cc: <stable@...nel.org>
> Link: https://lore.kernel.org/r/20230811213824.10025-1-bp@alien8.de
Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
