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

On February 2, 2023 7:17:01 AM PST, James Bottomley wrote: >On Thu, 2023-02-02 at 07:03 -0800, H. Peter Anvin wrote: >[...] >> NAK. We need to fix the actual problem of the kernel stomping on >> memory it shouldn't, not paper around it. > >This is a first boot situation, n

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

On February 2, 2023 7:17:01 AM PST, James Bottomley wrote: >On Thu, 2023-02-02 at 07:03 -0800, H. Peter Anvin wrote: >[...] >> NAK. We need to fix the actual problem of the kernel stomping on >> memory it shouldn't, not paper around it. > >This is a first boot situation, n

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

On February 2, 2023 7:17:01 AM PST, James Bottomley wrote: >On Thu, 2023-02-02 at 07:03 -0800, H. Peter Anvin wrote: >[...] >> NAK. We need to fix the actual problem of the kernel stomping on >> memory it shouldn't, not paper around it. > >This is a first boot situation, n

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

On February 2, 2023 6:38:12 AM PST, James Bottomley wrote: >On Wed, 2023-02-01 at 15:48 -0500, Jason A. Donenfeld wrote: >[...] >> But it sounds like you might now have a concrete suggestion on >> something even better. I'm CCing hpa, as this is his wheelhouse, and >> maybe you two can divise the

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

On January 31, 2023 1:22:43 PM PST, "Jason A. Donenfeld" wrote: >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" >> > &g

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

uld have to >be changed around, incurring more complexity. In contrast, using cmdline >is simple and doesn't interfere with anything. > >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 rese

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

On 12/31/22 20:55, Mika Penttilä wrote: If decompression does clobber the data, then we *also* need to figure out why that is. There are basically three possibilities: 1. If physical KASLR is NOT used:  a. The boot loader doesn't honor the kernel safe area properly;  b. Somewhere in

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

On 12/31/22 10:22, Jason A. Donenfeld wrote: 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

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

On 12/31/22 19:21, H. Peter Anvin wrote: Alternatively, setup_data could be relocated, the boot param protocol could be bumped, and then QEMU could conditionalized it's use of setup_data based on that protocol version. That'd work, but seems a bit more involved. I think this is at least

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

On 12/31/22 11:00, Borislav Petkov wrote: On Sat, Dec 31, 2022 at 07:22:47PM +0100, Jason A. Donenfeld wrote: So with that understanding confirmed, I'm confused at your surprise that hpa's unrelated fix to the different issue didn't fix this issue. No surprise there - I used a qemu variant

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

On 12/30/22 17:06, H. Peter Anvin wrote TThe 62 MB limit mentioned in boot.rst is unrelated, and only applies to very, very old kernels that used INT 15h, AH=88h to probe memory. I am 88% sure this was fixed long before setup_data was created, as it was created originally to carry e820

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

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. Not sure I follow. Is there another thread where somebody worked out why this 62meg limit was happening? Note

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

On December 30, 2022 11:54:11 AM PST, Borislav Petkov wrote: >On Fri, Dec 30, 2022 at 06:07:24PM +0100, Jason A. Donenfeld wrote: >> Look closer at the boot process. The compressed image is initially at >> 0x10, but it gets relocated to a safer area at the end of >> startup_64: > >That is the

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

On December 30, 2022 7:59:30 AM PST, "Jason A. Donenfeld" wrote: >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, >> > >> >

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

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, 2022 at 03:58:12PM -0800, H. Peter Anvin wrote: >> Glad you asked. >> >> So the kernel loa

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

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, 2022 at 03:58:12PM -0800, H. Peter Anvin wrote: >> Glad you asked. >> >> So the kernel loa

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

On 12/28/22 15:58, H. Peter Anvin wrote: On December 28, 2022 8:57:54 AM PST, "Jason A. Donenfeld" wrote: 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 sol

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

On December 28, 2022 8:57:54 AM PST, "Jason A. Donenfeld" wrote: >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

Re: [Qemu-devel] Qemu baseline requirements/portability?

