Re: [Xen-devel] [PATCH 14/16] SUPPORT.md: Add statement on PCI passthrough

[Rich Persaud]

On Nov 22, 2017, at 13:58, George Dunlap <george.dun...@citrix.com> wrote:
> 
>> On 11/16/2017 03:43 PM, Julien Grall wrote:
>> Hi George,
>> 
>>> On 13/11/17 15:41, George Dunlap wrote:
>>> Signed-off-by: George Dunlap <george.dun...@citrix.com>
>>> ---
>>> CC: Ian Jackson <ian.jack...@citrix.com>
>>> CC: Wei Liu <wei.l...@citrix.com>
>>> CC: Andrew Cooper <andrew.coop...@citrix.com>
>>> CC: Jan Beulich <jbeul...@suse.com>
>>> CC: Stefano Stabellini <sstabell...@kernel.org>
>>> CC: Konrad Wilk <konrad.w...@oracle.com>
>>> CC: Tim Deegan <t...@xen.org>
>>> CC: Rich Persaud <pers...@gmail.com>
>>> CC: Marek Marczykowski-Górecki <marma...@invisiblethingslab.com>
>>> CC: Christopher Clark <christopher.w.cl...@gmail.com>
>>> CC: James McKenzie <james.mcken...@bromium.com>
>>> ---
>>>   SUPPORT.md | 33 -
>>>   1 file changed, 32 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/SUPPORT.md b/SUPPORT.md
>>> index 3e352198ce..a8388f3dc5 100644
>>> --- a/SUPPORT.md
>>> +++ b/SUPPORT.md
>>> @@ -454,9 +454,23 @@ there is currently no xl support.
>>> ## Security
>>>   +### Driver Domains
>>> +
>>> +Status: Supported, with caveats
>>> +
>>> +"Driver domains" means allowing non-Domain 0 domains
>>> +with access to physical devices to act as back-ends.
>>> +
>>> +See the appropriate "Device Passthrough" section
>>> +for more information about security support.
>>> +
>>>   ### Device Model Stub Domains
>>>   -Status: Supported
>>> +Status: Supported, with caveats
>>> +
>>> +Vulnerabilities of a device model stub domain
>>> +to a hostile driver domain (either compromised or untrusted)
>>> +are excluded from security support.
>>> ### KCONFIG Expert
>>>   @@ -522,6 +536,23 @@ Virtual Performance Management Unit for HVM guests
>>>   Disabled by default (enable with hypervisor command line option).
>>>   This feature is not security supported: see
>>> http://xenbits.xen.org/xsa/advisory-163.html
>>>   +### x86/PCI Device Passthrough
>>> +
>>> +Status: Supported, with caveats
>>> +
>>> +Only systems using IOMMUs will be supported.
>>> +
>>> +Not compatible with migration, altp2m, introspection, memory sharing,
>>> or memory paging.
>>> +
>>> +Because of hardware limitations
>>> +(affecting any operating system or hypervisor),
>>> +it is generally not safe to use this feature
>>> +to expose a physical device to completely untrusted guests.
>>> +However, this feature can still confer significant security benefit
>>> +when used to remove drivers and backends from domain 0
>>> +(i.e., Driver Domains).
>>> +See docs/PCI-IOMMU-bugs.txt for more information.
>> 
>> Where can I find this file? Is it in staging?
> 
> No, I took this from a recommendation made to me, without checking.
> 
> Rich, are you going to send a patch adding this file, or did you mean to
> point to a different file?

Yes, I’ll send a patch to add this file.

Rich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC v2] Add SUPPORT.md

[Rich Persaud]

> On Sep 11, 2017, at 13:01, George Dunlap  wrote:
> 
> +### XSM & FLASK
> +
> +Status: Experimental
> +
> +Compile time disabled
> +
> +### XSM & FLASK support for IS_PRIV
> +
> +Status: Experimental

In which specific areas is XSM lacking in Functional completeness, Functional 
stability and/or Interface stability, resulting in "Experimental" status?  What 
changes to XSM would be needed for it to qualify for "Supported" status?

If there will be no security support for features in Experimental status, would 
Xen Project accept patches to fix XSM security issues?  Could downstream 
projects issue CVEs for XSM security issues, if these will not be issued by Xen 
Project?

Rich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

[Rich Persaud]

On Sep 11, 2017, at 10:16, George Dunlap  wrote:
> 
>>> +### vTPM Support
>>> +
>>> +Status: Supported, x86 only
>> 
>> This should probably be x86/vTPM. TPM, the way we are discussing it, is
>> an x86-only implementation. ARM-based alternatives are not called TPM
>> AFAIK.
> 
> Someone said that because this was implemented entirely in userspace,
> there's no reason the PV TPM couldn't work on ARM.  OTOH I suppose it
> would be a lot less valuable if there weren't a physical TPM to back it up.
> 
> Any thoughts on that?

Physical TPMs are present on both x86 and ARM Chromebooks:

  https://www.chromium.org/developers/design-documents/tpm-usage

e.g. see Step 9 in this Samsung Series 3 teardown, "Infineon SLB9635":

  https://www.ifixit.com/Teardown/Samsung+Chromebook+Series+3+Teardown/12225


>>> +### Intel/TXT ???
>> 
>> Same here
> 
> Well unless someone actually says something about this I'm just going go
> delete it.

That's one way to motivate a response :)

Slide 11 of Joe Cihula's 2007 presentation documents the Xen changes for TXT: 

  http://www-archive.xenproject.org/files/xensummit_fall07/23_JosephCihula.pdf

