From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH 1/2] VT-d: apply quirks at device setup time rather than only at boot Date: Mon, 28 Apr 2014 11:01:13 +0100 Message-ID: <535E26E9.8060100@citrix.com> References: <535E254A020000780000CA9A@nat28.tlf.novell.com> <535E26DE020000780000CAC8@nat28.tlf.novell.com> <535E1FA3.4060501@citrix.com> <535E41AA020000780000CCAD@nat28.tlf.novell.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 1WeiNC-00048e-FE for xen-devel@lists.xenproject.org; Mon, 28 Apr 2014 10:01:18 +0000 In-Reply-To: <535E41AA020000780000CCAD@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , xiantao.zhang@intel.com, Donald D Dugger List-Id: xen-devel@lists.xenproject.org On 28/04/14 10:55, Jan Beulich wrote: >>>> 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 > Hmm yes - that is a point. It probably is best to leave some hint for people really trying to find it. ~Andrew