linux-kernel - Re: [GIT PULL] KVM changes for Linux 6.14

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABgObfaar9uOx7t6vR0pqk6gU-yNOHX3=R1UHY4mbVwRX_wPkA@mail.gmail.com>
Date: Mon, 27 Jan 2025 16:15:01 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, "Michael S. Tsirkin" <mst@...hat.com>, 
	Christian Brauner <brauner@...nel.org>, "Eric W. Biederman" <ebiederm@...ssion.com>, linux-kernel@...r.kernel.org, 
	kvm@...r.kernel.org
Subject: Re: [GIT PULL] KVM changes for Linux 6.14

On Mon, Jan 27, 2025 at 3:10 PM Oleg Nesterov <oleg@...hat.com> wrote:
> On 01/26, Linus Torvalds wrote:
> > On Sun, 26 Jan 2025 at 10:54, Oleg Nesterov <oleg@...hat.com> wrote:
> > >
> > > I don't think we even need to detect the /proc/self/ or /proc/self-thread/
> > > case, next_tid() can just check same_thread_group,
> >
> > That was my thinking yes.
> >
> > If we exclude them from /proc/*/task entirely, I'd worry that it would
> > hide it from some management tool and be used for nefarious purposes
>
> Agreed,
>
> > (even if they then show up elsewhere that the tool wouldn't look at).
>
> Even if we move them from /proc/*/task to /proc ?

Indeed---as long as they show up somewhere, it's not worse than it
used to be. The reason why I'd prefer them to stay in /proc/*/task is
that moving them away at least partly negates the benefits of the
"workers are children of the starter" model. For example it
complicates measuring their cost within the process that runs the VM.
Maybe it's more of a romantic thing than a real practical issue,
because in the real world resource accounting for VMs is done via
cgroups. But unlike the lazy creation in KVM, which is overall pretty
self-contained, I am afraid the ugliness in procfs would be much worse
compared to the benefit, if there's a benefit at all.

> Perhaps, I honestly do not know what will/can confuse userspace more.

At the very least, marking workers as "Kthread: 1" makes sense and
should not cause too much confusion. I wouldn't go beyond that unless
we get more reports of similar issues, and I'm not even sure how
common it is for userspace libraries to check for single-threadedness.

Paolo

> > But as mentioned, maybe this is all more of a hack than what kvm now does.
>
> I don't know. But I will be happy to make a patch if we have a consensus.
>
> Oleg.
>