More info in the 2007 patch and the Linux kernel doc:

  http://old-list-archives.xen.org/archives/html/xen-devel/2007-10/msg00897.html
  https://www.kernel.org/doc/Documentation/intel_txt.txt

Intel TXT is used with Xen by (at least) Qubes, OpenXT and Skyport Systems.  
There was a design discussion at Xen Summit about implementing a 
frequently-used subset of tboot logic in Xen.  Hopefully Intel TXT will 
continue to be a Xen feature with security support.

Rich___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Call for Comment (by July 14) - NIST Platform Firmware Resiliency Guidelines

[Rich Persaud]

If you are working on EFI, secure boot or measured launch, this document may 
influence future hardware devices.  You can submit comments until this Friday.

https://beta.csrc.nist.gov/News/2017/NIST-Releases-Draft-SP-800-193-for-Public-Comment

---
NIST announces the public comment release of Draft Special Publication 800-193, 
Platform Firmware Resiliency Guidelines. The platform is a collection of 
fundamental hardware and firmware components needed to boot and operate a 
computer system. This document provides technical guidelines and 
recommendations supporting resiliency of platform firmware and data against 
potentially destructive attacks.  These draft guidelines promote resiliency in 
the platform by describing security mechanisms for protecting the platform 
against unauthorized changes, detecting unauthorized changes that occur, and 
secure recovery from attacks. This document is intended to guide implementers, 
including system manufacturers and and component suppliers, on how to use these 
mechanisms to build a strong security foundation into platforms.
---

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] EFI + tboot + Xen

[Rich Persaud]

On Apr 14, 2017, at 16:43, Daniel Kiper  wrote:
> 
>> On Fri, Apr 14, 2017 at 04:17:54PM +0100, Andrew Cooper wrote:
>>> On 14/04/2017 15:54, Daniel Kiper wrote:
>>> Hey,
>>> 
>>> Has anybody tried to run EFI + tboot + Xen?
>>> I have a feeling that it does not work because
>>> tboot shuts down EFI boot services. However,
>>> even if it works then efibootmgr is unusable
>>> due to lack of EFI runtime services. Do we care?
>>> Is it possible to make it work with full blown
>>> EFI infrastructure available for Xen?
>> 
>> Judging by
>> http://hg.code.sf.net/p/tboot/code/file/9352e6391332/tboot/common/boot.S#l83
>> it will be grub exiting boot services.  tboot needs rather more
>> multiboot2 knowledge before it could participate in a hand-off to Xen
>> while keeping boot services active.
> 
> Sure, it is not a problem. However, I was told that it was (not) done
> deliberately because we cannot trust EFI due to lack of its measurement.
> I am not sure it is true or not. I though that somebody played with tboot
> and Xen and has some knowledge in that area. Anyway, I will investigate
> this further. However, any knowledge sharing is greatly appreciated.

On the OpenXT project, Ross Philipson has an early PoC:
https://github.com/rossphilipson/efi-tboot

From the README:
---
EFI TBOOT is mostly a proof of concept at this point. It is not currently 
functional. It can be built and installed as an EFI boot loader. It only works 
in conjunction with Xen at the moment. The current development work is being 
done on Fedora 25 x64. The status as of March 14, 2017 is: 

- EFI TBOOT will boot, but it needs a few key strokes to get going (this is for 
debugging purposes). 
- EFI TBOOT will relocate itself to EFI runtime memory and setup a shared 
runtime variable with Xen. 
- EFI related configuration setup is done as well as standard TBOOT pre- launch 
configuration. 
- Xen is launched and has code to call EFI TBOOT back after EBS. 
- EFI TBOOT then does the SENTER successfully in the callback. 
- The post launch entry point is reached but the switch back to long mode is 
not working
---

Rich___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Intel hosts OpenXT Summit on Xen Project based Client Virtualization, June 7-8 in Fairfax, VA, USA

[Rich Persaud]

The inaugural OpenXT Summit brings together developers and ecosystem 
participants for a 2-day conference in Fairfax, VA, USA on June 7-8, 2016.  The 
audience for this event includes kernel and application developers, hardware 
designers, system integrators and security architects.

Released as open-source software in 2014, OpenXT is a development toolkit for 
hardware-assisted security research and appliance integration. It includes 
hardened Linux VMs that can be configured as a user-facing software appliance 
for client devices, with virtualization of storage, network, input, sound, 
display and USB devices.  Hardware targets include laptops, desktops and 
workstations.  

OpenXT stands on the shoulders of the Xen Project, OpenEmbedded Linux and 
Citrix XenClient XT.  It is optimized for hardware-assisted virtualization with 
an IOMMU and a TPM.  It configures Xen network driver domains, Linux stub 
domains, Xen Security Modules, GPU passthrough, Intel TXT, SE Linux, and VPNs.  
Guest operating systems include Windows, Linux and FreeBSD.  VM storage options 
include encrypted VHD files with boot-time measurement and non-persistence.  

The 2016 OpenXT Summit will chart the evolution of OpenXT from cross-domain 
endpoint virtualization to an extensible systems innovation platform, enabling 
derivative products to make security assurances for diverse hardware, markets 
and use cases.  

There is no cost to attend, but registration is required.  For more 
information, please see the event website at http://openxt.org/summit.   For 
presentations and papers related to OpenXT, please see 
http://openxt.org/history.

Regards,
Rich___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel