[Qemu-discuss] Override ECX for guest
Hi. I have a quite particular issue which I try to solve via QEMU/KVM. Background: I have a Linux based appliance running a commercial firewall product. The vendor bases the Linux version on RHEL5 2.6.18-92. The vendor then backports features as needed for their product and userspace and maintains security fixes. The firewall itself utilizes modules which are non-open source. As such building your own kernel, even with the same version is not possible as the firewall product would cease operating. The backported kernel API identifies as kvm-kmod-2.6.30.1 when loading. As far as userspace the appliance ships with QEMU: # ./qemu-system-x86_64 -version QEMU emulator version 1.2.0, Copyright (c) 2003-2008 Fabrice Bellard The appliance bases on an Intel ATOM C2558 (https://ark.intel.com/products/77983/Intel-Atom-Processor-C2558-2M-Cache-2_40-GHz). The vendor has written implementations for utilizing the AES-NI engine. However, the kernel itself seems too old to even detect this CPU capability; # grep -e vendor_id -e model -e flags /proc/cpuinfo vendor_id : GenuineIntel model : 77 model name : Intel(R) Atom(TM) CPU C2558 @ 2.40GHz flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr popcnt lahf_lm misalignsse As you can see the flags from the CPUID are not populated correctly. More particularly the aes (and others) flag is absent. Just as a proof that the vendor did not disable the capability the output from CPUID is as following: feature information (1/ecx): PNI/SSE3: Prescott New Instructions = true PCLMULDQ instruction= true 64-bit debug store = true MONITOR/MWAIT = true CPL-qualified debug store = true VMX: virtual machine extensions = true SMX: safer mode extensions = false Enhanced Intel SpeedStep Technology = true thermal monitor 2 = true SSSE3 extensions= true context ID: adaptive or shared L1 data = false FMA instruction = false CMPXCHG16B instruction = true xTPR disable= true perfmon and debug = true process context identifiers = false direct cache access = false SSE4.1 extensions = true SSE4.2 extensions = true extended xAPIC support = false MOVBE instruction = true POPCNT instruction = true time stamp counter deadline = true AES instruction = true XSAVE/XSTOR states = false OS-enabled XSAVE/XSTOR = false AVX: advanced vector extensions = false F16C half-precision convert instruction = false RDRAND instruction = true hypervisor guest status = false As you can see the flags for AES is clearly exposed / enabled. I also know that the vendor's provided proprietary VPN module utilizes AES-NI. Therefore I know it's usable in the current kernel configuration, although custom code to manually identify the presence and utilize these instruction sets. The vendor does not provide any kernel API module for accelerating AES via hardware. /proc/crypto is just having a generic x86_64 optimization for AES encryption / decryption; # grep aes /proc/crypto name : aes driver : aes-generic module : aes_generic name : aes driver : aes-x86_64 module : aes_x86_64 Issue which I try to solve: I am trying to set up an openvpn custom service on the box. But as the module for AES acceleration via the Linux crypto API is not present/available and I cannot compile it due to the kernel module source issue acceleration via AES-NI is unavailable. Unfortunately the CPU is quite slow encrypting/decrypting traffic without it. It pushes ~80Mbit/s where I'd be looking at ~300-400Mbit/s. I thought I would then do a workaround setting up a small virtual machine using the KVM infrastructure as it was provided and run the OpenVPN inside the guest machine with appropriate kernel crypto API support. However, as the kernel version 2.6.18 which it bases on does not properly identify the CPU capabilities (as seen in /proc/cpuinfo) I have not been able to get qemu to expose the AES flag to the guest despite that it's present. The guest boots perfectly, but it seems limited to the flags which the host has identified and written into the /proc/cpuinfo. The only exception is if I do -cpu host, this will cause the kernel to panic on bo
Re: [Qemu-discuss] Override ECX for guest
On Thu, 26 Jan 2017 10:49:42 +0100 (CET) Mikael wrote: > The firewall itself utilizes modules which are non-open source. As such > building your own kernel, even with the same version is not possible as the > firewall product would cease operating. You could try to build module for AES acceleration with the same vermagic (look at the output of modinfo some_module.ko) and try to insmod it without changing the running kernel. Regards, Nerijus
Re: [Qemu-discuss] Override ECX for guest
- On Jan 26, 2017, at 11:08 AM, Nerijus Baliunas neri...@users.sourceforge.net wrote: > On Thu, 26 Jan 2017 10:49:42 +0100 (CET) Mikael wrote: > >> The firewall itself utilizes modules which are non-open source. As such >> building >> your own kernel, even with the same version is not possible as the firewall >> product would cease operating. > > You could try to build module for AES acceleration with the same vermagic > (look at the output of modinfo some_module.ko) and try to insmod it > without changing the running kernel. Thanks for the tip. I have considered this. As the kernel is heavily patched / backported I'd be fully dependent on the vendor providing me their GPL part of the sources. I am sure they would honor a GPL request, however, I could probably not expect to receive it in a format which might be stock compatible for compilation as the main linux tree. This is something they seems to have branched off in 2008 manually maintaining adding support for new chipsets, security and devices. I guess we will see ;) I will try to make a request now just to see what they provide. If you know any paths of lesser resistance (i.e. overriding the ecx for a guest) this is still welcomed. Otherwise I need to maintain this parallel module on appliance updates which might introduce additional breakage. /Mikael
Re: [Qemu-discuss] Override ECX for guest
On Thu, 26 Jan 2017 12:02:16 +0100 (CET) Mikael wrote: > > You could try to build module for AES acceleration with the same vermagic > > (look at the output of modinfo some_module.ko) and try to insmod it > > without changing the running kernel. > > Thanks for the tip. I have considered this. As the kernel is heavily patched > / backported I'd be fully dependent on the vendor providing me their GPL part > of the sources. I meant to take the stock kernel sources (or RH patched sources), change vermagic/ modversions in it to match the vendor kernel, build it, and try to insert the built module. I did it successfully for a tablet (touchscreen driver) in the past. There is a probability that module will work (but of course, it may not work as well). Regards, Nerijus
Re: [Qemu-discuss] Override ECX for guest
- On Jan 26, 2017, at 12:16 PM, Nerijus Baliunas neri...@users.sourceforge.net wrote: > > I meant to take the stock kernel sources (or RH patched sources), change > vermagic/ modversions in it to match the vendor kernel, build it, and try to > insert the > built module. > I did it successfully for a tablet (touchscreen driver) in the past. There is > a > probability that module will work (but of course, it may not work as well). Thanks! I did some investigation and unfortunately there is no AES-NI crypto api support in 2.6.18 nor the RedHat patched versions. RHEL6 kernel basing on 2.6.32 does have aesni_intel and formal support. As they rewrote big parts of the crypto API around that time I think backporting into the source tree could be a tedious work. /Mikael
Re: [Qemu-discuss] Override ECX for guest
- On Jan 26, 2017, at 12:16 PM, Nerijus Baliunas neri...@users.sourceforge.net wrote: > > I meant to take the stock kernel sources (or RH patched sources), change > vermagic/ modversions in it to match the vendor kernel, build it, and try to > insert the > built module. > I did it successfully for a tablet (touchscreen driver) in the past. There is > a > probability that module will work (but of course, it may not work as well). Thanks! I did some investigation and unfortunately there is no AES-NI crypto api support in 2.6.18 nor the RedHat patched versions. RHEL6 kernel basing on 2.6.32 does have aesni_intel and formal support. As they rewrote big parts of the crypto API around that time I think backporting into the source tree could be a tedious work. /Mikael
Re: [Qemu-discuss] WinXP Guest: New hardware found - VGA controller
On Thu, Jan 26, 2017 at 12:18:53AM +0100, Joe wrote: > Anyway the issue was related to a misunderstanding of qemu man page: > > -vga type >Select type of VGA card to emulate. Valid values for type are > >cirrus >Cirrus Logic GD5446 Video card. All Windows versions > starting from Windows 95 should recognize >and use this graphic card. For optimal performances, > use 16 bit color depth in the guest and >the host OS. (This one is the default) > --- Yeah, cirrus used to be the default, but not anymore. The docs need to be fixed, I'll prepare a patch. > I noticed "-vga std" seems better than "cirrus", due to a higher > resolution: I'm trying to use autocad under XP virtualized by qemu > and high resolution would be appreciated. Yeah, I suppose 'std' should be the best option for XP. Berto
