* Re: [PATCH v2 1/4] virtio-mem: validate device-reported block size
From: Greg Kroah-Hartman @ 2026-07-17 5:03 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Hari Mishal, Michael S . Tsirkin, Jason Wang, Xuan Zhuo,
Eugenio Pérez, virtualization, linux-kernel
In-Reply-To: <4dda47ba-534a-4297-a25e-0d63d9167033@kernel.org>
On Thu, Jul 16, 2026 at 05:59:05PM +0200, David Hildenbrand (Arm) wrote:
> On 7/16/26 16:18, Greg Kroah-Hartman wrote:
> > On Thu, Jul 16, 2026 at 10:55:42AM +0200, David Hildenbrand (Arm) wrote:
> >> On 7/15/26 18:41, Hari Mishal wrote:
> >>> The device_block_size read from the virtio-mem config space is used as a
> >>> divisor and also in ALIGN_DOWN() further down the code path in the
> >>> driver without further validation. A zero value leads to a division by
> >>> zero, and a non-power-of-two value corrupts the ALIGN_DOWN() bitmask
> >>> arithmetic leading to a misreporting of guest-usable ram, post crash.
> >>>
> >>> Reject both at init time instead of trusting the device.
> >>>
> >>> Signed-off-by: Hari Mishal <harimishal1@gmail.com>
> >>> ---
> >>> v2: dropped the redundant explicit zero check, since
> >>> is_power_of_2(0) already returns false.
> >>>
> >>> drivers/virtio/virtio_mem.c | 6 ++++++
> >>> 1 file changed, 6 insertions(+)
> >>>
> >>> diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
> >>> index 11c441501582..0e04fec458af 100644
> >>> --- a/drivers/virtio/virtio_mem.c
> >>> +++ b/drivers/virtio/virtio_mem.c
> >>> @@ -2847,6 +2847,12 @@ static int virtio_mem_init(struct virtio_mem *vm)
> >>> &vm->plugged_size);
> >>> virtio_cread_le(vm->vdev, struct virtio_mem_config, block_size,
> >>> &vm->device_block_size);
> >>> + if (!is_power_of_2(vm->device_block_size)) {
> >>> + dev_err(&vm->vdev->dev,
> >>> + "invalid device block size: 0x%llx\n",
> >>> + (unsigned long long)vm->device_block_size);
> >>> + return -EINVAL;
> >>> + }
> >>
> >> The spec states "The device MUST set block_size to a power of two."
> >>
> >> I'm missing the point here.
> >
> > So what happens if we have a non-spec-compliant device? Shouldn't we be
> > attempting to verify this before doing something with the data?
>
> The problem I see is that there are plenty of other devices where a
> non-compliant device might cause problems.
>
> Like, we request to hotplug some memory block and our device ACKs it, but it
> simply didn't do that.
>
> Or we request to hotunplug a memory block and instead it hotplugs some random
> other memory block.
>
> Or we sense whether a memory block is plugged and the device lies to us.
>
> >
> > Or do we just always trust virtio mem devices explicitly?
>
> It's hard for me to understand where we draw the line, really.
>
> But maybe MST can clarify what we care about in virtio world where the
> hypervisor is fully in charge of the device,
That would be good to figure out, and write down somewhere, so we know
what to worry about here.
Right now, for almost all subsystems, Linux trusts the hardware
explicitly. But for some subsystems, it doesn't, or doesn't until
"something" happens (example, USB devices are untrusted until we bind a
driver to the device, and then they are trusted.)
But there are some people that want to never trust the hardware, or have
it in different states, specifically for virtual machines like this
driver operates in. The CoC model is just that, and patches from Dan
are working toward clearing this up a lot for some types of devices (PCI
and IOMMU), but I don't think they have thought about virtio devices
yet...
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 1/4] virtio-mem: validate device-reported block size
From: Michael S. Tsirkin @ 2026-07-17 5:48 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Greg Kroah-Hartman, Hari Mishal, Jason Wang, Xuan Zhuo,
Eugenio Pérez, virtualization, linux-kernel, elena.reshetova,
carlos.bilbao.osdev
In-Reply-To: <4dda47ba-534a-4297-a25e-0d63d9167033@kernel.org>
On Thu, Jul 16, 2026 at 05:59:05PM +0200, David Hildenbrand (Arm) wrote:
> > Or do we just always trust virtio mem devices explicitly?
>
> It's hard for me to understand where we draw the line, really.
>
> But maybe MST can clarify what we care about in virtio world where the
> hypervisor is fully in charge of the device,
Generally:
- The guest is expected to whitelist drivers (most drivers have not
been audited).
- Denial of service by the hypervisor is not considered a threat
(this is how cloud vendors charge their clients, by denying
service to whoever did not pay).
--
MST
^ permalink raw reply
* Re: [PATCH v2 1/4] virtio-mem: validate device-reported block size
From: David Hildenbrand (Arm) @ 2026-07-17 8:39 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Greg Kroah-Hartman, Hari Mishal, Jason Wang, Xuan Zhuo,
Eugenio Pérez, virtualization, linux-kernel, elena.reshetova,
carlos.bilbao.osdev
In-Reply-To: <20260717014134-mutt-send-email-mst@kernel.org>
On 7/17/26 07:48, Michael S. Tsirkin wrote:
> On Thu, Jul 16, 2026 at 05:59:05PM +0200, David Hildenbrand (Arm) wrote:
>>> Or do we just always trust virtio mem devices explicitly?
>>
>> It's hard for me to understand where we draw the line, really.
>>
>> But maybe MST can clarify what we care about in virtio world where the
>> hypervisor is fully in charge of the device,
>
> Generally:
> - The guest is expected to whitelist drivers (most drivers have not
> been audited).
But even if you audited your driver, who makes sure that we consider all ways
where the device could mess with us?
Something feels off here.
Handling selected out-of-spec scenarios like this feels like a band-aid. Happy
to be corrected.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v2 1/4] virtio-mem: validate device-reported block size
From: Michael S. Tsirkin @ 2026-07-17 8:59 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Greg Kroah-Hartman, Hari Mishal, Jason Wang, Xuan Zhuo,
Eugenio Pérez, virtualization, linux-kernel, elena.reshetova,
carlos.bilbao.osdev
In-Reply-To: <3b32a38f-0964-45b9-9529-933abedbf69b@kernel.org>
On Fri, Jul 17, 2026 at 10:39:40AM +0200, David Hildenbrand (Arm) wrote:
> On 7/17/26 07:48, Michael S. Tsirkin wrote:
> > On Thu, Jul 16, 2026 at 05:59:05PM +0200, David Hildenbrand (Arm) wrote:
> >>> Or do we just always trust virtio mem devices explicitly?
> >>
> >> It's hard for me to understand where we draw the line, really.
> >>
> >> But maybe MST can clarify what we care about in virtio world where the
> >> hypervisor is fully in charge of the device,
> >
> > Generally:
> > - The guest is expected to whitelist drivers (most drivers have not
> > been audited).
>
> But even if you audited your driver, who makes sure that we consider all ways
> where the device could mess with us?
A lot of this is up to a correct setup. For example, make sure all
filesystems are encrypted and refuse to mount unencrypted ones.
> Something feels off here.
>
> Handling selected out-of-spec scenarios like this feels like a band-aid. Happy
> to be corrected.
Well Documentation/security/snp-tdx-threat-model.rst puts it like this:
It is important to note
that this doesn’t imply that the host or VMM are intentionally
malicious, but that there exists a security value in having a small CoCo
VM TCB.
and
While traditionally the host has unlimited access to guest data and can
leverage this access to attack the guest, the CoCo systems mitigate such
attacks by adding security features like guest data confidentiality and
integrity protection.
now, when we are talking about "mitigation" it is indeed becoming a bit
murky.
For me, a rule of thumb I came up with is that if the validation happens
to also be helful for users e.g. to work around buggy devices,
or maybe because we feel failing gracefully is nice because this
will allow to later make use of this config and old drivers will
fail but at least not panic, then it is good to include.
> --
> Cheers,
>
> David
^ permalink raw reply
* Re: [PATCH v2 1/2] mm/page_reporting: use system_freezable_wq to fix UAF during suspend
From: David Hildenbrand (Arm) @ 2026-07-17 9:09 UTC (permalink / raw)
To: Link Lin, Andrew Morton, Vlastimil Babka, Michael S . Tsirkin
Cc: virtualization, linux-mm, linux-kernel, prasin, rientjes, duenwen,
jasowang, xuanzhuo, Ammar Faizi, jiaqiyan, ahwilkins, Greg Thelen,
Alexander Duyck, jthoughton, stable
In-Reply-To: <20260717002311.681748-2-linkl@google.com>
On 7/17/26 02:22, Link Lin wrote:
> During PM freeze (e.g. S3 suspend or S4 hibernation), device drivers like
> virtio_balloon reset their underlying virtio devices and delete their
> virtqueues via vdev->config->del_vqs().
>
> However, page reporting work (page_reporting_process) was scheduled on
> the global system_wq. Because system_wq lacks the WQ_FREEZABLE flag, the
> PM freezer skips it, leaving page_reporting_process active during
> suspend. If pages are freed into the buddy allocator while suspending,
> page reporting invokes virtballoon_free_page_report() on deleted
> virtqueues:
>
> [ 196.795226] general protection fault, probably for non-canonical address 0xaa1436fe70dae6df: 0000 [#1] SMP NOPTI
> [ 196.825967] Workqueue: events page_reporting_process
> [ 196.831038] RIP: 0010:virtqueue_add_split+0x233/0x4c0 [virtio_ring]
> [ 196.927073] virtballoon_free_page_report+0x3a/0xe0 [virtio_balloon]
> [ 196.946943] page_reporting_process+0x370/0x4f0
>
> Fix this by switching page reporting work to system_freezable_wq. This
> ensures that the PM freezer pauses page_reporting_process before device
> drivers destroy their reporting virtqueues.
>
> This aligns with the driver's existing design. The comment in
> virtballoon_freeze() states:
> /*
> * The workqueue is already frozen by the PM core before this
> * function is called.
> */
>
> Suggested-by: David Hildenbrand <david@redhat.com>
> Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> Acked-by: David Rientjes <rientjes@google.com>
> Fixes: 924a663f75e2 ("virtio-balloon: Reporting free page reservations")
> Cc: stable@vger.kernel.org
> Signed-off-by: Link Lin <linkl@google.com>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v2 1/4] virtio-mem: validate device-reported block size
From: Greg Kroah-Hartman @ 2026-07-17 9:14 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: David Hildenbrand (Arm), Hari Mishal, Jason Wang, Xuan Zhuo,
Eugenio Pérez, virtualization, linux-kernel, elena.reshetova,
carlos.bilbao.osdev
In-Reply-To: <20260717044019-mutt-send-email-mst@kernel.org>
On Fri, Jul 17, 2026 at 04:59:32AM -0400, Michael S. Tsirkin wrote:
> On Fri, Jul 17, 2026 at 10:39:40AM +0200, David Hildenbrand (Arm) wrote:
> > On 7/17/26 07:48, Michael S. Tsirkin wrote:
> > > On Thu, Jul 16, 2026 at 05:59:05PM +0200, David Hildenbrand (Arm) wrote:
> > >>> Or do we just always trust virtio mem devices explicitly?
> > >>
> > >> It's hard for me to understand where we draw the line, really.
> > >>
> > >> But maybe MST can clarify what we care about in virtio world where the
> > >> hypervisor is fully in charge of the device,
> > >
> > > Generally:
> > > - The guest is expected to whitelist drivers (most drivers have not
> > > been audited).
> >
> > But even if you audited your driver, who makes sure that we consider all ways
> > where the device could mess with us?
>
> A lot of this is up to a correct setup. For example, make sure all
> filesystems are encrypted and refuse to mount unencrypted ones.
>
> > Something feels off here.
> >
> > Handling selected out-of-spec scenarios like this feels like a band-aid. Happy
> > to be corrected.
>
> Well Documentation/security/snp-tdx-threat-model.rst puts it like this:
> It is important to note
> that this doesn’t imply that the host or VMM are intentionally
> malicious, but that there exists a security value in having a small CoCo
> VM TCB.
>
> and
>
> While traditionally the host has unlimited access to guest data and can
> leverage this access to attack the guest, the CoCo systems mitigate such
> attacks by adding security features like guest data confidentiality and
> integrity protection.
>
>
> now, when we are talking about "mitigation" it is indeed becoming a bit
> murky.
>
>
> For me, a rule of thumb I came up with is that if the validation happens
> to also be helful for users e.g. to work around buggy devices,
> or maybe because we feel failing gracefully is nice because this
> will allow to later make use of this config and old drivers will
> fail but at least not panic, then it is good to include.
Why not do what USB does? Don't trust the device until AFTER probe()
succeeds? All of the needed checking should happen before then, as that
is a "slow path" so lots of validation and the like can happen at that
point.
After that, during the normal data paths, after the driver is bound,
trust it all you want as attempting to validate every single packet is
just going to be impossible.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 2/2] virtio_balloon: avoid shrinker execution during PM suspend
From: Michael S. Tsirkin @ 2026-07-17 9:17 UTC (permalink / raw)
To: Link Lin
Cc: Andrew Morton, Vlastimil Babka, David Hildenbrand, virtualization,
linux-mm, linux-kernel, prasin, rientjes, duenwen, jasowang,
xuanzhuo, Ammar Faizi, jiaqiyan, ahwilkins, Greg Thelen,
Alexander Duyck, jthoughton, stable
In-Reply-To: <20260717002311.681748-3-linkl@google.com>
On Fri, Jul 17, 2026 at 12:22:21AM +0000, Link Lin wrote:
> During PM freeze (e.g. S4 hibernation), virtballoon_freeze() calls
> remove_common() which resets the virtio device and deletes all virtqueues.
> However, the balloon shrinker remains registered with core MM.
>
> If memory pressure occurs during S4 hibernation image creation/saving, MM
> invokes virtio_balloon_shrinker_scan(), which attempts to reclaim free
> pages. Although return_free_pages_to_mm() only frees pages back to MM,
> reclaiming free pages under memory pressure can trigger page reporting
> which might access the deleted reporting virtqueue if it is not yet
> frozen, or interact with other parts of the driver in a teardown state.
i feel this is the thing to fix then? not the freeing itself.
>
> Avoid this by adding a `suspended` flag to `struct virtio_balloon`. Set
> this flag to true in virtballoon_freeze() and false in
> virtballoon_restore(). Check this flag in both shrinker callbacks (scan
> and count) and return 0 if the device is suspended, preventing any
> shrinker execution while virtqueues are deleted. Wrap the lockless reads
> in READ_ONCE() and writes in WRITE_ONCE() to prevent compiler
> optimization issues and KCSAN data race warnings.
so you prevented the warnings but did you fix the races? CB
>
> Fixes: 71019de8219b ("virtio_balloon: Add free page hinting support")
> Cc: stable@vger.kernel.org
> Acked-by: David Rientjes <rientjes@google.com>
> Signed-off-by: Link Lin <linkl@google.com>
> ---
> drivers/virtio/virtio_balloon.c | 49 +++++++++++++++++++++++++++------
> 1 file changed, 41 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 088b3a0e6c..38e1166a64 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -68,6 +68,8 @@ struct virtio_balloon {
> /* Prevent updating balloon when it is being canceled. */
> spinlock_t stop_update_lock;
> bool stop_update;
> + /* Prevent shrinker from running while device is suspended. */
> + bool suspended;
> /* Bitmap to indicate if reading the related config fields are needed */
> unsigned long config_read_bitmap;
>
> @@ -471,9 +473,9 @@ static inline s64 towards_target(struct virtio_balloon *vb)
> return target - vb->num_pages;
> }
>
> -/* Gives back @num_to_return blocks of free pages to mm. */
> -static unsigned long return_free_pages_to_mm(struct virtio_balloon *vb,
> - unsigned long num_to_return)
> +/* Helper: must be called with free_page_list_lock held */
> +static unsigned long __return_free_pages_to_mm(struct virtio_balloon *vb,
> + unsigned long num_to_return)
> {
> unsigned long num_returned = 0;
> struct page *page, *next;
> @@ -481,8 +483,6 @@ static unsigned long return_free_pages_to_mm(struct virtio_balloon *vb,
> if (unlikely(!num_to_return))
> return 0;
>
> - spin_lock_irq(&vb->free_page_list_lock);
> -
> list_for_each_entry_safe(page, next, &vb->free_page_list, lru) {
> list_del(&page->lru);
> __free_pages(page, VIRTIO_BALLOON_HINT_BLOCK_ORDER);
> @@ -490,11 +490,27 @@ static unsigned long return_free_pages_to_mm(struct virtio_balloon *vb,
> break;
> }
> vb->num_free_page_blocks -= num_returned;
> - spin_unlock_irq(&vb->free_page_list_lock);
>
> return num_returned;
> }
>
> +/* Gives back @num_to_return blocks of free pages to mm. */
> +static unsigned long return_free_pages_to_mm(struct virtio_balloon *vb,
> + unsigned long num_to_return)
> +{
> + unsigned long ret;
> +
> + spin_lock_irq(&vb->free_page_list_lock);
> + if (vb->suspended) {
> + spin_unlock_irq(&vb->free_page_list_lock);
> + return 0;
> + }
> + ret = __return_free_pages_to_mm(vb, num_to_return);
> + spin_unlock_irq(&vb->free_page_list_lock);
> +
> + return ret;
> +}
> +
> static void virtio_balloon_queue_free_page_work(struct virtio_balloon *vb)
> {
> if (!virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT))
> @@ -871,6 +887,9 @@ static unsigned long virtio_balloon_shrinker_scan(struct shrinker *shrinker,
> {
> struct virtio_balloon *vb = shrinker->private_data;
>
> + if (READ_ONCE(vb->suspended))
> + return 0;
> +
what if vb->suspended is set right here?
> return shrink_free_pages(vb, sc->nr_to_scan);
> }
>
> @@ -879,6 +898,9 @@ static unsigned long virtio_balloon_shrinker_count(struct shrinker *shrinker,
> {
> struct virtio_balloon *vb = shrinker->private_data;
>
> + if (READ_ONCE(vb->suspended))
> + return 0;
> +
or here?
> return vb->num_free_page_blocks * VIRTIO_BALLOON_HINT_BLOCK_PAGES;
> }
>
> @@ -1089,8 +1111,11 @@ static void remove_common(struct virtio_balloon *vb)
> update_balloon_size(vb);
>
> /* There might be free pages that are being reported: release them. */
> - if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT))
> - return_free_pages_to_mm(vb, ULONG_MAX);
> + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
> + spin_lock_irq(&vb->free_page_list_lock);
> + __return_free_pages_to_mm(vb, ULONG_MAX);
> + spin_unlock_irq(&vb->free_page_list_lock);
this is remove, taking locks seems futile - if something will acquire
the lock here, we will be in trouble.
> + }
>
> /* Now we reset the device so we can clean up the queues. */
> virtio_reset_device(vb->vdev);
> @@ -1133,6 +1158,10 @@ static int virtballoon_freeze(struct virtio_device *vdev)
> * The workqueue is already frozen by the PM core before this
> * function is called.
> */
> + spin_lock_irq(&vb->free_page_list_lock);
> + WRITE_ONCE(vb->suspended, true);
> + spin_unlock_irq(&vb->free_page_list_lock);
> +
> remove_common(vb);
> return 0;
> }
> @@ -1148,6 +1177,10 @@ static int virtballoon_restore(struct virtio_device *vdev)
>
> virtio_device_ready(vdev);
>
> + spin_lock_irq(&vb->free_page_list_lock);
> + WRITE_ONCE(vb->suspended, false);
> + spin_unlock_irq(&vb->free_page_list_lock);
> +
> if (towards_target(vb))
> virtballoon_changed(vdev);
> update_balloon_size(vb);
> --
> 2.55.0.229.g6434b31f56-goog
^ permalink raw reply
* Re: [PATCH v2 1/2] mm/page_reporting: use system_freezable_wq to fix UAF during suspend
From: Michael S. Tsirkin @ 2026-07-17 9:17 UTC (permalink / raw)
To: Link Lin
Cc: Andrew Morton, Vlastimil Babka, David Hildenbrand, virtualization,
linux-mm, linux-kernel, prasin, rientjes, duenwen, jasowang,
xuanzhuo, Ammar Faizi, jiaqiyan, ahwilkins, Greg Thelen,
Alexander Duyck, jthoughton, stable, David Hildenbrand
In-Reply-To: <20260717002311.681748-2-linkl@google.com>
On Fri, Jul 17, 2026 at 12:22:20AM +0000, Link Lin wrote:
> During PM freeze (e.g. S3 suspend or S4 hibernation), device drivers like
> virtio_balloon reset their underlying virtio devices and delete their
> virtqueues via vdev->config->del_vqs().
>
> However, page reporting work (page_reporting_process) was scheduled on
> the global system_wq. Because system_wq lacks the WQ_FREEZABLE flag, the
> PM freezer skips it, leaving page_reporting_process active during
> suspend. If pages are freed into the buddy allocator while suspending,
> page reporting invokes virtballoon_free_page_report() on deleted
> virtqueues:
>
> [ 196.795226] general protection fault, probably for non-canonical address 0xaa1436fe70dae6df: 0000 [#1] SMP NOPTI
> [ 196.825967] Workqueue: events page_reporting_process
> [ 196.831038] RIP: 0010:virtqueue_add_split+0x233/0x4c0 [virtio_ring]
> [ 196.927073] virtballoon_free_page_report+0x3a/0xe0 [virtio_balloon]
> [ 196.946943] page_reporting_process+0x370/0x4f0
>
> Fix this by switching page reporting work to system_freezable_wq. This
> ensures that the PM freezer pauses page_reporting_process before device
> drivers destroy their reporting virtqueues.
>
> This aligns with the driver's existing design. The comment in
> virtballoon_freeze() states:
> /*
> * The workqueue is already frozen by the PM core before this
> * function is called.
> */
>
> Suggested-by: David Hildenbrand <david@redhat.com>
> Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> Acked-by: David Rientjes <rientjes@google.com>
> Fixes: 924a663f75e2 ("virtio-balloon: Reporting free page reservations")
> Cc: stable@vger.kernel.org
> Signed-off-by: Link Lin <linkl@google.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> mm/page_reporting.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/mm/page_reporting.c b/mm/page_reporting.c
> index 7418f2e500..4dc6f4b852 100644
> --- a/mm/page_reporting.c
> +++ b/mm/page_reporting.c
> @@ -80,7 +80,8 @@ __page_reporting_request(struct page_reporting_dev_info *prdev)
> * now we are limiting this to running no more than once every
> * couple of seconds.
> */
> - schedule_delayed_work(&prdev->work, PAGE_REPORTING_DELAY);
> + queue_delayed_work(system_freezable_wq, &prdev->work,
> + PAGE_REPORTING_DELAY);
> }
>
> /* notify prdev of free page reporting request */
> @@ -343,7 +344,8 @@ static void page_reporting_process(struct work_struct *work)
> */
> state = atomic_cmpxchg(&prdev->state, state, PAGE_REPORTING_IDLE);
> if (state == PAGE_REPORTING_REQUESTED)
> - schedule_delayed_work(&prdev->work, PAGE_REPORTING_DELAY);
> + queue_delayed_work(system_freezable_wq, &prdev->work,
> + PAGE_REPORTING_DELAY);
> }
>
> static DEFINE_MUTEX(page_reporting_mutex);
> --
> 2.55.0.229.g6434b31f56-goog
^ permalink raw reply
* Re: [PATCH v2 2/2] virtio_balloon: avoid shrinker execution during PM suspend
From: David Hildenbrand (Arm) @ 2026-07-17 9:30 UTC (permalink / raw)
To: Link Lin, Andrew Morton, Vlastimil Babka, Michael S . Tsirkin
Cc: virtualization, linux-mm, linux-kernel, prasin, rientjes, duenwen,
jasowang, xuanzhuo, Ammar Faizi, jiaqiyan, ahwilkins, Greg Thelen,
Alexander Duyck, jthoughton, stable
In-Reply-To: <20260717002311.681748-3-linkl@google.com>
On 7/17/26 02:22, Link Lin wrote:
> During PM freeze (e.g. S4 hibernation), virtballoon_freeze() calls
> remove_common() which resets the virtio device and deletes all virtqueues.
> However, the balloon shrinker remains registered with core MM.
>
> If memory pressure occurs during S4 hibernation image creation/saving, MM
> invokes virtio_balloon_shrinker_scan(), which attempts to reclaim free
> pages. Although return_free_pages_to_mm() only frees pages back to MM,
> reclaiming free pages under memory pressure can trigger page reporting
> which might access the deleted reporting virtqueue if it is not yet
> frozen, or interact with other parts of the driver in a teardown state.
Yes, this does seem possible.
> +
> static void virtio_balloon_queue_free_page_work(struct virtio_balloon *vb)
> {
> if (!virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT))
> @@ -871,6 +887,9 @@ static unsigned long virtio_balloon_shrinker_scan(struct shrinker *shrinker,
> {
> struct virtio_balloon *vb = shrinker->private_data;
>
> + if (READ_ONCE(vb->suspended))
> + return 0;
> +
> return shrink_free_pages(vb, sc->nr_to_scan);
> }
>
> @@ -879,6 +898,9 @@ static unsigned long virtio_balloon_shrinker_count(struct shrinker *shrinker,
> {
> struct virtio_balloon *vb = shrinker->private_data;
>
> + if (READ_ONCE(vb->suspended))
> + return 0;
> +
> return vb->num_free_page_blocks * VIRTIO_BALLOON_HINT_BLOCK_PAGES;
> }
>
> @@ -1089,8 +1111,11 @@ static void remove_common(struct virtio_balloon *vb)
> update_balloon_size(vb);
>
> /* There might be free pages that are being reported: release them. */
> - if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT))
> - return_free_pages_to_mm(vb, ULONG_MAX);
> + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
> + spin_lock_irq(&vb->free_page_list_lock);
> + __return_free_pages_to_mm(vb, ULONG_MAX);
> + spin_unlock_irq(&vb->free_page_list_lock);
> + }
Why not set the boolean immediately after this, and call it "shrinker_disabled"
instead of "suspended"?
Then you can keep calling "return_free_pages_to_mm(vb, ULONG_MAX);" here.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH 00/32] x86/msr: Drop 32-bit MSR interfaces
From: Ingo Molnar @ 2026-07-17 9:38 UTC (permalink / raw)
To: Juergen Gross
Cc: Sean Christopherson, Arnd Bergmann, linux-kernel, linux-pm,
linux-edac@vger.kernel.org, x86, linux-acpi, kvm, linux-coco,
linux-pci, virtualization, linux-ide, dri-devel, linux-fbdev,
linux-crypto, open list:GPIO SUBSYSTEM, linux-hyperv, linux-hwmon,
linux-perf-users, linux-mtd, platform-driver-x86,
Rafael J . Wysocki, Daniel Lezcano, Zhang Rui,
lukasz.luba@arm.com, Jason Baron, Borislav Petkov, Tony Luck,
Yazen Ghannam, Len Brown, Pavel Machek, Thomas Gleixner,
Ingo Molnar, Dave Hansen, H. Peter Anvin, Paolo Bonzini,
Kirill A. Shutemov, Rick Edgecombe, Pu Wen, Bjorn Helgaas,
Ajay Kaher, Alexey Makhalov, Broadcom internal kernel review list,
Viresh Kumar, Reinette Chatre, Dave Martin, James Morse,
Babu Moger, Tony W Wang-oc, Damien Le Moal, Niklas Cassel,
Dave Airlie, Helge Deller, linux-geode, Olivia Mackall,
Herbert Xu, Linus Walleij, Bartosz Golaszewski,
Greg Kroah-Hartman, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Guenter Roeck, Peter Zijlstra,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Josh Poimboeuf, Pawan Gupta, Vitaly Kuznetsov,
Andy Lutomirski, Boris Ostrovsky, Huang Rui, Mario Limonciello,
Perry Yuan, K Prateek Nayak, srinivas.pandruvada@linux.intel.com,
Artem Bityutskiy, Artem Bityutskiy, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, Ashok Raj, Hans de Goede,
Ilpo Järvinen, Rajneesh Bhardwaj, David E Box, xen-devel
In-Reply-To: <99228803-b8b7-47a3-b77c-6fdf3b785730@suse.com>
* Juergen Gross <jgross@suse.com> wrote:
> On 02.07.26 12:07, Ingo Molnar wrote:
> >
> > * Sean Christopherson <seanjc@google.com> wrote:
> >
> > > > Note that the individual patches are IMO significantly easier to review
> > > > through the actual 32-bit => 64-bit variable assignment changes done
> > > > in isolation (which sometimes include minor cleanups), while
> > > > the Coccinelle semantic patch:
> > > >
> > > > { a(b,c) => c = a(b) }
> > > >
> > > > which changes both the function signature and the order of terms as
> > > > well, is just a single add-on treewide patch.
> > >
> > > Is the plan for subsystem maintainers to pick up the relevant patches,
> > > and then do the treewide change one release cycle later?
> >
> > I'll try to keep the patches in a single tree (tip:x86/msr)
> > in the hope of not prolonging the pain two cycles - but it's
> > of course fine for maintainers to pick up the patches too
> > (most of them are standalone), we'll sort it all out in the end.
>
> Ingo, would you be fine with me posting patch updates just as replies to the
> original patch emails? This would speed things up, as I wouldn't need to wait
> for more review input of all the patches before sending out new versions.
Sure, that works for me too. I've picked up a couple of -v2 patches
already.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH v2 1/4] virtio-mem: validate device-reported block size
From: Michael S. Tsirkin @ 2026-07-17 10:10 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: David Hildenbrand (Arm), Hari Mishal, Jason Wang, Xuan Zhuo,
Eugenio Pérez, virtualization, linux-kernel, elena.reshetova,
carlos.bilbao.osdev
In-Reply-To: <2026071746-deviation-clad-1712@gregkh>
On Fri, Jul 17, 2026 at 11:14:23AM +0200, Greg Kroah-Hartman wrote:
> On Fri, Jul 17, 2026 at 04:59:32AM -0400, Michael S. Tsirkin wrote:
> > On Fri, Jul 17, 2026 at 10:39:40AM +0200, David Hildenbrand (Arm) wrote:
> > > On 7/17/26 07:48, Michael S. Tsirkin wrote:
> > > > On Thu, Jul 16, 2026 at 05:59:05PM +0200, David Hildenbrand (Arm) wrote:
> > > >>> Or do we just always trust virtio mem devices explicitly?
> > > >>
> > > >> It's hard for me to understand where we draw the line, really.
> > > >>
> > > >> But maybe MST can clarify what we care about in virtio world where the
> > > >> hypervisor is fully in charge of the device,
> > > >
> > > > Generally:
> > > > - The guest is expected to whitelist drivers (most drivers have not
> > > > been audited).
> > >
> > > But even if you audited your driver, who makes sure that we consider all ways
> > > where the device could mess with us?
> >
> > A lot of this is up to a correct setup. For example, make sure all
> > filesystems are encrypted and refuse to mount unencrypted ones.
> >
> > > Something feels off here.
> > >
> > > Handling selected out-of-spec scenarios like this feels like a band-aid. Happy
> > > to be corrected.
> >
> > Well Documentation/security/snp-tdx-threat-model.rst puts it like this:
> > It is important to note
> > that this doesn’t imply that the host or VMM are intentionally
> > malicious, but that there exists a security value in having a small CoCo
> > VM TCB.
> >
> > and
> >
> > While traditionally the host has unlimited access to guest data and can
> > leverage this access to attack the guest, the CoCo systems mitigate such
> > attacks by adding security features like guest data confidentiality and
> > integrity protection.
> >
> >
> > now, when we are talking about "mitigation" it is indeed becoming a bit
> > murky.
> >
> >
> > For me, a rule of thumb I came up with is that if the validation happens
> > to also be helful for users e.g. to work around buggy devices,
> > or maybe because we feel failing gracefully is nice because this
> > will allow to later make use of this config and old drivers will
> > fail but at least not panic, then it is good to include.
>
> Why not do what USB does? Don't trust the device until AFTER probe()
> succeeds? All of the needed checking should happen before then, as that
> is a "slow path" so lots of validation and the like can happen at that
> point.
>
> After that, during the normal data paths, after the driver is bound,
> trust it all you want as attempting to validate every single packet is
> just going to be impossible.
>
> thanks,
>
> greg k-h
People do expect that data path validation at this point.
--
MST
^ permalink raw reply
* Re: [PATCH v2 1/4] virtio-mem: validate device-reported block size
From: Greg Kroah-Hartman @ 2026-07-17 10:15 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: David Hildenbrand (Arm), Hari Mishal, Jason Wang, Xuan Zhuo,
Eugenio Pérez, virtualization, linux-kernel, elena.reshetova,
carlos.bilbao.osdev
In-Reply-To: <20260717060822-mutt-send-email-mst@kernel.org>
On Fri, Jul 17, 2026 at 06:10:41AM -0400, Michael S. Tsirkin wrote:
> On Fri, Jul 17, 2026 at 11:14:23AM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Jul 17, 2026 at 04:59:32AM -0400, Michael S. Tsirkin wrote:
> > > On Fri, Jul 17, 2026 at 10:39:40AM +0200, David Hildenbrand (Arm) wrote:
> > > > On 7/17/26 07:48, Michael S. Tsirkin wrote:
> > > > > On Thu, Jul 16, 2026 at 05:59:05PM +0200, David Hildenbrand (Arm) wrote:
> > > > >>> Or do we just always trust virtio mem devices explicitly?
> > > > >>
> > > > >> It's hard for me to understand where we draw the line, really.
> > > > >>
> > > > >> But maybe MST can clarify what we care about in virtio world where the
> > > > >> hypervisor is fully in charge of the device,
> > > > >
> > > > > Generally:
> > > > > - The guest is expected to whitelist drivers (most drivers have not
> > > > > been audited).
> > > >
> > > > But even if you audited your driver, who makes sure that we consider all ways
> > > > where the device could mess with us?
> > >
> > > A lot of this is up to a correct setup. For example, make sure all
> > > filesystems are encrypted and refuse to mount unencrypted ones.
> > >
> > > > Something feels off here.
> > > >
> > > > Handling selected out-of-spec scenarios like this feels like a band-aid. Happy
> > > > to be corrected.
> > >
> > > Well Documentation/security/snp-tdx-threat-model.rst puts it like this:
> > > It is important to note
> > > that this doesn’t imply that the host or VMM are intentionally
> > > malicious, but that there exists a security value in having a small CoCo
> > > VM TCB.
> > >
> > > and
> > >
> > > While traditionally the host has unlimited access to guest data and can
> > > leverage this access to attack the guest, the CoCo systems mitigate such
> > > attacks by adding security features like guest data confidentiality and
> > > integrity protection.
> > >
> > >
> > > now, when we are talking about "mitigation" it is indeed becoming a bit
> > > murky.
> > >
> > >
> > > For me, a rule of thumb I came up with is that if the validation happens
> > > to also be helful for users e.g. to work around buggy devices,
> > > or maybe because we feel failing gracefully is nice because this
> > > will allow to later make use of this config and old drivers will
> > > fail but at least not panic, then it is good to include.
> >
> > Why not do what USB does? Don't trust the device until AFTER probe()
> > succeeds? All of the needed checking should happen before then, as that
> > is a "slow path" so lots of validation and the like can happen at that
> > point.
> >
> > After that, during the normal data paths, after the driver is bound,
> > trust it all you want as attempting to validate every single packet is
> > just going to be impossible.
> >
> > thanks,
> >
> > greg k-h
>
> People do expect that data path validation at this point.
Ok, so you want this patch :)
And more, as you need to treat everything from the host as "untrusted",
and it must be "verified". Much like the proposed Rust patches we keep
slowly working on, which would make this much more obvious as to exactly
what needs to be verified, and where it happens.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 1/4] virtio-mem: validate device-reported block size
From: David Hildenbrand (Arm) @ 2026-07-17 10:21 UTC (permalink / raw)
To: Greg Kroah-Hartman, Michael S. Tsirkin
Cc: Hari Mishal, Jason Wang, Xuan Zhuo, Eugenio Pérez,
virtualization, linux-kernel, elena.reshetova,
carlos.bilbao.osdev
In-Reply-To: <2026071757-grout-composer-165d@gregkh>
On 7/17/26 12:15, Greg Kroah-Hartman wrote:
> On Fri, Jul 17, 2026 at 06:10:41AM -0400, Michael S. Tsirkin wrote:
>> On Fri, Jul 17, 2026 at 11:14:23AM +0200, Greg Kroah-Hartman wrote:
>>>
>>> Why not do what USB does? Don't trust the device until AFTER probe()
>>> succeeds? All of the needed checking should happen before then, as that
>>> is a "slow path" so lots of validation and the like can happen at that
>>> point.
>>>
>>> After that, during the normal data paths, after the driver is bound,
>>> trust it all you want as attempting to validate every single packet is
>>> just going to be impossible.
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>> People do expect that data path validation at this point.
>
> Ok, so you want this patch :)
I fail to see the value of this patch given that there are plenty of other cases
the device can mess with us.
But sure, let's check for some conditions if it makes us feel warm and fluffy as
we audited a driver and it's now super safe, fine with me.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v2 1/4] virtio-mem: validate device-reported block size
From: Michael S. Tsirkin @ 2026-07-17 10:23 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: David Hildenbrand (Arm), Hari Mishal, Jason Wang, Xuan Zhuo,
Eugenio Pérez, virtualization, linux-kernel, elena.reshetova,
carlos.bilbao.osdev
In-Reply-To: <2026071757-grout-composer-165d@gregkh>
On Fri, Jul 17, 2026 at 12:15:09PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Jul 17, 2026 at 06:10:41AM -0400, Michael S. Tsirkin wrote:
> > On Fri, Jul 17, 2026 at 11:14:23AM +0200, Greg Kroah-Hartman wrote:
> > > On Fri, Jul 17, 2026 at 04:59:32AM -0400, Michael S. Tsirkin wrote:
> > > > On Fri, Jul 17, 2026 at 10:39:40AM +0200, David Hildenbrand (Arm) wrote:
> > > > > On 7/17/26 07:48, Michael S. Tsirkin wrote:
> > > > > > On Thu, Jul 16, 2026 at 05:59:05PM +0200, David Hildenbrand (Arm) wrote:
> > > > > >>> Or do we just always trust virtio mem devices explicitly?
> > > > > >>
> > > > > >> It's hard for me to understand where we draw the line, really.
> > > > > >>
> > > > > >> But maybe MST can clarify what we care about in virtio world where the
> > > > > >> hypervisor is fully in charge of the device,
> > > > > >
> > > > > > Generally:
> > > > > > - The guest is expected to whitelist drivers (most drivers have not
> > > > > > been audited).
> > > > >
> > > > > But even if you audited your driver, who makes sure that we consider all ways
> > > > > where the device could mess with us?
> > > >
> > > > A lot of this is up to a correct setup. For example, make sure all
> > > > filesystems are encrypted and refuse to mount unencrypted ones.
> > > >
> > > > > Something feels off here.
> > > > >
> > > > > Handling selected out-of-spec scenarios like this feels like a band-aid. Happy
> > > > > to be corrected.
> > > >
> > > > Well Documentation/security/snp-tdx-threat-model.rst puts it like this:
> > > > It is important to note
> > > > that this doesn’t imply that the host or VMM are intentionally
> > > > malicious, but that there exists a security value in having a small CoCo
> > > > VM TCB.
> > > >
> > > > and
> > > >
> > > > While traditionally the host has unlimited access to guest data and can
> > > > leverage this access to attack the guest, the CoCo systems mitigate such
> > > > attacks by adding security features like guest data confidentiality and
> > > > integrity protection.
> > > >
> > > >
> > > > now, when we are talking about "mitigation" it is indeed becoming a bit
> > > > murky.
> > > >
> > > >
> > > > For me, a rule of thumb I came up with is that if the validation happens
> > > > to also be helful for users e.g. to work around buggy devices,
> > > > or maybe because we feel failing gracefully is nice because this
> > > > will allow to later make use of this config and old drivers will
> > > > fail but at least not panic, then it is good to include.
> > >
> > > Why not do what USB does? Don't trust the device until AFTER probe()
> > > succeeds? All of the needed checking should happen before then, as that
> > > is a "slow path" so lots of validation and the like can happen at that
> > > point.
> > >
> > > After that, during the normal data paths, after the driver is bound,
> > > trust it all you want as attempting to validate every single packet is
> > > just going to be impossible.
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > People do expect that data path validation at this point.
>
> Ok, so you want this patch :)
>
> And more, as you need to treat everything from the host as "untrusted",
> and it must be "verified".
Well. First it's not me) Second it's only specific configurations -
for example there's no short term plan to validate filesystem code, people
are expected to rely on encryption. The reasons have more to do
with the available manpower than anything else.
> Much like the proposed Rust patches we keep
> slowly working on, which would make this much more obvious as to exactly
> what needs to be verified, and where it happens.
>
> thanks,
>
> greg k-h
Or much like networking, except it's an old robust codebase.
--
MST
^ permalink raw reply
* Re: [PATCH v2 1/4] virtio-mem: validate device-reported block size
From: Michael S. Tsirkin @ 2026-07-17 10:28 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Greg Kroah-Hartman, Hari Mishal, Jason Wang, Xuan Zhuo,
Eugenio Pérez, virtualization, linux-kernel, elena.reshetova,
carlos.bilbao.osdev
In-Reply-To: <5877a6ae-5a9c-4376-8297-f17695964db0@kernel.org>
On Fri, Jul 17, 2026 at 11:21:34AM +0100, David Hildenbrand (Arm) wrote:
> On 7/17/26 12:15, Greg Kroah-Hartman wrote:
> > On Fri, Jul 17, 2026 at 06:10:41AM -0400, Michael S. Tsirkin wrote:
> >> On Fri, Jul 17, 2026 at 11:14:23AM +0200, Greg Kroah-Hartman wrote:
> >>>
> >>> Why not do what USB does? Don't trust the device until AFTER probe()
> >>> succeeds? All of the needed checking should happen before then, as that
> >>> is a "slow path" so lots of validation and the like can happen at that
> >>> point.
> >>>
> >>> After that, during the normal data paths, after the driver is bound,
> >>> trust it all you want as attempting to validate every single packet is
> >>> just going to be impossible.
> >>>
> >>> thanks,
> >>>
> >>> greg k-h
> >>
> >> People do expect that data path validation at this point.
> >
> > Ok, so you want this patch :)
>
> I fail to see the value of this patch given that there are plenty of other cases
> the device can mess with us.
>
> But sure, let's check for some conditions if it makes us feel warm and fluffy as
> we audited a driver and it's now super safe, fine with me.
>
> --
> Cheers,
>
> David
I merely made some generic comments since I was asked to clarify how
virtio interacts with coco. As for the specific patch, it does not make
me feel fluffy. It lacks motivation.
A broken device confuses the kernel with no way to exploit that. Shrug. So?
Nothing to do with coco, apparently.
It's maybe reasonable as a debugging aid but if this is intended as such
let's make it clear in the commit log.
--
MST
^ permalink raw reply
* Re: [PATCH v2 1/4] virtio-mem: validate device-reported block size
From: Greg Kroah-Hartman @ 2026-07-17 10:44 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Michael S. Tsirkin, Hari Mishal, Jason Wang, Xuan Zhuo,
Eugenio Pérez, virtualization, linux-kernel, elena.reshetova,
carlos.bilbao.osdev
In-Reply-To: <5877a6ae-5a9c-4376-8297-f17695964db0@kernel.org>
On Fri, Jul 17, 2026 at 11:21:34AM +0100, David Hildenbrand (Arm) wrote:
> On 7/17/26 12:15, Greg Kroah-Hartman wrote:
> > On Fri, Jul 17, 2026 at 06:10:41AM -0400, Michael S. Tsirkin wrote:
> >> On Fri, Jul 17, 2026 at 11:14:23AM +0200, Greg Kroah-Hartman wrote:
> >>>
> >>> Why not do what USB does? Don't trust the device until AFTER probe()
> >>> succeeds? All of the needed checking should happen before then, as that
> >>> is a "slow path" so lots of validation and the like can happen at that
> >>> point.
> >>>
> >>> After that, during the normal data paths, after the driver is bound,
> >>> trust it all you want as attempting to validate every single packet is
> >>> just going to be impossible.
> >>>
> >>> thanks,
> >>>
> >>> greg k-h
> >>
> >> People do expect that data path validation at this point.
> >
> > Ok, so you want this patch :)
>
> I fail to see the value of this patch given that there are plenty of other cases
> the device can mess with us.
How can the device mess with us?
> But sure, let's check for some conditions if it makes us feel warm and fluffy as
> we audited a driver and it's now super safe, fine with me.
I'm all for the folly of "it's an audited driver!" claims, but you all
need to decide either you do or you do not trust the device. Either way
is fine with me.
If you don't trust it, great, take patches that fix that. If you do
trust it, great, reject those types of patches.
But pick one please.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 1/4] virtio-mem: validate device-reported block size
From: Greg Kroah-Hartman @ 2026-07-17 10:46 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: David Hildenbrand (Arm), Hari Mishal, Jason Wang, Xuan Zhuo,
Eugenio Pérez, virtualization, linux-kernel, elena.reshetova,
carlos.bilbao.osdev
In-Reply-To: <20260717061901-mutt-send-email-mst@kernel.org>
On Fri, Jul 17, 2026 at 06:23:57AM -0400, Michael S. Tsirkin wrote:
> On Fri, Jul 17, 2026 at 12:15:09PM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Jul 17, 2026 at 06:10:41AM -0400, Michael S. Tsirkin wrote:
> > > On Fri, Jul 17, 2026 at 11:14:23AM +0200, Greg Kroah-Hartman wrote:
> > > > On Fri, Jul 17, 2026 at 04:59:32AM -0400, Michael S. Tsirkin wrote:
> > > > > On Fri, Jul 17, 2026 at 10:39:40AM +0200, David Hildenbrand (Arm) wrote:
> > > > > > On 7/17/26 07:48, Michael S. Tsirkin wrote:
> > > > > > > On Thu, Jul 16, 2026 at 05:59:05PM +0200, David Hildenbrand (Arm) wrote:
> > > > > > >>> Or do we just always trust virtio mem devices explicitly?
> > > > > > >>
> > > > > > >> It's hard for me to understand where we draw the line, really.
> > > > > > >>
> > > > > > >> But maybe MST can clarify what we care about in virtio world where the
> > > > > > >> hypervisor is fully in charge of the device,
> > > > > > >
> > > > > > > Generally:
> > > > > > > - The guest is expected to whitelist drivers (most drivers have not
> > > > > > > been audited).
> > > > > >
> > > > > > But even if you audited your driver, who makes sure that we consider all ways
> > > > > > where the device could mess with us?
> > > > >
> > > > > A lot of this is up to a correct setup. For example, make sure all
> > > > > filesystems are encrypted and refuse to mount unencrypted ones.
> > > > >
> > > > > > Something feels off here.
> > > > > >
> > > > > > Handling selected out-of-spec scenarios like this feels like a band-aid. Happy
> > > > > > to be corrected.
> > > > >
> > > > > Well Documentation/security/snp-tdx-threat-model.rst puts it like this:
> > > > > It is important to note
> > > > > that this doesn’t imply that the host or VMM are intentionally
> > > > > malicious, but that there exists a security value in having a small CoCo
> > > > > VM TCB.
> > > > >
> > > > > and
> > > > >
> > > > > While traditionally the host has unlimited access to guest data and can
> > > > > leverage this access to attack the guest, the CoCo systems mitigate such
> > > > > attacks by adding security features like guest data confidentiality and
> > > > > integrity protection.
> > > > >
> > > > >
> > > > > now, when we are talking about "mitigation" it is indeed becoming a bit
> > > > > murky.
> > > > >
> > > > >
> > > > > For me, a rule of thumb I came up with is that if the validation happens
> > > > > to also be helful for users e.g. to work around buggy devices,
> > > > > or maybe because we feel failing gracefully is nice because this
> > > > > will allow to later make use of this config and old drivers will
> > > > > fail but at least not panic, then it is good to include.
> > > >
> > > > Why not do what USB does? Don't trust the device until AFTER probe()
> > > > succeeds? All of the needed checking should happen before then, as that
> > > > is a "slow path" so lots of validation and the like can happen at that
> > > > point.
> > > >
> > > > After that, during the normal data paths, after the driver is bound,
> > > > trust it all you want as attempting to validate every single packet is
> > > > just going to be impossible.
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > >
> > > People do expect that data path validation at this point.
> >
> > Ok, so you want this patch :)
> >
> > And more, as you need to treat everything from the host as "untrusted",
> > and it must be "verified".
>
> Well. First it's not me) Second it's only specific configurations -
> for example there's no short term plan to validate filesystem code, people
> are expected to rely on encryption. The reasons have more to do
> with the available manpower than anything else.
Sure, but again, for subsystems, you have to define your threat model as
the LLMs are churning against the code base and coming up with lots of
crazy ideas if a device should or should not be trusted and spitting out
patches and reports like the ones that are in the first few patches of
this series.
So please, pick a model, let's document it, and go with that. I am
getting directly conflicting responses here.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 1/4] virtio-mem: validate device-reported block size
From: Michael S. Tsirkin @ 2026-07-17 10:52 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: David Hildenbrand (Arm), Hari Mishal, Jason Wang, Xuan Zhuo,
Eugenio Pérez, virtualization, linux-kernel, elena.reshetova,
carlos.bilbao.osdev
In-Reply-To: <2026071724-asleep-pedigree-ea54@gregkh>
On Fri, Jul 17, 2026 at 12:46:52PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Jul 17, 2026 at 06:23:57AM -0400, Michael S. Tsirkin wrote:
> > On Fri, Jul 17, 2026 at 12:15:09PM +0200, Greg Kroah-Hartman wrote:
> > > On Fri, Jul 17, 2026 at 06:10:41AM -0400, Michael S. Tsirkin wrote:
> > > > On Fri, Jul 17, 2026 at 11:14:23AM +0200, Greg Kroah-Hartman wrote:
> > > > > On Fri, Jul 17, 2026 at 04:59:32AM -0400, Michael S. Tsirkin wrote:
> > > > > > On Fri, Jul 17, 2026 at 10:39:40AM +0200, David Hildenbrand (Arm) wrote:
> > > > > > > On 7/17/26 07:48, Michael S. Tsirkin wrote:
> > > > > > > > On Thu, Jul 16, 2026 at 05:59:05PM +0200, David Hildenbrand (Arm) wrote:
> > > > > > > >>> Or do we just always trust virtio mem devices explicitly?
> > > > > > > >>
> > > > > > > >> It's hard for me to understand where we draw the line, really.
> > > > > > > >>
> > > > > > > >> But maybe MST can clarify what we care about in virtio world where the
> > > > > > > >> hypervisor is fully in charge of the device,
> > > > > > > >
> > > > > > > > Generally:
> > > > > > > > - The guest is expected to whitelist drivers (most drivers have not
> > > > > > > > been audited).
> > > > > > >
> > > > > > > But even if you audited your driver, who makes sure that we consider all ways
> > > > > > > where the device could mess with us?
> > > > > >
> > > > > > A lot of this is up to a correct setup. For example, make sure all
> > > > > > filesystems are encrypted and refuse to mount unencrypted ones.
> > > > > >
> > > > > > > Something feels off here.
> > > > > > >
> > > > > > > Handling selected out-of-spec scenarios like this feels like a band-aid. Happy
> > > > > > > to be corrected.
> > > > > >
> > > > > > Well Documentation/security/snp-tdx-threat-model.rst puts it like this:
> > > > > > It is important to note
> > > > > > that this doesn’t imply that the host or VMM are intentionally
> > > > > > malicious, but that there exists a security value in having a small CoCo
> > > > > > VM TCB.
> > > > > >
> > > > > > and
> > > > > >
> > > > > > While traditionally the host has unlimited access to guest data and can
> > > > > > leverage this access to attack the guest, the CoCo systems mitigate such
> > > > > > attacks by adding security features like guest data confidentiality and
> > > > > > integrity protection.
> > > > > >
> > > > > >
> > > > > > now, when we are talking about "mitigation" it is indeed becoming a bit
> > > > > > murky.
> > > > > >
> > > > > >
> > > > > > For me, a rule of thumb I came up with is that if the validation happens
> > > > > > to also be helful for users e.g. to work around buggy devices,
> > > > > > or maybe because we feel failing gracefully is nice because this
> > > > > > will allow to later make use of this config and old drivers will
> > > > > > fail but at least not panic, then it is good to include.
> > > > >
> > > > > Why not do what USB does? Don't trust the device until AFTER probe()
> > > > > succeeds? All of the needed checking should happen before then, as that
> > > > > is a "slow path" so lots of validation and the like can happen at that
> > > > > point.
> > > > >
> > > > > After that, during the normal data paths, after the driver is bound,
> > > > > trust it all you want as attempting to validate every single packet is
> > > > > just going to be impossible.
> > > > >
> > > > > thanks,
> > > > >
> > > > > greg k-h
> > > >
> > > > People do expect that data path validation at this point.
> > >
> > > Ok, so you want this patch :)
> > >
> > > And more, as you need to treat everything from the host as "untrusted",
> > > and it must be "verified".
> >
> > Well. First it's not me) Second it's only specific configurations -
> > for example there's no short term plan to validate filesystem code, people
> > are expected to rely on encryption. The reasons have more to do
> > with the available manpower than anything else.
>
> Sure, but again, for subsystems, you have to define your threat model as
> the LLMs are churning against the code base and coming up with lots of
> crazy ideas if a device should or should not be trusted and spitting out
> patches and reports like the ones that are in the first few patches of
> this series.
>
> So please, pick a model, let's document it, and go with that. I am
> getting directly conflicting responses here.
>
> thanks,
>
> greg k-h
Supposed to be this one:
Documentation/security/snp-tdx-threat-model.rst
what is missing?
--
MST
^ permalink raw reply
* Re: [PATCH v2 1/4] virtio-mem: validate device-reported block size
From: David Hildenbrand (Arm) @ 2026-07-17 11:00 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Michael S. Tsirkin, Hari Mishal, Jason Wang, Xuan Zhuo,
Eugenio Pérez, virtualization, linux-kernel, elena.reshetova,
carlos.bilbao.osdev
In-Reply-To: <2026071717-unfiled-manned-3305@gregkh>
On 7/17/26 12:44, Greg Kroah-Hartman wrote:
> On Fri, Jul 17, 2026 at 11:21:34AM +0100, David Hildenbrand (Arm) wrote:
>> On 7/17/26 12:15, Greg Kroah-Hartman wrote:
>>>
>>> Ok, so you want this patch :)
>>
>> I fail to see the value of this patch given that there are plenty of other cases
>> the device can mess with us.
>
> How can the device mess with us?
I raised some examples already, like lying about which memory chunks it makes
available.
I guess it could also throw a random "requested_size" at us. It could make up a
wrong physical address region. I assume there is plenty more we'd have to check.
Again, I'm not saying that this couldn't/shouldn't be done, but it requires some
*real thought* about all possible things a device could do.
>
>> But sure, let's check for some conditions if it makes us feel warm and fluffy as
>> we audited a driver and it's now super safe, fine with me.
>
> I'm all for the folly of "it's an audited driver!" claims, but you all
> need to decide either you do or you do not trust the device. Either way
> is fine with me.
Well, exactly, that is what I am saying. I don't know what we care about. This
patch here feels incomplete and that's what grinds my gears. It doesn't
magically make us deal with malicious devices.
And I don't buy the story about "buggy virtio-mem devices that set
block_size==0", which doesn't make any sense in any possible reality.
>
> If you don't trust it, great, take patches that fix that. If you do
> trust it, great, reject those types of patches.
>
> But pick one please.
Yes, I'd expect that we have general virtio guifance. I only co-maintain some
virtio bits and have no idea about the expected trust model and when we would
consider a devices trusted.
And what it would take to get there.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v2 1/4] virtio-mem: validate device-reported block size
From: Greg Kroah-Hartman @ 2026-07-17 12:07 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: David Hildenbrand (Arm), Hari Mishal, Jason Wang, Xuan Zhuo,
Eugenio Pérez, virtualization, linux-kernel, elena.reshetova,
carlos.bilbao.osdev
In-Reply-To: <20260717065219-mutt-send-email-mst@kernel.org>
On Fri, Jul 17, 2026 at 06:52:46AM -0400, Michael S. Tsirkin wrote:
> On Fri, Jul 17, 2026 at 12:46:52PM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Jul 17, 2026 at 06:23:57AM -0400, Michael S. Tsirkin wrote:
> > > On Fri, Jul 17, 2026 at 12:15:09PM +0200, Greg Kroah-Hartman wrote:
> > > > On Fri, Jul 17, 2026 at 06:10:41AM -0400, Michael S. Tsirkin wrote:
> > > > > On Fri, Jul 17, 2026 at 11:14:23AM +0200, Greg Kroah-Hartman wrote:
> > > > > > On Fri, Jul 17, 2026 at 04:59:32AM -0400, Michael S. Tsirkin wrote:
> > > > > > > On Fri, Jul 17, 2026 at 10:39:40AM +0200, David Hildenbrand (Arm) wrote:
> > > > > > > > On 7/17/26 07:48, Michael S. Tsirkin wrote:
> > > > > > > > > On Thu, Jul 16, 2026 at 05:59:05PM +0200, David Hildenbrand (Arm) wrote:
> > > > > > > > >>> Or do we just always trust virtio mem devices explicitly?
> > > > > > > > >>
> > > > > > > > >> It's hard for me to understand where we draw the line, really.
> > > > > > > > >>
> > > > > > > > >> But maybe MST can clarify what we care about in virtio world where the
> > > > > > > > >> hypervisor is fully in charge of the device,
> > > > > > > > >
> > > > > > > > > Generally:
> > > > > > > > > - The guest is expected to whitelist drivers (most drivers have not
> > > > > > > > > been audited).
> > > > > > > >
> > > > > > > > But even if you audited your driver, who makes sure that we consider all ways
> > > > > > > > where the device could mess with us?
> > > > > > >
> > > > > > > A lot of this is up to a correct setup. For example, make sure all
> > > > > > > filesystems are encrypted and refuse to mount unencrypted ones.
> > > > > > >
> > > > > > > > Something feels off here.
> > > > > > > >
> > > > > > > > Handling selected out-of-spec scenarios like this feels like a band-aid. Happy
> > > > > > > > to be corrected.
> > > > > > >
> > > > > > > Well Documentation/security/snp-tdx-threat-model.rst puts it like this:
> > > > > > > It is important to note
> > > > > > > that this doesn’t imply that the host or VMM are intentionally
> > > > > > > malicious, but that there exists a security value in having a small CoCo
> > > > > > > VM TCB.
> > > > > > >
> > > > > > > and
> > > > > > >
> > > > > > > While traditionally the host has unlimited access to guest data and can
> > > > > > > leverage this access to attack the guest, the CoCo systems mitigate such
> > > > > > > attacks by adding security features like guest data confidentiality and
> > > > > > > integrity protection.
> > > > > > >
> > > > > > >
> > > > > > > now, when we are talking about "mitigation" it is indeed becoming a bit
> > > > > > > murky.
> > > > > > >
> > > > > > >
> > > > > > > For me, a rule of thumb I came up with is that if the validation happens
> > > > > > > to also be helful for users e.g. to work around buggy devices,
> > > > > > > or maybe because we feel failing gracefully is nice because this
> > > > > > > will allow to later make use of this config and old drivers will
> > > > > > > fail but at least not panic, then it is good to include.
> > > > > >
> > > > > > Why not do what USB does? Don't trust the device until AFTER probe()
> > > > > > succeeds? All of the needed checking should happen before then, as that
> > > > > > is a "slow path" so lots of validation and the like can happen at that
> > > > > > point.
> > > > > >
> > > > > > After that, during the normal data paths, after the driver is bound,
> > > > > > trust it all you want as attempting to validate every single packet is
> > > > > > just going to be impossible.
> > > > > >
> > > > > > thanks,
> > > > > >
> > > > > > greg k-h
> > > > >
> > > > > People do expect that data path validation at this point.
> > > >
> > > > Ok, so you want this patch :)
> > > >
> > > > And more, as you need to treat everything from the host as "untrusted",
> > > > and it must be "verified".
> > >
> > > Well. First it's not me) Second it's only specific configurations -
> > > for example there's no short term plan to validate filesystem code, people
> > > are expected to rely on encryption. The reasons have more to do
> > > with the available manpower than anything else.
> >
> > Sure, but again, for subsystems, you have to define your threat model as
> > the LLMs are churning against the code base and coming up with lots of
> > crazy ideas if a device should or should not be trusted and spitting out
> > patches and reports like the ones that are in the first few patches of
> > this series.
> >
> > So please, pick a model, let's document it, and go with that. I am
> > getting directly conflicting responses here.
> >
> > thanks,
> >
> > greg k-h
>
> Supposed to be this one:
> Documentation/security/snp-tdx-threat-model.rst
>
> what is missing?
A policy decision that needs to be made. All that document does is
describe a bunch of different "threats" yet does not decide what to do
about them at all from what I can tell.
And that's just for one subset of the CoC world, right? Is that
something that all virtio drivers need/want to care about?
So I don't see a real answer to the "does Linux trust the host to give
you good data or not" question in that file, am I missing it?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 1/4] virtio-mem: validate device-reported block size
From: Michael S. Tsirkin @ 2026-07-17 13:08 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: David Hildenbrand (Arm), Hari Mishal, Jason Wang, Xuan Zhuo,
Eugenio Pérez, virtualization, linux-kernel, elena.reshetova,
carlos.bilbao.osdev
In-Reply-To: <2026071759-thermal-synopsis-7568@gregkh>
On Fri, Jul 17, 2026 at 02:07:50PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Jul 17, 2026 at 06:52:46AM -0400, Michael S. Tsirkin wrote:
> > On Fri, Jul 17, 2026 at 12:46:52PM +0200, Greg Kroah-Hartman wrote:
> > > On Fri, Jul 17, 2026 at 06:23:57AM -0400, Michael S. Tsirkin wrote:
> > > > On Fri, Jul 17, 2026 at 12:15:09PM +0200, Greg Kroah-Hartman wrote:
> > > > > On Fri, Jul 17, 2026 at 06:10:41AM -0400, Michael S. Tsirkin wrote:
> > > > > > On Fri, Jul 17, 2026 at 11:14:23AM +0200, Greg Kroah-Hartman wrote:
> > > > > > > On Fri, Jul 17, 2026 at 04:59:32AM -0400, Michael S. Tsirkin wrote:
> > > > > > > > On Fri, Jul 17, 2026 at 10:39:40AM +0200, David Hildenbrand (Arm) wrote:
> > > > > > > > > On 7/17/26 07:48, Michael S. Tsirkin wrote:
> > > > > > > > > > On Thu, Jul 16, 2026 at 05:59:05PM +0200, David Hildenbrand (Arm) wrote:
> > > > > > > > > >>> Or do we just always trust virtio mem devices explicitly?
> > > > > > > > > >>
> > > > > > > > > >> It's hard for me to understand where we draw the line, really.
> > > > > > > > > >>
> > > > > > > > > >> But maybe MST can clarify what we care about in virtio world where the
> > > > > > > > > >> hypervisor is fully in charge of the device,
> > > > > > > > > >
> > > > > > > > > > Generally:
> > > > > > > > > > - The guest is expected to whitelist drivers (most drivers have not
> > > > > > > > > > been audited).
> > > > > > > > >
> > > > > > > > > But even if you audited your driver, who makes sure that we consider all ways
> > > > > > > > > where the device could mess with us?
> > > > > > > >
> > > > > > > > A lot of this is up to a correct setup. For example, make sure all
> > > > > > > > filesystems are encrypted and refuse to mount unencrypted ones.
> > > > > > > >
> > > > > > > > > Something feels off here.
> > > > > > > > >
> > > > > > > > > Handling selected out-of-spec scenarios like this feels like a band-aid. Happy
> > > > > > > > > to be corrected.
> > > > > > > >
> > > > > > > > Well Documentation/security/snp-tdx-threat-model.rst puts it like this:
> > > > > > > > It is important to note
> > > > > > > > that this doesn’t imply that the host or VMM are intentionally
> > > > > > > > malicious, but that there exists a security value in having a small CoCo
> > > > > > > > VM TCB.
> > > > > > > >
> > > > > > > > and
> > > > > > > >
> > > > > > > > While traditionally the host has unlimited access to guest data and can
> > > > > > > > leverage this access to attack the guest, the CoCo systems mitigate such
> > > > > > > > attacks by adding security features like guest data confidentiality and
> > > > > > > > integrity protection.
> > > > > > > >
> > > > > > > >
> > > > > > > > now, when we are talking about "mitigation" it is indeed becoming a bit
> > > > > > > > murky.
> > > > > > > >
> > > > > > > >
> > > > > > > > For me, a rule of thumb I came up with is that if the validation happens
> > > > > > > > to also be helful for users e.g. to work around buggy devices,
> > > > > > > > or maybe because we feel failing gracefully is nice because this
> > > > > > > > will allow to later make use of this config and old drivers will
> > > > > > > > fail but at least not panic, then it is good to include.
> > > > > > >
> > > > > > > Why not do what USB does? Don't trust the device until AFTER probe()
> > > > > > > succeeds? All of the needed checking should happen before then, as that
> > > > > > > is a "slow path" so lots of validation and the like can happen at that
> > > > > > > point.
> > > > > > >
> > > > > > > After that, during the normal data paths, after the driver is bound,
> > > > > > > trust it all you want as attempting to validate every single packet is
> > > > > > > just going to be impossible.
> > > > > > >
> > > > > > > thanks,
> > > > > > >
> > > > > > > greg k-h
> > > > > >
> > > > > > People do expect that data path validation at this point.
> > > > >
> > > > > Ok, so you want this patch :)
> > > > >
> > > > > And more, as you need to treat everything from the host as "untrusted",
> > > > > and it must be "verified".
> > > >
> > > > Well. First it's not me) Second it's only specific configurations -
> > > > for example there's no short term plan to validate filesystem code, people
> > > > are expected to rely on encryption. The reasons have more to do
> > > > with the available manpower than anything else.
> > >
> > > Sure, but again, for subsystems, you have to define your threat model as
> > > the LLMs are churning against the code base and coming up with lots of
> > > crazy ideas if a device should or should not be trusted and spitting out
> > > patches and reports like the ones that are in the first few patches of
> > > this series.
> > >
> > > So please, pick a model, let's document it, and go with that. I am
> > > getting directly conflicting responses here.
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > Supposed to be this one:
> > Documentation/security/snp-tdx-threat-model.rst
> >
> > what is missing?
>
> A policy decision that needs to be made. All that document does is
> describe a bunch of different "threats" yet does not decide what to do
> about them at all from what I can tell.
That would be this section I think:
The **Linux kernel CoCo VM security objectives** can be summarized as follows:
it does, indeed, not go into detail about how to interact, safely,
with untrusted entities. Does it really need to be spelled out?
> And that's just for one subset of the CoC world, right? Is that
> something that all virtio drivers need/want to care about?
What is missing, and what you seem to be asking for, is an opinionated
stance on which drivers we care about in this world?
True.
coco guys tried to annotate drivers at some point to do exactly that.
this was rejected upstream from the position that this is not
different from handling buggy hardware, and just to fix all drivers.
so it's up to users, and I guess for virtio the answer is yes
with some exceptions because we don't have a better answer right now.
> So I don't see a real answer to the "does Linux trust the host to give
> you good data or not" question in that file, am I missing it?
>
> thanks,
>
> greg k-h
This? Note the last sentence.
The **Linux CoCo VM attack surface** is any interface exposed from a CoCo
guest Linux kernel towards an untrusted host that is not covered by the
CoCo technology SW/HW protection. This includes any possible
side-channels, as well as transient execution side channels. Examples of
explicit (not side-channel) interfaces include accesses to port I/O, MMIO
and DMA interfaces, access to PCI configuration space, VMM-specific
hypercalls (towards Host-side VMM), access to shared memory pages,
interrupts allowed to be injected into the guest kernel by the host, as
well as CoCo technology-specific hypercalls, if present. Additionally, the
host in a CoCo system typically controls the process of creating a CoCo
guest: it has a method to load into a guest the firmware and bootloader
images, the kernel image together with the kernel command line. All of this
data should also be considered untrusted until its integrity and
authenticity is established via attestation.
^ permalink raw reply
* [PATCH] vhost-scsi: Prevent OOM from invalid protection SGL count
From: Jia Jia @ 2026-07-17 14:22 UTC (permalink / raw)
To: mst, jasowang, michael.christie
Cc: pbonzini, stefanha, eperezma, virtualization, kvm, netdev,
linux-kernel, stable
The protection SGL path passes the result of vhost_scsi_calc_sgls()
directly to sg_alloc_table_chained(). The helper returns a negative
errno when the iterator is invalid or the request exceeds the segment
limit. The negative errno is then treated as a very large unsigned count
and sends the request into the SGL allocation path with an invalid size.
Repeated malformed T10-PI submissions from a host-side application caused
memory usage to rise sharply. MemAvailable fell to about 200 MB, and PSI
full avg10 reached about 1.46. The OOM killer terminated several userspace
processes before the endpoint cleanup completed. The kernel log included:
[17036.451028] Out of memory: Killed process 2345 (systemd)
[17036.493325] Out of memory: Killed process 2349 (sd-pam)
[17078.265127] Out of memory: Killed process 1793 (networkd-dispat)
Return the calculation error before setting up the protection SGL. This
keeps the protection path consistent with the data SGL path and prevents
the invalid count from entering the allocation path.
Fixes: bca939d5bcd0 ("vhost-scsi: Dynamically allocate scatterlists")
Cc: stable@vger.kernel.org
Signed-off-by: Jia Jia <physicalmtea@gmail.com>
---
drivers/vhost/scsi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 9a1253b9d..8486652fd 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -972,6 +972,9 @@ vhost_scsi_mapal(struct vhost_scsi *vs, struct vhost_scsi_cmd *cmd,
if (prot_bytes) {
sgl_count = vhost_scsi_calc_sgls(prot_iter, prot_bytes,
VHOST_SCSI_PREALLOC_PROT_SGLS);
+ if (sgl_count < 0)
+ return sgl_count;
+
cmd->prot_table.sgl = cmd->prot_sgl;
ret = sg_alloc_table_chained(&cmd->prot_table, sgl_count,
cmd->prot_table.sgl,
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 1/4] virtio-mem: validate device-reported block size
From: Greg Kroah-Hartman @ 2026-07-17 14:31 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: David Hildenbrand (Arm), Hari Mishal, Jason Wang, Xuan Zhuo,
Eugenio Pérez, virtualization, linux-kernel, elena.reshetova,
carlos.bilbao.osdev
In-Reply-To: <20260717085838-mutt-send-email-mst@kernel.org>
On Fri, Jul 17, 2026 at 09:08:23AM -0400, Michael S. Tsirkin wrote:
> On Fri, Jul 17, 2026 at 02:07:50PM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Jul 17, 2026 at 06:52:46AM -0400, Michael S. Tsirkin wrote:
> > > On Fri, Jul 17, 2026 at 12:46:52PM +0200, Greg Kroah-Hartman wrote:
> > > > On Fri, Jul 17, 2026 at 06:23:57AM -0400, Michael S. Tsirkin wrote:
> > > > > On Fri, Jul 17, 2026 at 12:15:09PM +0200, Greg Kroah-Hartman wrote:
> > > > > > On Fri, Jul 17, 2026 at 06:10:41AM -0400, Michael S. Tsirkin wrote:
> > > > > > > On Fri, Jul 17, 2026 at 11:14:23AM +0200, Greg Kroah-Hartman wrote:
> > > > > > > > On Fri, Jul 17, 2026 at 04:59:32AM -0400, Michael S. Tsirkin wrote:
> > > > > > > > > On Fri, Jul 17, 2026 at 10:39:40AM +0200, David Hildenbrand (Arm) wrote:
> > > > > > > > > > On 7/17/26 07:48, Michael S. Tsirkin wrote:
> > > > > > > > > > > On Thu, Jul 16, 2026 at 05:59:05PM +0200, David Hildenbrand (Arm) wrote:
> > > > > > > > > > >>> Or do we just always trust virtio mem devices explicitly?
> > > > > > > > > > >>
> > > > > > > > > > >> It's hard for me to understand where we draw the line, really.
> > > > > > > > > > >>
> > > > > > > > > > >> But maybe MST can clarify what we care about in virtio world where the
> > > > > > > > > > >> hypervisor is fully in charge of the device,
> > > > > > > > > > >
> > > > > > > > > > > Generally:
> > > > > > > > > > > - The guest is expected to whitelist drivers (most drivers have not
> > > > > > > > > > > been audited).
> > > > > > > > > >
> > > > > > > > > > But even if you audited your driver, who makes sure that we consider all ways
> > > > > > > > > > where the device could mess with us?
> > > > > > > > >
> > > > > > > > > A lot of this is up to a correct setup. For example, make sure all
> > > > > > > > > filesystems are encrypted and refuse to mount unencrypted ones.
> > > > > > > > >
> > > > > > > > > > Something feels off here.
> > > > > > > > > >
> > > > > > > > > > Handling selected out-of-spec scenarios like this feels like a band-aid. Happy
> > > > > > > > > > to be corrected.
> > > > > > > > >
> > > > > > > > > Well Documentation/security/snp-tdx-threat-model.rst puts it like this:
> > > > > > > > > It is important to note
> > > > > > > > > that this doesn’t imply that the host or VMM are intentionally
> > > > > > > > > malicious, but that there exists a security value in having a small CoCo
> > > > > > > > > VM TCB.
> > > > > > > > >
> > > > > > > > > and
> > > > > > > > >
> > > > > > > > > While traditionally the host has unlimited access to guest data and can
> > > > > > > > > leverage this access to attack the guest, the CoCo systems mitigate such
> > > > > > > > > attacks by adding security features like guest data confidentiality and
> > > > > > > > > integrity protection.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > now, when we are talking about "mitigation" it is indeed becoming a bit
> > > > > > > > > murky.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > For me, a rule of thumb I came up with is that if the validation happens
> > > > > > > > > to also be helful for users e.g. to work around buggy devices,
> > > > > > > > > or maybe because we feel failing gracefully is nice because this
> > > > > > > > > will allow to later make use of this config and old drivers will
> > > > > > > > > fail but at least not panic, then it is good to include.
> > > > > > > >
> > > > > > > > Why not do what USB does? Don't trust the device until AFTER probe()
> > > > > > > > succeeds? All of the needed checking should happen before then, as that
> > > > > > > > is a "slow path" so lots of validation and the like can happen at that
> > > > > > > > point.
> > > > > > > >
> > > > > > > > After that, during the normal data paths, after the driver is bound,
> > > > > > > > trust it all you want as attempting to validate every single packet is
> > > > > > > > just going to be impossible.
> > > > > > > >
> > > > > > > > thanks,
> > > > > > > >
> > > > > > > > greg k-h
> > > > > > >
> > > > > > > People do expect that data path validation at this point.
> > > > > >
> > > > > > Ok, so you want this patch :)
> > > > > >
> > > > > > And more, as you need to treat everything from the host as "untrusted",
> > > > > > and it must be "verified".
> > > > >
> > > > > Well. First it's not me) Second it's only specific configurations -
> > > > > for example there's no short term plan to validate filesystem code, people
> > > > > are expected to rely on encryption. The reasons have more to do
> > > > > with the available manpower than anything else.
> > > >
> > > > Sure, but again, for subsystems, you have to define your threat model as
> > > > the LLMs are churning against the code base and coming up with lots of
> > > > crazy ideas if a device should or should not be trusted and spitting out
> > > > patches and reports like the ones that are in the first few patches of
> > > > this series.
> > > >
> > > > So please, pick a model, let's document it, and go with that. I am
> > > > getting directly conflicting responses here.
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > >
> > > Supposed to be this one:
> > > Documentation/security/snp-tdx-threat-model.rst
> > >
> > > what is missing?
> >
> > A policy decision that needs to be made. All that document does is
> > describe a bunch of different "threats" yet does not decide what to do
> > about them at all from what I can tell.
>
> That would be this section I think:
>
> The **Linux kernel CoCo VM security objectives** can be summarized as follows:
>
> it does, indeed, not go into detail about how to interact, safely,
> with untrusted entities. Does it really need to be spelled out?
Seems like it as I didn't figure it out at all :)
> > And that's just for one subset of the CoC world, right? Is that
> > something that all virtio drivers need/want to care about?
>
> What is missing, and what you seem to be asking for, is an opinionated
> stance on which drivers we care about in this world?
> True.
Yes.
> coco guys tried to annotate drivers at some point to do exactly that.
> this was rejected upstream from the position that this is not
> different from handling buggy hardware, and just to fix all drivers.
> so it's up to users, and I guess for virtio the answer is yes
> with some exceptions because we don't have a better answer right now.
Ok, so back to the original question here:
> > So I don't see a real answer to the "does Linux trust the host to give
> > you good data or not" question in that file, am I missing it?
> >
> > thanks,
> >
> > greg k-h
>
> This? Note the last sentence.
>
> The **Linux CoCo VM attack surface** is any interface exposed from a CoCo
> guest Linux kernel towards an untrusted host that is not covered by the
> CoCo technology SW/HW protection. This includes any possible
> side-channels, as well as transient execution side channels. Examples of
> explicit (not side-channel) interfaces include accesses to port I/O, MMIO
> and DMA interfaces, access to PCI configuration space, VMM-specific
> hypercalls (towards Host-side VMM), access to shared memory pages,
> interrupts allowed to be injected into the guest kernel by the host, as
> well as CoCo technology-specific hypercalls, if present. Additionally, the
> host in a CoCo system typically controls the process of creating a CoCo
> guest: it has a method to load into a guest the firmware and bootloader
> images, the kernel image together with the kernel command line. All of this
> data should also be considered untrusted until its integrity and
> authenticity is established via attestation.
Great, so you are saying that we need to fix any bug found where a host
could be sending "bad" data over the virtio path before, and after, the
driver is bound to the device. That's a solid answer, and let's let the
LLMs run with that!
Which also implies that the first 3 patches here are acceptable, right?
:)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2] virtio-pmem: allocate flush bio from a driver-private bio_set
From: Pankaj Gupta @ 2026-07-17 15:03 UTC (permalink / raw)
To: Joseph Qi
Cc: Christoph Hellwig, Baokun Li, virtualization, linux-kernel,
Dan Williams, Michael S . Tsirkin, Alison Schofield, Linux NVDIMM,
Dave Jiang
In-Reply-To: <20260709124455.1547912-1-joseph.qi@linux.alibaba.com>
+CC more folks
> async_pmem_flush() allocates a child bio for the flush with GFP_ATOMIC.
> This runs from pmem_submit_bio(), a ->submit_bio callback that executes
> in a sleepable context, so there is no atomicity requirement here.
>
> bio_alloc() only guarantees success when __GFP_DIRECT_RECLAIM is set,
> because that is what lets it fall back to the mempool reserve. With
> GFP_ATOMIC the reclaim bit is absent, so the allocation can fail and
> return -ENOMEM whenever the fast paths (percpu cache and slab) are
> exhausted, which is common right after boot. A flush is issued from
> filesystem writeback and must not fail on a transient allocation
> shortage, otherwise the device can appear unmountable:
>
> Buffer I/O error on dev pmem0, logical block 0, lost sync page write
>
> Switch to GFP_NOIO so __GFP_DIRECT_RECLAIM is set and the allocation can
> make forward progress. However, bio_alloc() draws from the shared
> fs_bio_set, and the incoming bio being flushed may itself have come from
> fs_bio_set; allocating a second bio from the same set while submitting
> underneath ->submit_bio can deadlock the mempool. Add a driver-private
> bio_set for the flush and allocate from it via bio_alloc_bioset(), so
> the flush bio has an independent reserve.
>
> With a dedicated mempool-backed bio_set and GFP_NOIO the allocation
> cannot fail, so drop the now-redundant NULL check.
>
> Fixes: 6e84200c0a29 ("virtio-pmem: Add virtio pmem driver")
> Suggested-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com>
> ---
> drivers/nvdimm/nd_virtio.c | 11 ++++++-----
> drivers/nvdimm/virtio_pmem.c | 11 ++++++++++-
> drivers/nvdimm/virtio_pmem.h | 4 ++++
> 3 files changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/nvdimm/nd_virtio.c b/drivers/nvdimm/nd_virtio.c
> index 4176046627beb..b4bd21edf5c1c 100644
> --- a/drivers/nvdimm/nd_virtio.c
> +++ b/drivers/nvdimm/nd_virtio.c
> @@ -110,17 +110,18 @@ static int virtio_pmem_flush(struct nd_region *nd_region)
> /* The asynchronous flush callback function */
> int async_pmem_flush(struct nd_region *nd_region, struct bio *bio)
> {
> + struct virtio_device *vdev = nd_region->provider_data;
> + struct virtio_pmem *vpmem = vdev->priv;
> +
> /*
> * Create child bio for asynchronous flush and chain with
> * parent bio. Otherwise directly call nd_region flush.
> */
> if (bio && bio->bi_iter.bi_sector != -1) {
> - struct bio *child = bio_alloc(bio->bi_bdev, 0,
> - REQ_OP_WRITE | REQ_PREFLUSH,
> - GFP_ATOMIC);
> + struct bio *child = bio_alloc_bioset(bio->bi_bdev, 0,
> + REQ_OP_WRITE | REQ_PREFLUSH, GFP_NOIO,
> + &vpmem->flush_bio_set);
>
> - if (!child)
> - return -ENOMEM;
> bio_clone_blkg_association(child, bio);
> child->bi_iter.bi_sector = -1;
> bio_chain(child, bio);
> diff --git a/drivers/nvdimm/virtio_pmem.c b/drivers/nvdimm/virtio_pmem.c
> index 77b1966619059..136179506b478 100644
> --- a/drivers/nvdimm/virtio_pmem.c
> +++ b/drivers/nvdimm/virtio_pmem.c
> @@ -65,12 +65,17 @@ static int virtio_pmem_probe(struct virtio_device *vdev)
> }
>
> mutex_init(&vpmem->flush_lock);
> + err = bioset_init(&vpmem->flush_bio_set, BIO_POOL_SIZE, 0, 0);
> + if (err) {
> + dev_err(&vdev->dev, "failed to initialize flush bio_set\n");
> + goto out_err;
> + }
> vpmem->vdev = vdev;
> vdev->priv = vpmem;
> err = init_vq(vpmem);
> if (err) {
> dev_err(&vdev->dev, "failed to initialize virtio pmem vq's\n");
> - goto out_err;
> + goto out_bioset;
> }
>
> if (virtio_has_feature(vdev, VIRTIO_PMEM_F_SHMEM_REGION)) {
> @@ -131,6 +136,8 @@ static int virtio_pmem_probe(struct virtio_device *vdev)
> nvdimm_bus_unregister(vpmem->nvdimm_bus);
> out_vq:
> vdev->config->del_vqs(vdev);
> +out_bioset:
> + bioset_exit(&vpmem->flush_bio_set);
> out_err:
> return err;
> }
> @@ -138,10 +145,12 @@ static int virtio_pmem_probe(struct virtio_device *vdev)
> static void virtio_pmem_remove(struct virtio_device *vdev)
> {
> struct nvdimm_bus *nvdimm_bus = dev_get_drvdata(&vdev->dev);
> + struct virtio_pmem *vpmem = vdev->priv;
>
> nvdimm_bus_unregister(nvdimm_bus);
> vdev->config->del_vqs(vdev);
> virtio_reset_device(vdev);
> + bioset_exit(&vpmem->flush_bio_set);
> }
>
> static int virtio_pmem_freeze(struct virtio_device *vdev)
> diff --git a/drivers/nvdimm/virtio_pmem.h b/drivers/nvdimm/virtio_pmem.h
> index f72cf17f9518f..4ff2076f75047 100644
> --- a/drivers/nvdimm/virtio_pmem.h
> +++ b/drivers/nvdimm/virtio_pmem.h
> @@ -15,6 +15,7 @@
> #include <linux/libnvdimm.h>
> #include <linux/mutex.h>
> #include <linux/spinlock.h>
> +#include <linux/bio.h>
>
> struct virtio_pmem_request {
> struct virtio_pmem_req req;
> @@ -39,6 +40,9 @@ struct virtio_pmem {
> /* Serialize flush requests to the device. */
> struct mutex flush_lock;
>
> + /* bio_set for allocating flush child bios */
> + struct bio_set flush_bio_set;
> +
> /* nvdimm bus registers virtio pmem device */
> struct nvdimm_bus *nvdimm_bus;
> struct nvdimm_bus_descriptor nd_desc;
> --
> 2.39.3
>
^ permalink raw reply
* [PATCH] virtio_console: take a kref in find_port_by_vq() to fix port UAF
From: Hari Mishal @ 2026-07-17 15:06 UTC (permalink / raw)
To: Amit Shah
Cc: Arnd Bergmann, Greg Kroah-Hartman, virtualization, linux-kernel,
Hari Mishal
find_port_by_vq() returns a raw struct port pointer without taking a
reference on it, unlike find_port_by_devt_in_portdev() which does.
find_port_by_vq()'s only two callers, in_intr() and out_intr(), run as
virtqueue interrupt callbacks, entirely independent of and possibly
concurrently with unplug_port(), which itself runs from a workqueue when
the host sends a VIRTIO_CONSOLE_PORT_REMOVE control message.
unplug_port() removes the port from portdev->ports under ports_lock,
then later drops its last reference with kref_put(), freeing it via
remove_port(). find_port_by_vq() also walks portdev->ports under
ports_lock, so if it finds the port still on the list, the list removal,
and therefore the eventual kref_put(), has not happened yet, and taking
a reference at that point is always safe. Without doing so,
in_intr()/out_intr() can be left holding a pointer to a port that
unplug_port() frees on another core before they are done using it.
Both triggers are host-controlled as the host decides when to send the
PORT_REMOVE control message and when to kick the port's data vq. So a
malicious backend could race the two on purpose, without any guest side
cooperation. The freed object is a generic kmalloc allocation containing
a wait_queue_head_t, which in_intr()/out_intr() pass to
wake_up_interruptible() after touching the stale pointer.
wake_up_interruptible() invokes a function pointer read out of the wait
queue's entries. If the freed slab slot is reclaimed with attacker
influenced content before that call, then this is an arbitrary function
call primitive rather than just undefined behaviour.
Take a reference in find_port_by_vq() while still holding ports_lock,
matching find_port_by_devt_in_portdev(), and release it in in_intr() and
out_intr() once they are done with the port.
Signed-off-by: Hari Mishal <harimishal1@gmail.com>
---
drivers/char/virtio_console.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index faef362dae85..1b63afe24e29 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -304,6 +304,12 @@ static struct port *find_port_by_id(struct ports_device *portdev, u32 id)
return port;
}
+/*
+ * Finds a port by the virtqueue and returns a pointer to struct port
+ * with the reference count incremented.
+ *
+ * Callers MUST decrement it when finished.
+ */
static struct port *find_port_by_vq(struct ports_device *portdev,
struct virtqueue *vq)
{
@@ -312,8 +318,10 @@ static struct port *find_port_by_vq(struct ports_device *portdev,
spin_lock_irqsave(&portdev->ports_lock, flags);
list_for_each_entry(port, &portdev->ports, list)
- if (port->in_vq == vq || port->out_vq == vq)
+ if (port->in_vq == vq || port->out_vq == vq) {
+ kref_get(&port->kref);
goto out;
+ }
port = NULL;
out:
spin_unlock_irqrestore(&portdev->ports_lock, flags);
@@ -1706,6 +1714,7 @@ static void out_intr(struct virtqueue *vq)
}
wake_up_interruptible(&port->waitqueue);
+ kref_put(&port->kref, remove_port);
}
static void in_intr(struct virtqueue *vq)
@@ -1723,6 +1732,7 @@ static void in_intr(struct virtqueue *vq)
if (!port->portdev) {
/* Port is being unplugged, ignore further data. */
spin_unlock_irqrestore(&port->inbuf_lock, flags);
+ kref_put(&port->kref, remove_port);
return;
}
port->inbuf = get_inbuf(port);
@@ -1756,6 +1766,8 @@ static void in_intr(struct virtqueue *vq)
if (is_console_port(port) && hvc_poll(port->cons.hvc))
hvc_kick();
+
+ kref_put(&port->kref, remove_port);
}
static void control_intr(struct virtqueue *vq)
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox