0 Members and 1 Guest are viewing this topic.
I heard Google is working on a new OS to replace Android because its design is just getting plain outdated and is a pain to support the new features that came out since, say, Android 2. Looking forward to it, just to see how better it'll be or if it's gonna replace Android at all.
Also I hope you guys will not have to deal directly with the Win32 API in straight, unmanaged C/C++. Kinda forgot about that, been years I haven't touched it, but I remember it was kinda weird. At least, it made .NET look like a walk in the park.
PlayStation 2My take on this is somewhat atypical because I once tried to port back NetBSD to it, so I did not care about all the insane Sony proprietary bits. Turns out the CPU is one of the most insane things about it : from what I can recall, it's a MIPS-III with most MIPS-IV instructions, a couple of MIPS-V instructions, 128 bits registers, 64 bits virtual addresses like MIPS64, 32 bits physical addresses like MIPS32, FPU units almost but not quite IEEE 754-compliant and a 64 byte cache line.WHY?! It's technically a MIPS CPU, but that's the weirdest MIPS ever made by far. It's like they've decided to make a hybrid of five different MIPS ISA because they could and piled on more insanity on top of it...I haven't even talked about things a general-purpose UNIX-like OS does not care about, but the heterogeneous computing with the PS1 CPU bolted-on (or the PowerPC core on later models) on the bus would've yielded even more insanity to exploit.
HP Prime G1It's not hard because of the hardware (it's fairly standard), but the firmware' OS is quite odd from what I've heard (early versions actually relied on the RAM mirroring to boot, which screams sloppy programming to me), the flashing protocol is proprietary and the utilities are Windows-only, the calculator will be bricked if the beginning of the NAND gets corrupted or overwritten and the touch chip is proprietary. That makes for a very, very frustrating platform to work on for homebrews.Hopefully the G2 will not be such a pain in the ass to work with
Ah, interesting. I've heard a lot of talk about the GS processor on the PS2 but not a hell lot about the CPU. I guess most people assumed it was just a boring old MIPS cpu. I mean in theory it should be possible to tell GCC to target some of the CPU's features right ? (or even create a new target but i think you guys went with the safe route C:)
QuoteHopefully the G2 will not be such a pain in the ass to work withIsn't the G2 going to be more locked down though ? It's a shame that neither the Linux or NetBSD ports went anywhere.But touchscreen isn't that important on a calculator one could argue.
Hopefully the G2 will not be such a pain in the ass to work with
I saw some articles about Fushia but it's as early stages as Haiku OS it seems. At least they got rid of Java it seems.I don't really care for the microkernel design but as long as it is POSIX compliant and performs decently, it's all good.But then again, it might end up like Tizen and stay on smartwatches and all. (which kind of died because the license was not truly open source among other things)
[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.
Page created in 0.07 seconds with 61 queries.