[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNU-linux-libre] Fully FOSS Tails OS
Denis 'GNUtoo' Carikli
Re: [GNU-linux-libre] Fully FOSS Tails OS
Sun, 15 Jan 2017 23:31:29 +0100
On Sun, 15 Jan 2017 11:16:00 +0000
Kurtis Hanna <address@hidden> wrote:
> It's funny that you could use the Heads bios replacement program to
> boot into Heads the distribution once it is published. Ha ha. A
> Heads+Heads stack! That's almost as funny as a Heads+Tails stack.
When you think about it, making the boot firmware and a distribution
like Tails work together improves the security a lot.
ChromeOS and Tails also have lots of similarity, the use case and the
fact that both rootfs are read-only are.
Let's say that you don't trust storage devices because:
- They have non-free firmwares, such non-free firmware have access to
- The OS and other software(bootloader, etc) using them makes wrong
assumptions. They assume they will work correctly, and if you ask the
same block twice, it will contain the same data. Unfortunately
TOCTU attacks are posisble, there is some literature on it:
- Travis goodspeed talk on what it's possible to do
- Real example: https://github.com/kakaroto/PSFreedom
So it would make sense to prevent the firmware of the storage devices
to temper with the filesystem. It can be done by:
- Adding dm-verity to Tails, this is what chromeOS uses.
- Enabling the user to verify, from the boot firmware, that the kenrel,
initramfs and kenrnel parameters have not been tempered with.
This can for instance be done with GRUB by:
- Enforcing signatures (this is just to avoid TOCTU, it can be
enforced only when the user intend to boot tails)
- checking the gpg signatures before booting Tails.
This can also be done by using a GNU/Linux payload and:
- Copying the kernel and initramfs to check from the storage device
- Checking the signatures in RAM
- Booting them from RAM.
I tried to do it, and failed: I never managed to create a livecd image,
despite trying many times. The cause might be related to the ultra slow
speed of my Internet connection at the time.
> I know! I'm extremely excited for the possibility of this happening!
> Also, the Tails to Arm port keeps progressing at a steady pace:
Wow, I've been waiting for it too. Especially a port of the tor-browser
ARM has many advantages:
- There are many many ARM computers that can run only free software.
It's easy to find some SBC that can be used as main computer.
- The ARM diversity can also be an advantage. You have many devices
with many different features and form factors.
- It opens new security models: we can now have stateless computers
very easily thanks to the bootrom. Nothing is stored on the computer.
Everything can be stored on a microSD (which has non-free firmware
unfortunately). The bootloader can also be stored on a flash chip on
- We (The free software community) can actually build (and sell) our own
ARM computers. Doing that in a way that respects users freedom on x86
is not possible. On x86 the only way is *not* to build, but
to repurpose old computers.
- I've also made a compilation speed comparison between one of my
i945 thinkpads (that are 10 years old), and the c201. The compilation
took 1/4 less time on the c201. So ARM is not *that* slow compared to
some older generation libreboot compatible laptops.
I didn't do tests with GM45 Laptops, but I'd expect the GM45 laptops
to be faster than the C201 though.
- ARM chromebooks have a free software embedded controller.
> Can't wait to run a fully FOSS version of Tails, fork or not, on a
> brand new store bought ARM Chromebook that's been liberated of all
> blobs by flashing it with Libreboot. Bonus points if the security
> aspects of Heads the bios replacement is ported to Libreboot.
Beware, that one has a glossy display. Paul Kocialkowski has been
working on adding two tegra chromebook which have a mate display.
Thanks a lot for working on an FSDG version of Tails!
We built u-boot for the LG optimus black in both computers and
compared the time it took to build. It was measured by recording the
timestamps before and after the compilation.
I suspect that some of the effects are due to the need to accomodate
quickly between the reflection and what is displayed on the screen,
hence producing the srain.