Uncategorized

Alexander on U-Boot+UEFI+GRUB on ARM

Here’s one interesting presentation for the upcoming OpenIoT and Embedded Linux Conference:

Marrying U-Boot, uEFI and grub2 – Alexander Graf, SUSE

Booting is hard. Booting in the ARM world is even harder. State of the art are a dozen different boot loaders that may or may not deserve that name. Each gets configured differently and each has its own pros and cons. As a distribution this is a nightmare. Configuring each and every one of them complicates code that really should be very simple. To solve the problem, we can just add another layer of abstraction (grub2) on top of another layer of abstraction (uEFI) on top of another layer of abstraction (u-boot). Follow me on a journey on how all those layers can make life easier for the distribution and how much fun uEFI really is. After this talk, you will know how ARM systems boot, what uEFI really means, how uEFI binaries interact with firmware and how this enables convergence of the Enterprise and Embedded markets.

Alexander Graf, KVM Wizard, SUSE
Alexander started working for SUSE about 8 years ago. Since then he worked on fancy things like SUSE Studio, QEMU, KVM and openSUSE on ARM. Whenever something really useful comes to his mind, he tends to implement it. Among others he did Mac OS X virtualization using KVM, nested SVM, KVM on PowerPC and a lot of work in QEMU for openSUSE on ARM. He is the upstream maintainer of KVM for PowerPC, QEMU for PowerPC and QEMU for S390x.

https://openiotelcna2017.sched.com/event/9IuS

https://openiotelcna2017.sched.com/?s=firmware
https://openiotelcna2017.sched.com/?s=u-boot
http://events.linuxfoundation.org/events/openiot-summit
http://events.linuxfoundation.org/events/embedded-linux-conference

 

Standard
Uncategorized

Writing secure C code for ARM

https://www.community.arm.com/iot/embedded/b/blog/posts/a-few-intricacies-of-writing-armv8-m-secure-code

https://www.community.arm.com/processors/b/blog/posts/useful-tips-for-developing-secure-software-on-armv8-m

https://www.community.arm.com/processors/b/documents/posts/whitepaper—armv8-m-architecture-technical-overview

https://developer.arm.com/products/architecture/m-profile/docs/100720/latest/secure-software-guidelines

https://developer.arm.com/docs/100739_0100/latest/the-arm-c-language-extensions-acle-for-armv8m

Standard
Uncategorized

new AArch64 vm-spec validation tools

Riku Voipio of Linaro has announced the release of some new tools that validate the VM to the Linux cross-distro list.

Some time ago we drafted a specification[1] for AArch64 virtual machines. Now we are launching verification tools that let everyone verify that the whole stack (host hypervisor, guest firmware and guest OS image) implements the spec 2[]. For some extra background see the blog post on vmspec [3]. From the cross-distro point of view, we are interested in finding out if
– QEMU shipped is new enough (2.6+)
– a compatible EFI for arm64 guests is available
– a vmspec compatible cloud guest image is available

If the image comes with cloud-init, vmspec-boot can be used directly to verify compliance. Without cloud-init, one can run vmspec-verify inside the guest to verify manually. The tools are still under development, for example the ACPI test returns a failure even if the guest would support ACPI if forced. Feedback and patches are always welcome. The README.md lists a handful of guest images that have been used in testing. I’d be most happy to add more links to the list!

[1] http://www.linaro.org/app/resources/WhitePaper/VMSystemSpecificationForARM-v2.0.pdf
[2] https://github.com/linaro/vmspec-tools
[3] http://www.linaro.org/blog/core-dump/ensuring-bootable-arm-vm-images/
Full message:
https://lists.linaro.org/mailman/listinfo/cross-distro

Standard
Uncategorized

ACPIview

Evan Lloyd and Sami Mujawar of ARM have submitted a new ACPI UEFI Shell tool for Tianocore.

[edk2] [PATCH] ShellPkg: Add acpiview tool to dump ACPI tables

This program is provided to allow examination of ACPI table contents from the UEFI Shell.  This can help with investigations, especially at that stage where the tables are not enabling an OS to boot. The program is not exhaustive, and only encapsulates detailed knowledge of a limited number of table types. Default behaviour is to display the content of all tables installed. ‘Known’ table types will be parsed and displayed with descriptions and field values.  Where appropriate a degree of consistency checking is done and errors may be reported in the output. Other table types will be displayed as an array of Hexadecimal bytes. To facilitate debugging, the -t and -b options can be used to generate a binary file image of a table that can be copied elsewhere for investigation using tools such as those provided by acpica.org.  This is especially relevant for AML type tables like DSDT and SSDT. The inspiration for this is the existing smbiosview Debug1 Shell command, and the command is also intended for Debug1. Many tables are not explicitly handled, in part because no examples are available for our testing. The program is designed to be extended to new tables with minimal effort, and contributions are invited.

The code is available for examination at:
https://github.com/EvanLloyd/tianocore/tree/651_acpiview_v1

Standard
Uncategorized

1Bitsy and Black Magic Probe

1Bitsy and Black Magic Probe has a Kickstarter campaign worth checking out:

 

 

Standard
Uncategorized

MapleSyrup: ARM security tool

Maplesyrup Register Display Tool:
Maplesyrup is a tool that can be used to help determine the security state of an ARM-based device by examining the system register interface of the CPU. Maplesyrup is for anyone who has low level access to a handset or single-board PC running an ARMv7A/v8A based processor and is interested in knowing the register level configuration of their CPU at OS runtime. These registers contain featureset and security information that may influence operation of the system kernel and running applications. Linux provides featureset and platform information to the user in the /proc and /sys filesystems, but the configurations governing how these features operate is sometimes hidden to the user. In some cases, the OS will make use of the information to conform to implementation specific features and not indicate this to the user. In other cases, these features may not be managed by the operating system at all, but nevertheless could potentially affect the operation of the system by configuring how a CPU controls access to security domains, executes specific instructions, and handles CPU exceptions.[…]

 

https://github.com/iadgov/Maplesyrup

 

Standard