From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH 1/2] VT-d: apply quirks at device setup time rather than only at boot Date: Mon, 28 Apr 2014 10:55:22 +0100 Message-ID: <535E41AA020000780000CCAD@nat28.tlf.novell.com> References: <535E254A020000780000CA9A@nat28.tlf.novell.com> <535E26DE020000780000CAC8@nat28.tlf.novell.com> <535E1FA3.4060501@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WeiHX-0002nG-UA for xen-devel@lists.xenproject.org; Mon, 28 Apr 2014 09:55:32 +0000 In-Reply-To: <535E1FA3.4060501@citrix.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: xen-devel , xiantao.zhang@intel.com, Donald D Dugger List-Id: xen-devel@lists.xenproject.org >>> On 28.04.14 at 11:30, wrote: > On 28/04/14 09:01, Jan Beulich wrote: >> Accessing extended config space may not be possible at boot time, e.g. >> when the memory space used by MMCFG is reserved only via ACPI tables, >> but not in the E820/UEFI memory maps (which we need Dom0 to tell us >> about). Consequently the change here still leaves the issue unaddressed >> for systems where the extended config space remains inaccessible (due >> to firmware bugs, i.e. not properly reserving the address space of >> those regions). >> >> With the respective messages now potentially getting logged more than >> once, we ought to consider whether we should issue them only if we in >> fact were required to do any masking (i.e. if the relevant mask bits >> weren't already set). >> >> This is CVE-2013-3495 / XSA-59. >> >> Signed-off-by: Jan Beulich > > I would agree that log messages should only be presented if Xen had to > change system state. I'll wait for eventual other opinions, but might create a 3rd patch on top of these then. Just for the record, the downside I see to this is that then there's no trace left that a system is secure. An intermediate option might be to downgrade the messages to XENLOG_DEBUG when we didn't really need to do anything. Jan