From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Wang, Zhi A" <zhi.a.wang@intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>
Cc: "Vetter, Daniel" <daniel.vetter@intel.com>,
"Lv, Zhiyuan" <zhiyuan.lv@intel.com>
Subject: Re: Wrt golden MMIO/CFG snaphot in GVT-g
Date: Fri, 27 May 2016 10:09:07 +0000 [thread overview]
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D15F87B924@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <F3B0350DF4CB6849A642218320DE483D4B972048@SHSMSX101.ccr.corp.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 1758 bytes --]
Curious why leaking BIOS configuration to VM is a security problem... Can someone elaborate this view?
From: Wang, Zhi A
Sent: Friday, May 27, 2016 6:05 PM
To: intel-gfx@lists.freedesktop.org
Cc: joonas.lahtinen@linux.intel.com; Chris Wilson; Vetter, Daniel; tvrtko.ursulin@linux.intel.com; Tian, Kevin; Lv, Zhiyuan
Subject: FW: Wrt golden MMIO/CFG snaphot in GVT-g
For me I think maybe i915 could save the snapshot for GVT, then GVT-g patch the snapshot itself, then there won't be leaking happened I think. Even we wrote a dedicated little program, we would do the same thing.
From: Wang, Zhi A
Sent: Friday, May 27, 2016 12:59 PM
To: joonas.lahtinen@linux.intel.com<mailto:joonas.lahtinen@linux.intel.com>; 'Chris Wilson' <chris@chris-wilson.co.uk<mailto:chris@chris-wilson.co.uk>>; Vetter, Daniel <daniel.vetter@intel.com<mailto:daniel.vetter@intel.com>>; tvrtko.ursulin@linux.intel.com<mailto:tvrtko.ursulin@linux.intel.com>
Cc: Tian, Kevin <kevin.tian@intel.com<mailto:kevin.tian@intel.com>>; Lv, Zhiyuan <zhiyuan.lv@intel.com<mailto:zhiyuan.lv@intel.com>>
Subject: Wrt golden MMIO/CFG snaphot in GVT-g
Hi Guys:
I received some comments on from Kevin. Mostly his concern is the burden of maintain/releasing the MMIO/CFG snapshot for customers. As we might not have all the SKUs/platform which customers have, even we release the snapshot file generator for customer, it would still bring some extra effort when customer deploying the SW. And he suggested i915 better i915 could keep the snapshot for GVT-g during module loading. As we have shared some ideas about the security problem like leaking BIOS configuration to VM, better we could elaborate more ideas and figure out a better approach. Let's discuss. :)
Thanks,
Zhi.
[-- Attachment #1.2: Type: text/html, Size: 6685 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-05-27 10:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-27 10:05 FW: Wrt golden MMIO/CFG snaphot in GVT-g Wang, Zhi A
2016-05-27 10:09 ` Tian, Kevin [this message]
2016-05-27 11:38 ` Joonas Lahtinen
2016-06-03 12:19 ` Tian, Kevin
2016-05-27 11:32 ` FW: " Joonas Lahtinen
2016-05-31 14:01 ` Zhiyuan Lv
2016-06-01 12:49 ` Joonas Lahtinen
2016-06-01 14:40 ` Zhiyuan Lv
2016-06-03 12:36 ` Tian, Kevin
2016-06-08 9:23 ` Joonas Lahtinen
2016-06-15 8:05 ` Tian, Kevin
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=AADFC41AFE54684AB9EE6CBC0274A5D15F87B924@SHSMSX101.ccr.corp.intel.com \
--to=kevin.tian@intel.com \
--cc=daniel.vetter@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=zhi.a.wang@intel.com \
--cc=zhiyuan.lv@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.