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: <0c07a0dc-542a-48da-a286-280d9c02b353@huaweicloud.com>
Date: Mon, 6 May 2024 10:20:10 +0200
From: Jonas Oberhauser <jonas.oberhauser@...weicloud.com>
To: Marc Zyngier <maz@...nel.org>, Zayd Qumsieh <zayd_qumsieh@...le.com>
Cc: Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>,
 Mark Rutland <mark.rutland@....com>, Justin Lu <ih_justin@...le.com>,
 Ryan Houdek <Houdek.Ryan@...-emu.org>, Mark Brown <broonie@...nel.org>,
 Ard Biesheuvel <ardb@...nel.org>, Mateusz Guzik <mjguzik@...il.com>,
 Anshuman Khandual <anshuman.khandual@....com>,
 Oliver Upton <oliver.upton@...ux.dev>, Miguel Luis <miguel.luis@...cle.com>,
 Joey Gouly <joey.gouly@....com>, Christoph Paasch <cpaasch@...le.com>,
 Kees Cook <keescook@...omium.org>, Sami Tolvanen <samitolvanen@...gle.com>,
 Baoquan He <bhe@...hat.com>, Joel Granados <j.granados@...sung.com>,
 Dawei Li <dawei.li@...ngroup.cn>, Andrew Morton <akpm@...ux-foundation.org>,
 Florent Revest <revest@...omium.org>, David Hildenbrand <david@...hat.com>,
 Stefan Roesch <shr@...kernel.io>, Andy Chiu <andy.chiu@...ive.com>,
 Josh Triplett <josh@...htriplett.org>, Oleg Nesterov <oleg@...hat.com>,
 Helge Deller <deller@....de>, Zev Weiss <zev@...ilderbeest.net>,
 Ondrej Mosnacek <omosnace@...hat.com>, Miguel Ojeda <ojeda@...nel.org>,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 Asahi Linux <asahi@...ts.linux.dev>
Subject: Re: [PATCH 0/4] arm64: Support the TSO memory model



Am 5/2/2024 um 3:25 PM schrieb Marc Zyngier:
> although
> someone would need to start thinking of how this particular TSO
> implementation composes with the relaxed memory ordering used outside
> of the VM and show that they actually lead to correct results for
> something such as virtio, for example

I used to think about this problem space. Composing some kinds of memory
models (e.g., Arm and TSO) is easy, others is hard.

I don't know much about virtio, so this may show my naivety, but what
complications could arise from virtio?

Does the "visible behavior" of virtio change depending on the memory
model of the machine it is running on?

At least internally inside virtio it should not cause any problems, since
you are effectively adding some barriers inside some of the virtio threads.
(those that are running in the VM).

But if the VM relies on virtio behaving in a "TSO manner" but its behavior
is more relaxed on e.g. Arm, then that could cause issues.

have fun, jonas


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