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 --git
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 --git
pport")
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 +--
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_helper.c | 157
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_helper.c | 157
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
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
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
evice 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/
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
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
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;
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
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
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 in
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)...
>
>
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,
> > which mea
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
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
>
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
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
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
>
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
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,
>
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
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
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
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
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
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
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_helper.c | 157
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 --git
c: 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
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 --git
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.
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-devel
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_helper.c | 116
On Mon, Dec 26, 2022 at 03:43:04PM +0100, Jason A. Donenfeld wrote:
> On Mon, Dec 26, 2022 at 03:24:07PM +0100, Jason A. Donenfeld wrote:
> > Hi,
> >
> > I'm currently stumped at the moment, so adding linux-mm@ and x86@. Still
> > working on it though. Details of where
Hi,
I'm currently stumped at the moment, so adding linux-mm@ and x86@. Still
working on it though. Details of where I'm at are below the quote below.
On Sat, Dec 24, 2022 at 05:21:46AM +0100, Jason A. Donenfeld wrote:
> On Sat, Dec 24, 2022 at 04:09:08AM +0100, Jason A. Donenfeld wrote:
>
On Mon, Dec 26, 2022 at 03:24:07PM +0100, Jason A. Donenfeld wrote:
> Hi,
>
> I'm currently stumped at the moment, so adding linux-mm@ and x86@. Still
> working on it though. Details of where I'm at are below the quote below.
>
> On Sat, Dec 24, 2022 at 05:21:46AM +0100, Jason
Hi,
On Wed, Dec 28, 2022 at 11:31:34PM -0800, H. Peter Anvin wrote:
> On December 28, 2022 6:31:07 PM PST, "Jason A. Donenfeld"
> wrote:
> >Hi,
> >
> >Read this message in a fixed width text editor with a lot of columns.
> >
> >On Wed, Dec 28,
Er, .config attached now.
.config
Description: Binary data
On Thu, Dec 29, 2022 at 01:47:49PM +0100, Borislav Petkov wrote:
> On Wed, Dec 28, 2022 at 11:31:34PM -0800, H. Peter Anvin wrote:
> > As far as a crash... that sounds like a big and a pretty serious one at
> > that.
> >
> > Could you let me know what kernel you are using and how *exactly* you
On Wed, Dec 28, 2022 at 03:38:30PM +0100, Jason A. Donenfeld wrote:
> 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_size`, which does not get relocated during the
&
ppe Mathieu-Daudé
Cc: H. Peter Anvin
Cc: Borislav Petkov
Cc: Eric Biggers
Signed-off-by: Jason A. Donenfeld
---
hw/i386/microvm.c | 10
hw/i386/x86.c | 50 +++
hw/nvram/fw_cfg.c | 9 +++
include/hw/i386/microvm.h |
On Fri, Dec 30, 2022 at 6:01 PM Borislav Petkov wrote:
>
> On Fri, Dec 30, 2022 at 04:54:27PM +0100, Jason A. Donenfeld wrote:
> > > Right, with CONFIG_X86_VERBOSE_BOOTUP=y in a guest here, it says:
> > >
> > > early console in extract_kernel
> > > inpu
HELLO H. PETER ANVIN,
E
L
L
O
On Wed, Dec 28, 2022 at 05:30:30PM +0100, Jason A. Donenfeld wrote:
> > Fix looks good, glad you figured out the problem.
>
> I mean, kind of. The solution here sucks, especially given that in the
> worst case, setup_data just gets dropped. I'
On Wed, Dec 28, 2022 at 04:07:13AM +0100, Jason A. Donenfeld wrote:
> On Tue, Dec 27, 2022 at 02:36:54PM +0100, Jason A. Donenfeld wrote:
> > On Mon, Dec 26, 2022 at 05:57:30PM +0100, Jason A. Donenfeld wrote:
> > > On Mon, Dec 26, 2022 at 03:43:04PM +0100, Jason A. Donenfeld wro
caveat is that this only works for images less than around 64
megabytes, so just bail out in that case. This is unfortunate, but I
don't currently have a way of fixing it.
Cc: x...@kernel.org
Signed-off-by: Jason A. Donenfeld
---
hw/i386/x86.c | 30 ++
1 file changed
On Wed, Dec 28, 2022 at 05:02:22PM +0100, Philippe Mathieu-Daudé wrote:
> Hi Jason,
>
> On 28/12/22 15:38, Jason A. Donenfeld wrote:
> > The setup_data links are appended to the compressed kernel image. Since
> > the kernel image is typically loaded at 0x10, setup_data l
On Tue, Dec 27, 2022 at 02:36:54PM +0100, Jason A. Donenfeld wrote:
> On Mon, Dec 26, 2022 at 05:57:30PM +0100, Jason A. Donenfeld wrote:
> > On Mon, Dec 26, 2022 at 03:43:04PM +0100, Jason A. Donenfeld wrote:
> > > On Mon, Dec 26, 2022 at 03:24:07PM +0100, Jason A. Donenfeld
On Sat, Dec 31, 2022 at 02:48:12PM +0100, Borislav Petkov wrote:
> On Sat, Dec 31, 2022 at 02:44:08PM +0100, Jason A. Donenfeld wrote:
> > Are you using patch v1 minus the 62 MiB thing?
>
> No, I want to see the original failure - the one that prompted you to send
>
> http
On Sat, Dec 31, 2022 at 02:40:59PM +0100, Borislav Petkov wrote:
> On Fri, Dec 30, 2022 at 05:06:55PM -0800, H. Peter Anvin wrote:
> > This needs to be something like:
> >
> > kernel_add_identity_map(sd_addr, sd_addr + sizeof(*sd));
> > kernel_add_identity_map(sd_addr + sizeof(*sd),
> >
On Sat, Dec 31, 2022 at 02:35:45PM +0100, Borislav Petkov wrote:
> On Sat, Dec 31, 2022 at 01:54:50PM +0100, Jason A. Donenfeld wrote:
> > Nothing special... `-kernel bzImage` should be enough to do it. Eric
> > reported it, and then I was able to repro trivially. Sure you go
On Fri, Dec 30, 2022 at 07:38:19PM +0100, Jason A. Donenfeld wrote:
> The microvm machine has a gross hack where it fiddles with fw_cfg data
> after the fact. So this hack is updated to account for this appending,
> by reserving some bytes.
This is a little derpy. I'll send a v3 in
On Sat, Dec 31, 2022 at 10:48:16AM +0100, Borislav Petkov wrote:
> On Fri, Dec 30, 2022 at 04:59:30PM +0100, Jason A. Donenfeld wrote:
> > I'll attach a .config file. Apply the patch at the top of this thread to
> > qemu,
>
> Hmm, so the patch at the top of this thread is
On Fri, Dec 30, 2022 at 05:06:55PM -0800, H. Peter Anvin wrote:
>
>
> On 12/30/22 14:10, Jason A. Donenfeld wrote:
> > On Fri, Dec 30, 2022 at 01:58:39PM -0800, H. Peter Anvin wrote:
> >> See the other thread fork. They have identified the problem already.
&g
ppe Mathieu-Daudé
Cc: H. Peter Anvin
Cc: Borislav Petkov
Cc: Eric Biggers
Signed-off-by: Jason A. Donenfeld
---
Changes v2->v3:
- Fix mistakes in string handling.
Changes v1->v2:
- Append setup_data to cmdline instead of kernel image.
hw/i386/microvm.c | 13 ++
hw/i
On Fri, Dec 30, 2022 at 01:58:39PM -0800, H. Peter Anvin wrote:
> See the other thread fork. They have identified the problem already.
Not sure I follow. Is there another thread where somebody worked out why
this 62meg limit was happening?
Note that I sent v2/v3, to fix the original problem in a
Hi,
Read this message in a fixed width text editor with a lot of columns.
On Wed, Dec 28, 2022 at 03:58:12PM -0800, H. Peter Anvin wrote:
> Glad you asked.
>
> So the kernel load addresses are parameterized in the kernel image
> setup header. One of the things that are so parameterized are the
On Sat, Dec 31, 2022 at 03:24:32PM +0100, Borislav Petkov wrote:
> On Sat, Dec 31, 2022 at 02:51:28PM +0100, Jason A. Donenfeld wrote:
> > That failure is unrelated to the ident mapping issue Peter and
> > I discussed. The original failure is described in the commit message:
&g
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
On Mon, Dec 26, 2022 at 05:57:30PM +0100, Jason A. Donenfeld wrote:
> On Mon, Dec 26, 2022 at 03:43:04PM +0100, Jason A. Donenfeld wrote:
> > On Mon, Dec 26, 2022 at 03:24:07PM +0100, Jason A. Donenfeld wrote:
> > > Hi,
> > >
> > > I'm currently stumped at the
1:31:34AM +0200, Jason A. Donenfeld wrote:
> > This reverts 3824e25db1 ("x86: disable rng seeding via setup_data"), but
> > for 7.2 rather than 7.1, now that modifying setup_data is safe to do.
> >
> > Cc: Laurent Vivier
> > Cc: Michael S. Tsirkin
>
On Sat, Dec 24, 2022 at 04:09:08AM +0100, Jason A. Donenfeld wrote:
> Hi Eric,
>
> Replying to you from my telephone, and I'm traveling the next two days,
> but I thought I should mention some preliminary results right away from
> doing some termux compiles:
>
> On Fri,
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
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 patch here. Do not merg
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
>
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 I think be
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
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)
On Wed, Feb 08, 2023 at 04:12:51PM -0500, Michael S. Tsirkin wrote:
> This reverts commit e935b735085dfa61d8e6d276b6f9e7687796a3c7.
>
> Fixes: e935b73508 ("x86: return modified setup_data only if read as memory,
> not as file")
> Signed-off-by: Michael S. Tsirkin
> ---
>
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
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_
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_
On Tue, Feb 07, 2023 at 08:41:16AM +, Dov Murik wrote:
> Recent feature to supply RNG seed to the guest kernel modifies the
> kernel command-line by adding extra data at its end; this breaks
> measured boot with SEV and OVMF, and possibly signed boot.
>
> Specifically SEV doesn't miss this
On Tue, Feb 7, 2023 at 7:31 PM Michael S. Tsirkin wrote:
>
> On Tue, Feb 07, 2023 at 07:17:58PM -0300, Jason A. Donenfeld wrote:
> > On Tue, Feb 07, 2023 at 04:45:19PM -0500, Michael S. Tsirkin wrote:
> > > On Tue, Feb 07, 2023 at 08:41:16AM +, Dov Murik wrote:
&
nge
the re-randomization over to trigger when selecting the cmdline, rather
than the kernel image.
Fixes: eac7a7791bb6 ("x86: don't let decompressed kernel image clobber
setup_data")
Signed-off-by: Jason A. Donenfeld
---
hw/i386/x86.c | 8
1 file changed, 4 insertions(+), 4 deletions
On Tue, Feb 07, 2023 at 07:33:09PM -0300, Jason A. Donenfeld wrote:
> On Tue, Feb 7, 2023 at 7:31 PM Michael S. Tsirkin wrote:
> >
> > On Tue, Feb 07, 2023 at 07:17:58PM -0300, Jason A. Donenfeld wrote:
> > > On Tue, Feb 07, 2023 at 04:45:19PM -0500, Michael S. Tsirkin wr
as changed to
the cmdline file instead, with the sev_enabled() check left out.
Fixes: eac7a7791bb6 ("x86: don't let decompressed kernel image clobber
setup_data")
Reported-by: Tom Lendacky
Signed-off-by: Dov Murik
Signed-off-by: Jason A. Donenfeld
---
hw/i386/x86.c | 4 ++--
1 file c
seed when selecting the cmdline. This short series fixes those up.
Cc: "Michael S. Tsirkin"
Cc: Dov Murik
Cc: Tom Lendacky
Cc: Gerd Hoffmann
Cc: "Daniel P. Berrangé"
Cc: Paolo Bonzini
Cc: Richard Henderson
Dov Murik (1):
x86: don't append setup_data to cmdline for SEV
On Tue, Feb 07, 2023 at 04:45:19PM -0500, Michael S. Tsirkin wrote:
> On Tue, Feb 07, 2023 at 08:41:16AM +, Dov Murik wrote:
> > Recent feature to supply RNG seed to the guest kernel modifies the
> > kernel command-line by adding extra data at its end; this breaks
> > measured boot with SEV
Hi Tom,
On Tue, Feb 7, 2023 at 8:21 PM Tom Lendacky wrote:
>
> On 2/7/23 15:45, Michael S. Tsirkin wrote:
> > On Tue, Feb 07, 2023 at 08:41:16AM +, Dov Murik wrote:
> >> Recent feature to supply RNG seed to the guest kernel modifies the
> >> kernel command-line by adding extra data at its
Lendacky
Cc: Gerd Hoffmann
Cc: Daniel P. Berrangé
Cc: Paolo Bonzini
Cc: Richard Henderson
Cc: H. Peter Anvin
Cc: Philippe Mathieu-Daudé
Cc: Nathan Chancellor
Cc: Borislav Petkov
Cc: Eric Biggers
Signed-off-by: Jason A. Donenfeld
---
hw/i386/microvm.c | 15 ++
hw/i386/x86.c
On Wed, Feb 8, 2023 at 2:54 PM Jason A. Donenfeld wrote:
>
> Hi Nathan (and MST),
>
> On Wed, Feb 8, 2023 at 2:45 PM Nathan Chancellor wrote:
> >
> > Hi Jason,
> >
> > On Fri, Dec 30, 2022 at 11:07:25PM +0100, Jason A. Donenfeld wrote:
> > > The se
On Wed, Feb 08, 2023 at 08:20:17AM -0500, Michael S. Tsirkin wrote:
> On Wed, Feb 08, 2023 at 01:23:48PM +0200, Dov Murik wrote:
> > Hi Michael,
> >
> > On 08/02/2023 11:11, Michael S. Tsirkin wrote:
> > > On Tue, Feb 07, 2023 at 07:33:09PM -0300, Jason A. Donenfe
On Wed, Feb 8, 2023 at 12:49 PM Dov Murik wrote:
> Even if the DTB itself doesn't change and the Guest Owner could somehow add
> it to the expected cmdline to calculate the hash, the current implementation
> adds both the SetupData entry and the dtb itself to the cmdline. The
> SetupData
>
On Wed, Feb 8, 2023 at 12:49 PM Dov Murik wrote:
> /*
>* Add the NUL terminator, some padding for the microvm cmdline fiddling
>* hack, and then align to 16 bytes as a paranoia measure
>*/
> cmdline_size = (strlen(machine->kernel_cmdline) + 1 +
>
On Wed, Feb 8, 2023 at 12:38 PM Tom Lendacky wrote:
>
> On 2/7/23 16:48, Jason A. Donenfeld wrote:
> > From: Dov Murik
> >
> > Modifying the cmdline by appending setup_data breaks measured boot with
> > SEV and OVMF, and possibly signed boot. Previously this w
On Wed, Feb 8, 2023 at 12:26 PM Tom Lendacky wrote:
> However, is the change to the DTB check appropriate?
Yes it is appropriate. The reason is that the first setup_data link is
already conditionalized on sev:
/*
* If we're starting an encrypted VM, it will be OVMF based, which uses the
On Wed, Feb 8, 2023 at 3:13 PM Michael S. Tsirkin wrote:
>
> On Wed, Feb 08, 2023 at 03:08:35PM -0300, Jason A. Donenfeld wrote:
> > All attempts at providing setup_data have been made as an iteration on
> > whatever was there before, stretching back to the original
>
On Wed, Feb 08, 2023 at 01:18:37PM -0500, Michael S. Tsirkin wrote:
> On Wed, Feb 08, 2023 at 03:14:38PM -0300, Jason A. Donenfeld wrote:
> > On Wed, Feb 8, 2023 at 3:13 PM Michael S. Tsirkin wrote:
> > >
> > > On Wed, Feb 08, 2023 at 03:08:35PM -0300, Jason A. D
On Wed, Feb 08, 2023 at 06:31:20PM +, Daniel P. Berrangé wrote:
> On Wed, Feb 08, 2023 at 07:26:05PM +0100, Jason A. Donenfeld wrote:
> > On Wed, Feb 08, 2023 at 01:18:37PM -0500, Michael S. Tsirkin wrote:
> > > On Wed, Feb 08, 2023 at 03:14:38PM -0300, Jason A. Donenfeld wro
Hi Nathan (and MST),
On Wed, Feb 8, 2023 at 2:45 PM Nathan Chancellor wrote:
>
> Hi Jason,
>
> On Fri, Dec 30, 2022 at 11:07:25PM +0100, Jason A. Donenfeld wrote:
> > The setup_data links are appended to the compressed kernel image. Since
> > the kernel image is typi
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
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
301 - 396 of 396 matches
Mail list logo
