head 1.2; access; symbols pkgsrc-2022Q2:1.1.0.16 pkgsrc-2022Q2-base:1.1 pkgsrc-2022Q1:1.1.0.14 pkgsrc-2022Q1-base:1.1 pkgsrc-2021Q4:1.1.0.12 pkgsrc-2021Q4-base:1.1 pkgsrc-2021Q3:1.1.0.10 pkgsrc-2021Q3-base:1.1 pkgsrc-2021Q2:1.1.0.8 pkgsrc-2021Q2-base:1.1 pkgsrc-2021Q1:1.1.0.6 pkgsrc-2021Q1-base:1.1 pkgsrc-2020Q4:1.1.0.4 pkgsrc-2020Q4-base:1.1 pkgsrc-2020Q3:1.1.0.2; locks; strict; comment @# @; 1.2 date 2022.06.28.16.33.25; author bouyer; state dead; branches; next 1.1; commitid lkljtNX5KSYPgPJD; 1.1 date 2020.10.02.13.00.48; author bouyer; state Exp; branches 1.1.2.1; next ; commitid 2MY96Iq2OdtetkqC; 1.1.2.1 date 2020.10.02.13.00.48; author bsiegert; state dead; branches; next 1.1.2.2; commitid 6fMH1kUIpq0AYCqC; 1.1.2.2 date 2020.10.04.20.44.32; author bsiegert; state Exp; branches; next ; commitid 6fMH1kUIpq0AYCqC; desc @@ 1.2 log @Remove xenkernel411 and xenkernel411, they're EOL upstream @ text @$NetBSD: patch-XSA338,v 1.1 2020/10/02 13:00:48 bouyer Exp $ From: Jan Beulich Subject: evtchn: relax port_is_valid() To avoid ports potentially becoming invalid behind the back of certain other functions (due to ->max_evtchn shrinking) because of - a guest invoking evtchn_reset() and from a 2nd vCPU opening new channels in parallel (see also XSA-343), - alloc_unbound_xen_event_channel() produced channels living above the 2-level range (see also XSA-342), drop the max_evtchns check from port_is_valid(). For a port for which the function once returned "true", the returned value may not turn into "false" later on. The function's result may only depend on bounds which can only ever grow (which is the case for d->valid_evtchns). This also eliminates a false sense of safety, utilized by some of the users (see again XSA-343): Without a suitable lock held, d->max_evtchns may change at any time, and hence deducing that certain other operations are safe when port_is_valid() returned true is not legitimate. The opportunities to abuse this may get widened by the change here (depending on guest and host configuration), but will be taken care of by the other XSA. This is XSA-338. Fixes: 48974e6ce52e ("evtchn: use a per-domain variable for the max number of event channels") Signed-off-by: Jan Beulich Reviewed-by: Stefano Stabellini Reviewed-by: Julien Grall --- v5: New, split from larger patch. --- xen/include/xen/event.h.orig +++ xen/include/xen/event.h @@@@ -107,8 +107,6 @@@@ void notify_via_xen_event_channel(struct static inline bool_t port_is_valid(struct domain *d, unsigned int p) { - if ( p >= d->max_evtchns ) - return 0; return p < read_atomic(&d->valid_evtchns); } @ 1.1 log @dd uptream fixes for XSA333, XSA336, XSA337, XSA338, XSA339, XSA340, XSA342, XSA343, XSA344 bump PKGREVISION @ text @d1 1 a1 1 $NetBSD: $ @ 1.1.2.1 log @file patch-XSA338 was added on branch pkgsrc-2020Q3 on 2020-10-04 20:44:32 +0000 @ text @d1 44 @ 1.1.2.2 log @Pullup ticket #6332 - requested by bouyer sysutils/xenkernel411: security fix sysutils/xenkernel413: security fix Revisions pulled up: - sysutils/xenkernel411/Makefile 1.16 - sysutils/xenkernel411/distinfo 1.14 - sysutils/xenkernel411/patches/patch-XSA333 1.1 - sysutils/xenkernel411/patches/patch-XSA336 1.1 - sysutils/xenkernel411/patches/patch-XSA337 1.1 - sysutils/xenkernel411/patches/patch-XSA338 1.1 - sysutils/xenkernel411/patches/patch-XSA339 1.1 - sysutils/xenkernel411/patches/patch-XSA340 1.1 - sysutils/xenkernel411/patches/patch-XSA342 1.1 - sysutils/xenkernel411/patches/patch-XSA343 1.1 - sysutils/xenkernel411/patches/patch-XSA344 1.1 - sysutils/xenkernel413/Makefile 1.5 - sysutils/xenkernel413/distinfo 1.3 - sysutils/xenkernel413/patches/patch-XSA333 1.1 - sysutils/xenkernel413/patches/patch-XSA334 1.1 - sysutils/xenkernel413/patches/patch-XSA336 1.1 - sysutils/xenkernel413/patches/patch-XSA337 1.1 - sysutils/xenkernel413/patches/patch-XSA338 1.1 - sysutils/xenkernel413/patches/patch-XSA339 1.1 - sysutils/xenkernel413/patches/patch-XSA340 1.1 - sysutils/xenkernel413/patches/patch-XSA342 1.1 - sysutils/xenkernel413/patches/patch-XSA343 1.1 - sysutils/xenkernel413/patches/patch-XSA344 1.1 --- Module Name: pkgsrc Committed By: bouyer Date: Thu Oct 1 12:41:19 UTC 2020 Modified Files: pkgsrc/sysutils/xenkernel413: Makefile distinfo Added Files: pkgsrc/sysutils/xenkernel413/patches: patch-XSA333 patch-XSA334 patch-XSA336 patch-XSA337 patch-XSA338 patch-XSA339 patch-XSA340 patch-XSA342 patch-XSA343 patch-XSA344 Log Message: Add uptream fixes for XSA333, XSA334, XSA336, XSA337, XSA338, XSA339, XSA340, XSA342, XSA343, XSA344 bump PKGREVISION --- Module Name: pkgsrc Committed By: bouyer Date: Fri Oct 2 13:00:48 UTC 2020 Modified Files: pkgsrc/sysutils/xenkernel411: Makefile distinfo Added Files: pkgsrc/sysutils/xenkernel411/patches: patch-XSA333 patch-XSA336 patch-XSA337 patch-XSA338 patch-XSA339 patch-XSA340 patch-XSA342 patch-XSA343 patch-XSA344 Log Message: dd uptream fixes for XSA333, XSA336, XSA337, XSA338, XSA339, XSA340, XSA342, XSA343, XSA344 bump PKGREVISION @ text @a0 44 $NetBSD: patch-XSA338,v 1.1 2020/10/02 13:00:48 bouyer Exp $ From: Jan Beulich Subject: evtchn: relax port_is_valid() To avoid ports potentially becoming invalid behind the back of certain other functions (due to ->max_evtchn shrinking) because of - a guest invoking evtchn_reset() and from a 2nd vCPU opening new channels in parallel (see also XSA-343), - alloc_unbound_xen_event_channel() produced channels living above the 2-level range (see also XSA-342), drop the max_evtchns check from port_is_valid(). For a port for which the function once returned "true", the returned value may not turn into "false" later on. The function's result may only depend on bounds which can only ever grow (which is the case for d->valid_evtchns). This also eliminates a false sense of safety, utilized by some of the users (see again XSA-343): Without a suitable lock held, d->max_evtchns may change at any time, and hence deducing that certain other operations are safe when port_is_valid() returned true is not legitimate. The opportunities to abuse this may get widened by the change here (depending on guest and host configuration), but will be taken care of by the other XSA. This is XSA-338. Fixes: 48974e6ce52e ("evtchn: use a per-domain variable for the max number of event channels") Signed-off-by: Jan Beulich Reviewed-by: Stefano Stabellini Reviewed-by: Julien Grall --- v5: New, split from larger patch. --- xen/include/xen/event.h.orig +++ xen/include/xen/event.h @@@@ -107,8 +107,6 @@@@ void notify_via_xen_event_channel(struct static inline bool_t port_is_valid(struct domain *d, unsigned int p) { - if ( p >= d->max_evtchns ) - return 0; return p < read_atomic(&d->valid_evtchns); } @