With the increasing popularity of ARM64/AArch64 systems, from the Raspberry Pi 3 and PINE64 to Fujitsu’s move away from SPARC64 supercomputers, there hasn’t been a better time to get started with learning this architecture. I wanted to make a start to an Aarch64 assembly language tutorial but didn’t have access to my RPi3, so I looked into the state of QEMU’s emulation. I didn’t need RPi3-specific hardware – which is just as well as I can’t remember off-hand how the bootcode and start.elf crap would work with QEMU – anyway, I opted for a generic device using Linaro’s EDK2 UEFI firmware. The first pre-built EDK2 binary I downloaded wouldn’t play nicely with the OpenBSD kernel so I grabbed a release mentioned by the FreeBSD team – which worked.[…]
Some highlights that ‘caught my eye’:
* On sparc64 ldomctl(8) now supports more modern firmware found on SPARC T2+ and T3 machines in particular such as T1000, T5120 and T5240. NVRAM variables can now be set per logical domain.
* ACPI support on OpenBSD/arm64 platforms.
* New acpisurface(4) driver providing ACPI support for Microsoft Surface Book laptops.
* New acpipci(4/arm64) driver providing support for PCI host bridges based on information provided by ACPI.
* Added a sensor for port replicatior status to acpithinkpad(4).Implemented MAP_STACK option for mmap(2). At pagefaults and syscalls the kernel will check that the stack pointer points to MAP_STACK memory, which mitigates against attacks using stack pivots.
* New RETGUARD security mechanism on amd64 and arm64: use per-function random cookies to protect access to function return instructions, making them harder to use in ROP gadgets.
* clang(1) includes a pass that identifies common instructions which may be useful in ROP gadgets and replaces them with safe alternatives on amd64 and i386.
* The Retpoline mitigation against Spectre Variant 2 has been enabled in clang(1) and in assembly files on amd64 and i386.
* Added SpectreRSB mitigation on amd64.
* Added Intel L1 Terminal Fault mitigation on amd64.
* Meltdown mitigation was added to i386.
amd64 now uses eager-FPU switching to prevent FPU state information speculatively leaking across protection boundaries.
* Because Simultaneous MultiThreading (SMT) uses core resources in a shared and unsafe manner, it is now disabled by default. It can be enabled with the new hw.smt sysctl(2) variable.
Chip vendors controlling the security of OSes should be more transparent in their selection process. They should maintain a list of OSVs that they maintain embargoed fixes. Then uses could determine if they want to trust the OS or not, or try to lobby to try and get the ISA vendor to support their OS. Is the OS on the list, ok then they may have some chance at fixing things. If not on the list I expect to be vulnerable until the embargo ends. There are MANY more OSes than Microsoft Windows, Apple macOS, a limited number of Linux distros, and sometimes FreeBSD.
In some forums, Bryan Cantrill is crafting a fiction. He is saying the FPU problem (and other problems) were received as a leak. He is not being truthful, inventing a storyline, and has not asked me for the facts. This was discovered by guessing Intel made a mistake. We are doing the best for OpenBSD. Our commit is best effort for our user community when Intel didn’t reply to mails asking for us to be included. But we were not included, there was no reply. End of story. That leaves us to figure things out ourselves. Bryan is just upset we guessed right. It is called science.
RETGUARD for clang (amd64) added to -current
Contributed by rueda on 2018-06-06 from the d(e)ropping-the-gadgets dept.
Todd Mortimer has committed “RETGUARD” for clang (for amd64).
Over the last three weeks I’ve been working on a new randomization feature which will protect the kernel. The situation today is that many people install a kernel binary from OpenBSD, and then run that same kernel binary for 6 months or more. We have substantial randomization for the memory allocations made by the kernel, and for userland also of course. However that kernel is always in the same physical memory, at the same virtual address space (we call it KVA). Improving this situation takes a few steps.[…]
“Make a move towards ending 4 decades of kernel snooping. Add sysctl kern.allowkmem (default 0) which controls the ability to open /dev/mem or /dev/kmem at securelevel > 0. Over 15 years we converted 99% of utilities in the tree to operate on sysctl-nodes (either by themselves or via code hiding in the guts of -lkvm). pstat -d and -v & procmap are affected and continued use of them will require kern.allowkmem=1 in /etc/sysctl.conf. acpidump (and it’s buddy sendbug) are affected, but we’ll work out a solution soon. There will be some impact in ports.”
Filippo Valsorda of the CloudFlare Security Team wrote a blog on OpenBSD’s full-disk-encryption, after he lost his password.
So I lost my OpenBSD FDE password
The other day I set up a new OpenBSD instance with a nice RAID array, encrypted with Full Disk Encryption. And promptly proceeded to forget part of the passphrase. […] I did a weak attempt at finding some public bruteforce tool, and found nothing. I say weak because somewhere in the back of my brain, I already wanted to take a peek at the OpenBSD FDE implementation. Very little is documented, and while I do trust OpenBSD, I want to know how my data is encrypted. So this was the “perfect” occasion. […]
“Start using to XN flag to enforce that mappings without PROT_EXEC are non-executable.”
Excerpting the recent TCG announcement:
BSSSD: Trusted Computing now available for FreeBSD and OpenBSD: All pieces to utilize Trusted Computing and build Trusted Computing applications on FreeBSD and OpenBSD have been made available by the BSSSD-project.
* TPM device driver for the FreeBSD-kernel
* TPM device driver for the OpenBSD-kernel
* TCG Software Stack TrouSerS
* TrustedGRUB boot-loader
Kernel drivers were developed for the following TPMs:
* Atmel 97SC3203
* Broadcom BCM0102
* Infineon IFX SLB 9635 TT 1.2
* Intel INTC0102
* Sinosun SNS SSX35
* STM ST19WP18
* Winbond WEC WPCT200
OpenBSD 5.9 has been released. There are a few firmware-related improvements in this release, such as:
* New efifb(4) driver for EFI frame buffer.
* amd64 can now boot from 32 bit and 64 bit EFI.
* Initial support for hardware reduced ACPI added to acpi(4).
* New asmc(4) driver for the Apple System Management Controller.
* New dwiic(4) driver for the Synopsys DesignWare I2C controller.
* Support for ACPI configured SD host controllers has been added to sdhc(4).
* The sdmmc(4) driver now supports sector mode for eMMC devices, such as those found on some BeagleBone Black boards.
* The ipmi(4) driver now supports OpenIPMI compatible character device.
Kees Cook has a blog on seccomp, including a discussion of the new OpenBSD pledge technology, a bit of BSD -vs- Linux kernel security comparisons:
Resflash is a tool for building OpenBSD images for embedded and cloud systems in a reproducible way. Resflash exclusively uses read-only and memory-backed filesystems, and because the partitions are only written to during system upgrades (or as configured), filesystems are not subject to corruption or fsck due to power loss – and even cheap flash drives can last virtually forever. Resflash images can be written to any bootable media, flash or conventional, and make great firewalls and NAS boot drives. Resflash was written from scratch, with inspiration drawn from NanoBSD and flashrd.
Brian Conway of RCE Software just announced UEFI support for resflash:
I just pushed a new update to resflash that enables UEFI boot on 5.8-current and newer. There are no knobs to use this, it will be enabled if the sets used to create your OpenBSD base_dir support it, and will create an EFI System Partition (ESP) before the main OpenBSD partition. Partitioning is still done via MBR, so the image produced will be bootable in either native UEFI mode or in BIOS/CSM mode.
A few caveats:
– OpenBSD UEFI support is still under heavy development and is not guaranteed to work on all hardware. Also, I’m unable to get serial console output working yet on any of my hardware.
– Support is subject to change as GPT support in OpenBSD evolves, but I’m hoping not to break out images into separate UEFI and BIOS images.
Also, I’ve released a set of sample tools for building and configuring resflash images called resflash-tools.
Progress appears to be continuing at the OpenBSD project w/r/t UEFI support, with multiple devices!
Jaspar has a new blog post with information on using OpenBSD on UEFI-based systems.
Hmm, I was under the impression that of the BSDs, only FreeBSD supported UEFI. (As well as MacOSX, of course.) But it appears that despite Theo’s previous comments on UEFI 🙂 that there might be some UEFI support in OpenBSD eventually:
From last year, GSOC’14 for OpenBSD (UEFI and GPT), I’ve not studied to see if these have been upstreamed yet:
From 2 days ago, a new OpenBSD-centric boot loader:
It looks like the latter project needs some hardware help, besides the author’s VIAO, if you can help them out…