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
| ||
|
Message-ID: <20220302024608-mutt-send-email-mst@kernel.org> Date: Wed, 2 Mar 2022 02:48:41 -0500 From: "Michael S. Tsirkin" <mst@...hat.com> To: "Jason A. Donenfeld" <Jason@...c4.com> Cc: Laszlo Ersek <lersek@...hat.com>, LKML <linux-kernel@...r.kernel.org>, KVM list <kvm@...r.kernel.org>, QEMU Developers <qemu-devel@...gnu.org>, linux-hyperv@...r.kernel.org, Linux Crypto Mailing List <linux-crypto@...r.kernel.org>, Alexander Graf <graf@...zon.com>, "Michael Kelley (LINUX)" <mikelley@...rosoft.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, adrian@...ity.io, Daniel P. Berrangé <berrange@...hat.com>, Dominik Brodowski <linux@...inikbrodowski.net>, Jann Horn <jannh@...gle.com>, "Rafael J. Wysocki" <rafael@...nel.org>, "Brown, Len" <len.brown@...el.com>, Pavel Machek <pavel@....cz>, Linux PM <linux-pm@...r.kernel.org>, Colm MacCarthaigh <colmmacc@...zon.com>, Theodore Ts'o <tytso@....edu>, Arnd Bergmann <arnd@...db.de> Subject: Re: propagating vmgenid outward and upward On Wed, Mar 02, 2022 at 02:42:37AM -0500, Michael S. Tsirkin wrote: > On Tue, Mar 01, 2022 at 07:37:06PM +0100, Jason A. Donenfeld wrote: > > Hi Michael, > > > > On Tue, Mar 1, 2022 at 6:17 PM Michael S. Tsirkin <mst@...hat.com> wrote: > > > Hmm okay, so it's a performance optimization... some batching then? Do > > > you really need to worry about every packet? Every 64 packets not > > > enough? Packets are after all queued at NICs etc, and VM fork can > > > happen after they leave wireguard ... > > > > Unfortunately, yes, this is an "every packet" sort of thing -- if the > > race is to be avoided in a meaningful way. It's really extra bad: > > ChaCha20 and AES-CTR work by xoring a secret stream of bytes with > > plaintext to produce a ciphertext. If you use that same secret stream > > and xor it with a second plaintext and transmit that too, an attacker > > can combine the two different ciphertexts to learn things about the > > original plaintext. > > So what about the point about packets queued then? You don't fish > packets out of qdisc queues, do you? Oh pls ignore it, I think I got it. Resending same packet is not a problem, producing a new one is. > > But, anyway, it seems like the race is here to stay given what we have > > _currently_ available with the virtual hardware. That's why I'm > > focused on trying to get something going that's the least bad with > > what we've currently got, which is racy by design. How vitally > > important is it to have something that doesn't race in the far future? > > I don't know, really. It seems plausible that that ACPI notifier > > triggers so early that nothing else really even has a chance, so the > > race concern is purely theoretical. But I haven't tried to measure > > that so I'm not sure. > > > > Jason So how about measuring the performance impact of reading the 16 byte vmgenid then? This could be a performance option, too - some people might want extra security, some might not care. And I feel if linux DTRT and reads the 16 bytes then hypervisor vendors will be motivated to improve and add a 4 byte unique one. As long as linux is interrupt driven there's no motivation for change. -- MST
Powered by blists - more mailing lists