On 6/5/19 12:55 PM, H. Peter Anvin wrote: > Hi, > > I am writing some code I'm hoping will be able to make it into Qemu, but I > can't seem to find what the baseline portability requirements are. I'm > specifically wondering about newer POSIX features like openat(), which see

[Qemu-devel] Qemu baseline requirements/portability?

Hi, I am writing some code I'm hoping will be able to make it into Qemu, but I can't seem to find what the baseline portability requirements are. I'm specifically wondering about newer POSIX features like openat(), which seems to be used in the 9p filesystem and nowhere else, and what version of

Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to allow up to 4G initrd

On 11/11/18 10:19 PM, Ingo Molnar wrote: > >> In part as a result of this exchange I have spent some time thinking >> about the boot protocol and its dependencies, and there is, in fact, a >> much more serious problem that needs to be addressed: it is not >> currently possible in a

Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to allow up to 4G initrd

On 11/11/18 10:19 PM, Ingo Molnar wrote: > > I might be a bit dense early in the morning, but could you elaborate? > What do you mean by mapping all data areas? > Heh. I need to pack for LPC and get some sleep before my flight lest I'll be denser than depleted uranium; I'll write an

Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to allow up to 4G initrd

On 11/11/18 8:56 PM, Ingo Molnar wrote: > >> Also note that the ext_ramdisk_image and ext_ramdisk_size are part of >> struct boot_params as opposed to struct setup_header, which means that >> they are not supported when entering via the 16-bit BIOS entry point, >> and I am willing to bet that

Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to allow up to 4G initrd

On 11/9/18 5:40 AM, Li Zhijian wrote: > Just noticed that there is a field xloadflags at recent protocol >   60 Protocol 2.12:  (Kernel 3.8) Added the xloadflags field and > extension fields >   61 to struct boot_params for loading bzImage and ramdisk >   62 above

Re: [Qemu-devel] [PATCH] slirp: support dynamic block size for TFTP transfers

On 11/21/16 11:45, Hervé Poussineau wrote: > The blocksize option is defined in RFC 1783. > We now support block sizes between 1 and 1432 bytes, instead of 512 only. It ought to be 1476: Ethernet MTU = 1500, minus a minimum of 20 bytes for an IPv4 header and 4 for a TFTP header. Some bootloaders

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

On April 18, 2016 4:26:24 AM PDT, "Daniel P. Berrange" <berra...@redhat.com> wrote: >On Mon, Apr 18, 2016 at 01:07:40PM +0200, Hubert Kario wrote: >> On Monday 18 April 2016 02:46:19 H. Peter Anvin wrote: >> > Another thing that really needs to be addre

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

On April 18, 2016 2:28:42 AM PDT, "Daniel P. Berrange" <berra...@redhat.com> wrote: >On Fri, Apr 15, 2016 at 08:56:59AM -0700, H. Peter Anvin wrote: >> On April 15, 2016 3:41:34 AM PDT, Cole Robinson <crobi...@redhat.com> >wrote: >> >Libvirt currently

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

On 04/16/16 01:31, Paolo Bonzini wrote: > > Right, but there's always the point about people that use heterogeneous > hosts and cannot pass rdrand/rdseed to the guest. For these, we should > add a QEMU driver that uses rdrand/rdseed, and thus decouples virtio-rng > from the host /dev/*

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

On 04/16/16 01:31, Paolo Bonzini wrote: > > Right, but there's always the point about people that use heterogeneous > hosts and cannot pass rdrand/rdseed to the guest. For these, we should > add a QEMU driver that uses rdrand/rdseed, and thus decouples virtio-rng > from the host /dev/*

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

On April 15, 2016 9:10:44 AM PDT, Hubert Kario wrote: >On Friday 15 April 2016 09:47:51 Eric Blake wrote: >> On 04/15/2016 04:41 AM, Cole Robinson wrote: >> > Libvirt currently rejects using host /dev/urandom as an input >source >> > for a virtio-rng device. The only accepted

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

