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

Hey Edgar, On Wed, Jul 20, 2022 at 9:13 AM Edgar E. Iglesias wrote: > > > On Tue, Jul 19, 2022 at 2:23 PM Jason A. Donenfeld wrote: >> >> If the FDT contains /chosen/rng-seed, then the Linux RNG will use it to >> initialize early. Set this using the usual guest

Re: [PULL 7/9] hw/guest-loader: pass random seed to fdt

Hi Alex, On Thu, Jul 21, 2022 at 08:36:10PM +0100, Alex Bennée wrote: > > Paolo Bonzini writes: > > > From: "Jason A. Donenfeld" > > > > If the FDT contains /chosen/rng-seed, then the Linux RNG will use it to > > initialize early. Set this using t

Re: [PULL 7/9] hw/guest-loader: pass random seed to fdt

Hey Alex, On Fri, Jul 22, 2022 at 10:45:19AM +0100, Alex Bennée wrote: > All the guest-loader does is add the information about where in memory a > guest and/or it's initrd have been placed in memory to the DTB. It's > entirely up to the initial booted code (usually a hypervisor in this > case) to

Re: [PULL 7/9] hw/guest-loader: pass random seed to fdt

Hi Paolo, On Fri, Jul 22, 2022 at 02:04:45PM +0200, Paolo Bonzini wrote: > On 7/21/22 22:20, Jason A. Donenfeld wrote: > >> Why are we inserting this here? The guest-loader is only building on > >> what the machine type has already constructed which in the case of -M > &

Re: [PULL 7/9] hw/guest-loader: pass random seed to fdt

Hi Alex, On Fri, Jul 22, 2022 at 4:37 PM Alex Bennée wrote: > That sounds suspiciously like inventing a new ABI between QEMU and > guests which we generally try to avoid. Well the ABI is just the "rng-seed" param which is part of the DT spec. But I can understand why you might find this use a bi

Re: [PATCH v3] target/s390x: support PRNO_TRNG instruction

Hey David, On Wed, Jul 20, 2022 at 08:41:48PM +0200, David Hildenbrand wrote: > I did not review the doc in detail once again, maybe I get to that later > this week. Did you ever get around to merging this patch? Is it in some tree somewhere? Jason

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

Hi Edgar, On Thu, Jul 21, 2022 at 8:43 PM Edgar E. Iglesias wrote: > Ah OK, Paolo, it would be great if you would take this via your tree! It looks like Paolo never did this. So you might want to queue this somewhere, or bug him to take it, or something. I don't know how this works with 7.1-rc0

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

Hi Richard, On Tue, Jul 26, 2022 at 08:13:09PM -0700, Richard Henderson wrote: > On 7/26/22 18:49, Jason A. Donenfeld wrote: > > Hi Edgar, > > > > On Thu, Jul 21, 2022 at 8:43 PM Edgar E. Iglesias > > wrote: > >> Ah OK, Paolo, it would be great if you would

Re: [PATCH v3] target/s390x: support PRNO_TRNG instruction

Hey Thomas, On Wed, Jul 27, 2022 at 08:32:22AM +0200, Thomas Huth wrote: > On 27/07/2022 03.35, Jason A. Donenfeld wrote: > > Hey David, > > > > On Wed, Jul 20, 2022 at 08:41:48PM +0200, David Hildenbrand wrote: > >> I did not review the doc in detail once ag

Re: [PULL 9/9] hw/i386: pass RNG seed via setup_data entry

