Skip to content

Shim-15.1 for Miray Software AG #102

@miray-tf

Description

@miray-tf

Make sure you have provided the following information:

What organization or people are asking to have this signed:

We are the Miray Software AG, producers of microkernel OS "Symobi" and the
widely known Stand-Alone-Tools "HDClone" and "HDShredder" as well as other
hardware related tools, running without an installed operating system.
https://www.miray-software.com/

What product or service is this for:

The product is a Self-Booting system (typically from a USB flash drive or a CD,
containing one of our Stand-Alone-Tools, based on either our own microkernel
OS "Symobi" or a Linux kernel with our application framework on top.
A similar version, which runs as a normal Windows application, also exists, but
isn't actually considered to be "Stand-Alone", as it requires an existing
Windows installation and is limited in several aspects that require direct
hardware access.

We have used a Microsoft SecureBoot signed Shim since 2014 and the focus and
requirements of our products have not changed since then.

What is the origin and full version number of your shim?

Shim is based on 'shim-15.1' from rhboot/shim
https://github.com/rhboot/shim/tree/shim-15.1

The tree with patches can be found at
https://github.com/MiraySoftware/shim/tree/miray-15.1

We enable support to verify 32bit kernels on 64bit systems for our own operating systems

What's the justification that this really does need to be signed for the whole world to be able to boot it:

We make software tools for Data Cloning, Backup/Recovery and Secure Deletion,
as well as other specialized tools for computer technicians, companies and
industrial use. Our tools are well known and used worldwide in more than 160
countries. Many of the tasks our software performs requires direct hardware
access and is usually not possible to perform under a Windows environment.
Especially restoring system backups and master images requires our software
to boot directly on SecureBoot systems.

How do you manage and protect the keys used in your SHIM?

Keys are stored in a hardware token. Access to the token is restricted.

Do you use EV certificates as embedded certificates in the SHIM?

Yes, EV certificate issued by DigiCert.

If you use new vendor_db functionality, are any hashes whitelisted, and if yes: for what binaries ?

Not used, no binaries whitelisted

Is kernel upstream commit 75b0cea7bf307f362057cc778efe89af4c615354 present in your kernel, if you boot chain includes a linux kernel ?

Yes, we currently use linux lts kernel 5.4.51:
75b0cea7bf307f362057cc778efe89af4c615354 was merged to upstream linux version 5.4.50

if SHIM is loading grub2 bootloader, is CVE CVE-2020-10713 fixed ?

Yes

Grub is branched from GRUB upstream commit e7b8856f8be3292afdb38d2e8c70ad8d62a61e10:
'linux: Fix integer overflows in initrd size handling'

Did you change your certificate strategy, so that affected by CVE CVE-2020-10713 grub2 bootloaders can not be verified ?

New shim uses new certificate.
No affected versions were signed with the new certificate.

What is the origin and full version number of your bootloader (GRUB or other)?

Bootloader based on GRUB 2.04+e7b8856f8be3292afdb38d2e8c70ad8d62a61e10
That commit is currently the upstream HEAD and includes the BootHole patches

The GRUB tree is available from
https://github.com/MiraySoftware/grub2/tree/sysload_2_5

If your SHIM launches any other components, please provide further details on what is launched

Shim is only used to launch a GRUB 2.04 based bootloader.

How do the launched components prevent execution of unauthenticated code?

Loaded code is validated through shim.
Linux is validated through linuxefi from fedora-33 branch of rhboot.
Symobi kernel is validated through shim_lock module in GRUB.
No other code is loaded.

Does your SHIM load any loaders that support loading unsigned kernels (e.g. GRUB)?

No, our GRUB flavor does not load any unsigned kernels when SecureBoot mode is active
We use a modified GRUB based on current trunk with shim_lock verifier module.
GRUB includes the upstream BootHole patches

What kernel are you using? Which patches does it includes to enforce Secure Boot?
  • Linux: Version 5.4.51 with additional lockdown patches from Debian. Automatic lockdown if booted in SecureBoot
    Applied patches are
    features/all/lockdown/efi-add-an-efi_secure_boot-flag-to-indicate-secure-b.patch
    features/all/lockdown/efi-lock-down-the-kernel-if-booted-in-secure-boot-mo.patch
    features/all/lockdown/add-a-sysrq-option-to-lift-kernel-lockdown.patch
    features/all/lockdown/enable-cold-boot-attack-mitigation.patch
    features/all/lockdown/mtd-disable-slram-and-phram-when-locked-down.patch
    features/all/lockdown/arm64-add-kernel-config-option-to-lock-down-when.patch
    The patches are currently available through
    https://salsa.debian.org/kernel-team/linux/tree/master/
    commit hash bb116bf757073347c9297ed7276cfc42e413222c

  • Symobi:

    • EFI Bootservices are disabled by GRUB before the operating system is started
    • Hardware access is limited to kernel and drivers stored in core file system
    • Kernel validates core file system against SHA2 hash embedded in the signed kernel.
What changes were made since your SHIM was last signed?

Update from shim '12' to 'shim-15.1'
Renewed certificate
Added 'Check PxeReplyReceived as fallback in netboot' patch
Enabled HTTPBoot option

What is the hash of your final SHIM binary?

Sha256 hash: 997a16266f105da86252d1801f95c02e7c4f570892c35f16f3d122c1ecd2dc71

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions