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-XSA340,v 1.1 2020/10/02 13:00:48 bouyer Exp $ From: Julien Grall Subject: xen/evtchn: Add missing barriers when accessing/allocating an event channel While the allocation of a bucket is always performed with the per-domain lock, the bucket may be accessed without the lock taken (for instance, see evtchn_send()). Instead such sites relies on port_is_valid() to return a non-zero value when the port has a struct evtchn associated to it. The function will mostly check whether the port is less than d->valid_evtchns as all the buckets/event channels should be allocated up to that point. Unfortunately a compiler is free to re-order the assignment in evtchn_allocate_port() so it would be possible to have d->valid_evtchns updated before the new bucket has finish to allocate. Additionally on Arm, even if this was compiled "correctly", the processor can still re-order the memory access. Add a write memory barrier in the allocation side and a read memory barrier when the port is valid to prevent any re-ordering issue. This is XSA-340. Reported-by: Julien Grall Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini --- xen/common/event_channel.c.orig +++ xen/common/event_channel.c @@@@ -178,6 +178,13 @@@@ int evtchn_allocate_port(struct domain * return -ENOMEM; bucket_from_port(d, port) = chn; + /* + * d->valid_evtchns is used to check whether the bucket can be + * accessed without the per-domain lock. Therefore, + * d->valid_evtchns should be seen *after* the new bucket has + * been setup. + */ + smp_wmb(); write_atomic(&d->valid_evtchns, d->valid_evtchns + EVTCHNS_PER_BUCKET); } --- xen/include/xen/event.h.orig +++ xen/include/xen/event.h @@@@ -107,7 +107,17 @@@@ void notify_via_xen_event_channel(struct static inline bool_t port_is_valid(struct domain *d, unsigned int p) { - return p < read_atomic(&d->valid_evtchns); + if ( p >= read_atomic(&d->valid_evtchns) ) + return false; + + /* + * The caller will usually access the event channel afterwards and + * may be done without taking the per-domain lock. The barrier is + * going in pair the smp_wmb() barrier in evtchn_allocate_port(). + */ + smp_rmb(); + + return true; } static inline struct evtchn *evtchn_from_port(struct domain *d, unsigned int p) @ 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-XSA340 was added on branch pkgsrc-2020Q3 on 2020-10-04 20:44:32 +0000 @ text @d1 67 @ 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 67 $NetBSD: patch-XSA340,v 1.1 2020/10/02 13:00:48 bouyer Exp $ From: Julien Grall Subject: xen/evtchn: Add missing barriers when accessing/allocating an event channel While the allocation of a bucket is always performed with the per-domain lock, the bucket may be accessed without the lock taken (for instance, see evtchn_send()). Instead such sites relies on port_is_valid() to return a non-zero value when the port has a struct evtchn associated to it. The function will mostly check whether the port is less than d->valid_evtchns as all the buckets/event channels should be allocated up to that point. Unfortunately a compiler is free to re-order the assignment in evtchn_allocate_port() so it would be possible to have d->valid_evtchns updated before the new bucket has finish to allocate. Additionally on Arm, even if this was compiled "correctly", the processor can still re-order the memory access. Add a write memory barrier in the allocation side and a read memory barrier when the port is valid to prevent any re-ordering issue. This is XSA-340. Reported-by: Julien Grall Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini --- xen/common/event_channel.c.orig +++ xen/common/event_channel.c @@@@ -178,6 +178,13 @@@@ int evtchn_allocate_port(struct domain * return -ENOMEM; bucket_from_port(d, port) = chn; + /* + * d->valid_evtchns is used to check whether the bucket can be + * accessed without the per-domain lock. Therefore, + * d->valid_evtchns should be seen *after* the new bucket has + * been setup. + */ + smp_wmb(); write_atomic(&d->valid_evtchns, d->valid_evtchns + EVTCHNS_PER_BUCKET); } --- xen/include/xen/event.h.orig +++ xen/include/xen/event.h @@@@ -107,7 +107,17 @@@@ void notify_via_xen_event_channel(struct static inline bool_t port_is_valid(struct domain *d, unsigned int p) { - return p < read_atomic(&d->valid_evtchns); + if ( p >= read_atomic(&d->valid_evtchns) ) + return false; + + /* + * The caller will usually access the event channel afterwards and + * may be done without taking the per-domain lock. The barrier is + * going in pair the smp_wmb() barrier in evtchn_allocate_port(). + */ + smp_rmb(); + + return true; } static inline struct evtchn *evtchn_from_port(struct domain *d, unsigned int p) @