Download Qemu For Linux

[Lupita Calvi]

Iinitially thought that the resolution would have to be set by a flag on qemu or something like that. I didn't think that i could just use xrandr inside the virtual machine, it turned out that i can. So i was able to add an undetected resolution.

I am able to get a resolution of 1920x1080 @ 30Hz to work, however i am unable to get the full resolution of 2560x1440 @ 30 Hz to work. When i set the custom resolution of 2560x1440 via xrandr in qemu the display stops working, it looks like i get massive amounts of tearing, but i'm not sure. All i know is that it didn't work properly.

Okay, what a coincidence. Just after posting this I rebooted my laptop and now, for the first time since I started using KVM, exactly this works! So I can now resize the virt-manager window and the guest adapts! The output device shown by xrandr also changed from Virtual-0 to qxl-0. As I didn't change anything in the host, guest or VM configuration, I guess it's just a new package. There are still some glitches, but I am happy to see that it starts working now

Hi folks, in this post I'm going to walk through how to setup the linux kernel for debugging. I will also demonstrate that the setup works by setting a break-point to a test driver I wrote myself. All the code will be available from my gitlab, all the links to my gitlab will be re-posted at the end.

The setup I describe here re-uses some parts of the syzkaller setup, and for good reason later on in the post series I will break into a tutorial for the syzkaller tool as well. So lets get on with it.

Okay so we want to study kernel exploitation but given that the kernel isn't something totally accessible in userspace, its not as convenient to debug as userpace stuff, we need a bit of a run up before we can actually poke and prod the kernel to figure out how to write our exploits. So there's a number of important steps to how we get this done, here's what we're going to do:

We also need to be able to build our kernel because there may be build options that are important to configure in order to control exploit protection or include modules and functionality to the kernel when needed.

Okay so before we get going with launching our Qemu instances and debugging modules we need an environment. For convenience sake I'm working off of a fresh Ubuntu 18.04.5 LTS machine. I'll document the processes from fresh install to first successful kernel build.

We're just a couple steps from sending the final build commands, before we get to that lets make sure the kernel config is ready to rock. Because we're working on a Linux host we can simply swipe the .config for the virtual machine's Ubuntu kernel like so:

Great, now we need to enable some options for debug symbols, kaslr and other awesome things. So open the .config somewhere in a text editor and make sure you either add or modify the file so these options are set:

Once you're kernel is build we need to start thinking about how to build a file system for this. Here I'm going to cheat and steal some tips from the syzkaller folks. We need to first download syzkaller, as follows:

The -s is a shorthand for -gdb tcp::1234, which means the gdbserver will be hosted at port 1234. -S tells qemu not to start the cpu automatically, this gives us a chance to set a breakpoint before the kernel starts executing.

We give the "c" command to continue execution. We can now set some of our own breakpoints. As part of the tutorial I've included a custom IOCTL driver and app code (code that invokes the ioctl from userspace), i thought this would be nifty since it shows full ability to develope and debug a driver, something crucial to hunting down modern bugs and exploit development. Anyway lets code and build our own module.

The code for debug_driver.c and debug_driver_app.c as we well as the Makefile are available at this repo -kernel-exploit-development. All you need to do is download the repo and stick this in its own folder under [kernel_dir]/drivers/. To build the module the we need to set the "M" variable in the kernel make script:

Now we need to get this module on our qemu host somehow, I do this the hard way, I'm sure there's all sorts of nifty ways to scp files onto the qemu host but I actually just re-create the image after copying the drivers to a folder to be baked into the start up filesystem. First we need to edit create-image.sh so it includes everything in a folder we specify, that way we can just dump stuff in the folder and run create-image.sh whenever we want those files on a live instance.

Okay so we have a module, we have a symbol file debug_driver.ko, with stuff we need to set breakpoints. Lets load the module into the kernel, then check where it gets loaded before we actually set the breakpoint:

So thats the breakpoint hit! We achived our goal for this post, if you'd like to explore more try setting more breakpoints and before moving on to the next post make sure to get your gdb foo up. Next post is going to look at exploitation of stack vulnerabilities.

To "install" this version as a non-admin, open a command prompt, issue the command set __COMPAT_LAYER=RunAsInvoker and run qemu-w64-setup-20170131.exe from that prompt. Install in a folder where you have write permissions, like "My Documents" or something.