On April 15, 2016 9:10:44 AM PDT, Hubert Kario wrote: >On Friday 15 April 2016 09:47:51 Eric Blake wrote: >> On 04/15/2016 04:41 AM, Cole Robinson wrote: >> > Libvirt currently rejects using host /dev/urandom as an input >source >> > for a virtio-rng device. The only accepted

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

On April 15, 2016 3:41:34 AM PDT, Cole Robinson wrote: >Libvirt currently rejects using host /dev/urandom as an input source >for a >virtio-rng device. The only accepted sources are /dev/random and >/dev/hwrng. >This is the result of discussions on qemu-devel around when the

Re: [Qemu-devel] [PATCH v3 1/4] KVM/X86: Fix xsave cpuid exposing bug

exposing bug EBX of cpuid(0xD, 0) is dynamic per XCR0 features enable/disable. Bit 63 of XCR0 is reserved for future expansion. Signed-off-by: Liu Jinsong jinsong@intel.com Peter, can I have your acked-by on this? Yes. Acked-by: H. Peter Anvin h...@linux.intel.com

Re: [Qemu-devel] [RFC PATCH 1/3] target-i386: Add 486sx, old486, and old486sx CPU models

On 03/25/2013 01:56 PM, Eduardo Habkost wrote: It needs to be possible to fix bugs It is possible to fix them today: just write a compat function or add a global variable that is handled by cpu_x86_init(), and call it from the pc-1.3 machine-type init function. See

Re: [Qemu-devel] [PATCH 2/3] X86, mpx: Intel MPX definition

No... we always ask for cpufeature.h patches separately because they sometimes cause conflicts between branches. Borislav Petkov b...@alien8.de wrote: On Sat, Dec 07, 2013 at 02:52:55AM +0800, Qiaowei Ren wrote: Signed-off-by: Qiaowei Ren qiaowei@intel.com Signed-off-by: Xudong Hao

Re: [Qemu-devel] [PATCH v3 0/2] Intel MPX feature support at Qemu

On 12/06/2013 08:27 AM, Liu, Jinsong wrote: Eric Blake wrote: On 12/06/2013 07:06 AM, Liu, Jinsong wrote: Intel has released Memory Protection Extensions (MPX) recently. Please refer to http://download-software.intel.com/sites/default/files/319433-015.pdf These 2 patches are version2 to

Re: [Qemu-devel] [PATCH 3/3] X86, mpx: Intel MPX xstate feature definition

On 12/06/2013 05:46 AM, Borislav Petkov wrote: I'm guessing this and the struct lwp_struct above is being added so that you can have the LWP XSAVE area size? If so, you don't need it: LWP XSAVE area is 128 bytes at offset 832 according to my manuals so I'd guess having a u8 lwp_area[128]

Re: [Qemu-devel] [PATCH v2 3/3] X86, mpx: Intel MPX xstate feature definition

On 12/06/2013 09:35 AM, Paolo Bonzini wrote: Sorry for the back-and-forth, but I think this and the removal of XSTATE_FLEXIBLE (perhaps XSTATE_LAZY?) makes your v2 worse than v1. Since Peter already said the same, please undo these changes. Also, how is XSTATE_EAGER used? Should MPX be

Re: [Qemu-devel] [PATCH v2 3/3] X86, mpx: Intel MPX xstate feature definition

On 12/06/2013 12:05 PM, Liu, Jinsong wrote: Since Peter already said the same, please undo these changes. Also, how is XSTATE_EAGER used? Should MPX be disabled when xsaveopt is disabled on the kernel command line? (Liu, how would this affect the KVM patches, too?) Paolo Currently

Re: [Qemu-devel] [PATCH v2 3/3] X86, mpx: Intel MPX xstate feature definition

On 12/06/2013 05:16 PM, Ren, Qiaowei wrote: Jinsong think that both kvm and host depend on these feature definition header file, so we firstly submit these files depended on. Yes, but we can't turn on the feature without proper protection. Either way, they are now in tip:x86/cpufeature.

