[Qemu-devel] Shutting down x86 QEMU with ACPI from Userspace

Hi all, This took a lot of fiddling, so I figured I'd document my findings here in case it helps anybody else. If you don't want to have CONFIG_ACPI in your kernel, but still would like to shutdown QEMU, the following works for the q35 machine type: ioperm(0x604, 2, 1); outw(1 << 13,

[Qemu-devel] [PATCH] hw/arm/virt: support 4 serial ports

actually work. Sending it to the list as inspiration for somebody on the ARM team who might be able to do this more properly. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- hw/arm/virt.c | 45 +++-- 1 file changed, 27 insertions(+), 18 del

Re: [Qemu-devel] [Qemu-arm] [PATCH] hw/arm/virt: support 4 serial ports

Hey Peter, I really do need more serial ports. Two, actually. I'm using qemu on build.wireguard.com for CI. I have normal output come on ttyS0 (ttyAMA0) and then if it's successful, the final step is writing "success" into ttyS1 (ttyAMA1), so that I can confirm with certainty that the tests

Re: [Qemu-devel] [Qemu-arm] [PATCH] hw/arm/virt: support 4 serial ports

On Fri, Dec 8, 2017 at 12:49 PM, Peter Maydell wrote: > Now that the 2.11 release is mostly out of the way, I've been > working through some of my other todo list items so I've > come back to this thread. > > My suggestion is that we should add a second non-secure UART >

Re: [Qemu-devel] [PATCH 2/3] hw/arm/virt: Add another UART to the virt board

In case it's of direct interest in this thread, the ARM results on https://www.wireguard.com/build-status/ are running on a QEMU built with this disgusting cludge: https://א.cc/roJ0gMw3 The patch of this thread is the actually correct way of accomplishing what that cludge does.

Re: [Qemu-devel] [Qemu-arm] [PATCH] hw/arm/virt: support 4 serial ports

Hey folks, In case you're curious, this is the kind of hideous workaround required until this is fixed: https://git.zx2c4.com/WireGuard/commit/?id=2456a56729f7247bf88476317fed0ac822a31e92 Please let me know if you intend to fix this or if you will accept working patches from me for it, or if

Re: [Qemu-devel] [PATCH 2/3] hw/arm/virt: Add another UART to the virt board

Hi Peter, What ever became of this? I still really could use a second UART in the standard configuration. I'm still building with this cludge -- https://א.cc/RXI3ssWV -- in order to run the test suite on build.wireguard.com. Thanks, Jason

Re: [Qemu-devel] [PATCH 2/3] hw/arm/virt: Add another UART to the virt board

On Thu, May 31, 2018 at 10:32 AM, Peter Maydell wrote: > It stalled on the fact that adding the second UART breaks > UEFI images (annoyingly, UEFI iterates through UARTs in > the DTB in the opposite direction to Linux, so if you add > a second UART then it picks that one to use rather than > the

Re: [Qemu-devel] [Qemu-arm] [PATCH] hw/arm/virt: support 4 serial ports

On Thu, Oct 26, 2017 at 4:36 PM, Peter Maydell wrote: > This has *never* been guaranteed or indeed true. It's just happened > to be true for the x86 PC machine and perhaps for some others that > you've been using. For instance, the MIPS boston board only has > one uart.

Re: [Qemu-devel] [Qemu-arm] [PATCH] hw/arm/virt: support 4 serial ports

On Thu, Oct 26, 2017 at 6:34 PM, Peter Maydell wrote: > Reordering it would break existing users of the trustzone uart, > whose command lines would stop working. I thought this was the reason for all of those virt26, virt28,etc types -- people who want stability code

Re: [Qemu-devel] [Qemu-arm] [PATCH] hw/arm/virt: support 4 serial ports

On Thu, Oct 26, 2017 at 3:34 PM, Andrew Jones wrote: > You could make the PL011 user instantiate-able and make the necessary > changes to use the dynamic FDT node generation framework (sysbus-fdt), > and then you'd be able to add as many additional UARTs as you like to >

Re: [Qemu-devel] [Qemu-arm] [PATCH] hw/arm/virt: support 4 serial ports

On Thu, Oct 26, 2017 at 6:41 PM, Peter Maydell wrote: > Those are primarily about migration compatibility -- you should > be able to live migrate a guest from QEMU 2.6's virt-2.6 machine to > QEMU 2.7's virt-2.6 machine. That's a stricter requirement than > the

[Qemu-devel] ARM64 STR Instruction Crash Regression in TCG

Hello, Gcc 7.3 compiles bash's array_flush's dual assignment using: STP X20, X20, [X20,#0x10] But gcc 8.1 compiles it as: STR Q0, [X20,#0x10] Real processors seem okay, and qemu 2.11 seems okay. But qemu 2.12 results in a segfaulting process. I'm pretty sure this is a

Re: [Qemu-devel] [PATCH for-3.0] tcg/i386: Mark xmm registers call-clobbered

Hi Richard, I can confirm this fixes the issue. https://www.wireguard.com/build-status/ is now all green again. Thanks, Jason

Re: [Qemu-devel] [Qemu-arm] more serial ports on arm?

On Tue, Nov 20, 2018 at 11:08 AM Peter Maydell wrote: > It's still stuck, because unconditionally adding a second serial > port to the virt board breaks some commonly used existing guest > code (UEFI + Linux), and it's not clear to me what the best > command line UI is for allowing the user to

[Qemu-devel] more serial ports on arm?

Hey guys, I sort of lost track of the discussion, but what ever happened to adding an extra serial port to the arm virt machine? I'm still carrying around the attached patch to run build.wireguard.com and I'd of course like to see a real solution upstream. Jason diff -ru qemu-3.0.0/hw/arm/virt.c

Re: [PATCH] q800: implement mac rom reset function for BIOS-less mode

On Thu, Jan 2, 2020 at 12:41 PM Laurent Vivier wrote: > > Le 02/01/2020 à 12:10, Laurent Vivier a écrit : > > Le 02/01/2020 à 11:36, Jason A. Donenfeld a écrit : > >> On Linux, calling `reboot(RB_AUTOBOOT);` will result in > >> arch/m68k/mac/misc.c's mac_reset funct

CONFIG_JUMP_LABEL=y on 32-bit x86 leads to intermittent qemu crashes

Hi, Here's an interesting crash I've seen pop up since enabling CONFIG_JUMP_LABEL=y: [4.716238] EIP: secure_tcp_seq+0x1e/0xa0^M [4.716238] Code: c1 e8 46 90 fb ff eb a2 8d 74 26 00 55 89 e5 83 ec 18 89 75 f8 89 c6 0f b7 45 08 89 5d f4 0f b7 d9 89 7d fc 89 d7 89 45 ec 3e <8d> 74 26 00 8b

[PATCH] q800: map reset function to poweroff of some random kernel

there to tinker with it, or something else. Signed-off-by: Jason A. Donenfeld --- hw/m68k/q800.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/m68k/q800.c b/hw/m68k/q800.c index 4ca8678007..bd75dd3141 100644 --- a/hw/m68k/q800.c +++ b/hw/m68k/q800.c @@ -339,6 +339,7 @@ static void q800_init

[PATCH] q800: implement mac rom reset function for BIOS-less mode

trying to reboot. So, this commit adds a very simple implementation at that location, which just writes to via2 to power down. Signed-off-by: Jason A. Donenfeld --- hw/m68k/q800.c | 21 + 1 file changed, 21 insertions(+) diff --git a/hw/m68k/q800.c b/hw/m68k/q800.c index

Re: [PATCH] q800: map reset function to poweroff of some random kernel

Superseded by https://lore.kernel.org/qemu-devel/20200102103644.233370-1-ja...@zx2c4.com , thankfully.

[PATCH v2] q800: implement mac rom reset function for BIOS-less mode

trying to reboot. So, this commit adds a very simple implementation at that location, which just writes to via2 to power down. We also correct the value of ROMBASE while we're at it. Signed-off-by: Jason A. Donenfeld --- hw/m68k/q800.c | 29 - 1 file changed, 28

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

After discussing this offline with Jann a bit, I have a few general comments on the design of this. First, the UUID communicated by the hypervisor should be consumed by the kernel -- added as another input to the rng -- and then userspace should be notified that it should reseed any userspace

[PATCH] sparc: implement addr function

Signed-off-by: Jason A. Donenfeld --- After this lands, somebody will need to update the submodule and prebuilt inside of qemu. forth/device/extra.fs | 6 ++ 1 file changed, 6 insertions(+) diff --git a/forth/device/extra.fs b/forth/device/extra.fs index 9ca6b78..f778f7a 100644 --- a/forth

[PATCH] hw/acpi: specify 64-bit acpi table

SSDTs cannot address 64-bit physical addresses in 32-bit tables, so we increment the revision to '2' so that these larger addresses are addressable. This matters because the DSDT revision represents the maximum capability of all other SSDTs. This is also what arm does. Signed-off-by: Jason

Re: [PATCH] hw/acpi: specify 64-bit acpi table

On Tue, Jun 16, 2020 at 2:16 AM Igor Mammedov wrote: > On Mon, 15 Jun 2020 18:36:54 -0600 > "Jason A. Donenfeld" wrote: > > SSDTs cannot address 64-bit physical addresses in 32-bit tables, so we > please clarify what accesses waht within tables (i.e. be more concr

Re: [PATCH] hw/acpi: specify 64-bit acpi table

> > increment the revision to '2' so that these larger addresses are > > addressable. This matters because the DSDT revision represents the > > maximum capability of all other SSDTs. This is also what arm does. > it was keept at 1 for compat reasons with WindowsXP. > by now it is long time EOL, so

[PATCH] linux-user: add TARGET_SO_{DOMAIN,PROTOCOL}

These were defined for other platforms but mistakenly left out of mips and generic, so this commit adds them to the places missing. Then it makes them be translated in getsockopt. Signed-off-by: Jason A. Donenfeld --- linux-user/generic/sockbits.h | 3 +++ linux-user/mips/sockbits.h| 2

Re: propagating vmgenid outward and upward

Hi Alex, On Wed, Mar 9, 2022 at 3:10 AM Alexander Graf wrote: > > The vmgenid driver basically works, though it is racy, because that ACPI > > notification can arrive after the system is already running again. This > > > I believe enough people already pointed out that this assumption is >

Re: [PATCH RFC v1 1/2] random: add mechanism for VM forks to reinitialize crng

On 2/24/22, Eric Biggers wrote: > I think we should be removing cases where the base_crng key is changed > directly > besides extraction from the input_pool, not adding new ones. Why not > implement > this as add_device_randomness() followed by crng_reseed(force=true), where > the > 'force'

Re: [PATCH RFC v1 1/2] random: add mechanism for VM forks to reinitialize crng

Hey Eric, On Thu, Feb 24, 2022 at 2:27 AM Eric Biggers wrote: > > On Thu, Feb 24, 2022 at 01:54:54AM +0100, Jason A. Donenfeld wrote: > > On 2/24/22, Eric Biggers wrote: > > > I think we should be removing cases where the base_crng key is changed > > > directly

[PATCH v3 2/2] virt: vmgenid: introduce driver for reinitializing RNG on VM fork

0,0 +1,121 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Virtual Machine Generation ID driver + * + * Copyright (C) 2022 Jason A. Donenfeld . All Rights Reserved. + * Copyright (C) 2020 Amazon. All rights reserved. + * Copyright (C) 2018 Red Hat Inc. All rights reserved. + */ + +#include +#

Re: [PATCH RFC v1 0/2] VM fork detection for RNG

Hi Lazlo, Thanks for your reply. On Thu, Feb 24, 2022 at 9:23 AM Laszlo Ersek wrote: > QEMU's related design is documented in > . I'll link to this document on the 2/2 patch next to the other ones. > "they can also use the data

Re: [PATCH RFC v1 0/2] VM fork detection for RNG

Hi Alex, Strangely your message never made it to me, and I had to pull this out of Lore after seeing Daniel's reply to it. I wonder what's up. On Thu, Feb 24, 2022 at 09:53:59AM +0100, Alexander Graf wrote: > The main problem with VMGenID is that it is inherently racy. There will > always be a

Re: [PATCH RFC v1 0/2] VM fork detection for RNG

On Thu, Feb 24, 2022 at 11:56 AM Daniel P. Berrangé wrote: > IIRC this part of the QEMU doc was making an implicit assumption > about the way QEMU is to be used by mgmt apps doing snapshots. > > Instead of using the 'loadvm' command on the existing running QEMU > process, the doc seems to tacitly

[PATCH v3 0/2] VM fork detection for RNG

sthem...@microsoft.com Cc: wei@kernel.org Cc: de...@microsoft.com Cc: li...@dominikbrodowski.net Cc: ebigg...@kernel.org Cc: a...@kernel.org Cc: ja...@google.com Cc: gre...@linuxfoundation.org Cc: ty...@mit.edu Jason A. Donenfeld (2): random: add mechanism for VM forks to reinitialize crng

[PATCH v3 1/2] random: add mechanism for VM forks to reinitialize crng

of the next 256 bits. Cc: Dominik Brodowski Cc: Theodore Ts'o Cc: Jann Horn Cc: Eric Biggers Signed-off-by: Jason A. Donenfeld --- drivers/char/random.c | 50 +- include/linux/random.h | 1 + 2 files changed, 36 insertions(+), 15 deletions(-) diff --git

Re: [PATCH v7 2/2] drivers/virt: vmgenid: add vm generation id driver

Hey again, On Tue, Feb 22, 2022 at 10:24 PM Jason A. Donenfeld wrote: > This thread seems to be long dead, but I couldn't figure out what > happened to the ideas in it. I'm specifically interested in this part: > > On Wed, Feb 24, 2021 at 9:48 AM Adrian Catangiu wrote: >

Re: [PATCH v7 2/2] drivers/virt: vmgenid: add vm generation id driver

Hi Adrian, This thread seems to be long dead, but I couldn't figure out what happened to the ideas in it. I'm specifically interested in this part: On Wed, Feb 24, 2021 at 9:48 AM Adrian Catangiu wrote: > +static void vmgenid_acpi_notify(struct acpi_device *device, u32 event) > +{ > +

Re: [PATCH v4] virt: vmgenid: introduce driver for reinitializing RNG on VM fork

Hi Alex, On Fri, Feb 25, 2022 at 04:37:43PM +0100, Alexander Graf wrote: > I believe "VMGENID" was for the firecracker prototype that Adrian built > back then, yeah. Matching on _HID for this is a rat hole unfortunately, > so let's see what the ACPI patch gets us :). Thanks. I'll add a comment

Re: [PATCH v4] virt: vmgenid: introduce driver for reinitializing RNG on VM fork

On Fri, Feb 25, 2022 at 3:12 PM Jason A. Donenfeld wrote: > > Hi Alex, > > On Fri, Feb 25, 2022 at 02:57:38PM +0100, Alexander Graf wrote: > > > +static const struct acpi_device_id vmgenid_ids[] = { > > > + { "VMGENID", 0 }, > > >

Re: [PATCH v4] virt: vmgenid: introduce driver for reinitializing RNG on VM fork

On Fri, Feb 25, 2022 at 04:16:27PM +0100, Ard Biesheuvel wrote: > > > I just booted up a Windows VM, and it looks like Hyper-V uses > > > "Hyper_V_Gen_Counter_V1", which is also quite long, so we can't really > > > HID match on that either. > > > > > > Yes, due to the same problem. I'd really

Re: [PATCH v4] virt: vmgenid: introduce driver for reinitializing RNG on VM fork

Hi again, On Fri, Feb 25, 2022 at 04:31:02PM +0100, Alexander Graf wrote: > >> Please expose the vmgenid via /sysfs so that user space even remotely has a > >> chance to check if it's been cloned. > > Export it how? And why, who would care? > You can just As mentioned in

Re: [PATCH v4] virt: vmgenid: introduce driver for reinitializing RNG on VM fork

Hi Alex, On Fri, Feb 25, 2022 at 04:22:54PM +0100, Alexander Graf wrote: > I don't understand the rush here. This had been sitting on the ML for 1 > year - and now suddenly talking the match through properly and getting > VMGenID spec compatible matching support into the ACPI core is a >

Re: [PATCH v4] virt: vmgenid: introduce driver for reinitializing RNG on VM fork

Hi Alex, Missed this remark before: On Fri, Feb 25, 2022 at 02:57:38PM +0100, Alexander Graf wrote: > Please expose the vmgenid via /sysfs so that user space even remotely > has a chance to check if it's been cloned. No. Did you read the 0/2 cover letter? I'll quote it for you here: > As a

Re: [PATCH v4] virt: vmgenid: introduce driver for reinitializing RNG on VM fork

Hi Alex, On Fri, Feb 25, 2022 at 04:15:59PM +0100, Alexander Graf wrote: > I'm not talking about a notification interface - we've gone through > great length on that one in the previous submission. What I'm more > interested in is *any* way for user space to read the current VM Gen ID. > The

Re: [PATCH v4] virt: vmgenid: introduce driver for reinitializing RNG on VM fork

On Fri, Feb 25, 2022 at 03:18:43PM +0100, Alexander Graf wrote: > > I recall this part of the old thread. From what I understood, using > > "VMGENID" + "QEMUVGID" worked /well enough/, even if that wasn't > > technically in-spec. Ard noted that relying on _CID like that is > > technically an ACPI

[PATCH RFC v1 0/2] VM fork detection for RNG

rg Cc: ty...@mit.edu Jason A. Donenfeld (2): random: add mechanism for VM forks to reinitialize crng drivers/virt: add vmgenid driver for reinitializing RNG drivers/char/random.c | 58 ++ drivers/virt/Kconfig | 8 +++ drivers/virt/Makefile | 1 + drivers/

Re: [PATCH v7 2/2] drivers/virt: vmgenid: add vm generation id driver

On Tue, Feb 22, 2022 at 11:17 PM Jason A. Donenfeld wrote: > Well I cleaned up this v7 and refactored it into something along the > lines of what I'm thinking. I don't yet know enough about this general > problem space to propose the patch and I haven't tested it either A little furt

[PATCH RFC v1 1/2] random: add mechanism for VM forks to reinitialize crng

(), for that. Cc: Theodore Ts'o Cc: Jann Horn Signed-off-by: Jason A. Donenfeld --- drivers/char/random.c | 58 ++ include/linux/random.h | 1 + 2 files changed, 59 insertions(+) diff --git a/drivers/char/random.c b/drivers/char/random.c index 536237a0f073

[PATCH RFC v1 2/2] drivers/virt: add vmgenid driver for reinitializing RNG

newly added add_vmfork_randomness() function. This driver builds on prior work from Adrian Catangiu at Amazon, and it is my hope that that team can resume maintenance of this driver. Cc: Adrian Catangiu Signed-off-by: Jason A. Donenfeld --- drivers/virt/Kconfig | 8 +++ drivers/virt/Makefile |

Re: [PATCH RFC v1 0/2] VM fork detection for RNG

On Wed, Feb 23, 2022 at 2:12 PM Jason A. Donenfeld wrote: > second patch is the reason this is just an RFC: it's a cleanup of the > ACPI driver from last year, and I don't really have much experience > writing, testing, debugging, or maintaining these types of drivers. > Ideally this

Re: [PATCH RFC v1 2/2] drivers/virt: add vmgenid driver for reinitializing RNG

Adding the Hyper-V people to this: On Wed, Feb 23, 2022 at 2:13 PM Jason A. Donenfeld wrote: > > VM Generation ID is a feature from Microsoft, described at > <https://go.microsoft.com/fwlink/?LinkId=260709>, and supported by > Hyper-V and QEMU. Its usage is described

Re: [PATCH RFC v1 0/2] VM fork detection for RNG

On Wed, Feb 23, 2022 at 5:08 PM Jason A. Donenfeld wrote: > > On Wed, Feb 23, 2022 at 2:12 PM Jason A. Donenfeld wrote: > > second patch is the reason this is just an RFC: it's a cleanup of the > > ACPI driver from last year, and I don't really have much experience &g

Re: propagating vmgenid outward and upward

Hi Greg, On Tue, Mar 1, 2022 at 7:01 PM Greg KH wrote: > A notifier block like this makes sense, but why tie onto the PM_ stuff? > This isn't power management issues, it's a system-wide change that I am > sure others will want to know about that doesn't reflect any power > changes. > > As much

Re: propagating vmgenid outward and upward

On Tue, Mar 1, 2022 at 8:41 PM Greg KH wrote: > > On Tue, Mar 01, 2022 at 07:24:11PM +0100, Jason A. Donenfeld wrote: > > Hi Greg, > > > > On Tue, Mar 1, 2022 at 7:01 PM Greg KH wrote: > > > A notifier block like this makes sense, but why tie onto the PM_ stuff?

Re: propagating vmgenid outward and upward

Hi Laszlo, On Tue, Mar 01, 2022 at 05:15:21PM +0100, Laszlo Ersek wrote: > > If we had a "pull" model, rather than just expose a 16-byte unique > > identifier, the vmgenid virtual hardware would _also_ expose a > > word-sized generation counter, which would be incremented every time the > >

Re: propagating vmgenid outward and upward

Hi Michael, On Tue, Mar 1, 2022 at 6:17 PM Michael S. Tsirkin 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

propagating vmgenid outward and upward

Hey folks, Having finally wrapped up development of the initial vmgenid driver, I thought I'd pull together some thoughts on vmgenid, notification, and propagating, from disjointed conversations I've had with a few of you over the last several weeks. The basic problem is: VMs can be cloned,

Re: propagating vmgenid outward and upward

Hi Michael, On Tue, Mar 01, 2022 at 11:21:38AM -0500, Michael S. Tsirkin wrote: > > If we had a "pull" model, rather than just expose a 16-byte unique > > identifier, the vmgenid virtual hardware would _also_ expose a > > word-sized generation counter, which would be incremented every time the >

Re: propagating vmgenid outward and upward

Hey again, On Tue, Mar 01, 2022 at 04:42:47PM +0100, Jason A. Donenfeld wrote: > For (B), it's a little bit trickier. But I think our options follow the > same rubric. We can expose a generation counter in the vDSO, with > semantics akin to the extern integer I described above. Or

Re: propagating vmgenid outward and upward

Hey Michael, Thanks for the benchmark. On Wed, Mar 2, 2022 at 9:30 AM Michael S. Tsirkin wrote: > So yes, the overhead is higher by 50% which seems a lot but it's from a > very small number, so I don't see why it's a show stopper, it's not by a > factor of 10 such that we should sacrifice

Re: propagating vmgenid outward and upward

Hi Michael, On Wed, Mar 02, 2022 at 07:58:33AM -0500, Michael S. Tsirkin wrote: > > There's also the atomicity aspect, which I think makes your benchmark > > not quite accurate. Those 16 bytes could change between the first and > > second word (or between the Nth and N+1th word for N<=3 on

Re: propagating vmgenid outward and upward

Hi Michael, On Wed, Mar 2, 2022 at 3:46 PM Michael S. Tsirkin wrote: > I just don't see how "value changed while it was read" is so different > from "value changed one clock after it was read". Since we don't detect > the latter I don't see why we should worry about the former. The "barrier"

Re: propagating vmgenid outward and upward

Hi Michael, On Wed, Mar 02, 2022 at 10:20:25AM -0500, Michael S. Tsirkin wrote: > So writing some code: > > 1: > put plaintext in a buffer > put a key in a buffer > put the nonce for that encryption in a buffer > > if vm gen id != stored vm gen id > stored

Re: propagating vmgenid outward and upward

Hi Michael, On Wed, Mar 02, 2022 at 11:22:46AM -0500, Michael S. Tsirkin wrote: > > Because that 16 byte read of vmgenid is not atomic. Let's say you read > > the first 8 bytes, and then the VM is forked. > > But at this point when VM was forked plaintext key and nonce are all in > buffer, and

Re: [PATCH v4] virt: vmgenid: introduce driver for reinitializing RNG on VM fork

On Fri, Feb 25, 2022 at 1:53 PM Greg KH wrote: > > On Fri, Feb 25, 2022 at 01:48:48PM +0100, Jason A. Donenfeld wrote: > > +static struct acpi_driver acpi_driver = { > > + .name = "vmgenid", > > + .ids = vmgenid_ids, > > +

Re: [PATCH v4] virt: vmgenid: introduce driver for reinitializing RNG on VM fork

Hi Alex, On Fri, Feb 25, 2022 at 02:57:38PM +0100, Alexander Graf wrote: > > +static const struct acpi_device_id vmgenid_ids[] = { > > + { "VMGENID", 0 }, > > + { "QEMUVGID", 0 }, > > > According to the VMGenID spec[1], you can only rely on _CID and _DDN for > matching. They both

[PATCH v2 0/2] VM fork detection for RNG

abk...@redhat.com Cc: b...@skyportsystems.com Cc: m...@redhat.com Cc: k...@microsoft.com Cc: haiya...@microsoft.com Cc: sthem...@microsoft.com Cc: wei@kernel.org Cc: de...@microsoft.com Cc: li...@dominikbrodowski.net Cc: a...@kernel.org Cc: ja...@google.com Cc: gre...@linuxfoundation.org Cc: ty...@mit.edu

[PATCH v2 2/2] virt: vmgenid: introduce driver for reinitializing RNG on VM fork

the new UUID to the RNG. This driver builds on prior work from Adrian Catangiu at Amazon, and it is my hope that that team can resume maintenance of this driver. Cc: Adrian Catangiu Cc: Dominik Brodowski Cc: Ard Biesheuvel Signed-off-by: Jason A. Donenfeld --- drivers/virt/Kconfig | 9

[PATCH v2 1/2] random: add mechanism for VM forks to reinitialize crng

(), for that. Cc: Dominik Brodowski Cc: Theodore Ts'o Cc: Jann Horn Signed-off-by: Jason A. Donenfeld --- drivers/char/random.c | 53 ++ include/linux/random.h | 1 + 2 files changed, 54 insertions(+) diff --git a/drivers/char/random.c b/drivers/char/random.c

Re: [PATCH v3 2/2] virt: vmgenid: introduce driver for reinitializing RNG on VM fork

On Fri, Feb 25, 2022 at 12:52 PM Michael S. Tsirkin wrote: > > > if VIRT_DRIVERS > > > > > > +config VMGENID > > > + tristate "Virtual Machine Generation ID driver" > > > + default y > > > > Please make this default m - this code can run as a module and the > > feature it relies on

[PATCH v4] virt: vmgenid: introduce driver for reinitializing RNG on VM fork

ing that's how it ends up when handed to the RNG in the end. Cc: Adrian Catangiu Cc: Daniel P. Berrangé Cc: Dominik Brodowski Cc: Ard Biesheuvel Cc: Greg Kroah-Hartman Reviewed-by: Laszlo Ersek Signed-off-by: Jason A. Donenfeld --- Changes v3->v4: - Add this driver to MAINTAINERS, per Ard's

Re: [PATCH v3 1/2] random: add mechanism for VM forks to reinitialize crng

On Fri, Feb 25, 2022 at 12:26 PM Ard Biesheuvel wrote: > > On Thu, 24 Feb 2022 at 14:39, Jason A. Donenfeld wrote: > > > > When a VM forks, we must immediately mix in additional information to > > the stream of random output so that two forks or a rollback don't >

Re: [PATCH v3 2/2] virt: vmgenid: introduce driver for reinitializing RNG on VM fork

ier: GPL-2.0 > > +/* > > + * Virtual Machine Generation ID driver > > + * > > + * Copyright (C) 2022 Jason A. Donenfeld . All Rights > > Reserved. > > + * Copyright (C) 2020 Amazon. All rights reserved. > > + * Copyright (C) 2018 Red Hat Inc. All rights rese

Re: propagating vmgenid outward and upward

Hey Alex, On Thu, Mar 10, 2022 at 12:18 PM Alexander Graf wrote: > I agree on the slightly racy compromise and that it's a step into the > right direction. Doing this is a no brainer IMHO and I like the proc > based poll approach. Alright. I'm going to email a more serious patch for that in the

[PATCH qemu] m68k: virt: pass RNG seed via bootinfo block

l.org/lkml/20220625153841.143928-1-ja...@zx2c4.com/ Signed-off-by: Jason A. Donenfeld --- This requires this trivial cleanup commit first: https://lore.kernel.org/qemu-devel/20220625152318.120849-1-ja...@zx2c4.com/ hw/m68k/bootinfo.h | 16 hw/m

[PATCH] m68k: use correct variable name in boot info string macro

Every time this macro is used, the caller is passing in "parameters_base", so this bug wasn't spotted. But the actual macro variable name is "base", so use that instead. Signed-off-by: Jason A. Donenfeld --- hw/m68k/bootinfo.h | 2 +- 1 file changed, 1 insertion(+), 1 del

[PATCH v2] hw/openrisc: virt: pass random seed to fdt

If the FDT contains /chosen/rng-seed, then the Linux RNG will use it to initialize early. Set this using the usual guest random number generation function. This is confirmed to successfully initialize the RNG on Linux 5.19-rc2. Cc: Stafford Horne Signed-off-by: Jason A. Donenfeld --- Changes v1

Re: [PATCH] hw/riscv: virt: pass random seed to fdt

Hi Alistair, On 7/8/22, Alistair Francis wrote: >> > but I think that's just the way things go unfortunately. > > Hmm... That's a pain. So there is a bug in older kernels where they > won't boot if we specify this? > > Can you point to the fixes? Actually, in trying to reproduce this, I don't

[PATCH v2] hw/i386: pass RNG seed to e820 setup table

with the Linux patch in the link. Link: https://lore.kernel.org/lkml/20220708113907.891319-1-ja...@zx2c4.com/ Signed-off-by: Jason A. Donenfeld --- hw/i386/x86.c| 19 ++- include/standard-headers/asm-x86/bootparam.h | 1 + 2 files changed, 15 insertions(+), 5

Re: [PATCH] hw/i386: pass RNG seed to e820 setup table

Hi Daniel, On Fri, Jul 8, 2022 at 2:00 PM Daniel P. Berrangé wrote: > > On Thu, Jun 30, 2022 at 01:37:17PM +0200, Jason A. Donenfeld wrote: > > Tiny machines optimized for fast boot time generally don't use EFI, > > which means a random seed has to be supplied some other way

[PATCH] hw/arm/virt: dt: add rng-seed property

Cc: Peter Maydell Signed-off-by: Jason A. Donenfeld --- hw/arm/virt.c | 40 include/hw/arm/virt.h | 1 + 2 files changed, 41 insertions(+) diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 097238faa7..8a3436a370 100644 --- a/hw/arm/virt.c +++ b/hw/

Re: [PATCH] hw/arm/virt: dt: add rng-seed property

On 6/27/22, Peter Maydell wrote: > On Mon, 27 Jun 2022 at 17:07, Jason A. Donenfeld wrote: >> >> In 60592cfed2 ("hw/arm/virt: dt: add kaslr-seed property"), the >> kaslr-seed property was added, but the equally as important rng-seed >> property was forgotten

Re: [PATCH v2] hw/arm/virt: dt: add rng-seed property

Hi Peter, On Mon, Jul 04, 2022 at 03:42:55PM +0100, Peter Maydell wrote: > We should also add a section to docs/about/deprecated.rst > noting that the old name is deprecated in favour of the new one. > I'll fold that in when I add the patch to target-arm.next, to > save you doing a respin:

Re: [PATCH] hw/riscv: virt: pass random seed to fdt

Hi Alistair, On Wed, Jun 29, 2022 at 4:09 AM Alistair Francis wrote: > I have a Linux 5.8 test case that is failing due to this patch. Before I started fixing things in random.c, there were a lot of early boot bugs with the RNG in Linux. I backported the fixes for these to all stable kernels.

Re: [PATCH v2 03/11] goldfish_rtc: Add endianness property

On Tue, Jul 05, 2022 at 05:40:31AM +0900, Stafford Horne wrote: > riscv{LE}--->goldfish_rtc{LE} > mips-longsoon3{LE}-->goldfish_rtc{LE} > openrisc{BE}>goldfish_rtc{LE} (LE to BE conversion done in > driver) > m68k{BE}>goldfish_rtc{BE} (only

Re: [PATCH] hw/arm/virt: dt: add rng-seed property

On Wed, Jun 29, 2022 at 11:18:23AM +0100, Alex Bennée wrote: > > Peter Maydell writes: > > > On Tue, 28 Jun 2022 at 19:45, Jason A. Donenfeld wrote: > >> > >> On 6/27/22, Jason A. Donenfeld wrote: > >> > On 6/27/22, Peter Maydell wrote

Re: [PATCH] hw/riscv: virt: pass random seed to fdt

On 7/11/22, Alistair Francis wrote: > On Fri, Jul 8, 2022 at 7:56 PM Jason A. Donenfeld wrote: >> >> Hi Alistair, >> >> On 7/8/22, Alistair Francis wrote: >> >> >> > but I think that's just the way things go unfortunately. >> > >> &

[PATCH v2] m68k: virt: pass RNG seed via bootinfo block

l.org/lkml/20220626111509.330159-1-ja...@zx2c4.com/ Based-on: <20220625152318.120849-1-ja...@zx2c4.com> Reviewed-by: Laurent Vivier Signed-off-by: Jason A. Donenfeld --- hw/m68k/bootinfo.h | 16 hw/m68k/virt.c | 7 +

Re: [PATCH] hw/riscv: virt: pass random seed to fdt

Hi Alistair, On Mon, Jul 11, 2022 at 01:36:28PM +1000, Alistair Francis wrote: > On Mon, Jul 11, 2022 at 10:28 AM Jason A. Donenfeld wrote: > > > > On 7/11/22, Alistair Francis wrote: > > > On Fri, Jul 8, 2022 at 7:56 PM Jason A. Donenfeld wrote: > > >> >

[PATCH v3] hw/i386: pass RNG seed via setup_data entry

bootloaders. The linked commit shows the upstream kernel implementation. Link: https://git.kernel.org/tip/tip/c/68b8e9713c8 Cc: Laurent Vivier Cc: Philippe Mathieu-Daudé Signed-off-by: Jason A. Donenfeld --- hw/i386/x86.c| 19 ++- include/standard-headers

[PATCH] hw/ppc: pass random seed to fdt

platforms, spapr and e500, just as is done on other architectures with paravirt hardware. Cc: Daniel Henrique Barboza Signed-off-by: Jason A. Donenfeld --- hw/ppc/e500.c | 5 + hw/ppc/spapr.c | 5 + 2 files changed, 10 insertions(+) diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c index

[PATCH qemu] target/s390x: support PRNO_TRNG instruction

Freudenberger Cc: Holger Dengler Signed-off-by: Jason A. Donenfeld --- target/s390x/gen-features.c | 2 ++ target/s390x/tcg/crypto_helper.c | 23 +++ 2 files changed, 25 insertions(+) diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c index

Re: [PATCH] hw/arm/virt: dt: add rng-seed property

Hi Alex, On Wed, Jun 29, 2022 at 04:24:20PM +0100, Alex Bennée wrote: > > The code is exactly the same for kaslr-seed and rng-seed. Everytime > > there's some kaslr-seed thing, there is now the same rng-seed thing. > > The duplication is annoying but specs are specs - where is this written > by

Re: [PATCH] hw/arm/virt: dt: add rng-seed property

On Thu, Jun 30, 2022 at 10:15:29AM +0100, Peter Maydell wrote: > On Wed, 29 Jun 2022 at 16:56, Jason A. Donenfeld wrote: > > On Wed, Jun 29, 2022 at 04:24:20PM +0100, Alex Bennée wrote: > > > Given the use case for the dtb-kaslr-seed knob I wonder if we should > >

[PATCH v2] hw/arm/virt: dt: add rng-seed property

en changes the name of the disabling option to reflect that this has more to do with randomness vs determinism, rather than something particular about kaslr. Cc: Peter Maydell Signed-off-by: Jason A. Donenfeld --- docs/system/arm/virt.rst | 17 ++-- hw/arm/virt.c

[PATCH] hw/i386: pass RNG seed to e820 setup table

with the Linux patch in the link. Link: https://lore.kernel.org/lkml/20220630113300.1892799-1-ja...@zx2c4.com/ Signed-off-by: Jason A. Donenfeld --- hw/i386/x86.c| 19 ++- include/standard-headers/asm-x86/bootparam.h | 1 + 2 files changed, 15 insertions(+), 5

Re: [PATCH] hw/arm/virt: dt: add rng-seed property

On 6/27/22, Jason A. Donenfeld wrote: > On 6/27/22, Peter Maydell wrote: >> On Mon, 27 Jun 2022 at 17:07, Jason A. Donenfeld wrote: >>> >>> In 60592cfed2 ("hw/arm/virt: dt: add kaslr-seed property"), the >>> kaslr-seed property was added, but

Re: [PATCH] hw/riscv: virt: pass random seed to fdt

Hey Alistair, On Tue, Jul 05, 2022 at 03:09:09AM +0200, Jason A. Donenfeld wrote: > Hi Alistair, > > On Wed, Jun 29, 2022 at 4:09 AM Alistair Francis wrote: > > I have a Linux 5.8 test case that is failing due to this patch. > > Before I started fixing things in rando

  1   2   3   4   >