09-16-15 12:21 PM
32 12
tools
  1. Empyrean's Avatar
    Okay, so I know there's some wishy-washiness around whether the Slider'll be black with white stripes or white with black stripes vis--vis the whole monolithic kernel with secured Android apps or QNX microkernel with Android or blah-de-blah-de-blah. I know we have to wait to know for sure...

    BUT for those who know what they're talking about -- is the kernel something that can be "replaced" or flashed onto a device securely? Or does it require some crazy open-up-the-device-and-shortcircuit-something-to-reflash-the-kernel kind of ordeal? Anyone who's hardmodded their videogame consoles knows what I'm talking about.

    The reason I ask is sheer curiosity. I would suspect that, honestly, if the Slider will be available to *consumers* to purchase, I don't think they'll have QNX-secured Android out of the box. Where's the money in that?

    Instead, if consumer-available, I'd think the device would come with Linux/Android and enterprise users will be able to "flash" the device with the QNX/Android. That way, akin to the old BES model, you have end-to-end security contingent upon the entire ecosystem integrating with the hardware. Kind-of like how you HAD to be on BES to activate BlackBerry Balance. I know that's a far cry from an accurate example, but you get my point.

    This, actually, would also be a similar hardware-kernel authentication that I'd expect QNX to have for an IoT (Project Ion) sort of platform as well.

    Thoughts?

    Posted via CB10
    09-10-15 07:47 PM
  2. BB-JAM215's Avatar
    Okay, so I know there's some wishy-washiness around whether the Slider'll be black with white stripes or white with black stripes vis--vis the whole monolithic kernel with secured Android apps or QNX microkernel with Android or blah-de-blah-de-blah. I know we have to wait to know for sure...
    Exactly, so let's wait and then we'll know for sure.
    09-10-15 08:37 PM
  3. matt4pack's Avatar
    I guess it's theoretical that you could swap out the Linux kernel in android with Qnx with some work. Just like you can run KDE and gnome on bsd or Darwin.

    I'm not sure how much work would be involved though and it's probably just wishful thinking.

    Posted via CB10
    09-10-15 09:29 PM
  4. thurask's Avatar
    tl;dr: why spend all the work to replace the kernel when one can harden what's in place?

    Most talk of kernel replacement with regards to Android is replacing the manufacturer's kernel build with a custom one; different versions and/or different build options. Still, it's replacing a Linux kernel with a Linux kernel.

    Replacing the Linux kernel with a non-Linux kernel would need more work, since compatibility between apps and kernel services is not guaranteed if one swaps wholly different kernels. A good example is the Debian/kFreeBSD project; take regular Debian GNU/Linux, but replace the Linux kernel/associated tools with the FreeBSD equivalents. While a good percentage of the Debian software collection is made available for kFreeBSD (around 90%), the project itself has been dropped as an official architecture, probably due to core system software (systemd) requiring Linux and only Linux.

    If BlackBerry managed the Sisyphean task of making sure the entire non-kernel Android experience works with the QNX kernel while maintaining compatibility with at least 90% of all apps (and on a staff of mostly interns from the University of Waterloo, but I digress), they would face two problems. One, the 10% of apps, since there will always be some key customer who requires some app in the 10%. Two, if Google, in its role as overlord of the Android source, implements a fundamental change that locks out the QNX kernel, then BlackBerry would either have to suck it up, or fork their QNX-Android and have even less of a user base than BB10.

    Going back to Debian, their implementation of systemd has led to two things: a fork without systemd, and the possibility of replacing systemd with the old way. In contrast, Google's anti-fragmentation stance means that if they were to make such an atomic change, OEMs have to deal with it, lest they make a fork and lose access to sweet sweet Google services.

    A better, more feasible way to improve kernel-level security is to patch it. This is less effort than stripping out the kernel, forcing in the QNX kernel and hoping it works. In fact, BlackBerry might be doing something like this, according to speculation.
    Last edited by thurask; 09-10-15 at 09:52 PM.
    mrfreeze, BigBadWulf and mithrazor like this.
    09-10-15 09:31 PM
  5. howarmat's Avatar
    in short i will say there is not way to do this with resources that BB has. Sure it can be done but the money involved would be more than its worth AND they dont have the man power honestly. They would have had to be working on this well before chen took the helm IMO to have this done AND be very close to bug free.
    09-10-15 10:02 PM
  6. AnimalPak200's Avatar
    I think we all really wish this could be done by BlackBerry, but all they have been doing lately is 'integrating' already existing companies into their website.

    But who knows... Maybe they left a small Skunkworks team of super engineers work without any management involvement and.. voila, something actually got done.

    Posted via CB10
    09-10-15 10:10 PM
  7. Uzi's Avatar
    Just a month away we will know it soon all rumours will be end
    09-10-15 10:13 PM
  8. Arabianhorse's Avatar
    tl;dr: why spend all the work to replace the kernel when one can harden what's in place?

    Most talk of kernel replacement with regards to Android is replacing the manufacturer's kernel build with a custom one......

    Replacing the Linux kernel with a non-Linux kernel.....

    If BlackBerry managed the Sisyphean task......

    A better, more feasible way to improve kernel-level security is to patch it. This is less effort than stripping out the kernel, forcing in the QNX kernel and hoping it works. In fact, BlackBerry might be doing something like this, according to speculation.
    I am a layman but agree with the path of least resistence (patch).
    Any other pushes them into.....

    Feasibility of Kernel Swapping-sisyphean-task.png

    STA 100-3, SQW 100-4 / 10.3.2.2639
    CygnusX-1 and 00stryder like this.
    09-10-15 10:30 PM
  9. Alejandro Nova's Avatar
    tl;dr: why spend all the work to replace the kernel when one can harden what's in place?

    Most talk of kernel replacement with regards to Android is replacing the manufacturer's kernel build with a custom one; different versions and/or different build options. Still, it's replacing a Linux kernel with a Linux kernel.

    Replacing the Linux kernel with a non-Linux kernel would need more work, since compatibility between apps and kernel services is not guaranteed if one swaps wholly different kernels. A good example is the Debian/kFreeBSD project; take regular Debian GNU/Linux, but replace the Linux kernel/associated tools with the FreeBSD equivalents. While a good percentage of the Debian software collection is made available for kFreeBSD (around 90%), the project itself has been dropped as an official architecture, probably due to core system software (systemd) requiring Linux and only Linux.

    If BlackBerry managed the Sisyphean task of making sure the entire non-kernel Android experience works with the QNX kernel while maintaining compatibility with at least 90% of all apps (and on a staff of mostly interns from the University of Waterloo, but I digress), they would face two problems. One, the 10% of apps, since there will always be some key customer who requires some app in the 10%. Two, if Google, in its role as overlord of the Android source, implements a fundamental change that locks out the QNX kernel, then BlackBerry would either have to suck it up, or fork their QNX-Android and have even less of a user base than BB10.

    Going back to Debian, their implementation of systemd has led to two things: a fork without systemd, and the possibility of replacing systemd with the old way. In contrast, Google's anti-fragmentation stance means that if they were to make such an atomic change, OEMs have to deal with it, lest they make a fork and lose access to sweet sweet Google services.

    A better, more feasible way to improve kernel-level security is to patch it. This is less effort than stripping out the kernel, forcing in the QNX kernel and hoping it works. In fact, BlackBerry might be doing something like this, according to speculation.
    Speculating even more:

    1. Debian/kFreeBSD has been dropped because of a lack of volunteers, which can be explained through a general lack of users and developers (specially the second) for FreeBSD. You know, that pesky copyleft thing means you must release your code modifications with the source code. No internal versions. You haven't that with the BSD systems.

    FreeBSD itself contains the solution to this problem. FreeBSD shoehorned the Linux kernel, containerized, and made it run under a kernel module, with a compatibility rate of more than 99 per cent with native apps. Since lots of Android apps are Java apps that can run in the current BB10 runtime, and I expect a fundamentally better runtime with a solution a la FreeBSD, expect the only corner cases to be some apps using directly some Linux functions and bypassing the sandbox, something that isn't allowed by Google and is a no-no if you want to distribute your Android app in the Google Play Store, since that means: your app wants a rooted device.

    Remember, a QNX/Android shouldn't run every Android app. It's enough to run every Android app that follows Google's guidelines. Apps who, for instance, expect root access to modify system files, shouldn't run and Google doesn't care about them.

    2. A fundamentally better runtime may mean a containerized Linux kernel (the FreeBSD solution), and that kernel can be patched like this: https://grsecurity.net/compare.php . The problem is: the Android kernel already has some Grsecurity patches.

    A better approach is to containerize apps and provide extra security. The truth is: Linux can do that, but you require Linux 3.16 or above, and the Android userland doesn't support that. The only userland that truly can do that with Linux is, and it's great you mentioned it, systemd. So, you have to do major Android developments, or you just use what you have. Occam's razor.

    Wide vision, from Chile.
    09-11-15 04:53 AM
  10. app_Developer's Avatar
    in short i will say there is not way to do this with resources that BB has. Sure it can be done but the money involved would be more than its worth AND they dont have the man power honestly. They would have had to be working on this well before chen took the helm IMO to have this done AND be very close to bug free.
    If they are getting Google's help with this, then I could see this happening.

    But I still don't get the point. It doesn't address the real world vulnerabilities of Android, which are further up the stack. And it complicates the introduction of new chipsets and hardware for BB going forward.

    I suppose psychologically it helps move BB diehards to Android more gently. But that's an awful lot of time and effort to spend just for that, IMO.
    howarmat likes this.
    09-11-15 06:10 AM
  11. AnimalPak200's Avatar
    If they are getting Google's help with this, then I could see this happening.

    But I still don't get the point. It doesn't address the real world vulnerabilities of Android, which are further up the stack. And it complicates the introduction of new chipsets and hardware for BB going forward.

    I suppose psychologically it helps move BB diehards to Android more gently. But that's an awful lot of time and effort to spend just for that, IMO.
    Well, they could go lower down the stack and remove the RF emitting hardware components. Should make for a pretty slick USB thumbdrive.

    Seems to me that device user education + organizational/commercial infrastructure (merchant/bank/insurance/university/OPM servers), hardening is probably where the solution to most vulnerabilities lies.

    Kind of like... Require car drivers to get a license (they can still drive the car off a bridge... but hopefully they know how to avoid it when they don't want to), while at the same time making sure the bridge is built in a way that will not crumble.

    Right now, most data theft occurs because the bridges are crumbling.

    Posted via CB10
    app_Developer and 00stryder like this.
    09-11-15 07:35 AM
  12. thurask's Avatar
    FreeBSD itself contains the solution to this problem. FreeBSD shoehorned the Linux kernel, containerized, and made it run under a kernel module, with a compatibility rate of more than 99 per cent with native apps. Since lots of Android apps are Java apps that can run in the current BB10 runtime, and I expect a fundamentally better runtime with a solution a la FreeBSD, expect the only corner cases to be some apps using directly some Linux functions and bypassing the sandbox, something that isn't allowed by Google and is a no-no if you want to distribute your Android app in the Google Play Store, since that means: your app wants a rooted device.
    Perhaps.

    Given all the talk about how microkernels are supposedly inherently superior, maybe I should have said Debian GNU/HURD...

    2. A fundamentally better runtime may mean a containerized Linux kernel (the FreeBSD solution), and that kernel can be patched like this: https://grsecurity.net/compare.php . The problem is: the Android kernel already has some Grsecurity patches.
    They could go the extra mile, though; "some patches" vis-a-vis a full implementation.
    09-11-15 02:26 PM
  13. raremage's Avatar
    If they are getting Google's help with this, then I could see this happening.

    But I still don't get the point. It doesn't address the real world vulnerabilities of Android, which are further up the stack. And it complicates the introduction of new chipsets and hardware for BB going forward.

    I suppose psychologically it helps move BB diehards to Android more gently. But that's an awful lot of time and effort to spend just for that, IMO.
    Why would Google help with this, when it would not effect 99% of their potential userbase?

    A much better solution from Googles perspective is one that makes their existing OS (Android) more secure via a series of patches that could potentially be branched to also make some percentage of the existing Android userbase more secure as well.

    Since this is the path of least resistance for both BlackBerry and Google, it seems like a safe bet this will be the way things happen.

    Posted via CB10
    ayngling likes this.
    09-11-15 04:15 PM
  14. Munx's Avatar
    A more informed discussion on this topic can be found here:

    https://www.reddit.com/r/blackberry/...ort=confidence

    Posted via CB10
    09-11-15 04:23 PM
  15. app_Developer's Avatar
    Why would Google help with this, when it would not effect 99% of their potential userbase?

    A much better solution from Googles perspective is one that makes their existing OS (Android) more secure via a series of patches that could potentially be branched to also make some percentage of the existing Android userbase more secure as well.

    Since this is the path of least resistance for both BlackBerry and Google, it seems like a safe bet this will be the way things happen.

    Posted via CB10
    I totally agree that Google would get involved only if this became the next version of Android.

    I find it unlikely because I know both Google and Apple have looked at realtime schedulers on phones years ago, and rightly (IMO) decided against that idea.

    It's also unlikely because Google doesn't keep Android development very secret. If they were thinking about replacing Linux, we'd probably all know that by now. That's a big change for them.


    Sent from my iPad using Tapatalk
    Last edited by app_Developer; 09-11-15 at 05:10 PM.
    09-11-15 04:33 PM
  16. howarmat's Avatar
    A more informed discussion on this topic can be found here:

    https://www.reddit.com/r/blackberry/...ort=confidence

    Posted via CB10
    i wouldnt say its informed. Its some anonymous person that create that after the idea basically was presented in a thread here on CB
    AnimalPak200 likes this.
    09-11-15 04:35 PM
  17. AnimalPak200's Avatar
    i wouldnt say its informed. Its some anonymous person that create that after the idea basically was presented in a thread here on CB
    Yup... pretty much the case with the BerryFlow article on this topic.

    Alejandro deserves some credit.

    Posted via CB10
    Alejandro Nova likes this.
    09-11-15 04:56 PM
  18. Bla1ze's Avatar
    Wait till you realize you discussed it to death all for nothing lol.
    09-11-15 05:01 PM
  19. Empyrean's Avatar
    Wait till you realize you discussed it to death all for nothing lol.
    lol! Yeah -- watch the Slider ship with 10.3 like the MWC reveal made it appear!

    Posted via CB10
    09-11-15 06:47 PM
  20. Alejandro Nova's Avatar
    Yup... pretty much the case with the BerryFlow article on this topic.

    Alejandro deserves some credit.

    Posted via CB10
    Thanks for the credit, but I think Bla1ze leaked the negative. Is it just plain Android?

    Edit: Did someone say realtime? Recent Linux kernels have major improvements in that area. But as recent, I'm definitely not talking about Linux 3.4 (LTS Android). I'm a happy user of Fedora 22, that features Linux 4.1.6. That is recent.

    Wide vision, from Chile.
    09-11-15 09:38 PM
  21. Alejandro Nova's Avatar
    I totally agree that Google would get involved only if this became the next version of Android.

    I find it unlikely because I know both Google and Apple have looked at realtime schedulers on phones years ago, and rightly (IMO) decided against that idea.

    It's also unlikely because Google doesn't keep Android development very secret. If they were thinking about replacing Linux, we'd probably all know that by now. That's a big change for them.


    Sent from my iPad using Tapatalk
    You are deeply underestimating the secrecy of Google. Google tends to develop everything under seven keys, and, when it's ready and announced, they publish the source and make all relevant bugs public. That has been that way for Chrome, and for every relevant release of Android.

    Wide vision, from Chile.
    09-11-15 09:43 PM
  22. Hlao-roo's Avatar
    So, assuming it's largely vanilla Android, how do we think Chen is going to spin the phone's level of security, given his earlier statements?
    09-11-15 10:12 PM
  23. lawguyman's Avatar
    So, assuming it's largely vanilla Android, how do we think Chen is going to spin the phone's level of security, given his earlier statements?
    He's going to say that BlackBerry made Android more secure.



    Posted via CB10
    09-12-15 08:47 AM
  24. AnimalPak200's Avatar
    He's going to say that BlackBerry made Android more secure.



    Posted via CB10
    ... "as long as you sign up for one of our great BES 12 plans!"

    Posted via CB10
    09-12-15 08:55 AM
  25. BB-JAM215's Avatar
    He's going to say that BlackBerry made Android more secure.
    ... "as long as you sign up for one of our great BES 12 plans!"
    All he needs is to be able to say that Android is more secure on BlackBerry hardware, with or without BES.
    09-12-15 09:36 AM
32 12

Similar Threads

  1. Can someone give link .Bar files of the below apps?
    By chemmutk1 in forum BlackBerry Passport
    Replies: 9
    Last Post: 09-12-15, 11:54 PM
  2. What's the future of BB10 ?
    By RudyP1969 in forum General BlackBerry Discussion
    Replies: 6
    Last Post: 09-10-15, 03:05 PM
  3. what is the model number of black berry passport
    By CrackBerry Question in forum Ask a Question
    Replies: 2
    Last Post: 09-10-15, 01:02 PM
  4. Port of Houston Authority selects AtHoc to improve secure communication and collaboration
    By CrackBerry News in forum CrackBerry.com News Discussion
    Replies: 0
    Last Post: 09-10-15, 09:51 AM
  5. When will Snap 3 be out of beta?
    By mnc76 in forum General BlackBerry Discussion
    Replies: 1
    Last Post: 09-10-15, 04:51 AM
LINK TO POST COPIED TO CLIPBOARD