We're on Discord! Please join our server now if you don't want to miss anything! (More info) | Join the UCC4 contest! (More info)

* WalrusIRC & Discord main room

If you have a forum account, have more than 4 posts and are not part of a restricted usergroup, then you can chat in our main Discord server room directly from here and continue using the forums at the same time. Or you can join our server directly and access many more discussion rooms!

Author Topic: Hardest platforms to program/work for ?  (Read 1278 times)

0 Members and 2 Guests are viewing this topic.

Offline Lionel Debroux

  • Full User
  • Join Date: Jan 2015
  • Location:
  • Posts: 243
  • Post Rating Ratio: +11/-0
    • debrouxl
    • 58/5891
Re: Hardest platforms to program/work for ?
« on: December 06, 2018, 09:31:58 pm »
Switching Android from Linux to Fuchsia is apparently far from trivial, according to Kees Cook this summer (2018/07/28) on ##linux-hardened. I'm not aware of a no-logs policy on that chan, so straight from my logs:
[18:48:21 CEST] <xtrWrithe>   hello, im using this kernel, it comes with grsec? or i will need to patch it manually?
[20:04:37 CEST] <Lionel_Debroux>   linux-hardened does not come with PaX/grsecurity.
[20:05:24 CEST] <Lionel_Debroux>   There used to be minipli's unofficial forward port of grsecurity to newer Linux 4.9 stable versions, but that stopped when KPTI was integrated to mainline: mixing the broad KPTI changes with MEMORY_UDEREF and KERNEXEC was too much, too hard work, IIUC.
[20:22:57 CEST] <xtrWrithe>   Lionel_Debroux: ty for reply, yes i saw that the other port is dapper's one, but as you say KPTI made it very hard to keep working and the 4.13 versiom doesnt work yet
[20:23:38 CEST] <xtrWrithe>   what should i focus on to prevent kernel exploits or at least mitiagte them a bit?
[20:37:45 CEST] <Lionel_Debroux>   smeso reimplemented something like MPROTECT, and several other protections, in the SARA LSM... but LSMs still aren't stackable, and on the anti-exploitation front, nothing comes remotely close to grsecurity.
[20:37:59 CEST] <Lionel_Debroux>   Individuals are out of luck, they can't buy grsecurity subscriptions on their own.
[20:39:55 CEST] <Lionel_Debroux>   If you're part of a small company, and can convince those who decide (or are one of the deciders and it doesn't cost too much), maybe you can become a customer of Open Source Security, Inc.
[20:41:54 CEST] <Lionel_Debroux>   If you're part of a large company... you're probably out of luck as well, as the subscription probably won't be very cheap, and making those who have the power to decide on such bills - and are usually of the dumb financial type - understand the value of grsecurity, no matter how huge it is, is usually a hopeless task.
[20:51:01 CEST] <Lionel_Debroux>   In the longer term... IIUC, Android's going to switch to a completely different kernel implementation with a Linux compatibility layer. Microsoft used the same approach for Win10's WSL.
[21:49:16 CEST] <kees>   Lionel_Debroux: Android leaving Linux is somewhere between "never" and "in decades maybe"
[21:49:44 CEST] <kees>   xtrWrithe: I recommend the latest upstream kernel, and the recommended settings linked from the /topic
[21:49:51 CEST] <kees>   (if you can't find a way to use grsecurity)
[21:53:26 CEST] <Lionel_Debroux>   You know the topic better than I do, but... that far in the future, really ? Why ?
[21:53:54 CEST] <kees>   Lionel_Debroux: because changing a kernel is hard. :)
[21:54:03 CEST] <Lionel_Debroux>   AFAIK, many Android apps, especially those written in higher-level languages, do not have strong dependencies on Linux.
[21:54:32 CEST] <kees>   Lionel_Debroux: true, but the system integrity is tightly bound to Linux (e.g. SELinux)
[21:55:05 CEST] <kees>   Lionel_Debroux: now, what I'd expect is for that kind of thing to happen in VERY small devices where memory and CPU resources are the tight spot
[21:55:29 CEST] <kees>   but on phones... multi-core CPUs, gigs of RAM, I really think it'll stay Linux for a long long time
[21:57:56 CEST] <Lionel_Debroux>   Yeah, Linux on very small devices is a lost cause. The tinification efforts weren't deemed useful enough (by the powers that be) to offset the (sometimes small, IIUC) maintenance increase.
[21:58:32 CEST] <Lionel_Debroux>   Higher performance and better compatibility are deemed more important than smaller footprint... or better security.
[22:00:29 CEST] <Lionel_Debroux>   It's the first time I'm reading "the system integrity is tightly bound to Linux (e.g. SELinux)" argument, which is indeed a good technical reason why moving away from the Linux kernel for some usages can be hard.

And agreed, Fuchsia should be able to manage to be part of our world for a while.
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.


You can also use the following HTML or bulletin board code to share it on your page or forum signature!

Also do not forget to check our affiliates below.
Planet Casio TI-Planet Calc.news BroniesQC BosaikNet Velocity Games