Hi, On Tue, Aug 02, 2022 at 11:28:15AM +0800, Xiaoyao Li wrote: > > static void pc_q35_7_0_machine_options(MachineClass *m) > > { > > +PCMachineClass *pcmc = PC_MACHINE_CLASS(m); > > pc_q35_7_1_machine_options(m); > > m->alias = NULL; > > +pcmc->legacy_no_rng_seed = true; >

Re: [PULL 9/9] hw/i386: pass RNG seed via setup_data entry

Hi Xiaoyao, On Tue, Aug 02, 2022 at 10:53:07PM +0800, Xiaoyao Li wrote: > yes, with >= 7.1, pcmc->legacy_no_rng_seed = false by default, and RNG > seed is used. This is intended behavior. Being on by default is basically the whole point of it. Otherwise it's useless. > > > Either way, this sho

Re: [PULL 9/9] hw/i386: pass RNG seed via setup_data entry

Hi Xiaoyao, On Tue, Aug 2, 2022 at 5:06 PM Jason A. Donenfeld wrote: > > Hi Xiaoyao, > > On Tue, Aug 02, 2022 at 10:53:07PM +0800, Xiaoyao Li wrote: > > yes, with >= 7.1, pcmc->legacy_no_rng_seed = false by default, and RNG > > seed is used. > > This is inten

Re: [PATCH v3] target/s390x: support PRNO_TRNG instruction

Hi David, Christian, While this thread has your attention, I thought I'd reiterate my offer in: https://lore.kernel.org/qemu-devel/yueouwzdzbqff...@zx2c4.com/ Do either of you want to "take ownership" of this patch to bring it past the finish line, and I can provide whatever additional crypto cod

Re: [PATCH v3] target/s390x: support PRNO_TRNG instruction

On Wed, Jul 20, 2022 at 02:08:59PM +0200, Jason A. Donenfeld wrote: > +case 114: > +if (r1 & 1 || !r1 || r2 & 1 || !r2) > +tcg_s390_program_interrupt(env, PGM_SPECIFICATION, ra); This is already handled in op_msa. I'm going to remove it for v4.

Re: [PATCH v3] target/s390x: support PRNO_TRNG instruction

On Tue, Aug 02, 2022 at 05:32:26PM +0200, David Hildenbrand wrote: > On 02.08.22 17:28, Jason A. Donenfeld wrote: > > Hi David, Christian, > > > > While this thread has your attention, I thought I'd reiterate my offer in: > > https://lore.kernel.org/qemu-

[PATCH v4 0/2] MSA EXT 5 for s390x

er Cc: Richard Henderson Cc: Cornelia Huck Cc: Harald Freudenberger Cc: Holger Dengler Jason A. Donenfeld (2): target/s390x: support PRNO_TRNG instruction target/s390x: support SHA-512 extensions target/s390x/gen-features.c | 4 + target/s390x/tcg/crypto_helper.c | 146 +++

[PATCH v4 1/2] target/s390x: support PRNO_TRNG instruction

stian Borntraeger Cc: Richard Henderson Cc: Cornelia Huck Cc: Harald Freudenberger Cc: Holger Dengler Signed-off-by: Jason A. Donenfeld --- target/s390x/gen-features.c | 2 ++ target/s390x/tcg/crypto_helper.c | 30 ++ 2 files changed, 32 insertions(+) diff --

[PATCH v4 2/2] target/s390x: support SHA-512 extensions

7;re going for. Cc: Thomas Huth Cc: David Hildenbrand Cc: Christian Borntraeger Cc: Richard Henderson Cc: Cornelia Huck Cc: Harald Freudenberger Cc: Holger Dengler Signed-off-by: Jason A. Donenfeld --- target/s390x/gen-features.c | 2 + target/s390x/tcg/crypto_help

Re: [PATCH v4 2/2] target/s390x: support SHA-512 extensions

Hi David, On Wed, Aug 03, 2022 at 01:55:21PM +0200, David Hildenbrand wrote: > On 02.08.22 21:00, Jason A. Donenfeld wrote: > > In order to fully support MSA_EXT_5, we have to also support the SHA-512 > > special instructions. So implement those. > > > > The implem

[PATCH v5 1/2] target/s390x: support PRNO_TRNG instruction

stian Borntraeger Cc: Richard Henderson Cc: Cornelia Huck Cc: Harald Freudenberger Cc: Holger Dengler Signed-off-by: Jason A. Donenfeld --- target/s390x/gen-features.c | 2 ++ target/s390x/tcg/crypto_helper.c | 30 ++ 2 files changed, 32 insertions(+) diff --

[PATCH v5 2/2] target/s390x: support SHA-512 extensions

7;re going for. Cc: Thomas Huth Cc: David Hildenbrand Cc: Christian Borntraeger Cc: Richard Henderson Cc: Cornelia Huck Cc: Harald Freudenberger Cc: Holger Dengler Signed-off-by: Jason A. Donenfeld --- target/s390x/gen-features.c | 2 + target/s390x/tcg/crypto_help

Re: [PATCH v4 2/2] target/s390x: support SHA-512 extensions

On Wed, Aug 03, 2022 at 02:14:58PM +0200, Jason A. Donenfeld wrote: > s.even = (unsigned long)src; > s.odd = (unsigned long)src_len; > asm volatile( > " lgr 0,%[fc]\n" > " lgr 1,%[pba]\n&qu

Re: [PULL 9/9] hw/i386: pass RNG seed via setup_data entry

Hi Daniel, On Wed, Aug 03, 2022 at 11:52:25AM +0100, Daniel P. Berrangé wrote: > On Tue, Aug 02, 2022 at 05:13:26PM +0200, Jason A. Donenfeld wrote: > > Hi Xiaoyao, > > > > On Tue, Aug 2, 2022 at 5:06 PM Jason A. Donenfeld wrote: > > > > > > Hi Xiaoyao, &g

Re: [PULL 9/9] hw/i386: pass RNG seed via setup_data entry

On Wed, Aug 03, 2022 at 03:11:48PM +0200, Jason A. Donenfeld wrote: > Thanks for the info. Very helpful. Looking into it now. So interestingly, this is not a new issue. If you pass any type of setup data, OVMF appears to be doing something unusual and passing 0x for all the entr

[PATCH RFC v1] hw/i386: place setup_data at fixed place in memory

/i386: add device tree support") Reported-by: Xiaoyao Li Cc: Paolo Bonzini Cc: Richard Henderson Cc: Peter Maydell Cc: Michael S. Tsirkin Cc: Daniel P. Berrangé Cc: Gerd Hoffmann Cc: Ard Biesheuvel Cc: linux-...@vger.kernel.org Signed-off-by: Jason A. Donenfeld --- hw/i386/x86.c | 38 ++

Re: [PULL 9/9] hw/i386: pass RNG seed via setup_data entry

On Wed, Aug 03, 2022 at 03:34:04PM +0200, Jason A. Donenfeld wrote: > On Wed, Aug 03, 2022 at 03:11:48PM +0200, Jason A. Donenfeld wrote: > > Thanks for the info. Very helpful. Looking into it now. > > So interestingly, this is not a new issue. If you pass any type of setup >

[PATCH v6 1/2] target/s390x: support PRNO_TRNG instruction

stian Borntraeger Cc: Richard Henderson Cc: Cornelia Huck Cc: Harald Freudenberger Cc: Holger Dengler Signed-off-by: Jason A. Donenfeld --- target/s390x/gen-features.c | 2 ++ target/s390x/tcg/crypto_helper.c | 30 ++ 2 files changed, 32 insertions(+) diff --

[PATCH 1/2] target/s390x: support PRNO_TRNG instruction

stian Borntraeger Cc: Richard Henderson Cc: Cornelia Huck Cc: Harald Freudenberger Cc: Holger Dengler Signed-off-by: Jason A. Donenfeld --- target/s390x/gen-features.c | 2 ++ target/s390x/tcg/crypto_helper.c | 30 ++ 2 files changed, 32 insertions(+) diff --

[PATCH 2/2] target/s390x: support SHA-512 extensions

7;re going for. Cc: Thomas Huth Cc: David Hildenbrand Cc: Christian Borntraeger Cc: Richard Henderson Cc: Cornelia Huck Cc: Harald Freudenberger Cc: Holger Dengler Signed-off-by: Jason A. Donenfeld --- target/s390x/gen-features.c | 2 + target/s390x/tcg/crypto_help

[PATCH v6 2/2] target/s390x: support SHA-512 extensions

7;re going for. Cc: Thomas Huth Cc: David Hildenbrand Cc: Christian Borntraeger Cc: Richard Henderson Cc: Cornelia Huck Cc: Harald Freudenberger Cc: Holger Dengler Signed-off-by: Jason A. Donenfeld --- target/s390x/gen-features.c | 2 + target/s390x/tcg/crypto_help

Re: [PULL 9/9] hw/i386: pass RNG seed via setup_data entry

Hi Michael, On Wed, Aug 03, 2022 at 06:03:20PM -0400, Michael S. Tsirkin wrote: > On Wed, Aug 03, 2022 at 07:07:52PM +0200, Jason A. Donenfeld wrote: > > On Wed, Aug 03, 2022 at 03:34:04PM +0200, Jason A. Donenfeld wrote: > > > On Wed, Aug 03, 2022 at 03:11:48PM +0200, Jason

Re: [PATCH RFC v1] hw/i386: place setup_data at fixed place in memory

Hi Michael, On Wed, Aug 03, 2022 at 06:25:39PM -0400, Michael S. Tsirkin wrote: > > -/* Offset 0x250 is a pointer to the first setup_data link. */ > > -stq_p(header + 0x250, first_setup_data); > > +if (first_setup_data) { > > +/* Offset 0x250 is a pointer to the first setup

Re: [PATCH RFC v1] hw/i386: place setup_data at fixed place in memory

Hey again, On Thu, Aug 04, 2022 at 12:50:50AM +0200, Jason A. Donenfeld wrote: > Hi Michael, > > On Wed, Aug 03, 2022 at 06:25:39PM -0400, Michael S. Tsirkin wrote: > > > -/* Offset 0x250 is a pointer to the first setup_data link. */ > > > -stq_p(heade

[PATCH v2] hw/i386: place setup_data at fixed place in memory

;hw/i386: add device tree support") Reported-by: Xiaoyao Li Cc: Paolo Bonzini Cc: Richard Henderson Cc: Peter Maydell Cc: Michael S. Tsirkin Cc: Daniel P. Berrangé Cc: Gerd Hoffmann Cc: Ard Biesheuvel Cc: linux-...@vger.kernel.org Signed-off-by: Jason A. Donenfeld

Re: [PATCH v2] hw/i386: place setup_data at fixed place in memory

Hi Ard, On Thu, Aug 4, 2022 at 2:16 PM Ard Biesheuvel wrote: > > On Thu, 4 Aug 2022 at 14:11, Daniel P. Berrangé wrote: > > > > On Thu, Aug 04, 2022 at 02:03:29PM +0200, Jason A. Donenfeld wrote: > > > Hi Daniel, > > > > > > On Thu, Aug 04, 2022

Re: [PATCH v4 2/2] target/s390x: support SHA-512 extensions

Hi, On Thu, Aug 04, 2022 at 10:10:52AM +0200, David Hildenbrand wrote: > > Hm, you don't really want to implement some kind of particial complete. > > Qemu is an emulation and you would have to implement some kind of > > fragmenting this based on machine generation. > > Do we? > > "The > CPU-det

Re: [PATCH v2] hw/i386: place setup_data at fixed place in memory

Hi Daniel, On Thu, Aug 04, 2022 at 10:25:36AM +0100, Daniel P. Berrangé wrote: > Yep, and ultimately the inability to distinguish UEFI vs other firmware > is arguably correct by design, as the QEMU <-> firmware interface is > supposed to be arbitrarily pluggable for any firmware implementation > n

Re: [PATCH v2] hw/i386: place setup_data at fixed place in memory

On Thu, Aug 4, 2022 at 2:17 PM Jason A. Donenfeld wrote: > > Hi Ard, > > On Thu, Aug 4, 2022 at 2:16 PM Ard Biesheuvel wrote: > > > > On Thu, 4 Aug 2022 at 14:11, Daniel P. Berrangé wrote: > > > > > > On Thu, Aug 04, 2022 at 02:03:29PM +0200, J

Re: [PATCH v4 2/2] target/s390x: support SHA-512 extensions

Hi, On Thu, Aug 04, 2022 at 08:56:19AM +0200, Christian Borntraeger wrote: > We do not support the esa390 mode, but the 24/31 bit _addressing_ modes are > totally valid to be used in zarch mode (with sam31 for example). The kernel > does that for example for some diagnoses under z/VM. > Nobody in

Re: [PATCH v2] hw/i386: place setup_data at fixed place in memory

On Thu, Aug 4, 2022 at 2:11 PM Jason A. Donenfeld wrote: > > Hi Laszlo, > > On Thu, Aug 04, 2022 at 01:31:36PM +0200, Laszlo Ersek wrote: > > None of the existing info passing methods seem early enough, generic > > enough, and secure enough (at the same time)... > >

Re: [PULL 9/9] hw/i386: pass RNG seed via setup_data entry

Hi Daniel, On Thu, Aug 4, 2022 at 2:01 PM Daniel P. Berrangé wrote: > > On Thu, Jul 21, 2022 at 06:36:21PM +0200, Paolo Bonzini wrote: > > From: "Jason A. Donenfeld" > > > > Tiny machines optimized for fast boot time generally don't use EFI, > > whic

Re: [PATCH v2] hw/i386: place setup_data at fixed place in memory

Hi Laszlo, On Thu, Aug 4, 2022 at 3:17 PM Laszlo Ersek wrote: > > On 08/04/22 14:47, Jason A. Donenfeld wrote: > > On Thu, Aug 4, 2022 at 2:11 PM Jason A. Donenfeld wrote: > >> > >> Hi Laszlo, > >> > >> On Thu, Aug 04, 2022 at 01:31:36PM +0200

Re: [PATCH] pc: add property for Linux setup_data seed

On Thu, Aug 04, 2022 at 03:13:20PM +0200, Paolo Bonzini wrote: > Using a property makes it possible to use the normal compat property > mechanism instead of ad hoc code; it avoids parameter proliferation > in x86_load_linux; and allows shipping the code even if it is > disabled by default. Strong

Re: [PATCH v2] hw/i386: place setup_data at fixed place in memory

Hi Daniel, On Thu, Aug 4, 2022 at 2:54 PM Daniel P. Berrangé wrote: > > On Thu, Aug 04, 2022 at 02:44:11AM +0200, Jason A. Donenfeld wrote: > > The boot parameter header refers to setup_data at an absolute address, > > and each setup_data refers to the next setup_data at a

Re: [PATCH v2] hw/i386: place setup_data at fixed place in memory

On Thu, Aug 4, 2022 at 3:25 PM Laszlo Ersek wrote: > > On 08/04/22 14:16, Ard Biesheuvel wrote: > > On Thu, 4 Aug 2022 at 14:11, Daniel P. Berrangé wrote: > >> > >> On Thu, Aug 04, 2022 at 02:03:29PM +0200, Jason A. Donenfeld wrote: > >>> Hi Daniel, >

Re: [PATCH v2] hw/i386: place setup_data at fixed place in memory

Hi Laszlo, On Thu, Aug 04, 2022 at 01:31:36PM +0200, Laszlo Ersek wrote: > None of the existing info passing methods seem early enough, generic > enough, and secure enough (at the same time)... Can you look at the v2 patch? It seems to work on every configuration I throw at it. Keep in mind that

Re: [PATCH] pc: add property for Linux setup_data seed

Hi Daniel, On Thu, Aug 04, 2022 at 02:31:06PM +0100, Daniel P. Berrangé wrote: > On Thu, Aug 04, 2022 at 03:20:59PM +0200, Jason A. Donenfeld wrote: > > On Thu, Aug 04, 2022 at 03:13:20PM +0200, Paolo Bonzini wrote: > > > Using a property makes it possible to use the norm

Re: [PATCH 0/2] vmgenid: add generation counter

Hi Babis, On Wed, Aug 03, 2022 at 03:41:45PM +0200, bchal...@amazon.es wrote: > From: Babis Chalios > > VM generation ID exposes a GUID inside the VM which changes every time a > VM restore is happening. Typically, this GUID is used by the guest > kernel to re-seed its internal PRNG. As a result

Re: [PATCH v2] hw/i386: place setup_data at fixed place in memory

Hey Laszlo, On Thu, Aug 04, 2022 at 03:56:54PM +0200, Laszlo Ersek wrote: > - do we want setup_data chaining work generally? > > - or do we want only the random seed injection to stop crashing OVMF guests? Preferably the first - generally. Which brings us to your point: > > Given we only need

[PATCH v3] hw/i386: place setup_data at fixed place in memory

l Cc: Laszlo Ersek Cc: linux-...@vger.kernel.org Signed-off-by: Jason A. Donenfeld --- hw/i386/x86.c | 39 +-- 1 file changed, 21 insertions(+), 18 deletions(-) diff --git a/hw/i386/x86.c b/hw/i386/x86.c index 050eedc0c8..3affef3277 100644 --- a/hw/i386/x86.c +++ b/hw

Re: [PATCH v3] hw/i386: place setup_data at fixed place in memory

Hi Paolo, On Fri, Aug 05, 2022 at 10:10:02AM +0200, Paolo Bonzini wrote: > On 8/5/22 01:04, Jason A. Donenfeld wrote: > > +/* Nothing else uses this part of the hardware mapped region */ > > +setup_data_base = 0xf - 0x1000; > > Isn't this where the BIOS

Re: [PATCH v6 2/2] target/s390x: support SHA-512 extensions

Hi David, On Fri, Aug 05, 2022 at 01:28:18PM +0200, David Hildenbrand wrote: > On 03.08.22 19:15, Jason A. Donenfeld wrote: > > In order to fully support MSA_EXT_5, we have to also support the SHA-512 > > special instructions. So implement those. > > > > The implem

Re: [PATCH v3] hw/i386: place setup_data at fixed place in memory

Hey Paolo, On Fri, Aug 05, 2022 at 02:47:27PM +0200, Jason A. Donenfeld wrote: > Hi Paolo, > > On Fri, Aug 05, 2022 at 10:10:02AM +0200, Paolo Bonzini wrote: > > On 8/5/22 01:04, Jason A. Donenfeld wrote: > > > +/* Nothing else uses this part of th

[PATCH v7 1/2] target/s390x: support SHA-512 extensions

going for. Cc: Thomas Huth Cc: David Hildenbrand Cc: Christian Borntraeger Cc: Richard Henderson Cc: Cornelia Huck Cc: Harald Freudenberger Cc: Holger Dengler Signed-off-by: Jason A. Donenfeld --- target/s390x/gen-features.c | 3 + target/s390x/tcg/crypto_help

[PATCH v7 2/2] target/s390x: support PRNO_TRNG instruction

stian Borntraeger Cc: Richard Henderson Cc: Cornelia Huck Cc: Harald Freudenberger Cc: Holger Dengler Signed-off-by: Jason A. Donenfeld --- target/s390x/gen-features.c | 1 + target/s390x/tcg/crypto_helper.c | 30 ++ 2 files changed, 31 insertions(+) diff --

Re: [PATCH qemu v3] x86: don't let decompressed kernel image clobber setup_data

Hi Michael, Could you queue up this patch and mark it as a fix for 7.2.1? It is a straight-up bug fix for a 7.2 regression that's now affected several users. - It has two Tested-by tags on the thread. - hpa, the maintainer of the kernel side of this, confirmed on one of the various tributary th

Re: [RFC PATCH 0/1] Implement entropy leak reporting for virtio-rng

Hi Babis, Why are you resending this? As I mentioned before, I'm going to move forward in implementing this feature in a way that actually works with the RNG. I'll use your RFC patch as a base, but I think beyond that, I can take it from here. Thanks, Jason

Re: [RFC PATCH 0/1] Implement entropy leak reporting for virtio-rng

On Mon, Apr 3, 2023 at 4:15 PM Jason A. Donenfeld wrote: > > Hi Babis, > > Why are you resending this? As I mentioned before, I'm going to move > forward in implementing this feature in a way that actually works with > the RNG. I'll use your RFC patch as a base, but

Re: [RFC PATCH 0/1] Implement entropy leak reporting for virtio-rng

On Tue, Apr 11, 2023 at 6:19 PM Amit Shah wrote: > > Hey Babis, > > On Mon, 2023-04-03 at 12:52 +0200, Babis Chalios wrote: > > This patchset implements the entropy leak reporting feature proposal [1] > > for virtio-rng devices. > > > > Entropy leaking (as defined in the specification proposal) ty

Re: [PATCH qemu v3] x86: don't let decompressed kernel image clobber setup_data

On Mon, Jan 23, 2023 at 6:12 AM Michael S. Tsirkin wrote: > > On Sun, Jan 22, 2023 at 08:21:30PM -0800, Eric Biggers wrote: > > Hi Michael, > > > > On Tue, Jan 10, 2023 at 12:50:42PM -0500, Michael S. Tsirkin wrote: > > > On Tue, Jan 10, 2023 at 04:34:49P

Re: [PULL 10/56] x86: don't let decompressed kernel image clobber setup_data

On Mon, Jan 30, 2023 at 03:19:59PM -0500, Michael S. Tsirkin wrote: > From: "Jason A. Donenfeld" > > The setup_data links are appended to the compressed kernel image. Since > the kernel image is typically loaded at 0x10, setup_data lives at > `0x10 + compressed_

Re: [PULL 10/56] x86: don't let decompressed kernel image clobber setup_data

On Tue, Jan 31, 2023, 15:55 H. Peter Anvin wrote: > On January 30, 2023 12:19:14 PM PST, "Michael S. Tsirkin" > wrote: > >From: "Jason A. Donenfeld" > > > >The setup_data links are appended to the compressed kernel image. Since > >the kernel

Re: [PULL 10/56] x86: don't let decompressed kernel image clobber setup_data

On Mon, Jan 30, 2023 at 03:19:59PM -0500, Michael S. Tsirkin wrote: > From: "Jason A. Donenfeld" > > The setup_data links are appended to the compressed kernel image. Since > the kernel image is typically loaded at 0x10, setup_data lives at > `0x10 + compressed_

Re: [PATCH] x86: fix q35 kernel measurements broken due to rng seeding

This is already fixed via the patch that MST just sent in his pull. So wait a few days for that to be merged and it'll be all set. No need for this patch here. Do not merge. On Wed, Feb 1, 2023, 08:57 James Bottomley wrote: > The origin commit for rng seeding 67f7e426e5 ("hw/i386: pass RNG seed

Re: [PATCH] x86: fix q35 kernel measurements broken due to rng seeding

This patch is not needed. It is already fixed in a pending pull. Do not merge. On Wed, Feb 1, 2023, 09:57 James Bottomley wrote: > On Wed, 2023-02-01 at 14:35 +, Daniel P. Berrangé wrote: > > On Wed, Feb 01, 2023 at 08:57:10AM -0500, James Bottomley wrote: > > > The origin commit for rng see

Re: [PATCH] x86: fix q35 kernel measurements broken due to rng seeding

23, 10:24 James Bottomley wrote: > On Wed, 2023-02-01 at 10:10 -0500, Jason A. Donenfeld wrote: > > This is already fixed via the patch that MST just sent in his pull. > > So wait a few days for that to be merged and it'll be all set. > > > > No need for this pat

Re: [PATCH] x86: fix q35 kernel measurements broken due to rng seeding

Hi James, On Wed, Feb 1, 2023, 15:39 James Bottomley wrote: > On Wed, 2023-02-01 at 12:51 -0500, Jason A. Donenfeld wrote: > > It's not a secret, but I have so little internet right now that I > > can't even load a webpage, and I'm on my phone, hence the short &g

[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

[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

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

kernel.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

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

kernel.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

[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] 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 the

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/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 t

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

h 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(

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: Thanks

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 big-e

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. It

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) > +{ > + uuid

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 w

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

m Cc: gre...@linuxfoundation.org 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/vi

[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 53

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

RNG's 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/Make

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

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. > Ide

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 exp

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

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

mamm...@redhat.com Cc: ehabk...@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...@linuxfoundat

[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/cha

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

h hands 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

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' argum

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

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 0/2] VM fork detection for RNG

aiya...@microsoft.com Cc: 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 fo

  1   2   3   4   5   >