Re: [Qemu-devel] [PATCH 1/4] X86: Intel MPX definiation

On 12/05/2013 08:08 AM, Paolo Bonzini wrote: Il 02/12/2013 17:43, Liu, Jinsong ha scritto: From fbfa537f690eca139a96c6b2636ab5130bf57716 Mon Sep 17 00:00:00 2001 From: Liu Jinsong jinsong@intel.com Date: Fri, 29 Nov 2013 01:27:00 +0800 Subject: [PATCH 1/4] X86: Intel MPX definiation

Re: [Qemu-devel] Would virtio support 64 bit address for vring virtqueue?

On 08/28/2013 10:35 AM, Anthony Liguori wrote: Yes, it was originally designed with the 16TB limit in mind. PCI doesn't support 64-bit PIO operations so it would have required a high/low register and additional magic. s/PCI/x86/ Additional magic is needed only if atomic changes are

Re: [Qemu-devel] [RFC] sanitize memory on system reset

Only on a real 286. At least since 486 the legacy switch has been INIT, not RESET. Alexander Graf ag...@suse.de wrote: Am 14.06.2013 um 08:56 schrieb Christian Borntraeger borntrae...@de.ibm.com: On 13/06/13 13:56, Anthony Liguori wrote: Markus Armbruster arm...@redhat.com writes:

Re: [Qemu-devel] [Patch] fix /proc/self/maps output

On 03/29/2013 09:01 AM, Christophe Lyon wrote: Add a space at end of line when there is no filename to print, to conform to linux kernel format. Signed-off-by: Christophe Lyon christophe.l...@linaro.org --- linux-user/syscall.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [Qemu-devel] [RFC PATCH 1/3] target-i386: Add 486sx, old486, and old486sx CPU models

On 03/28/2013 12:15 PM, Aurelien Jarno wrote: This really looks like Linux kernel specific. I haven't been able to test on a real machine, but the documentation I have found suggest that without and x87 FPU, the FPU instructions are simply ignored. The common way to detect an FPU is

Re: [Qemu-devel] [RFC PATCH 1/3] target-i386: Add 486sx, old486, and old486sx CPU models

On 03/28/2013 12:15 PM, Aurelien Jarno wrote: This really looks like Linux kernel specific. I haven't been able to test on a real machine, but the documentation I have found suggest that without and x87 FPU, the FPU instructions are simply ignored. The common way to detect an FPU is

Re: [Qemu-devel] [RFC PATCH 1/3] target-i386: Add 486sx, old486, and old486sx CPU models

Qemu is absolutely horrid at modeling corner cases. Rob Landley r...@landley.net wrote: On 03/28/2013 03:12:11 PM, H. Peter Anvin wrote: On 03/28/2013 12:15 PM, Aurelien Jarno wrote: This really looks like Linux kernel specific. I haven't been able to test on a real machine

Re: [Qemu-devel] [RFC PATCH 3/3] mc146818rtc: export the timezone information

On 03/25/2013 02:05 AM, Paolo Bonzini wrote: Interesting, do you have SeaBIOS and/or OVMF patches for this? Not at this point. -hpa

Re: [Qemu-devel] [RFC PATCH 1/3] target-i386: Add 486sx, old486, and old486sx CPU models

On 03/25/2013 08:15 AM, Igor Mammedov wrote: Such changes have been rejected in the past (e.g., n270 Atom). I personally wouldn't object to 486 changes, but I guess it should rather be handled via Igor's CPU static properties that I have in my review queue: The .model value would be set to 8

Re: [Qemu-devel] [RFC PATCH 1/3] target-i386: Add 486sx, old486, and old486sx CPU models

On 03/25/2013 12:05 PM, Eduardo Habkost wrote: On Mon, Mar 25, 2013 at 11:44:30AM -0700, H. Peter Anvin wrote: On 03/25/2013 08:15 AM, Igor Mammedov wrote: Such changes have been rejected in the past (e.g., n270 Atom). I personally wouldn't object to 486 changes, but I guess it should rather

