From owner-freebsd-virtualization@freebsd.org Thu Dec 13 11:15:42 2018 Return-Path: Delivered-To: freebsd-virtualization@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 738B31317865 for ; Thu, 13 Dec 2018 11:15:42 +0000 (UTC) (envelope-from martin@lucina.net) Received: from smtp.lucina.net (smtp.lucina.net [62.176.169.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.lucina.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F8AC832BF for ; Thu, 13 Dec 2018 11:15:41 +0000 (UTC) (envelope-from martin@lucina.net) Received: from nodbug.lucina.net (78-141-76-187.dynamic.orange.sk [78.141.76.187]) by smtp.lucina.net (Postfix) with ESMTPSA id BCA8C122804 for ; Thu, 13 Dec 2018 12:15:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201811; t=1544699739; bh=Vuz2WFm9I/CFl0n88PAlOisZDz0KAaZnrLxlNK0XjuQ=; h=Date:From:To:Subject:From; b=S29wc4MbqThCSNM/Z5G0OxQP+RFZXCqWTQEg2rbNNvsm3wC1q/iAjrDbHc4WHubT5 Pjvhqzy5gMFG9IXmDX9eA9PZezqoGeAjIGp95aIZevR4pJRN4Q1His6d5LhA6D24NT Hzbb1ULjw2tOM4VsFkxb95ijBTVNyZP1TF2Jrg46sfHRNflZax4vwzc6xRRob+gdXf U0F+D9KXD2p/S/3w0gSHheiYest4uclPqSMQukufiSgfKgclEJhq0OD1TaSnUMxF0B TXtD/AwCL5avgSABVuYF59buy9UteboM+GwVtEWue3MeUq166d5yS8CDdPeZLg7/Iv YrSvkYoQviL9Q== Received: by nodbug.lucina.net (Postfix, from userid 1000) id ACDDC265F864; Thu, 13 Dec 2018 12:15:39 +0100 (CET) Date: Thu, 13 Dec 2018 12:15:39 +0100 From: Martin Lucina To: freebsd-virtualization@freebsd.org Subject: vmm support for updating guest EPT mappings Message-ID: <20181213111539.m3jsxl7eg3btrjf7@nodbug.lucina.net> Mail-Followup-To: freebsd-virtualization@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) X-Rspamd-Queue-Id: 9F8AC832BF X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lucina.net header.s=dkim-201811 header.b=S29wc4Mb; dmarc=pass (policy=none) header.from=lucina.net; spf=pass (mx1.freebsd.org: domain of martin@lucina.net designates 62.176.169.44 as permitted sender) smtp.mailfrom=martin@lucina.net X-Spamd-Result: default: False [-0.86 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[lucina.net:s=dkim-201811]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:62.176.169.44]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-virtualization@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(0.09)[0.090,0]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.05)[0.047,0]; DKIM_TRACE(0.00)[lucina.net:+]; DMARC_POLICY_ALLOW(-0.50)[lucina.net,none]; MX_GOOD(-0.01)[cached: smtp.lucina.net]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:12905, ipnet:62.176.160.0/19, country:SK]; IP_SCORE(0.01)[country: SK(0.05)]; RECEIVED_SPAMHAUS_PBL(0.00)[187.76.141.78.zen.spamhaus.org : 127.0.0.11] X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 11:15:42 -0000 Hi, as part of my work on Solo5 [1], I recently discovered that some assumptions I made during developing a FreeBSD vmm backend for our "hvt" tender (f.k.a. "ukvm", which some of you may be aware of) do not hold. Specifically, our ELF loader relies on the ability to enforce memory protection at the guest-physical to host-virtual translation point (i.e. via the EPT mappings). At the time that I wrote the code, I wrongly assumed that FreeBSD vmm would follow the Linux KVM behaviour, i.e. that a host-side mprotect() on a memory range which is part of guest memory would update the EPT mapping used by the hypervisor. For some discussion on our end please see the issue filed at [2], including a proposal from the OpenBSD vmm folks, for which we also have a backend, to implement an "ept-mprotect" like call. Is there any way to get this ability in FreeBSD vmm? I'd be happy with either a solution similar to what Linux KVM does (hooking the EPT mapping update to the host-side mprotect), or the OpenBSD proposal which is actually more flexible in the long run as it could allow for execute-only pages on x86. In my initial investigation I thought this might be achievable in a limited way with careful use of VM_MMAP_MEMSEG, but that seems like the wrong approach? Note that we deliberately do not use libvmmapi in Solo5 due to it making assumptions over things like guest memory layout that are more suited to a "classic" VMM such as bhyve. Martin [1] https://github.com/Solo5/solo5 [2] https://github.com/Solo5/solo5/issues/303