Kobo Libra Colour is using Secure Boot

[NiMa]

I guess this was bound to happen some day... but is also extremely contradictory with Kobo's "Right to repair" philosophy that honestly just seems like the dumbest thing ever said, at least considering what I have discovered.

## Checking Image at 41000000 ...
   FIT image found
   FIT description: U-Boot fitImage for Poky (Yocto Project Reference Distro)/4.9/aud8113tp1
    Image 0 (kernel@1)
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x410000fc
     Data Size:    14675968 Bytes = 14 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x40008000
     Entry Point:  0x40008000
     Hash algo:    sha256
     Hash value:   2bae18998544ca39a2cbfe1bcc1a4408ba876db3b470a98689503fee7795d447
    Image 1 (fdt@1)
     Description:  aud8113tp1-E70T00-A0x00.dtb
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x41dff224
     Data Size:    47831 Bytes = 46.7 KiB
     Architecture: ARM
     Load Address: 0x44000000
     Hash algo:    sha256
     Hash value:   7db67257f744a64c42f62fe0e7ef343e1ea5ec0e00a6e1726b78f15075a3bab5
    Default Configuration: 'conf@1'
    Configuration 0 (conf@1)
     Description:  Boot Linux kernel with FDT blob
     Kernel:       kernel@1
     FDT:          fdt@1
     Sign algo:    sha256,rsa2048:dev
     Sign value:   b8f687f70f33eb5597a3ac8d1e4e754d6287ad77a9cfd5dd9082c92ff198e1fd277464ab0141a71fe451fd66fe3780a67efdd0d3d7e77b6fa681ead844e46d10283499f5303c6c312dbca66fe76163f5cf57135b3667c17c80c8301afe40d3289e8272612a8da57462a884a6c41a88290cbd1309ea2aeac0e2abc820a286116f5ba371bfd1f06a7aecea106b2bbcd2c85527d5acf76270dcc7d2f7d5d15d434e3b2845fd8f3ebf770d353adffb156d266d82b5f719608115ec4b65460b7b14d07d234a4dfe92f0a4c560da7092f0dc340a57006f7285ed370d
808bd9b77423e25efd116e463b051c491dec2ece5a5ef96f137007bf81200b50190b239404acec

Kobo is now using signature verification of both the Libra Colour's U-Boot and kernel (Little Kernel is launched first, I don't know yet if that is signed or not). It is probably the case for the Clara Colour as well.

For the less techies out there: this means more locking down from Kobo's end, basically putting them a step closer to Amazon's extremely agressive practices in the jailbreaking world.

This also means that porting Quill OS/InkBox OS to these new devices is currently impossible/very difficult.

I am just angry at them now...

[Szybet]

Clarification:
Previous kobo's didn't have this and everything was fine.

[JSWolf]

It could be that went the older devices get 4.39.xxx, we'll also get secure boot.

[elinkser]

Originally Posted by JSWolf

It could be that went the older devices get 4.39.xxx, we'll also get secure boot.

I think on laptops there was a hardware TPM chip or in other cases a hypervisor that enforced the secure boot, while the OS that was being loaded did not need to know anything about whether it was being loaded into a secure boot environment or not.

I still have a laptop that lets me set Secure Boot or not. Hopefully Kobo has allowed this, since they didn't seem to be against SideloadedMode? e.g, my chromebook has the option to run in Developer's mode, which allowed me to install MXLinux which was what made me choose to buy the device.


EDIT : Ahhh, this link says amazon was able to turn on secure boot over the air, if I understand correctly (probably not
https://xdaforums.com/t/mod-dev-medi...4232377/page-6

[NiMa]

Secure Boot is mainly due to the fact that the new devices are using a MediaTek SoC (the older ones were using the Freescale/i.MX platform) Whether or not it was Kobo's will to include it, it got there anyway, either because it was the standard for such boards and the devs were too lazy to change it, or maybe it really was a thought-out decision.

Either way, it is pretty disappointing. We are currently trying to find ways to circumvent that restriction as I am writing.

[foosion]

Will this let them restrict patching, nickelmenu, etc?

[NiMa]

Not yet. But who knows what they are planning...

[elinkser]

Originally Posted by NiMa

Not yet. But who knows what they are planning...

Although, I believe it is the same device (edit: family) as for the Ellipsa2e, so that bodes well.
https://en.m.wikipedia.org/wiki/Kobo_eReader

Unfortunately, it's not one of the PostmarketOs supported devices:
https://wiki.postmarketos.org/wiki/Category:MediaTek

Reading up on it it seems complicated to bypass and many experienced devs have bricked their expensive devices. I saw an old guide to the boot process if any one is interested.
http://www.lieberbiber.de/2015/07/04...and-preloader/

Good luck - you're braver than me!

[NiMa]

Thanks for the link.

[krob11]

For work with MTK processors: https://mtktool.com/

[NiMa]

Thanks for the link too. Do you know if any of these tools have a chance of working with the obscure series of MT8512/MT8110/MT8113 processors?

[krob11]

MT8512 SDK: https://stash.phytec.com/projects/AS...673244282d185d

[NiMa]

Thanks again for the link. You are welcome to join our effort to find a workaround (I see you have a Libra Colour too). Any help is appreciated...
https://discord.com/invite/uSWtWbY23m

[pazos]

It isn't a big deal (yet!). I doubt it will be an issue for running third party apps in the long run, but more on that later.

Docs to grasp the architecture of Mediatek secure boot: https://mediatek.gitlab.io/aiot/doc/...cure-boot.html

That's probably what Kobo or its OEM follow for this board.

The key is to understand that secure boot/verified boot is a chain of trust that starts in BootROM and can go up to the root filesystem, efectively locking the system if that's the intention of the manufacturer.

On a regular computer the chain of trust ends with the 2nd stage bootloader, which needs to be signed with Microsoft approved keys.
On chromebooks it goes up to the root filesystem via dm-verity.

The way chromebooks and android implement verified boot is the "standard" way on linux OSes and the route to follow for third party OEMs. If kobo wants to do this they need to:

1. pass the hash key of the read-only rootfs as a kernel command line argument (thus available in /proc/cmdline)
2. the kernel will then verify the block device isn't tampered.

That's doable and there's nothing wrong with it but there're other clues that would point they're trying to achieve verified boot on kobos:

A/B root: because updating anything in the AP, such as the final reader application, involves, at least, a new hash for the new rootfs. Things might go wrong with an update so the ability to fallback to a previous version is a must in those cases.

Two kernels: even when kobo rarely updated a kernel on a production device, you must want two slots for two different kernels (even if both contain the same) to implement A/B root properly.

Two root filesystems.

Even with a full chain of trust up to the linux userspace, that doesn't mean the device is locked (the kernel really is!). It is up to the the manufacturer to provide a different, not "dm-veritied" filesystem for storage persistence. Overlayfs might also be used to make a regular linux system to play nice with read-only rootfs.

[pazos]

We still don't now if SecureBoot is enabled (via efuse) on that board. The BSP might provide an u-boot source tree that's able to deal with verified boot but that isn't enough to enforce the chain of trust.

If uboot verifies the kernel but nothing verifies uboot it should be possible to overwrite uboot entirely.

Also we don't know what happens if the kernel signature doesn't match. Since u/NiMa has access to the serial port I would suggest to check:

1. If uboot prompt is available
2. There's no watchdog to trigger a reset on the AP after a few seconds standing at the uboot prompt
3. Try to load a kernel image to ram and jump to it, see what uboot does.