Re: [Qemu-devel] [RFC PATCH 1/3] target-i386: Add 486sx, old486, and old486sx CPU models

Now, all this said... if the only objection is the change of model number for 486 then I suggest just dropping that. -hpa

Re: [Qemu-devel] [RFC PATCH 1/3] target-i386: Add 486sx, old486, and old486sx CPU models

On 03/25/2013 01:56 PM, Eduardo Habkost wrote: It needs to be possible to fix bugs It is possible to fix them today: just write a compat function or add a global variable that is handled by cpu_x86_init(), and call it from the pc-1.3 machine-type init function. See

Re: [Qemu-devel] [RFC PATCH 1/3] target-i386: Add 486sx, old486, and old486sx CPU models

Low priority ping on this patchset...? -hpa

Re: [Qemu-devel] virtio-rng and fd passing

in the guest!) and it does make sense for a very thin host. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.

Re: [Qemu-devel] virtio-rng and fd passing

On 02/28/2013 04:36 PM, Eric Blake wrote: Stefan Berger and I discovered on IRC that virtio-rng is unable to support fd passing. We attempted: qemu-system-x86_64 ... -add-fd set=4,fd=34,opaque=RDONLY:/dev/urandom -object

Re: [Qemu-devel] 9pfs segfaults on chmod(special)

On 02/28/2013 04:24 AM, M. Mohan Kumar wrote: By default 9p.u is used, you can override by that mount -t 9p -otrans=virtio,version=9p2000.L tag /mnt Shouldn't we change that default? -hpa

Re: [Qemu-devel] virtio-rng and fd passing

The guest kernel already provides the PRNG itself. We have been over this... Stefan Berger stef...@linux.vnet.ibm.com wrote: On 03/01/2013 02:37 PM, H. Peter Anvin wrote: On 02/28/2013 04:36 PM, Eric Blake wrote: Stefan Berger and I discovered on IRC that virtio-rng is unable to support fd

Re: [Qemu-devel] [SeaBIOS] [RFC PATCH] Distinguish between reset types

that version of the patch, with a suitable comment. Right... the soft reset described above is really INIT, which isn't even a reset in modern CPUs (it couldn't be, it has to preserve caches) but more of a special interrupt. It is also used during multiprocessor init. -hpa -- H. Peter

[Qemu-devel] [RFC PATCH 2/3] target-i386: Raise #UD on accessing non-existent control registers

From: H. Peter Anvin h...@zytor.com If we touch control registers that don't exist, either read or write, raise the #UD exception (undefined opcode). This is useful for testing booting on old CPUs. CR4 is assumed to exist if and only if there are CPU features other than the FPU defined

[Qemu-devel] [RFC PATCH 3/3] mc146818rtc: export the timezone information

From: H. Peter Anvin h...@zytor.com There is no standard method for storing timezone information associated with the classic PC/AT RTC, however, there are standard methods in ACPI (Time and Alarm Device) and EFI (GetTime/SetTime) for getting this information. Since these are abstract methods

[Qemu-devel] [RFC PATCH 1/3] target-i386: Add 486sx, old486, and old486sx CPU models

From: H. Peter Anvin h...@zytor.com Add models for 486SX, and pre-CPUID versions of the 486 (DX SX). Change the model number for the standard 486DX to a model which actually had CPUID. Note: these models are fairly vestigial, for example most of the FPU operations still work; only F*ST[CS]W

Re: [Qemu-devel] [edk2] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM

On 02/14/2013 12:41 PM, Laszlo Ersek wrote: ). cpu_reset() [target-i386/helper.c] sets CS:IP to f000:fff0, which is the exact address of... reset_vector() in SeaBIOS. This would be a bug, but it isn't quite true. If you look at x86_cpu_reset() you will note that it sets the code segment

Re: [Qemu-devel] [SeaBIOS] [edk2] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM

-Kbyte range. That is presumably a 286 compatibility hack -- the 286 had 24 address lines. I doubt anyone gives a hoot about it, and neither EDK2 nor SeaBIOS should care. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.

Re: [Qemu-devel] [PATCH] target-i386: n270 can MOVBE

MOVBE. This is needed when booting 3.8 and later linux kernels built with the MATOM target because we require MOVBE in order to boot properly now. Cc: H. Peter Anvin h...@zytor.com Cc: Richard Henderson r...@twiddle.net Signed-off-by: Borislav Petkov b...@suse.de --- Right, so I

Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support

in newer CPUs to correct this. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.

Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support

On 10/30/2012 02:05 AM, Paolo Bonzini wrote: Either you're not reading what I wrote, or you're confusing me with someone else. My apologies, you are indeed correct. I misinterpreted your emails, probably because I got you confused with someone else. I *never* mentioned passing /dev/urandom,

Re: [Qemu-devel] [PATCH 0/8] add paravirtualization hwrng support (v2)

. If RDRAND is available in the guest it should be used directly if rngd is new enough, but since virtio-rng has been in the kernel since 2008 there still might be some guests which could use such an implementation without having been RDRAND-enabled. -hpa -- H. Peter Anvin, Intel Open Source

Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support

the PRNG in host space. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.

Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support

/random, is all I care about at this time. There is always time to change defaults to something better. Your logic are roughly on the level with the people who caused the Debian bug. You are proposing something utterly reckless. Sorry, please stop. -hpa -- H. Peter Anvin, Intel

Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support

On 10/29/2012 01:45 AM, Paolo Bonzini wrote: Il 26/10/2012 22:29, H. Peter Anvin ha scritto: This is surreal. Output from /dev/hwrng turns into output for /dev/random... it us guaranteed worse; period, end of story. Isn't that exactly what happens in bare-metal? hwrng - rngd - random

Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support

be an option to don't start the guest until X bytes of entropy have been gathered. Overall, I want to emphasize that we don't want to try solve generic problems in virtualization space... resource constraints on /dev/random is a generic host OS issue for example. -hpa -- H. Peter

Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support

PRNGs don't create entropy. Period. The guest will run its own PRNG. Anthony Liguori aligu...@us.ibm.com wrote: H. Peter Anvin h...@zytor.com writes: On 10/26/2012 08:42 AM, Anthony Liguori wrote: Is /dev/random even appropriate to feed rngd? rngd needs _a lot_ of entropy to even start

Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support

with an outline for what we can do to improve the current situation. It is challenging to deal with the patanoia crowd at the same time. Paolo Bonzini pbonz...@redhat.com wrote: Il 26/10/2012 18:09, H. Peter Anvin ha scritto: a) it means that the guest *has* to run rngd or a similar engine

Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support

That statement is pretty toxic... I wonder where it came from. It is at best horribly misleading and actively encourages dangerous behaviours even for the cases where it isn't actively wrong. Paolo Bonzini pbonz...@redhat.com wrote: Il 26/10/2012 21:07, H. Peter Anvin ha scritto

Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support

On 10/26/2012 12:51 PM, Paolo Bonzini wrote: Il 26/10/2012 21:07, H. Peter Anvin ha scritto: This is surreal. Output from /dev/hwrng turns into output for /dev/random... it us guaranteed worse; period, end of story. Isn't that exactly what happens in bare-metal? hwrng - rngd - random

[Qemu-devel] [PATCH] x86: Implement SMEP and SMAP

From: H. Peter Anvin h...@linux.intel.com This patch implements Supervisor Mode Execution Prevention (SMEP) and Supervisor Mode Access Prevention (SMAP) for x86. The purpose of the patch, obviously, is to help kernel developers debug the support for those features. A fair bit of the code

Re: [Qemu-devel] [PATCH] x86: Implement SMEP and SMAP

On 09/26/2012 12:50 PM, Anthony Liguori wrote: The patch looks good except for these two chunks. This would break live migration from a new QEMU to an old one because CPUs are currently not versioned. If you just remove these two chunks, the patch can be applied and you can still test

[Qemu-devel] [PATCH v2] x86: Implement SMEP and SMAP

From: H. Peter Anvin h...@linux.intel.com This patch implements Supervisor Mode Execution Prevention (SMEP) and Supervisor Mode Access Prevention (SMAP) for x86. The purpose of the patch, obviously, is to help kernel developers debug the support for those features. A fair bit of the code

Re: [Qemu-devel] [PATCH 07/22] target-i386: convert cpuid features into properties

On 09/26/2012 01:32 PM, Igor Mammedov wrote: + +static void x86_cpuid_get_feature(Object *obj, Visitor *v, void *opaque, + const char *name, Error **errp) +{ +X86CPU *cpu = X86_CPU(obj); +CPUX86State *env = cpu-env; +bool value = true; +

Re: [Qemu-devel] [PATCH v3 0/1] virtio-rng: hardware random number generator

: /dev/random in the guest will behave like (a very expensive version of) /dev/urandom from a cryptographic point of view. The right interface to the host kernel, therefore, is /dev/random. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak

Re: [Qemu-devel] [PATCH v3 0/1] virtio-rng: hardware random number generator

protocol. Anyway, this is on my list for 1.3. The series just needs some light dusting before resubmission. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.

Re: [Qemu-devel] [PATCH v3 0/1] virtio-rng: hardware random number generator

Right, obviously. However, under no circumstances should /dev/urandom be used! Amit Shah amit.s...@redhat.com wrote: On (Sun) 16 Sep 2012 [13:42:46], H. Peter Anvin wrote: On 06/19/2012 11:59 PM, Amit Shah wrote: Hello, Here's the 3rd iteration of the virtio-rng device. This update just

Re: [Qemu-devel] x86, nops settings result in kernel crash

On 08/16/2012 11:53 AM, Alan Cox wrote: Yes, if I remove the break statement (introduced by this commit), it works fine. What version of qemu is this - do we have qemu bug here I wonder. Also, is it 32 or 64 bits? -hpa

[Qemu-devel] Re: [PATCH 5/6] Add support for a USB audio device model

On 10/28/2010 1:01 AM, Gerd Hoffmann wrote: On 10/27/10 19:13, H. Peter Anvin wrote: On 10/27/2010 9:04 AM, Gerd Hoffmann wrote: This brings a usb audio device to qemu. Output only, fixed at 16bit stereo @ 48 Hz. Based on a patch from H. Peter Anvinh...@linux.intel.com Please don't

[Qemu-devel] Re: [PATCH 5/6] Add support for a USB audio device model

On 10/28/2010 1:01 AM, Gerd Hoffmann wrote: On 10/27/10 19:13, H. Peter Anvin wrote: On 10/27/2010 9:04 AM, Gerd Hoffmann wrote: This brings a usb audio device to qemu. Output only, fixed at 16bit stereo @ 48 Hz. Based on a patch from H. Peter Anvinh...@linux.intel.com Please don't

[Qemu-devel] Re: [PATCH 5/6] Add support for a USB audio device model

On 10/28/2010 1:01 AM, Gerd Hoffmann wrote: On 10/27/10 19:13, H. Peter Anvin wrote: On 10/27/2010 9:04 AM, Gerd Hoffmann wrote: This brings a usb audio device to qemu. Output only, fixed at 16bit stereo @ 48 Hz. Based on a patch from H. Peter Anvinh...@linux.intel.com Please don't

Re: [Qemu-devel] Hitting 29 NIC limit

On 10/14/2010 05:57 AM, Anthony Liguori wrote: I've always been sceptical of this. When physical systems have a large number of NICs, it's via multiple functions, not a bunch of PCI bridges. Actually a lot of multiport PCI cards are in fact single or dual NICs behind PCI bridges.

[Qemu-devel] Re: [PATCH] [RFC] Add support for a USB audio device model

will never work. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

On 10/12/2010 12:06 PM, Gleb Natapov wrote: This is true to some extent -- there is some standard content, and some further can be described via ACPI tables. However, my point was mostly that it is an existing model for nonvolatile storage which also works on hardware (and is vastly simpler

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

On 10/13/2010 12:17 PM, H. Peter Anvin wrote: The ACPI specification recognizes three interfaces as standard: PC/AT (64 bytes, even though 128 bytes is available on a lot of platforms), PIIX4 (256 bytes), and Dallas Semiconductor (256 bytes or more). The interface for the latter isn't well

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

On 10/13/2010 01:00 PM, H. Peter Anvin wrote: On 10/13/2010 12:17 PM, H. Peter Anvin wrote: The ACPI specification recognizes three interfaces as standard: PC/AT (64 bytes, even though 128 bytes is available on a lot of platforms), PIIX4 (256 bytes), and Dallas Semiconductor (256 bytes

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

On 10/12/2010 01:01 AM, Gleb Natapov wrote: On Mon, Oct 11, 2010 at 02:15:26PM -0700, H. Peter Anvin wrote: I don't disagree. I think the best thing to do is to let SeaBIOS create a boot order table that contains descriptive information and then advertise that to QEMU. QEMU can then try

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

On real hardware it is shared between BIOS and the OS, actually. Gleb Natapov g...@redhat.com wrote: On Tue, Oct 12, 2010 at 09:33:16AM -0700, H. Peter Anvin wrote: On 10/12/2010 01:01 AM, Gleb Natapov wrote: On Mon, Oct 11, 2010 at 02:15:26PM -0700, H. Peter Anvin wrote: I don't disagree

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

On 10/12/2010 10:41 AM, Gleb Natapov wrote: On Tue, Oct 12, 2010 at 10:35:51AM -0700, H. Peter Anvin wrote: On real hardware it is shared between BIOS and the OS, actually. Guest OS can write in qemu CMOS too. But what is it useful for? Most of its content is not standard AFAIK

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

On 10/11/2010 12:51 PM, Anthony Liguori wrote: -kernel hijacks int19 so it cannot participate in any kind of boot order. It's either present (and therefore the bootable disk) or not present. That's a misdesign, though: it should be able to participate in BBS as a BEV. -hpa

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

On 10/11/2010 01:30 PM, Anthony Liguori wrote: On 10/11/2010 02:59 PM, Gleb Natapov wrote: No boot rom should do that. extboot wreaks havoc when it is used. And since virtio is now supported by bios there is no reason to use it. You don't really have a choice. You could be doing hardware

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

On 10/11/2010 02:41 PM, Sebastian Herbszt wrote: H. Peter Anvin wrote: On 10/11/2010 01:30 PM, Anthony Liguori wrote: On 10/11/2010 02:59 PM, Gleb Natapov wrote: No boot rom should do that. extboot wreaks havoc when it is used. And since virtio is now supported by bios there is no reason

Re: [Qemu-devel] [PATCH] add 40-48 bit RAM range to seabios

On 09/17/2010 06:11 AM, Kevin O'Connor wrote: On Fri, Sep 17, 2010 at 07:53:12AM -0500, Anthony Liguori wrote: On 09/16/2010 08:47 PM, Kevin O'Connor wrote: On Wed, Sep 15, 2010 at 07:15:28PM +0200, Andrea Arcangeli wrote: This uses a new cmos port at 0x5e that shall read zero to be backwards

[Qemu-devel] Re: [PATCH] [RFC] Add support for a USB audio device model

On 09/13/2010 01:53 PM, Amos Kong wrote: # patch -p1 /tmp/usb-audio.patch # ./configure ... ... preadv supportyes fdatasync yes uuid support no vhost-net support no Trace backend nop Trace output file trace-pid ./configure: 2276: Bad substitution What shell is

[Qemu-devel] Re: [PATCH] [RFC] Add support for a USB audio device model

On 09/13/2010 01:53 PM, Amos Kong wrote: # patch -p1 /tmp/usb-audio.patch # ./configure ... ... preadv supportyes fdatasync yes uuid support no vhost-net support no Trace backend nop Trace output file trace-pid ./configure: 2276: Bad substitution diff --git

  1   2   >