FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F12.2 2021-02-24T01:42:01Z 2021-02-24T01:42:01Z Roger Pau Monné royger@FreeBSD.org 2021-01-20T18:40:51Z urn:sha1:602f1da04217967e7627be3fe19a56098ad29b6f Multi page rings are mapped using a single hypercall that gets passed an array of grants to map. One of the grants in the array failing to map would lead to the failure of the whole ring setup operation, but there was no cleanup of the rest of the grant maps in the array that could have likely been created as a result of the hypercall. Add proper cleanup on the failure path during ring setup to unmap any grants that could have been created. This is part of XSA-361. Approved by: so Security: CVE-2021-26932 Security: FreeBSD-SA-21:06.xen Security: XSA-361 Sponsored by: Citrix Systems R&D (cherry picked from commit 808d4aad1022a2a33d222663b0c9badde30b9d45) (cherry picked from commit dfb372f5d38c302953a6a4e2838179cd0a1a6438) 2021-01-29T01:15:45Z Roger Pau Monné royger@FreeBSD.org 2020-11-25T11:34:38Z urn:sha1:0b9b9a15c24142efcd675b454843991856af1c97 Xenstore watches received are queued in a list and processed in a deferred thread. Such queuing was done without any checking, so a guest could potentially trigger a resource starvation against the FreeBSD kernel if such kernel is watching any user-controlled xenstore path. Allowing limiting the amount of pending events a watch can accumulate to prevent a remote guest from triggering this resource starvation issue. For the PV device backends and frontends this limitation is only applied to the other end /state node, which is limited to 1 pending event, the rest of the watched paths can still have unlimited pending watches because they are either local or controlled by a privileged domain. The xenstore user-space device gets special treatment as it's not possible for the kernel to know whether the paths being watched by user-space processes are controlled by a guest domain. For this reason watches set by the xenstore user-space device are limited to 1000 pending events. Note this can be modified using the max_pending_watch_events sysctl of the device. This is XSA-349. Sponsored by: Citrix Systems R&D MFC after: 3 days (cherry picked from commit 4e4e43dc9e1afc863670a031cc5cc75eb5e668d6) (cherry picked from commit 2d194dc219892049dd03564c4083080cac1aa688) Approved by: so Security: XSA-349, CVE-2020-29568 2020-07-01T01:12:23Z Konstantin Belousov kib@FreeBSD.org 2020-07-01T01:12:23Z urn:sha1:4d27be0a24ee18e87be72e35d2c775dd262772d7 Remove double-calls to tc_get_timecount() to warm timecounters 2020-06-18T15:15:04Z Roger Pau Monné royger@FreeBSD.org 2020-06-18T15:15:04Z urn:sha1:f82d96fe8037ab66f7841de5fd0b52da7caf463d MFC r357616: xen/console: fix priority of Xen console MFC r361274: dev/xenstore: fix return with locks held Note this should be dev/evtchn not dev/xenstore. MFC r361578: xenpv: do not use low 1MB for Xen mappings on i386 MFC r361580: xen/control: short circuit xctrl_on_watch_event on spurious event Those are all Xen related fixes or minor improvements that have been sitting on current for a reasonable time without complaints. Sponsored by: Citrix Systems R&D 2020-04-24T13:31:22Z Kyle Evans kevans@FreeBSD.org 2020-04-24T13:31:22Z urn:sha1:74727284b626971c5209f162f593ec65d4606b64 A later change, currently being iterated on in D24459, will in-fact change the lock type to an sx so that TTY drivers can sleep on it if they need to. Committing this ahead of time to make the review in question a little more palatable. tty_lock_assert() is unfortunately still needed for now in two places to make sure that the tty lock has not been recursed upon, for those scenarios where it's supplied by the TTY driver and possibly a mutex that is allowed to recurse. 2019-10-18T13:41:08Z Mark Johnston markj@FreeBSD.org 2019-10-18T13:41:08Z urn:sha1:c63146855722abc9a489bdcf468c480dfef107ba Remove an unneeded include of opt_sctp.h. 2019-06-17T15:11:04Z Mark Johnston markj@FreeBSD.org 2019-06-17T15:11:04Z urn:sha1:3c2656961c6594094d39059e03986cc897fbb3a3 Replace uses of vm_page_unwire(m, PQ_NONE) with vm_page_unwire_noq(m). 2018-12-16T02:42:32Z Konstantin Belousov kib@FreeBSD.org 2018-12-16T02:42:32Z urn:sha1:eb0fe45f8bbe3eccfa09feddef3c060acd56f0b2 Change the vm_ooffset_t type to unsigned. MFC note: For KPI stability, UOFF_TO_IDX() macro is still provided, redefined to OFF_TO_IDX(). 2018-09-13T07:15:02Z Roger Pau Monné royger@FreeBSD.org 2018-09-13T07:15:02Z urn:sha1:5ff6c7f3638411bf7e82dedd57f0f7cba57bc77d The Xen page-table walker used to resolve the virtual addresses in the hypercalls will refuse to access user-space pages when SMAP is enabled unless the AC flag in EFLAGS is set (just like normal hardware with SMAP support would do). Since privcmd allows forwarding hypercalls (and buffers) from user-space into Xen make sure SMAP is temporary disabled for the duration of the hypercall from user-space. Approved by: re (gjb) Sponsored by: Citrix Systems R&D 2018-08-23T16:52:52Z Kristof Provost kp@FreeBSD.org 2018-08-23T16:52:52Z urn:sha1:903eaa68f13b8a3b2d6fd035bb1376d7ac2247a7 netfront_backend_changed() is called from the xenwatch_thread(), which means that the curvnet is not set. We have to set it before we can call things like arp_ifinit(). PR: 230845