“In general parlance, bootstrapping usually refers to the starting of a self-sustaining process that is supposed to proceed without external input. In computer technology the term (usually shortened to booting) usually refers to the process of loading the basic software into the memory of a computer after power-on or general reset, especially the operating system which will then take care of loading other software as needed.” -Wikipedia
This is the first post in many about our hardware adaptation project for the Jolla Tablet. Hardware adaptation is the activity in which we tie Sailfish OS together with a piece of hardware and the drivers for it. It is our hope that this will give you an unprecedented view into the world of how you build some parts of a tablet. It may get a bit long and technical, but feel free to ask to have some things elaborated further if you want.
Before our designers, care, marketing, program management, infrastructure, testers, UI coders, core and middleware developers can really truly do their work, we need to give them some hardware with a combination of Sailfish OS and a hardware interfacing on to develop, prepare test, design and experiment on. Because it’s no fun developing with a device that can’t e.g. show an UI with Sailfish OS, take a picture or play a sound.
The duty to make this happen is that of the hardware adaptation team. I.e. to bootstrap the device to work. Do note this does not mean that our developers can’t already develop things (we have the Jolla phone, SDK emulator, etc), but it’s much better to develop using the target device to get the experience right from the start.
Working with the ODM and chipset vendor
Like many other companies, we are working together with an ODM (a company that manufactures a product as specified by its customer company) to produce the Jolla tablet. When you receive a piece of hardware from an ODM, you don’t just get a blank device with an empty disk, you get a hardware design along with a bunch of software components that fits with the specific hardware of the device.
The situation is however today in the mobile industry that while you can get a great hardware design and a stable software delivery matching this hardware, these software deliveries are typically drivers for Android. This is a very real pain for non-Android OS’s: You can of course try to get custom drivers matching your particular OS, but this involves a lot of money, support from chipset manufacturers, a lot of pain and time that could be used instead to make your tablet experience greater.
This is the case with the Jolla Tablet as well: we have drivers for Android matching the hardware. It is the norm in the industry that these specific software deliveries contain a majority of closed source parts that are not possible to share outside Jolla and the ODM. It is very hard or near impossible to find a competitive price and effort-wise hardware with fully open drivers.
One of the main advantages of Sailfish OS is that it is able to leverage existing drivers for Android through a technology called “libhybris”. The driver infrastructure of Android is very tightly integrated together, e.g. if you are using camera drivers made for Android, you have to leverage their software infrastructure for graphical buffer allocation. Which in turn means that in order to bring those camera images into your UI, you need to render with Android GPU drivers.
We do not have the capacity to write native Sailfish OS drivers for many parts of the devices. Especially parts like modems, GPUs or cameras, and embarking on a journey to enable custom Sailfish OS adaptations for certain chips is not a direction we want to go. We’ve tried this before and it was not a good experience. We can only hope that one day through sheer volume of Sailfish OS devices, adapting hardware directly for Sailfish OS by chipset vendors and ODMs will be the norm.
This causes us to focus at what we’re good at: delivering a great UI experience for our users, making great interfacing towards the chipset vendor + ODM software deliveries and to build an operating system platform. We re-use as much as we can from the HW software deliveries. And we know that those drivers are working today, as in, they are known to be working and are performant. Not having that is extremely painful.
That means also that we can receive support from ODM and chipset vendors when there are problems in those pieces. We have applied this same model to our first product, the Jolla smartphone with great success.
After we shipped the Jolla smartphone, we worked with our community to make it possible to put Sailfish OS on a lot of different existing Android devices. This was done and evolved through a document called the “HADK” (Hardware Adaptation Development Kit). HADK is a set of very useful methods and instructions on how to take Sailfish OS, and an existing Android software delivery for a device and create the interfacing configuration and code to make Sailfish OS work with a device.
First things first
Let’s take a look at the tablet. It has a 2K (2048×1536) display with a capacitive touchscreen. It has an Intel Z3735F processor; quad core 1.83ghz with an Intel HD Graphics GPU, with 2 GB of RAM associated to the CPU. It is capable of running 64-bit software. It has a microSD card slot, 32gb of eMMC storage (though my exact development device has less) and a few buttons, power button, volume up/down. Along with that, a 5MP rear, 2MP front camera.
Before doing anything, we built the (Android 4.4 based) software delivery using instructions from the ODM and flash the result to the device. Initially we flashed under Windows, but eventually we found out that the device supports a “fastboot” mode, which is a mode and an associated utility to flash images to a device. It was possible to get to this mode by holding down volume down and the power button on the device.
When the device to our relief still booted up, we went onwards to check through that every part of the hardware still worked through a number of test applications listed in the HADK*. It is a real pain to debug hardware interfacing and then discover it doesn’t actually work in the software delivery or the hardware is broken or missing. So, this particular thing potentially saves you a lot of time. All tests passed still. In addition, we made sure we could forcibly turn off the device by holding down the power button. This also comes in handy surprisingly often.
First thing we discovered as we rummaged through the device was that it has a 64-bit Linux kernel and a 32-bit software stack (userland). This seems to be standard on Intel Android 4.4 64-bit devices. This means that we have to use Sailfish OS for 32-bit X86, which it is already ported. You cannot mix 32 bit and 64 bit code in same process.
Additionally to that, we discovered that the tablet utilises UEFI & SecureBoot for bootup along with using cryptographic signing of the individual elements in the bootup process, down to the boot loader, kernel and kernel modules. We know that this is a sensitive topic. So here’s the deal: UEFI & SecureBoot are a bit new for us coming from the ARM side.
Balancing hackability and privacy/security
The story of Jolla is such that we have built our own OS utilizing “hackable” devices (as in, able to load another OS on a device) and we wouldn’t be able to exist today otherwise. We believe that it should be technically possible to run alternative Linux operating systems on our devices by people outside of Jolla.
We already know that it is possible for us to build a signed Linux boot loader that will load unsigned boot images and we’ve tested this already. But a boot loader that loads unsigned boot images can have other consequences in terms of security.
Here are the technical basics:
- It should be possible to enable or disable entering UEFI settings/UEFI shell at boot-up through a key combo – in there you can supposedly set up your own UEFI PK/db/dbx etc. keys
- It is possible to reboot into UEFI settings from Sailfish OS
- efilinux is used and has to be signed by something in UEFI PK/db/dbx and it can check signatures of the Linux kernel+initrd (boot images)
- We don’t currently use UEFI shim loader so no MOK functionality
- Kernel uses/can use CONFIG_MODULE_SIG kernel option
- There’s no ‘fastboot oem unlock’ functionality currently, but flashed images need to be appropriately signed towards SecureBoot configured keys in order to boot, but efilinux can be modified
This is an invitation to discuss how we should make a device security configuration that has appropriate balance between hackability and privacy/security. Nothing is set in stone but there might be hardware or technology imposed limitations. Mobile devices are a very typical target for attacks and people often lose them out in the wild so this is a high priority. If you are utilising IRC, feel free to come and discuss with us and other porters of Sailfish OS at irc.freenode.net #sailfishos-porters. Let the discussions about this particular topic begin! I believe we can find a strongly secure and technically sound solution together.
With this added understanding of the device, we’re now ready to instruct our infrastructure to make a Sailfish OS software release for the device and attempt to reach it from the other end of the HW software delivery through the instructions in the HADK. But that’s a topic for another blog post.
I hope you’ve enjoyed this post, despite it being long!
Thank you for this very interesting insight.
So you have to use the x86 architecture and can not use the x64?
I will come to the IRC maybe later, but for the first:
You don’t know at now, how you could access the device without destroy the security configuration?
Indeed, we need to use X86 for the userland. The kernel runs X64 just fine, as well as bootloader. If people truly wanted they could run 64-bit things in chroot.
So, if I wanted I could run OpenSuse in a chroot? Seems like a best of both worlds approach.
Or rather, using LXC. That’s generally a better idea if you want to isolate both systems, and avoid having your “guest” screw something up on the host OS. I don’t know whether the LXC tools will be available in the default repositories, though (they should be!).
On the issue of security, is there no way to offer the end-user some choices? I would imagine that some tablets will face greater security issues than others in daily use, and different users will have very different opinions about how locked-down they would like their device to be. Perhaps an optimal solution would be to have the tablet locked-down by default when shipped to the average user, but give the option to those who want it to receive a more open device…
What about password protecting the relevant menu and shipping the password to the user on a piece of paper ? So that any hypotethical bad guy can’t install malware on it if you leave it unattended somewhere.
Alternatively what about the “wipe all data to unlock” think the Nexus Android tablets reportedly have ?
Well, wipe all data to unlock is a decent direction but at same time, if I lose my tablet, I’d personally like to have it worthless to the one who stole it. Password protecting is one direction you can do (albeit I’m not sure about “BIOS” password security in this day and age.. CMOS batteries come to mind – or is it all in Flash nowadays?).
The problem with setting ‘your own password’ is that it needs to come from the user, I haven’t yet found out how to programmatically set it .. and there’s no on screen keyboard in BIOS so you’d have to drag out a USB keyboard..
If we pre-set it, the code needs to be along in the sales box or otherwise retrieved online..
Well, once my tablet is stolen I can say that I don’t really care if the one who stole it is able to use it or not – it is not like it would make him return it to me. Especially if it meant preventing me from using the hardware as I will. 🙂
Actually, a usable tablet leaves some possibility of the thief being caught when trying to sell it VS not possibility due to the device just ending in a random landfill. 🙂
As for the lack of on-screen keyboard in the UEFI menu:
* I think USB keyboard is just fine for the type of users fiddling with the menu 🙂 especially for on-off action (turn off secure boot, etc.)
* if it supports touch, some sort of simple numeric keyboard might not be so difficult to hack together
Actually when we have USB devices and the micro SD card, what about supplying the key through that ? It could for example check for a partition with a specific GUID and if found, check for a file in the root with a specific name like unlock.txt.
As for where to get the key, there are various possibilities:
* ship it on a cheap flash drive with the device
– can be lost
– many might not need it
* get it from an online service after authenticating with the Jolla account (how to pair tablets to an account ?)
– dependency on an online service
* timeout based service – gives you the key after a week after inputting the serial number of the tablet (or something similar)
– users would be able to report their tablet as stolen, cancelling any requests for the given serial number
– still a dependency on an online service
Still I think there should always be some sort of a backup (wipe all and let me in) so that the tablet remains “free” if the physical key is lost or the tablet is resold, the paring is borked, mistakes with shipping get tablets and assigned keys lost, online service not being reachable for various reasons (blocking, network troubles, no Internet) etc.
Regarding ‘able to use it’, it is sometimes a deterrent to stealing even in first place:
http://www.zdnet.com/article/fcc-report-apple-iphone-activation-lock-significantly-reducing-theft-rates/
I’d like to somehow avoid making tablets that require a service at Jolla (keeping physical or digital services cost, too) or even Jolla existing in order to ‘unlock’ it. How difficult it is to deal with a N810/N900 in this day and age should be a good example.
Just a quick note on a pre-set code needing to be in the sales box or online, as mentioned by Carsten: I had assumed that such a pre-set code would not be in the box, nor online, but rather mailed separately to the customer via a physical piece of paper. (That’s generally how my bank has handled such things in the past.) Maybe not a perfect system, but at least an alternative method to consider…
There’s always possibility of choice. But some sane defaults are needed – hence this initial discussion. Losing your tablet in a plane or bar is a very real scenario and basic privacy is something I personally consider important.
“Sane defaults needed” — ok, but if you already know that your target user is going to lose their tablet in a bar, and you already know you have to hardcode the OS in order to save them from this dire situation, what is the point of having a discussion? 🙂
Honestly, the people who like the way privacy works in modern mobile devices probably aren’t going to even bother adding their voices here. (And they’re probably not going to be the folks most interested in Jolla to begin with…)
So yeah, I’m one of those folks who would like to see a piece of mobile hardware that works like my desktop hardware — give me the final say over the OS that actually runs on the thing, and let me deal with the liability issues myself. I’ll sign a waiver or something if you’re really worried about legal issues. 🙂 I think there’s a decent-sized market out there who crave this kind of control…
The question posed in this blog is exactly that, how do you make the right toggles or options for people who’ll happily waiver 🙂 Some might want to have their own kernel but not give up on rest of security.
Ah, ok. 🙂 I have to admit that I don’t have anywhere near the know-how on hardware to provide any new options for you myself. Really, the only thing I can say is that I’m one of those folks tired of the “no, you’re not allowed to install your own software on this hardware you purchased” line we’ve been getting from, well, absolutely every mobile device producer in existence… 🙂
So you really are using android libs at all? I thought because of brilliant x86 support you’ll use more native linux libs. Like mesa and wayland for gfx
I’ve tried to allude a bit to the reasons for just reusing the Android drivers we have. The problem is that the moment you select some other SW for interfacing than what your ODM delivers, you don’t have support for that part. I’m welcoming everybody to help out getting Mesa/kms/gbm/Wayland going on the tablet – I can help test. I’m sure there’s people who’ll want to run with more open drivers. We do already use Wayland, but on top of libhybris instead.
An immensely better, more informative and grown up post than the toe-curlingly bad Mosconi one. Would like to see more of this.
However, I find it more than a little disconcerting that Carsten continually uses the mode of phrase “discovered”. Surely many of the features or limitations that are being ‘discovered’ by Jolla should have been known before any deal was signed with Intel / the ODM? It seems bizarre that the hardware adaption team had to find this out for themselves.
Also, if I’m reading the tone of the post right, it may be very difficult to have an unlocked bootloader or support the installation of different ROMs whilst maintaining any semblance of security. Having some experience and knowledge of UEFI, one of the reasons for its adoption was that Wintel wanted more control over what operating systems could be installed on desktops, laptops (and tablets). Indeed, there was much worry that desktops or laptops sold with Windows would be locked out of installing Linux or BSD before UEFI BIOS based motherboards launched. I guess if you’re going to work around it, then you’re left with precious little in the way of security.
Indeed – and that’s why I’m reaching out to see what we can figure out what to be done. I’d be interested to discuss the UEFI/SecureBoot aspects deeper with you, if you’re interested too.
I’ll take it as a compliment that my post isn’t toe-curlingily bad. I’ve tried to make a post that explains a bit the exploratory process of a new hardware.
Working with ODMs is worth of an entire blog series in itself. To make a long short short: In order to work well with an ODM you need to ask many questions and more importantly, know what exact questions to ask. Unless you ask, you’re not going to get answers. Exploring a device is a good way to figure out what questions to ask, both for internal SW planning and for product planning. Often the real useful documentation is first available past signing contracts. There’s nothing ideal about this process as it may easily be imagined to be but when you have experience in dealing with an ODM in general, you know a lot better what to ask next time around.
I must say I second Meowmeow in his concern about ‘discovering’ the breadboard you specified. At least as concerns the UEFI feature, that to me appears an enormously salient point regarding openness and privacy…
I do understand already that we are constrained by android drivers reuse (which I fear will slow the device already and impose closed software in many parts); but now by adopting the UEFI default it may well give the outside impression that what we propose is little more than just an original rooted device locked in with our own system…
Ok, it’s better than Blackberry and I’ll buy it, but I really see the negative comments coming in even before the tablet exists…
Am I too pessimist ?
Aren’t software firewalls reasonably efficient already ?
Well, in itself UEFI isn’t that evil. It’s significantly saner than old style MBR booting. Part of the reason I want to have this discussion is that we end up with a solution for device security, openness most if not all think is sane and technically evaluated. You can never stop negative comments and personally, if somebody brings a negative comment along with ‘here’s how to make the situation better’, or better yet, a patch, then it’s doing it properly together.
I’m sorry, I’ll never ‘bring a patch’, I’m not at all capable of doing this.
But I fear we are confusing priorities here.
We are talking boot and UEFI like if there was a important danger of being attacked by ‘pirats’ during boot time.
I consider this danger is absolutely zero, and will stay zero until Jolla OS has become a significant player in the market.
Which is not at all the case today, and won’t be during the whole physical lifetime of our coming tablet.
The priority for Jolla and Jolla users is obviously independence from Google/Apple and other quasi-monopolies: there, we have an important issue.
Things like firewalls, filters à la Little Snitch (on OSX) or Peer Guardian on Linux are to me extremely important.
At the very least something like the Android AFWall+ is of the essence, at Jolla OS level.
This, is important.
In contrast, disputing about how to harden boot time through UEFI is almost of no importance for me, because I already know just nobody will try to tamper with Jolla OS itself for at least a couple of years.
I am just sad because imposing UEFI, seen from my remote, stupid, end-user perspective means less freedom for the end-user. That’s all. It’s much smaller a concern than the fact we rely on a lot of Google apps, for instance. It’s almost minor. But it remains a concern.
Now, you can just delete this post, since you apparently find my concern is ‘negative’ and I don’t bring you a patch.
Just to clarify, I don’t refer to your concern as negative, moreas what you referred to negative comments coming in. It’s a very valid concern what you’re having.
A blog comments system is a bit difficult to really go this in depth. Could you message me ‘Stskeeps’ on IRC/irc.freenode.net #sailfishos at some point and I’d very much like to talk to you and hear you out more as I think I could learn something from how you feel about this.
OK, thank you Carsten. I’ll try to do this in the coming days!
Speaking about security there is one thing I’d like to put under consideration of brave sailors. OS behaviour in case of known events, and especially one of them. A time ago, in Symbian when any connection would happen, or more precisely a demand for outgoing connection from user’s device, OS by default asks user for a permission for such outgoing connection. So, even if a malware would happen and would try to send sms or to make a call (eg. a cost-full connection to sexline or other continent, and this way collect money for malware author from a user’s account) – then it was possible only if user manually would allow a connection.
I think this is the good behaviour of OS, as it prevents unauthorised overuse of device and user finally. Will such legacy of Symbian behaviour be implemented? Even when FB etc. staff set on constant monitoring can complicate, I think this can be useful. And prevent a whole bucket of spyware/malware from enemy activities, IMHO.
Just an idea for consideration: lets use legacy of good practices and behaviours from Symbian and MeeGo, but only those which are worth of this because of advantages.
I’d like to point and say loudly about one essential problem with Jolla smartphone IMHO: it is only single-SIM. How about tri-SIM and dual-SIM? This is really needed, in fact its a must. For those have tried and use tri-SIM and dual-SIM there is not way back to ancient single-SIM devices.
One transmitter is enough, as most users accept can accept having one call at a moment only, while rest 2 SIMs appears as “out of range” or similar.
My point (idea) is following:
Sailfish should have possibility to declare an n number of SIMs, where n is natural number. So, building an distro/OS for a particular device would be possible to declare how many SIM ports are to served in a particular case.
Single SIM is also a significant limitation and does not allow use existing hardware (eg Android mobiles) of tri-SIM and dual-SIM in effective way when it have tri-SIM or dual-SIM.
Tri-SIM does not drain a battery – I’ve checked by own experience using tri-SIM in daily practise, so it is not any argument against. It is more about display and WiFi searching all the time.
It also eventually could be used for access control systems when a SIMcard would be an access card – if somebody would like to create something like that.
When can I buy tri-SIM Jolla??
Talking about security: how can I logout from here? Am I logged forever? I think after a time without activity I should be automatically logout by default? Could I set this time in my profile settings? Seems this blog has a bug or wrong settings in this area. How to logout?
Thanks a lot for talking technical to us, Carsten. So many company blogs write small talk and marketing instead of the technical aspects of their devices, reading this piece was a joy!
I love the premise of the Jolla Tablet’s open bootloader. The Intel Atoms are quite powerful beings and having the ability to test it out in other operating systems instead of being locked into a single one is very promising.
Thanks a lot for the update, keep on blogging and good luck!
The big question is what does a open bootloader consitute of, how does it balance with a user’s privacy. I want a open bootloader. But I also want my data private if stolen or somehow in the hands of an evil maid. Finding the right balance is part of what this blog post is about 🙂
Must there be just one balance? Sure, go ahead and provide a highly secure, closed solution for the default user. Then, give those who care less for their privacy the option to have an open piece of hardware.
It just seems to me that if combining openness and privacy is a really hard task, then the solution is to _not_ bother trying to combine them in the first place. 🙂
Or perhaps provide the knobs to make it as secure but where you’re in charge?
Sure! But are you going to have enough time and resources to accomplish this feat? 🙂 No other device manufacturer seems to have gotten away with it — everybody’s gone completely closed with their devices.
If you can do it, great! But my worry is that given you’re at the mercy of your hardware provider, that you’re limited to using their drivers to maintain their support, and that you have real-world deadlines and resource limitations for this project, any hope of implementing serious security is ultimately going to have to use the standard, and therefore completely closed, systems already available.
Yeah, I’m being paranoid here. 🙂 But if this turns out to be the case, I’m hoping that you’ll still provide an official mechanism to unlock the machine. 🙂
Maybe using an hypervisor and virtualizing the hardware cold be useful.
The first part about the drivers lack is somewhat theoretical. Can you please go into detail what exactly is lacking in open and / or native drivers in this particular case for the tablet? Are there SoCs from Intel which have all needed open drivers or they don’t exist?
You mentioned in the past that Mesa Intel driver doesn’t provide enough performance. Can you please elaborate on this?
I’ve tried to explain this through the fact that if you’ll want to use, let’s say, video encoding/decoding or camera buffers, you’ll need to use the Android drivers, which in term means you need to use Android gralloc, which in turn means that if you want to have something showing on your OpenGL interface, you’ll need to use Android OpenGL drivers. Performance is also about productization. Known working trumps may be working.
> if you’ll want to use, let’s say, video encoding/decoding or camera buffers, you’ll need to use the Android drivers
Is this about hardware accelerated video encoding / decoding using some dedicated chip on the SoC? So basically Intel provides some software module for that (I guess blob with no sources?) which is built against Android libraries (bionic and OpenGL), right? That’s indeed a major roadblock.
For instance Nvidia provides hardware accelerated modules for gstreamer integration in their Tegra packages (for Xorg though, not for Wayland yet). Doesn’t Intel have anything similar?
> Performance is also about productization.
Just to clarify, so you didn’t mean that let’s say you tested Mesa in this case and it didn’t have enough performance (computing wise), it’s more about ODM providing easy bundle of Android stuff and everything else requiring lot’s of manual assembling?
Yes, camera & video enc/dec is certainly very tied to Android drivers. We also need to in order to have a performant UI use on 2K resolution, use of hardware composer to layer things together with hardware, where this is a thing that’s not well developed on KMS side. But where we know for sure it’s working properly and is productized with Android HW interfaces.
I’m still interested in volunteers that’ll help put a Mesa configuration together for the tablet, so I can test it out early, for those who’d like to use more open drivers.
Also, why isn’t Intel making their Android drivers open?
And if they invest in Mesa and Wayland development doesn’t it make sense for them to reuse the effort? Did you get any help from Intel Wayland team in general?
You’ll have to ask Intel about that. I had hoped for Mesa on Android too. But they’re not using that, they’re using something called “UFO”. From what I know, Kristian Hoegsberg is doing something else than Wayland in his work. Remember that as a product programme, our primary interface is with a ODM, not a chipset vendor. Support requests go through our ODM. You cannot rely on having a close relationship with a chipset vendor in this day and age.
Is there a TPM device onboard?
http://www.intel.in/content/dam/www/public/us/en/documents/datasheets/atom-z36xxx-z37xxx-datasheet-vol-1.pdf talks about TXE around page 199.
Nice post. Keep them coming.
I assume that many backers (like me) are interested in hacking on this device (i.e. running other Linux distros). Opting for Intel GPU will help tremendously (yep, I’m looking at you PowerVR :D).
If you ask me, option to disable Secure Boot is a must have; and/or a straightforward way do add user keys.
I don’t care much how to switch device to “developer” mode as long the option exist and it is documented (including open-the-case-short-the-pins-x-and-y).
Also, please consider sending some referent/demo/RC devices to active community members/developers (to name the few from the top of my head: Matthew Garrett, Daniel Stone, Dave Airlie, Bryan Lunduke) who are passionate about FLOSS and could help with bootstrapping the hackabilty aspect.
If we’re looking at the Jolla device it was practically you could enable developer mode and no restrictions in that scenario. I’ll note the idea of demo devices to active community members. It’s not a PowerVR.
I think UEFI shim with MOK management could be interesting.
One of the management schemes I really like, which may not be possible due to alteration in hardware design, is to enable key management (and “developer mode” in general) with a hardware switch. It unfortunately doesn’t protect against an attacker with physical access, but I think most of the threats these days are remote.
If the hardware can’t be modified, then maybe dev mode can be enabled with a unique hardware token, like a NFC or USB fob containing a particular key. Still requires physical access, but no extra switchgear. And maybe once you unlock it, you can do things like update it to key on a different fob, require fob to boot or unlock, etc.
Very interesting post, which I am in the process of digesting.
Quick question: Where is the ODM, who is responsible for building the tablet, based?
a beautiful technical post, thanks for all the stuff. I wish for more insights on how Jolla team works behind all ‘toe-curling’ (which was not bad after all imo, but not what we wanted to read).
Another question: if the hardware team is done with Jolla tablet and has nothing special to do, will they start to bring Sailfish on android devices as well, or will this be left by free time developers?
I could imagine to pay some money to get sailfish ported correctly on my Moor and on that conference (I don’t remember if it was Slush 2013?) Marc said it takes one night to create a fairly working port on any existing Android hardware.
Just a question, that is not so related to the technical aspect.
Regards, Kai
We’ve already had an ongoing project where we work with community to bring SailfishOS to existing devices (hence the HADK). The model that’s been taken is teaching how to do it and helping out where we can; because then our skills are also better for when we adapt for new Jolla devices. #sailfishos-porters on irc.freenode.net is where people gather; and a lot of threads on xda-developers.com. There’s just too many devices out there to support all of them..
I would be interested if Android 5 (Lollipop) was already ported to this device by the ODM. If it would be possible, I think that it may be better to base the work on this, due to the better support it has for 64 bit (my guess, although not confirmed, is that the userland applications would be 64 bit on the Intel platforms for Android 5).
As for the security point of view, here is how I would personally would like to see this done (in order of highest preference first):
– If possible integrate the oem lock/unlock functionality within fastboot. This would give the ideal level of security while offering the best and most reasonable way to modify one’s device when wanted. The blog post mentioned that it is not currently supported, which leaves open the door that it may be possible. This would be the best option. If you can not get support from your ODM to enable this, I would directly reach out to Intel. They have been working hard to get their Bay Trail platform into mobile devices, and in my experience are very good to work with (especially if you can and feel okay with getting an NDA with them).
– Otherwise, it seems to me that a home-grown option may make sense, somewhat similar to how Google has the option to enable developer mode on a Chromebook. It seems that Google has done this on the Bay Trail platform as well (on the Swanky code-named Toshiba Chromebook 2, which I am typing this on). It may be worth a check into if this could apply to the startup process for Android on this similar processor.
– The least preferable option would be to have a device made either open or closed when assembled for shipping. At least here, for any given order, one could request a “developer-friendly” device, or a “fully secured” device. This would require two different devices at least logically from some point in the assembly line, so it is not at all ideal from Jolla’s perspective too…
– The completely last option would be to just leave all of the first batch of Jolla tablets open. I would highly prefer this to “fully secured”. Since the whole idea of this tablet launch seems to me to have been a trial of the whole Jolla tablet concept, this seems reasonable.
I’d love to have had a 64-bit base too, but it would also mean more work in us validating SailfishOS for x86_64. We’ve validated 32-bit x86 quite intensively due to our SDK, build infrastructure and emulator, so it’s more workload in a tight schedule.
oem unlock sometimes also means ‘delete data’ on some devices. Which may make sense from privacy point of view, but it also potentially means that I can be tricked with a new OS.. Do we want oem unlock only with a code? Lock code as set in OS?
Developer mode in ChromeOS is something I need to look into, they for sure use some UEFI stuff there.
Open or closed in assembling is not something you’ll ever want to do, it simply causes too much cost/trouble in order fullfillment/care when device is swapped, etc. At setup time in SW is much saner.
Leaving it open is also an option but I believe it can be done better. Security off by default doesn’t seem like a sane direction in this day and age.
Hi, I would like to ask for something similar as S Note in Jolla Tablet, do you think it could be posible?
best wishes and lots of fun and force in your work
Great post Stskeeps. It is toe-curling however mostly due to the OLD boot nastiness, for example Javispedro’s question about TPM is particularly frustrating. Intel does a lot for free software, but other parts of Intel are actively harming user freedom.
What does Tizen do? I can’t imagine they’re using Android drivers given that Intel has invested so much in Wayland. Has Jolla taken a good look at that OS?
Hi. I’m looking forward to the delivery of my tablet from the (projected) May, 2015 batch. I’ve been bootstrapping hardware, and writing drivers for various OSes, since the days of wirewrap and big DIP packages. If you still haven’t figured out 64-bit support by the time mine comes in, I’d be interested in signing the I’m-sure-necessary NDA and seeing what I can do to help. I’ve watched the x86 catch up to the 32-bit 68K (among others) and, now, the 64-bit SPARC, so I’d like to have that addressability and integer width on my tablet, too.
gcuser, the challenge is that sometimes these things are NDA’s we can’t give (as it’s not our information/code), as that work has to happen in the chipset vendor and we may not even have access to work on those parts, or source code available. You should be able to run 64-bit programs with a lot of grease work, but you’d loose access to 3D rendering, etc.
Hi,
why don’t you use coreboot (coreboot.org) as BIOS for this platform ? Instead of using the UEFI crap.
You could ask http://www.se-eng.com/ to do the support if the SOC vendor is unsupported.
I guess normally it shouldn’t be a big deal to adapt coreboot in order to run on the choosen tablet platform.
Regards Zaolin
Very good post. Very interesting. Very honest too. Which logically makes two of your paragraphs quite disturbing: “First thing we discovered as we rummaged through the device was that it has a 64-bit Linux kernel and a 32-bit software stack” & “Additionally to that, we discovered that the tablet utilises UEFI & SecureBoot for bootup along with using cryptographic signing of the individual elements in the bootup process”. Anyway, still much better than trying to hide those information under the rug.
I really enjoyed that post, but Carsten, please don’t be such a brag – it was not that long. (TWSS)
Also, I second Herve5 posts in every aspect.
On a side note, your “Hardware Adaptation Development Kit” – HADK – sounds like a Terry Pratchett’s Discworld(C)(R)[TM] dwarfish noun. So I guess your an equal heights company ? 😉
MORE!!
(please)
Interesting article, thank you.
In terms of security I’d prefer that the tablet arrives in an “secure” and “sane” default, e.g. it is locked to only boot/execute trusted software. It should ask the user to set a lock/password to seed the encryption of the user data.
This will ensure that if I “use” the tablet only a lost/stolen tablet will only cost the replacement with little risk of abuse of the contained data.
However an option must exist to switch it at least to “open” (preferably a middle way of adding keys of what is considered trusted as well) where the user is responsible for the security to the level required by the user.
This will ensure that tablet can be used with other OSes as many of the supporters plan I suspect (e.g. I’m fully intending to try a dual boot of Ubuntu, potentially even the desktop option)
How that option is activated I’m agnostic, if it requires connecting a keyboard to enter a code once (which might be published in my jolla store account, e.g. on the receipt) then that is fine for me. It is a one off or at least very rarely required operation.
If possible I’d like an option of a configurable kill switch (e.g. wipe only, wipe and blow software fuse) which is disabled by default.
As the tablet has no built in GSM module I’d probably prefer to trigger on some brute force attempt (e.g. after the 20th failed unlock attempt).
Enjoy, Andre
Thanks for providing us this information and telling people to join you there. I saw many people want to join you for new info and its a great opportunity to have someone best in the computer technology. Also http://hireessaywriter.org/ is the best for students want the best writer for their assignments.