From: "Adam Dunlap via groups.io" <acdunlap=google.com@groups.io>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: devel@edk2.groups.io, Borislav Petkov <bp@alien8.de>,
Peter Gonda <pgonda@google.com>,
Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [edk2-devel] [PATCH] OvmfPkg: Harden #VC instruction emulation somewhat (CVE-2024-25742)
Date: Thu, 18 Apr 2024 08:39:20 -0700 [thread overview]
Message-ID: <CAMBK9=bXi5fG6KAdUy7oa7=ZWQqC4u0iYHdoL_UnuT0RKDZ-Dw@mail.gmail.com> (raw)
In-Reply-To: <daghpwou63yyswucaecnuubjxabx47ygbza7l7fnc4xxsnvju4@hvxr3vdo54xg>
On Thu, Apr 18, 2024 at 5:15 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> On Wed, Apr 17, 2024 at 09:54:00AM -0700, Adam Dunlap via groups.io wrote:
> > + UINT8 OpCode;
>
> The linux kernel patch uses "unsigned int opcode" and apparently
> checks more than just the first byte for multi-byte opcodes. Why
> do it differently here?
Good question. This patch does check for two-byte opcodes with this snippet:
+ OpCode = *(InstructionData->OpCodes);
+ if (OpCode == TWO_BYTE_OPCODE_ESCAPE) {
+ OpCode = *(InstructionData->OpCodes + 1);
+ }
This works because the first byte of two-byte opcodes is always 0x0f in the
cases that we're checking for. I was wary about blindly dereferencing two
bytes since that could cause a page fault if it was actually a 1 byte opcode
that was at the very end of an allocated region. This is also what is done in
the MmioExit function in this file. The linux kernel instruction decoder is much
more extensive than what is done here and I didn't want to duplicate the
whole thing.
> On the bigger picture: I'm wondering why SNP allows external #VC
> injections in the first place?
Yup, I think it'd be better if it didn't.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117995): https://edk2.groups.io/g/devel/message/117995
Mute This Topic: https://groups.io/mt/105581633/7686176
Mute #vc:https://edk2.groups.io/g/devel/mutehashtag/vc
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
next prev parent reply other threads:[~2024-04-18 15:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 16:54 [edk2-devel] [PATCH] OvmfPkg: Harden #VC instruction emulation somewhat (CVE-2024-25742) Adam Dunlap via groups.io
2024-04-17 17:08 ` Ard Biesheuvel
2024-04-17 17:45 ` Adam Dunlap via groups.io
2024-04-18 8:03 ` Yao, Jiewen
2024-04-18 12:15 ` Gerd Hoffmann
2024-04-18 15:39 ` Adam Dunlap via groups.io [this message]
2024-04-18 15:43 ` Peter Gonda via groups.io
2024-04-19 11:31 ` Gerd Hoffmann
2024-04-19 14:56 ` Lendacky, Thomas via groups.io
2024-04-19 15:12 ` Lendacky, Thomas via groups.io
2024-04-19 17:39 ` Adam Dunlap via groups.io
2024-04-19 18:21 ` [edk2-devel] [PATCH v2] " Adam Dunlap via groups.io
2024-04-22 14:12 ` Lendacky, Thomas via groups.io
2024-04-23 9:27 ` Gerd Hoffmann
2024-04-24 16:27 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMBK9=bXi5fG6KAdUy7oa7=ZWQqC4u0iYHdoL_UnuT0RKDZ-Dw@mail.gmail.com' \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox