If you don't own the hardware, you emulate it.
The ESP32 QEMU port appears to work, though it's slow.
@zygoon @hrw I think we have build targets in the #qemu source tree but I'm not sure how they are invoked, also see: https://gitlab.com/kraxel/edk2-build-config
Another random #QEMU tip:
#Windows2000 works pretty well under modern versions of QEMU, though not quite as well as WinXP. Try this:
* Video: vmvga or vmware-svga
* Audio: ac97
* Net: rtl8139
Install the video driver from an old VMWare Guest Utilities CD. One from the 3.x or 4.x series should work well. This will give you better video than the Cirrus card that's usually recommended, though you'll still be stuck with 4:3 or 5:4.
NT4 and earlier are a mess. Use #86Box or #VirtualBox for those.
[Перевод] Как я убедил виртуальную машину, что у неё есть кулер
Зачем вообще этим заморачиваться? Некоторые образцы malware выполняют различные проверки, чтобы определить, запущены ли они в виртуальной машине. Один из самых частых способов — проверка наличия определённых аппаратных компонентов, обычно не эмулируемых в виртуальных средах. Один из таких компонентов — кулер процессора . Например, malware может проверять наличие кулера процессора, поискав в WMI класс Win32_Fan : wmic path Win32_Fan get * Они делают это, чтобы не запускаться в виртуальных машинах, усложнив таким образом процесс анализа для исследователей безопасности. Зловредное ПО может определять, запущено ли оно в виртуальной машине, множеством разных способов. Есть различные классы WMI, позволяющие обнаружит присутствие виртуальной машины, например, Win32_CacheMemory , Win32_VoltageProbe и множество других . В этом посте я расскажу о кулере процессора. Мне просто понравилась идея убедить виртуальную машину, что он у неё есть. Однако такой же подход можно применить к другим аппаратным компонентам и классам WMI.
[Перевод] Как я убедил виртуальную машину, что у неё есть кулер
Зачем вообще этим заморачиваться? Некоторые образцы malware выполняют различные проверки, чтобы определить, запущены ли они в виртуальной машине. Один из самых частых способов — проверка наличия определённых аппаратных компонентов, обычно не эмулируемых в виртуальных средах. Один из таких компонентов — кулер процессора . Например, malware может проверять наличие кулера процессора, поискав в WMI класс Win32_Fan : wmic path Win32_Fan get * Они делают это, чтобы не запускаться в виртуальных машинах, усложнив таким образом процесс анализа для исследователей безопасности. Зловредное ПО может определять, запущено ли оно в виртуальной машине, множеством разных способов. Есть различные классы WMI, позволяющие обнаружит присутствие виртуальной машины, например, Win32_CacheMemory , Win32_VoltageProbe и множество других . В этом посте я расскажу о кулере процессора. Мне просто понравилась идея убедить виртуальную машину, что он у неё есть. Однако такой же подход можно применить к другим аппаратным компонентам и классам WMI.
virtio-win-0.1.132_x86.vfd
file somewhere handy and attach it to your VM.winxp.qcow2
before trying to run it!Épisode 6 de la saga #NetBSD et #virtualisation avec #NVMM, toujours avec un petit bout de #EdgeBSD de @khorben ! À très vite sur https://twitch.tv/ahp_nils ! #sysadmin #devops #twitchfr #twitchstreamer #TwitchStreamers #BSD #qemu
When researching for one of my last articles, I noticed a speed difference between RHEL7 and RHEL10. I used these 2, but the observed speciality can also be seen on (all?) other distros.
Got to the ground of it, might make a fun read for all involved with glibc and emulation :
https://blog.fluxcoil.net/posts/2025/06/the-riddle-of-rhel7-being-faster-than-rhel10/
#qemu #glibc #emulation
EDIT: graphics added to the article
The #UEFI shell protocol is optional and missing on one of my #ITX atom boards.
Updating my #osdev C codebase, I needed a fallback for filesystem access and therefore a path parser was required.
I took the old #DOS approach: drive letters. Its really simple to register each detected volume device handle in an array and use the drive letter as an index to it.
Big thanks to the #QEMU team which made testing EFI app code simple for me.
(I hate software tests via usb flash drives.) 🤓
docs: define policy forbidding use of AI code generators · qemu/qemu@3d40db0
https://github.com/qemu/qemu/commit/3d40db0efc22520fa6c399cf73960dced423b048
Según el objetivo de este proyecto
El objetivo de esta herramienta es proporcionar una implementación de host KVM limpia, desde cero y ligera que pueda arrancar imágenes de invitado de Linux (solo un hobby, no será grande ni profesional como QEMU) sin dependencias de BIOS y con una mínima cantidad de emulación de dispositivos heredados.
https://github.com/kvmtool/kvmtool
El desarrollador dice que es un proyecto hobby
Lo comparto me parece interesante. Este proyecto es de hace 8 años
#linux #qemu #kvm
Anyone have experience with #QEMU to emulate RISC-V on x86? Specifically, I'm wondering if anyone can speak to its performance (or knows of good resources)
"This patch thus defines a policy that the #QEMU project will currently not accept contributions where use of #AI code generators is either known, or suspected."
https://github.com/qemu/qemu/commit/3d40db0efc22520fa6c399cf73960dced423b048
🌕 文件:定義禁止使用 AI 程式碼生成器的政策
➤ QEMU 專案暫停接受 AI 生成程式碼,以確保專案的法律合規性。
✤ https://github.com/qemu/qemu/commit/3d40db0efc22520fa6c399cf73960dced423b048
QEMU 專案因應 AI 程式碼生成器興起,制定新政策,暫時不接受任何包含或衍自 AI 生成內容的程式碼貢獻。由於 AI 生成程式碼的授權和版權狀況不明確,無法確保符合開發者證書的原產地 (DCO) 要求,因此採取此措施以避免潛在的法律風險。此政策不影響使用 AI 於研究、靜態分析或除錯等用途,但生成的程式碼不得納入貢獻。此政策將隨著 AI 工具的成熟和法律狀況的釐清而可能調整,並可針對個案申請例外。
+ 這個決定很明智,AI 生成的程式碼的確存在授權問題,對開源專案來說是個隱患。
+ 雖然方便,但為了維護專案的穩定性,暫時禁止使用 AI 生成碼也是可以理解的。
#開源專案 #法律 #AI #QEMU