Changes since v1 [1]:
* Fix the fact that devmem_is_allowed() == 2 does not prevent
mmap access (Kees)
* Rather than teach devmem_is_allowed() == 2 to map zero pages in the
mmap case, just fail (Nikolay)
[1]: http://lore.kernel.org/67f5b75c37143_71fe2949b@dwillia2-xfh.jf.intel.com.no…
---
The story starts with Nikolay reporting an SEPT violation due to
mismatched encrypted/non-encrypted mappings of the BIOS data space [2].
An initial suggestion to just make sure that the BIOS data space is
mapped consistently [3] ran into another issue that TDX and SEV-SNP
disagree about when that space can be mapped as encrypted.
Then, in response to a partial patch to allow SEV-SNP to block BIOS data
space for other reasons [4], Dave asked why not just give up on /dev/mem
access entirely in the confidential VM case [5].
Enter this series to:
1/ Close a subtle hole whereby /dev/mem that is supposed return zeros in
lieu of access only enforces that for read()/write()
2/ Use that new closed hole to reliably disable all /dev/mem access for
confidential x86 VMs
[2]: http://lore.kernel.org/20250318113604.297726-1-nik.borisov@suse.com
[3]: http://lore.kernel.org/174346288005.2166708.14425674491111625620.stgit@dwil…
[4]: http://lore.kernel.org/20250403120228.2344377-1-naveen@kernel.org
[5]: http://lore.kernel.org/fd683daa-d953-48ca-8c5d-6f4688ad442c@intel.com
---
Dan Williams (3):
x86/devmem: Remove duplicate range_is_allowed() definition
devmem: Block mmap access when read/write access is restricted
x86/devmem: Restrict /dev/mem access for potentially unaccepted memory by default
arch/x86/Kconfig | 2 ++
arch/x86/include/asm/x86_init.h | 2 ++
arch/x86/kernel/x86_init.c | 6 ++++++
arch/x86/mm/init.c | 23 +++++++++++++++++------
arch/x86/mm/pat/memtype.c | 31 ++++---------------------------
drivers/char/mem.c | 18 ------------------
include/linux/io.h | 26 ++++++++++++++++++++++++++
7 files changed, 57 insertions(+), 51 deletions(-)
base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8
The following commit has been merged into the sched/core branch of tip:
Commit-ID: c70fc32f44431bb30f9025ce753ba8be25acbba3
Gitweb: https://git.kernel.org/tip/c70fc32f44431bb30f9025ce753ba8be25acbba3
Author: Peter Zijlstra <peterz(a)infradead.org>
AuthorDate: Tue, 28 Jan 2025 15:39:49 +01:00
Committer: Peter Zijlstra <peterz(a)infradead.org>
CommitterDate: Wed, 16 Apr 2025 21:09:12 +02:00
sched/fair: Adhere to place_entity() constraints
Mike reports that commit 6d71a9c61604 ("sched/fair: Fix EEVDF entity
placement bug causing scheduling lag") relies on commit 4423af84b297
("sched/fair: optimize the PLACE_LAG when se->vlag is zero") to not
trip a WARN in place_entity().
What happens is that the lag of the very last entity is 0 per
definition -- the average of one element matches the value of that
element. Therefore place_entity() will match the condition skipping
the lag adjustment:
if (sched_feat(PLACE_LAG) && cfs_rq->nr_queued && se->vlag) {
Without the 'se->vlag' condition -- it will attempt to adjust the zero
lag even though we're inserting into an empty tree.
Notably, we should have failed the 'cfs_rq->nr_queued' condition, but
don't because they didn't get updated.
Additionally, move update_load_add() after placement() as is
consistent with other place_entity() users -- this change is
non-functional, place_entity() does not use cfs_rq->load.
Fixes: 6d71a9c61604 ("sched/fair: Fix EEVDF entity placement bug causing scheduling lag")
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Reported-by: Mike Galbraith <efault(a)gmx.de>
Signed-off-by: "Peter Zijlstra (Intel)" <peterz(a)infradead.org>
Signed-off-by: Mike Galbraith <efault(a)gmx.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Cc: stable(a)vger.kernel.org
Link: https://lore.kernel.org/r/c216eb4ef0e0e0029c600aefc69d56681cee5581.camel@gm…
---
kernel/sched/fair.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 5e1bd9e..eb5a257 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3795,6 +3795,7 @@ static void reweight_entity(struct cfs_rq *cfs_rq, struct sched_entity *se,
update_entity_lag(cfs_rq, se);
se->deadline -= se->vruntime;
se->rel_deadline = 1;
+ cfs_rq->nr_queued--;
if (!curr)
__dequeue_entity(cfs_rq, se);
update_load_sub(&cfs_rq->load, se->load.weight);
@@ -3821,10 +3822,11 @@ static void reweight_entity(struct cfs_rq *cfs_rq, struct sched_entity *se,
enqueue_load_avg(cfs_rq, se);
if (se->on_rq) {
- update_load_add(&cfs_rq->load, se->load.weight);
place_entity(cfs_rq, se, 0);
+ update_load_add(&cfs_rq->load, se->load.weight);
if (!curr)
__enqueue_entity(cfs_rq, se);
+ cfs_rq->nr_queued++;
/*
* The entity's vruntime has been adjusted, so let's check
On Mon, 2025-04-14 at 06:43 -0400, Sasha Levin wrote:
> This is a note to let you know that I've just added the patch titled
>
> s390/pci: Support mmap() of PCI resources except for ISM devices
>
> to the 6.14-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
>
> The filename of the patch is:
> s390-pci-support-mmap-of-pci-resources-except-for-is.patch
> and it can be found in the queue-6.14 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable(a)vger.kernel.org> know about it.
>
Hi Sasha,
Including this in stable is fine but if you do please also pick up
commit 41a0926e82f4 ("s390/pci: Fix s390_mmio_read/write syscall page
fault handling") otherwise the mmap() with vfio-pci won't work on
systems that rely on the MMIO syscalls but would already work on those
that have the newer memory I/O feature. Meaning once you have the
mmap() PCI resource suppot the cited commit becomes a relevant fix.
Thanks,
Niklas
From: Guixin Liu <kanie(a)linux.alibaba.com>
[ Upstream commit 1e95c798d8a7f70965f0f88d4657b682ff0ec75f ]
Currently, this does not cause any issues, but I believe it is necessary to
set bsg_queue to NULL after removing it to prevent potential use-after-free
(UAF) access.
Signed-off-by: Guixin Liu <kanie(a)linux.alibaba.com>
Link: https://lore.kernel.org/r/20241218014214.64533-3-kanie@linux.alibaba.com
Reviewed-by: Avri Altman <avri.altman(a)wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Xiangyu Chen <xiangyu.chen(a)windriver.com>
Signed-off-by: He Zhe <zhe.he(a)windriver.com>
---
Verified the build test.
---
drivers/scsi/ufs/ufs_bsg.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/ufs/ufs_bsg.c b/drivers/scsi/ufs/ufs_bsg.c
index 16e8ddcf22fe..b8bbfd81b8ae 100644
--- a/drivers/scsi/ufs/ufs_bsg.c
+++ b/drivers/scsi/ufs/ufs_bsg.c
@@ -175,6 +175,7 @@ void ufs_bsg_remove(struct ufs_hba *hba)
return;
bsg_remove_queue(hba->bsg_queue);
+ hba->bsg_queue = NULL;
device_del(bsg_dev);
put_device(bsg_dev);
--
2.34.1