planet.virt-tools.orgBlogging about open source virtualization

News from QEMU , KVM , libvirt , libguestfs , virt-manager and related tools Subscriptions ARM Datacenter Project (feed) Adam Litke (feed) Alberto Garcia (feed) Alex Bennée (feed) Alex Williamson (feed) Chris Lalancette (feed) Christophe Fergeau (feed) Cole Robinson (feed) Cornelia Huck (feed) Cédric Bosdonnat (feed) Daniel Berrange (feed) Eduardo Habkost (feed) Eduardo Otubo (feed) Fabian Deutsch (feed) Fabiano Fidêncio (feed) Gerd Hoffmann (feed) KVM on Z (feed) Kashyap Chamarthy (feed) Ladi Prosek (feed) Marcin Juszkiewicz (feed) Nathan Gauër (feed) Peter Maydell (feed) QEMU project (feed) Richard Jones (feed) Stefan Hajnoczi (feed) Stefano Garzarella (feed) Thomas Huth (feed) Yoni Bettan (feed) Add roach works. In a type safe programming language with capability-based security it becomes possible to give components access to only those resources that they require. Usually type safety is the mechanism that prevents capabilities from being created out of thin air, although other approaches may be possible for dynamic languages. The type system will not allow a component to create itself a new capability that the component does not already possess. Capability-based security addresses safety at runtime, but it does not address safety at compile time. If we want to compose programs from untrusted components then it is not possible to rely on today’s build scripts, code generators, or macro systems. The problem is that they can be abused by a component to execute code in the context of another component. Compile-time supply chain safety means isolating components so their code stays within their component. For example, a "leftpad" macro that pads a string literal with leading spaces would be unsafe if it can generate code that is compiled as part of the main program using the macro. Similarly, a build script for the leftpad module must not be able to affect or escape the build environment. Macros, build scripts, code generators, and so on are powerful tools that programmers find valuable. The challenge for supply chain safe programming languages is to harness that power so that it remains convenient to use without endangering safety. One example solution is running build scripts in an isolated environment that cannot affect other components in the program. This way a component can take advantage of custom build-time behavior without endangering the program. However, it is unclear to me how far inter-component facilities like macros can be made safe, if at all. Conclusion I don’t have the answers or even a prototype, but I think supply chain safe programming languages are an inevitability. Modern programs are composed of many third-party components yet we do not have effective techniques for confining components. Languages treat the entire program as trusted rather than as separate untrusted components that must be isolated. Hopefully we will begin to see new mainstream programming languages emerge that are supply chain safe, not just memory safe! by Unknown (noreply@blogger.com) at March 31, 2024 02:16 AM March 25, 2024 KVM on Z Important Note on Verifying Secure Execution Host Key Documents The certificates of the host key signing keys that are needed to verify host key documents will expire on April 24, 2024 for IBM z15 and LinuxONE III and on March 29, 2024 for IBM z16 and LinuxONE 4. Due to a requirement from the Certificate Authority (DigiCert), the renewed certificates are equipped with a new Locality value (Armonk” instead of Poughkeepsie”). These renewed certificates cause the current versions of the genprotimg , pvattest, and pvsecret tools to fail the verification of host key documents. The IBM Z team is preparing updates of the genprotimg , pvattest , and pvsecret tools to accept the new certificates and is working with Linux distribution partners to release the updated tools. To build new Secure Execution images, attestation requests, or add-secret requests before the updated tools are available in Linux distributions, follow these steps: Step 1: Obtain the host key document, the host key signing key certificate, the intermediate certificate from the Certificate Authority, and the list of revoked host keys (CRL): For IBM z15 and LinuxONE III, see https://www.ibm.com/support/resourcelink/api/content/public/secure-execution-gen1.html For IBM z16 and LinuxONE 4, see https://www.ibm.com/support/resourcelink/api/content/public/secure-execution-gen2.html Step 2: Download the script check_hostkeydoc from https://github.com/ibm-s390-linux/s390-tools/blob/master/genprotimg/samples/check_hostkeydoc . Step 3: Verify each host key document using the check_hostkeydoc script. For example, issue # ./check_hostkeydoc HKD1234.crt ibm-z-host-key-signing.crt \ -c DigiCertCA.crt -r ibm-z-host-key.crl This example verifies the host key document HKD1234.crt using the host key signing key certificate ibm-z-host-key-signing.crt , and the intermediate certificate of the Certificate Authority DigiCertCA.crt , as well as the list of revoked host keys ibm-z-host-key.crl . After the host key documents are verified using the check_hostkeydoc script, you can safely call genprotimg , pvattest , or pvsecret with the –-no-verify option. For a description about how to manually verify host key documents, see https://www.ibm.com/docs/en/linux-on-z?topic=execution-verify-host-key-document . p { line-height: 115%; text-align: left; orphans: 2; widows: 2; margin-bottom: 0.1in; direction: ltr; background: transparent }a:link { color: #467886; text-decoration: underline } by Stefan Raspl (noreply@blogger.com) at March 25, 2024 10:51 AM Marcin Juszkiewicz Running SBSA Reference Platform Recently people asked me how to run SBSA Reference Platform for their own testing and development. Which shows that I should write some documentation. But first let me blog about it… Requirements To run SBSA Reference Platform emulation you need: QEMU (8.2+ recommended) EDK2 firmware files That’s all. Sure, some hardware resources would be handy but everyone has some kind of computer available, right? QEMU Nothing special is required as long as you have qemu-system-aarch64 binary available. EDK2 We provide EDK2 binaries on CodeLinaro server. Go to latest/edk2” directory, fetch both SBSA_FLASH*” files, unpack them and you are ready to go. You may compare checksums (before unpacking) with values present in latest/ README .txt” file. Those binaries are built from release versions of Trusted Firmware ( TF -A) and Tianocore EDK2 plus latest edk2-platforms” code (as this repo is not using tags). Building EDK2 If you decide to build EDK2 on your own then we provide TF -A binaries in edk2-non-osi” repository. I update those when it is needed. Instructions to build EDK2 are provided in Qemu/SbsaQemu directory of edk2-platforms” repository. Running SBSA Reference Platform emulation Note that this machine is fully emulated. Even on AArch64 systems where virtualization is available. Let go through example QEMU command line: qemu-system-aarch64 -machine sbsa-ref -drive file=firmware/SBSA_FLASH0.fd,format=raw,if=pflash -drive file=firmware/SBSA_FLASH1.fd,format=raw,if=pflash -serial stdio -device usb-kbd -device usb-tablet -cdrom disks/alpine-standard-3.19.1-aarch64.iso At first we select sbsa-ref” machine (defaults to four Neoverse-N1 cpu cores and 1GB of ram). Then we point to firmware files (order of them is important). Serial console is useful for diagnostic output, just remember to not press Ctrl-C there unless you want to take whole emulation down. USB devices are to have working keyboard and pointing device. USB tablet is more useful that USB mouse ( -device usb-mouse adds it). If you want to run * BSD operating systems then I recommend to add USB mouse. And the last entry adds Alpine 3.19.1 ISO image. System boots to text console on graphical output. For some reason boot console is on serial port. Adding hard disk If you want to add hard disk then adding-hdb disk.img ” is enough (hdb” as cdrom took 1st...