qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Brijesh Singh <brijesh.singh@amd.com>
Cc: qemu-devel@nongnu.org,
	Alistair Francis <alistair.francis@xilinx.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Cornelia Huck <cornelia.huck@de.ibm.com>,
	"Daniel P . Berrange" <berrange@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Edgar E. Iglesias" <edgar.iglesias@xilinx.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	Eric Blake <eblake@redhat.com>,
	kvm@vger.kernel.org, Marcel Apfelbaum <marcel@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Peter Crosthwaite <crosthwaite.peter@gmail.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	Richard Henderson <richard.henderson@linaro.org>,
	Stefan Hajnoczi <stefanha@gmail.com>,
	Thomas Lendacky <Thomas.Lendacky@amd.com>,
	Borislav Petkov <bp@suse.de>, Alexander Graf <agraf@suse.de>,
	Bruce Rogers <brogers@suse.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v11 21/28] sev/i386: add debug encrypt and decrypt commands
Date: Wed, 7 Mar 2018 20:11:13 +0000	[thread overview]
Message-ID: <20180307201112.GK3089@work-vm> (raw)
In-Reply-To: <7b76c3ca-dc35-8bea-2513-7b4da262c91d@amd.com>

* Brijesh Singh (brijesh.singh@amd.com) wrote:
> 
> 
> On 3/7/18 12:24 PM, Dr. David Alan Gilbert wrote:
> > * Brijesh Singh (brijesh.singh@amd.com) wrote:
> >>
> >> On 03/07/2018 11:27 AM, Dr. David Alan Gilbert wrote:
> >>
> >> [...]
> >>
> >>>> +{
> >>>> +    SEVState *s = (SEVState *)handle;
> >>>> +
> >>>> +    /* If policy does not allow debug then no need to register ops */
> >>>> +    if (s->policy & SEV_POLICY_NODBG) {
> >>>> +        return;
> >>>> +    }
> >>> So what happens if someone tries to use a gdb or monitor command when
> >>> policy didn't allow debug?  Does it end up with an obvious error
> >>> somehow?
> >>>
> >> In those cases caller will get encrypted bytes, leading to unintelligible
> >> data. It can sometime translate into  obvious errors e.g caller tries to
> >> walk guest pagtable and it gets garbage and will have trouble dumping the
> >> pgtables etc. Many times qemu calls ldphys_* functions to access the data it
> >> may get tricky to report the errors.
> > So would it make sense to have something like:
> >
> > sev_mem_cant_read(uint8_t *dst, const uint8_t *src, uint32_t len, MemTxAttrs attrs)
> > {
> >     error_report("SEV Guest policy does not allow debug access");
> >
> >     return -EPERM;
> > }
> 
> In very early patches we had something similar but I was not sure  if
> that was right thing. Any debug accesses were  printing ton of messages

OK, if it would generate silly amounts of debug then leave it as is;
but I bet it'll confuse someone in the future when they try and dig
through it for debug without realising SEV-debug is there!

Dave

> and also in some case caller actually wants to dump the memory content
> (e.g x /10gx 0x000).. what we should return in those cases ? In my
> approach was if debug was not enabled then simply don't decrypt the
> memory and provide the raw data.
> 
> There was some discussion to have very high level security policy which
> may have attribute like debug=on|off, if debug is disabled then QEMU
> monitor can display messages like debug not allowed to better inform user.
> 
> 
> > void
> > sev_set_debug_ops(void *handle, MemoryRegion *mr)
> > {
> >     SEVState *s = (SEVState *)handle;
> >
> >     /* If policy does not allow debug then no need to register ops */
> >     if (s->policy & SEV_POLICY_NODBG) {
> >         sev_ops.read = sev_mem_cant_read;
> >         sev_ops.write = sev_mem_cant_write;
> >     } else {
> >         sev_ops.read = sev_mem_read;
> >         sev_ops.write = sev_mem_write;
> >     }
> >
> > Dave
> >
> >> -Brijesh
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

  reply	other threads:[~2018-03-07 20:11 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-07 16:50 [Qemu-devel] [PATCH v11 00/28] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 01/28] memattrs: add debug attribute Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 02/28] exec: add ram_debug_ops support Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 03/28] exec: add debug version of physical memory read and write API Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 04/28] monitor/i386: use debug APIs when accessing guest memory Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 05/28] machine: add -memory-encryption property Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 06/28] kvm: update kvm.h to include memory encryption ioctls Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 07/28] docs: add AMD Secure Encrypted Virtualization (SEV) Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 09/28] qmp: add query-sev command Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 10/28] include: add psp-sev.h header file Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 11/28] sev/i386: add command to initialize the memory encryption context Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 12/28] sev/i386: register the guest memory range which may contain encrypted data Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 13/28] kvm: introduce memory encryption APIs Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 14/28] hmp: add 'info sev' command Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 15/28] sev/i386: add command to create launch memory encryption context Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 16/28] sev/i386: add command to encrypt guest memory region Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 17/28] target/i386: encrypt bios rom Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 18/28] sev/i386: add support to LAUNCH_MEASURE command Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 19/28] sev/i386: finalize the SEV guest launch flow Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 20/28] hw/i386: set ram_debug_ops when memory encryption is enabled Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 21/28] sev/i386: add debug encrypt and decrypt commands Brijesh Singh
2018-03-07 17:27   ` Dr. David Alan Gilbert
2018-03-07 17:40     ` Brijesh Singh
2018-03-07 18:24       ` Dr. David Alan Gilbert
2018-03-07 19:38         ` Brijesh Singh
2018-03-07 20:11           ` Dr. David Alan Gilbert [this message]
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 22/28] target/i386: clear C-bit when walking SEV guest page table Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 23/28] qmp: add query-sev-launch-measure command Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 24/28] sev/i386: add migration blocker Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 25/28] cpu/i386: populate CPUID 0x8000_001F when SEV is active Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 26/28] qmp: add query-sev-capabilities command Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 27/28] sev/i386: add sev_get_capabilities() Brijesh Singh
2018-03-07 16:50 ` [Qemu-devel] [PATCH v11 28/28] tests/qmp-test: blacklist sev specific qmp commands Brijesh Singh
2018-03-07 17:24 ` [Qemu-devel] [PATCH v11 00/28] x86: Secure Encrypted Virtualization (AMD) no-reply
2018-03-07 20:35   ` Brijesh Singh
2018-03-08  1:10     ` Fam Zheng

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-all 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=20180307201112.GK3089@work-vm \
    --to=dgilbert@redhat.com \
    --cc=Thomas.Lendacky@amd.com \
    --cc=agraf@suse.de \
    --cc=alistair.francis@xilinx.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=bp@suse.de \
    --cc=brijesh.singh@amd.com \
    --cc=brogers@suse.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=crosthwaite.peter@gmail.com \
    --cc=eblake@redhat.com \
    --cc=edgar.iglesias@xilinx.com \
    --cc=ehabkost@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=marcel@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=rth@twiddle.net \
    --cc=stefanha@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).