linux-kernel - Re: [REGRESSION] Re: [PATCH] Revert "vmgenid: emit uevent when VMGENID updates"

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]

Date: Tue, 23 Apr 2024 08:56:03 +0200
From: Alexander Graf <graf@...zon.com>
To: "Jason A. Donenfeld" <Jason@...c4.com>
CC: <linux-kernel@...r.kernel.org>, <stable@...r.kernel.org>, "Greg
 Kroah-Hartman" <gregkh@...uxfoundation.org>, Linus Torvalds
	<torvalds@...ux-foundation.org>, Lennart Poettering <mzxreary@...inter.de>,
	Babis Chalios <bchalios@...zon.es>, Theodore Ts'o <tytso@....edu>, "Cali,
 Marco" <xmarcalx@...zon.co.uk>, Arnd Bergmann <arnd@...db.de>,
	"rostedt@...dmis.org" <rostedt@...dmis.org>, Christian Brauner
	<brauner@...nel.org>, <linux@...mhuis.info>, <regressions@...ts.linux.dev>,
	"Woodhouse, David" <dwmw@...zon.co.uk>
Subject: Re: [REGRESSION] Re: [PATCH] Revert "vmgenid: emit uevent when
 VMGENID updates"

Hey Jason,

On 23.04.24 03:21, Jason A. Donenfeld wrote:
> Hi Alexander,
>
> The process here seems weirdly aggressive and sneaky.
>
> On 2023-06-19, I wrote that I didn't want to take this route for
> userspace notifications.
>
> Then on 2023-06-28, you wrote to Greg asking him to take it instead of
> me. Nine minutes later, Greg said "yea sure." Then he caught up on the
> thread and some hours later wrote:
>
>> Wait, no, I'm not the maintainer of this, Jason is.  And he already
>> rejected it (and based on the changelog text, I would too), so why are
>> you asking me a month later to take this?
>>
>> Work with the maintainer please, don't try to route around them, you
>> both know better than this.
> Then on 2023-11-14 you wrote to me again asking me to take it, despite
> my earlier reservations not changing in the interim. I didn't have a
> chance to reply.
>
> Then on 2023-11-30, Greg weirdly took it anyway, with zero discussion
> or evidence on the mailing list as to what had happened.
>
> When I noticed what had happened (while working on his driver in the
> process of cleaning up/reworking patches that your Amazon employees
> sent me that needed work), suspicious that you tried to "route around"
> the proper way of getting this done and trick Greg again into taking a
> patch that's not his purview, I asked him wtf happened on IRC:
>
> <gregkh> ugh, sorry, I don't remember that.  I think Alexander talked
> to me at plumbers and said, "hey, please take this virt patch"
> <gregkh> but you are right, you NAKed it in that thread, I forgot
> that, sorry.  Yes, revert it if that's needed.
>
> Greg then ACK'd the revert commit which came with a stable@ marking
> and a Fixes: tag (for 6.8, which isn't very old).
>
> So it looks to me like you twice tried to trick Greg into taking this,
> succeeded the second time, got caught, and now are trying to make a
> regression argument as a means of keeping your sneaky commit in there.
> All of this really _really_ rubs me the wrong way, I have to say.
>
> I don't know what holds more weight here -- the predictable regression
> argument, or the fact that you snuck nack'd changes into a very very
> recent kernel that can still be removed while probably only affecting
> you. But I'm obviously not happy about this.


I'm personally much more concerned about Linux' ability to deal with VM 
Clone events than "my personal use case". The group at Amazon you see 
working on this is working on AWS Lambda which owns the full host and 
guest stack, including Linux on both ends. They could happily patch 
their own Linux kernel. Instead, I have managed to get them to do "the 
right thing" and work with the Linux upstream community to build a 
viable solution that works for everyone.

However, every time they do that, all they get back is vgetrandom() 
arguments which are completely irrelevant to the conversation and 
deteriorate my efforts to get AWS to work *more* rather than less 
upstream. Can we please move this back to a technical discussion and 
based on technical grounds determine why sending a notification to user 
space when a VM was cloned via uevents is even remotely a bad idea?


Thanks,

Alex




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879