New OpenBSD FAQ: Virtualization

OpenBSD has, arguably, some of the best officially-maintained documentation of any modern operating system. Solene Rapenne added a new FAQ section for Virtualization that covers getting OpenBSD's VMM hypervisor off the ground, and it gets the basics out of the way pretty well.

The FAQ kind of glosses over the more elaborate network configuration schemes, one of which I covered in Part 2 of my VMM article a while ago, though if you poke around between the FAQ and man pages, you can find pretty much all you need.

There are some new features to VMM which I plan on writing about soon. Stay tuned!

Via Undeadly


Windows Defender can now run in a sandbox

Via the Microsoft Security Blog:

Windows Defender Antivirus has hit a new milestone: the built-in antivirus capabilities on Windows can now run within a sandbox. With this new development, Windows Defender Antivirus becomes the first complete antivirus solution to have this capability and continues to lead the industry in raising the bar for security.
Sandboxes isolate processes in such a way as to prevent them from causing systemic harm, and because of the way modern antiviruses work, many of them have proven vulnerable to targeted arbitrary code execution attacks -- that's right, proof-of-concept malware exists that can exploit the antivirus suite! This is a major step toward improving the security of the Windows platform, and as far as I can tell, Defender is the first in its class to adopt this sort of fortification.

Right now, It's not set up by default. I'd imagine that may change in the near future.
Users can also force the sandboxing implementation to be enabled by setting a machine-wide environment variable (setx /M MP_FORCE_USE_SANDBOX 1) and restarting the machine. This is currently supported on Windows 10, version 1703 or later.


Small TFT displays for Kali on the Raspberry Pi

Earlier this week, I saw this hot tip from Hack A Day with regards to a high-performance driver for SPI-driven displays on the Pi. That article was published just as I had been digging into getting my Adafruit 3.5" PiTFT display working under Kali so I can run FruityWiFi and other tools with a super-portable kit.

I've had the PiTFT working under Raspbian for years, but Kali isn't Raspbian, and I remember that getting it working the way I wanted, even with the Adafruit helper tool, was somewhat of an ordeal.

Although a number of folks (e.g. re4son) have published unofficial Kali images for the Pi, some of which claim to work with various add-on displays, I tried and a few and failed to get them to work properly, if at all, even without the display. I started with a fresh official Kali Linux 2018.3 RaspberryPi 2 and 3 image.

The fbcp-ili9341 driver doesn't work out-of-the-box on Kali, either, but getting it up and running wasn't too hard. It doesn't support touch input yet, but for me, Kali requires at least a keyboard, and my trusty Logitech K400r (affiliate link) is always nearby. One thing I like about framebuffer copy (fbcp) is that you can have the Pi plugged into HDMI (or not...) and the video is mirrored to the TFT, but needless to say, you'll have to start with the Pi plugged into an external monitor until you get the TFT working.
To get the driver to compile on Kali, I had to download libbcm_host.so, libvchiq_arm.so and libvcos.so from the opt/vc/lib directory of the RaspberryPi Git repository (or you could copy them from a running raspbian host or SD card).

I put the library files in /opt/vc/lib (I had to create this directory) and then added it to the libary path by creating a file called /etc/ld.so.conf.d/vc.conf :
#vc libs

run ldconfig to reload the library cache.

I'll be going through the steps specific to the Adafruit PiTFT 3.5, however it looks like a lot of various, generic displays have been tested to work, as long as you pass the right options to cmake when you build it. The Readme in the repository has a lot of helpful tips on cmake options, but the basic "get it compiled" instructions are pretty simple:

For the Adafruit PiTFT 3.5 display, this was the magic sauce for the cmake command, though you may wish to mess with the Clock Divisor timing:


Before I ran "make -j" per the above, I edited config.h to make some tweaks, uncommenting two options to get the orientation of the display the way I wanted it (so the Raspberry Pi power plug sticks out of the top when looking at the screen upright) and to fill more of the display:


Once I got it running nicely, I copied the binary to /usr/local/bin/fbcp (because I can't remember "fbcp-ili9341")

Next, I edited /boot/config.txt and experimented with the various video modes to give me a display that was both legible on a tiny screen, and filled as much of the display as possible. I ended up with a 480p 16:9 mode that, combined with the BREAK_ASPECT_RATIO fbcp build config, looks about as good as I can get it on the display. You'll have to tinker with these options to find what works best on yours. I added this to the end of /boot/config.txt:


If you're cool with running full brightness, you can skip this next part. If you want variable brightness on the backlight, we have to configure GPIO. This display uses GPIO Pin 18 for the backlight LEDs. Other TFTs might not support PWM brightness control, or may use a different pin than 18 for it. By default, the display is on 100% full brightness, but if you tweak the GPIO configuration in the bootloader, you can use PWM to modulate the brightness. I added the following line to /boot/config.txt:


This change will kill the power to the backlight at boot (as the PWM mode will default to no power output) so you'll need to initialize and power-up the GPIO at boot if you want the display to be usable. To do this, I created a "rc.local" file in /etc (which systemd will run at boot) to launch the fbcp driver, initialize the GPIO, and set the display to 50% brightness. I'm running a really high frequency on the GPIO because a lower frequencies created a very audible high-pitch whine, and very low values (e.g. periods of 255 to 10000) were not giving any kind of granularity to the backlight brightness. /etc/rc.local:

echo 0 > /sys/class/pwm/pwmchip0/export 
echo 10000000 > /sys/class/pwm/pwm0/period 
echo 5000000 > /sys/class/pwm/pwm0/duty_cycle 
echo 1 > /sys/class/pwm/pwm0/enable 

Make sure it's executable:
chmod 755 /etc/rc.local

I opted to enable automatic login (as root) on this since it's basically a plug-in-and-go appliance. I followed this quick guide.

Reboot to test it out. You should see a white screen (or whatever was on the screen before rebooting) for a few seconds, then the backlight should go out until rc.local is executed right before it goes into GUI mode.

Finally, I created a "backlight.sh" script that handles setting the brightness. You'll need to make this executable, too. Syntax is basically "./brightness.sh (percentage)" where 0 is off, 1 is very dim, and 100 is full brightness.

if [ -n $1 ]
    echo ${1}00000 > /sys/class/pwm/pwm0/duty_cycle


OpenBSD 6.4 released, Web server guide updated

OpenBSD 6.4 was released last week. It comes chock full of new goodies, including a built-in Wireless network manager ('join' syntax for ifconfig), derived snapshots for vmm virtual machine disk images (based on qcow2 support), improvements to pledge including the addition of unveil, and RETGUARD, a new stack protector for thwarting ROP attacks just to name a few new features.

I've been busy with the new job and getting settled into the new digs here in the Austin suburbs, but I carved out some time to update the OpenBSD/HTTPD/MySQL/PHP guide. There are a few changes to how PHP-FPM is configured, so you may want to pay close attention if you've followed the guide before.

The nginx and apache pages haven't gotten that many views lately, so I am not updating them this go-around. The httpd in OpenBSD's base install is a pretty well-proven web server at this point, and I've been using it in production, reliably, for years now. If you're thinking of running nginx or apache on OpenBSD, I'd urge you to take a look at httpd.