I added a local portforward : if you ssh/putty to localhost:2222, you will reach the SSH daemon of your VM. Beware that firewalld or iptables might block traffic, depending on the way you installed Linux.

I have a directory filled with data at /var/backups/disk1 that I want to convert into a virtual disk image which I'll then be able to boot using QEMU or KVM (the directory contains the file system for a virtual machine, copied out via rsync).

While there are plenty of instructions out there for converting a complete physical disk to a virtual disk, packaging up only the contents of a single directory into a virtual disk image is turning out to be much more difficult than I expected. Any ideas?

By the way, I know I can use qemu-img to convert a block device into a virtual disk (e.g., qemu-img convert -f /dev/sdc -O qcow2 disk.qcow2), so if only I could get the directory /var/backups/disk1 to appear to be a block device, then theoretically I should be able to accomplish my goal using qemu-img. I've thought about creative ways to expose the directory as a block device using NBD or a loopback device, however, and have not had success.

Now you can copy your files to /mnt/example. Once this is done, unmount it and you can use example.img as a drive in a virtual machine. If you want you can convert it from a raw image to another format like qcow2e using qemu-img, but this isn't required.

What about accessing the directory as a network share from a VM that is also mounted to your target virtual disk image? You than than just perform a simple copy from the share to the mounted disk image.

Today I tried to compile our customized image with MACHINE set to qemuarm. Unfortunately, qtbase failed to build because of a opengl error. This might be, because we inherited from console-tdx-image and removed x11 and wayland from the distro features.

I should have mentioned, that we use a 3,5" EDT Display and our application is written in Qt and using the eglfs driver, and of course, it would also be nice, if I could see the display output of a emulated linux image.

Hi, ligenix!

I used this repo ligenix/enterprise-qemu-spice Copr for my RockyLinux 9 distro, but I meet some problems on virt-manager when I open windows10 guest os on virt-manager config spice server and QXL driver.

I do the steps on new installed Rocky Linux 9:

Yes, spice seems to be working normally, it should be because you have updated the package in the repository.

Currently the installation instructions and packages in your repository are working correctly.

I need to test the reason why the default network configured by virt-manager cannot be connected. At present, this is the only problem. I will try to find out the reason later.

Should I keep this repository enabled and dnf update? Or disable the repository after installing spice?

Finally there is a way to use spice in RockyLinux 9.

Thanks a lot ligenix!

Thank you for this positive feedback.

Yes you can keep this repository enabled for updates.

The next step is to merge it into the upcoming Rocky Linux FastTrack Updates repository, but I have currently a bit of work to do to reach the standard quality level of this distro.

Unfortunately, like SPICE, GluterFS and oVirt were left behind by Red Hat for RHEL 9. I pushed a rebuild wih qemu-block-gluster, depending on Gluster 11 but it breaks system updates. I have to reworking it a little more with epoch probably needs to be bumped.

Hi ligenix ! I rebuilt libsoup3, glib2 and virt-manager from your repo. When connecting to a virtual machine using virt-manager I get a double boot error with libsoup versions 2 and 3. Can you help ? You solved this problem in your repo.

Hi smusich ! Sure, I seeked for it during hours by parsing the crossing library dependencies one by one. You have to rebuild libosinfo also, all the packges I modified for spice have a specific _spice tag to be properly identified.

As previously assumed, I had to change the epoch from 17 to 18 to bypass the Obsoletes directive placed on the block-gluster subpackage, moreover I did the same for the block-iscsi and block-ssh subpackages to fully revert qemu-kvm to RHEL 8 state.

Sorry! you may be right, it seems ssh connect error, I solved it by re import vm instances

Do you have other contact method like Telegram or Gmail? if you have it, I can reply to you as soon as possible if I find any other issues about spice on your repo or spice

When used as a machine emulator, QEMU can run OSes and programs made for one machine (e.g. an ARM board) on a different machine (e.g. your x86 PC). By using dynamic translation, it achieves very good performance.

QEMU can use other hypervisors like Xen or KVM to use CPU extensions (HVM) for virtualization. When used as a virtualizer, QEMU achieves near native performances by executing the guest code directly on the host CPU.

3a8082e126