Live data from Hacker News

CopperheadOS: A hardened open-source operating system based on Android

copperhead.co

31–40 of 105 posts

Re: CopperheadOS: A hardened open-source operating system based on Android

#31
post #5

Earlier quoted context omitted.

Blame the OEMs for that. The driver situation on ARM devices is quite dire.

Is this a side-effect of mobile devices having extremely tight requirement for power usage and packaging? I could see how that, and a huge number of functions being packaged into a single SOC would make each board design far less generalizable from either one generation to the next or one form factor to the next. On the other hand, that doesn't preclude drivers for the relevant chipsets being more easily available. D…

The PC has PCI enumeration, that allows the kernel to ask each device on the bus for a id code. This in turn allows the kernel to load the appropriate drivers.

ARM do not really have this. Unless you know exactly what device is on what address range etc, you risk sending the wrong signals and fill its firmware with garbage or something.

This means you can't really cook up a generic kernel package and apply it across the product range as you can on PC.

Re: CopperheadOS: A hardened open-source operating system based on Android

#32
post #5

Earlier quoted context omitted.

Is this a side-effect of mobile devices having extremely tight requirement for power usage and packaging? I could see how that, and a huge number of functions being packaged into a single SOC would make each board design far less generalizable from either one generation to the next or one form factor to the next. On the other hand, that doesn't preclude drivers for the relevant chipsets being more easily available. D…

The PC has PCI enumeration, that allows the kernel to ask each device on the bus for a id code. This in turn allows the kernel to load the appropriate drivers. ARM do not really have this. Unless you know exactly what device is on what address range etc, you risk sending the wrong signals and fill its firmware with garbage or something. This means you can't really cook up a generic kernel package and apply it across…

This seems like a fatal flaw in the design of ARM.

Re: CopperheadOS: A hardened open-source operating system based on Android

#33
post #14

I like to see it enable the user to logs and optionally block connections attempt base on IP/dns names with both whitelist and blacklist. And track/logs all of them per Apk.

>And track/logs all of them per Apk.

Don't run programs you can't trust.

Re: CopperheadOS: A hardened open-source operating system based on Android

#35
post #14

I like to see it enable the user to logs and optionally block connections attempt base on IP/dns names with both whitelist and blacklist. And track/logs all of them per Apk.

>And track/logs all of them per Apk. Don't run programs you can't trust.

No point in a smartphone if you were to follow that mindset

Re: CopperheadOS: A hardened open-source operating system based on Android

#36
post #5

Earlier quoted context omitted.

Is this a side-effect of mobile devices having extremely tight requirement for power usage and packaging? I could see how that, and a huge number of functions being packaged into a single SOC would make each board design far less generalizable from either one generation to the next or one form factor to the next. On the other hand, that doesn't preclude drivers for the relevant chipsets being more easily available. D…

I think in reality it's simply a matter of everyone having their own build of the kernel and needing their own set of kernel modules. Google could have solved this in some way with Android, went for something closer to the way drivers work on Windows, a single long term service kernel that everyone builds their drivers against. But instead they told everyone to just build it themselves... resulting in the current sit…

Google's certainly at some fault here, e.g. by choosing to long-term fork Linux instead of trying to upstream their patches.

But my understanding is that they couldn't "just" do something like what Windows does, they don't get to boss the OEMs around in that capacity, some of the big ones effectively have their own Android forks (Samsung) or have already forked (Amazon), and if Google starts bossing them around they're just as likely to fully fork it as be brought into the fold.

Re: CopperheadOS: A hardened open-source operating system based on Android

#37
post #5

Earlier quoted context omitted.

Is this a side-effect of mobile devices having extremely tight requirement for power usage and packaging? I could see how that, and a huge number of functions being packaged into a single SOC would make each board design far less generalizable from either one generation to the next or one form factor to the next. On the other hand, that doesn't preclude drivers for the relevant chipsets being more easily available. D…

The PC has PCI enumeration, that allows the kernel to ask each device on the bus for a id code. This in turn allows the kernel to load the appropriate drivers. ARM do not really have this. Unless you know exactly what device is on what address range etc, you risk sending the wrong signals and fill its firmware with garbage or something. This means you can't really cook up a generic kernel package and apply it across…

U-Boot and linux have the Flattened Device Tree[1] (FDT) which allows the kernel to load and configure the appropriate drivers.

Your statement is true, however, that someone knowledgeable of the actual hardware has to create the correct FDT. This is slowly getting better and easier.

The more intractable problem, as others observed, is that ARM hardware vendors tend to throw together a custom kernel for a given ARM processor and board and then abandon it.

[1] https://en.wikipedia.org/wiki/Device_tree

Re: CopperheadOS: A hardened open-source operating system based on Android

#38
post #36

Earlier quoted context omitted.

I think in reality it's simply a matter of everyone having their own build of the kernel and needing their own set of kernel modules. Google could have solved this in some way with Android, went for something closer to the way drivers work on Windows, a single long term service kernel that everyone builds their drivers against. But instead they told everyone to just build it themselves... resulting in the current sit…

Google's certainly at some fault here, e.g. by choosing to long-term fork Linux instead of trying to upstream their patches. But my understanding is that they couldn't "just" do something like what Windows does, they don't get to boss the OEMs around in that capacity, some of the big ones effectively have their own Android forks (Samsung) or have already forked (Amazon), and if Google starts bossing them around they'…

I would point out that OEMs are unable to even release an Android device without Google's permission if they want any of their devices to have access to the Play Store. Google has an extensive compatibility suite that devices must pass to even qualify to request permission to release, and Google regularly changes the requirements to enforce what they feel is a good platform. They also mandate over 20 preinstalled applications, define default search settings, and the placement of app icons on the home screen.

They ABSOLUTELY do get to boss OEMs around in that capacity.

Re: CopperheadOS: A hardened open-source operating system based on Android

#39
post #28

Earlier quoted context omitted.

ASLR is already a part of pretty much every current operating system ( save FreeBSD-RELEASE )

ASLR is a band-aid. If you need it, your system is already insecure. It's just that the attacker may need to crash your system a few times before they get in.

64 bit ASLR is not a bandaid. There are definitely ASLR approaches that don't have enough entropy, but that doesn't mean ASLR as a whole is unworkable.

Re: CopperheadOS: A hardened open-source operating system based on Android

#40

Earlier quoted context omitted.

ASLR is already a part of pretty much every current operating system ( save FreeBSD-RELEASE )

Not all ASLR implementations are equal, eg. PaX's ASLR vs standard Linux KASLR.

I've heard rumors that the new ASLR in Android N is actually worse than the current implementation. I don't have anything online to link to, unfortunately.
Post reply on HN