Poll: How much would you be willing to pay for a Neo900 (complete device) with TI DM3730 1GHz/512M-RAM/1GB
Poll Options
How much would you be willing to pay for a Neo900 (complete device) with TI DM3730 1GHz/512M-RAM/1GB

Reply
Thread Tools
Posts: 3,328 | Thanked: 4,476 times | Joined on May 2011 @ Poland
#2821
Why Devuan and not simply Debian? Anything besides "we don't like systemd"?

One idea that comes to me mind: using systemd would break the compatibility with the existing apps, which target upstart.

One more thought. I'm wondering: what is the current ETA for it? Sidenote: I'm not buying a Neo (can't afford). Just curious.
__________________
If you want to support my work, you can donate by PayPal or Flattr

Projects no longer actively developed: here
 

The Following 8 Users Say Thank You to marmistrz For This Useful Post:
Posts: 3 | Thanked: 30 times | Joined on Oct 2013
#2822
This is just my personal opinion and this is not a place for yet another Systemd-war... but...

Systemd could work just fine in the future but it could be also a huge risk in a somewhat exotic software/hardware project as it seems to be hogging everything into one huge monolith ball of everything-that-is-not-unix one dependency at a time. To me, that is not a matter of preference but practicality.

On the other hand, Devuan seems to be maturing into a self sustaining fork quite slowly.

If a piece of hardware handles Devuan without a hiccup, it should be somewhat straightforward to customize and install Debian on it pretty painlessly as well (?). I suppose it might be a more difficult process the other way around as Devuan is (at least philosophically) closer to what Maemo was originally built on.

I am happy for the options existing either way.
 

The Following 8 Users Say Thank You to YuppieNalle For This Useful Post:
Posts: 13 | Thanked: 9 times | Joined on Mar 2010 @ England
#2823
Joerg,

It's been a while since your update on the delivery of the Neo900 project so my recurring question is: when are we going to get our hands on the device? Otherwise, please forgive me for being blunt, I would like to get full refund of my contribution!

I would appreciate your prompt reply as I have been in the waiting for long enough--sorry!

Peter
 

The Following 4 Users Say Thank You to pbox For This Useful Post:
Posts: 89 | Thanked: 194 times | Joined on Feb 2010
#2824
Originally Posted by YuppieNalle View Post
Systemd could work just fine in the future
Seems to work ok on sailfish.
 

The Following 4 Users Say Thank You to JohnHughes For This Useful Post:
joerg_rw's Avatar
Posts: 2,222 | Thanked: 12,651 times | Joined on Mar 2010 @ SOL 3
#2825
Hi Pbox,
yes, I've been quite silent lately, sorry for that. We moved to a new infra (tools, procedures, even HR) which was quite a bit of work but seems to be almost reaching a first goal now. Hellekin today picked up on the task to write a comprehensive newsletter summing up on all that happened since we lost Nikolaus for layout. Should appear RSN. Again sorry for the silence, please bear with us and stay tuned.
[edit] meanwhile prease refer to http://irclog.whitequark.org/neo900 and to our new EE repo at https://neo900.org/git/?p=ee;a=summary
/j

Last edited by joerg_rw; 2016-07-27 at 19:49.
 

The Following 13 Users Say Thank You to joerg_rw For This Useful Post:
Posts: 15 | Thanked: 43 times | Joined on Feb 2015
#2826
Today I have read about the Drammer attack.

For details see:
https://www.vusec.net/projects/drammer/
and:
https://github.com/vusec/drammer

There seems to be no 100% reliable way to secure a device in software against such an attack.
Ok, the described attack runs on Android, but imho it should be portable to any platform. Might it be possible to secure the Neo900 by design?

Regards
mith
__________________
www.mygnu.de
 

The Following 3 Users Say Thank You to mithrandir For This Useful Post:
joerg_rw's Avatar
Posts: 2,222 | Thanked: 12,651 times | Joined on Mar 2010 @ SOL 3
#2827
Originally Posted by mithrandir View Post
There seems to be no 100% reliable way to secure a device in software against such an attack.
Well, the app with embedded hidden Drammer code needs to get installed in the usual (or not so usual) ways to the target system. So to protect your system against Drammer, do not install apps that contain Drammer exploit code

There's nothing we could do on a hw design level to mitigate that. It's about the way RAM and the memory controller work


cheers
jOERG
 

The Following 5 Users Say Thank You to joerg_rw For This Useful Post:
Posts: 15 | Thanked: 43 times | Joined on Feb 2015
#2828
According to https://en.m.wikipedia.org/wiki/Row_hammer there have been Javascript implementations of Rowhammer. Thus the Drammer attack could also be possible in Javascript and not only by installing an application.

If we could ensure (somehow) that the neo900 is invulnerable to this kind of attack this could be a strong argument for potential buyers. Maybe we could take this advantage by chance. It could be sufficient to test the device for the vulnerability.

Regards
mith
__________________
www.mygnu.de
 

The Following 2 Users Say Thank You to mithrandir For This Useful Post:
Posts: 915 | Thanked: 3,209 times | Joined on Jan 2011 @ Germany
#2829
Would something like emulating ECC in software be feasible? I'm thinking about using some of the RAM as checksum space for the rest - sort of like RAID parity bits in RAM.
It wouldn't prevent rowhammer-based attacks, but if it works, it would make detecting them more likely.

It's purely theroretical speculation on my side though. I don't have the slightest clue how to implement such a feature.


Edit:
There's a thread about rowhammer in the Pyra forums too [1], and I guess what Nikolaus said there would also apply to the Neo900.

[1] https://pyra-handheld.com/boards/thr...whammer.78436/

Last edited by sulu; 2016-10-24 at 20:53.
 

The Following 4 Users Say Thank You to sulu For This Useful Post:
joerg_rw's Avatar
Posts: 2,222 | Thanked: 12,651 times | Joined on Mar 2010 @ SOL 3
#2830
Originally Posted by mithrandir View Post
According to https://en.m.wikipedia.org/wiki/Row_hammer there have been Javascript implementations of Rowhammer. Thus the Drammer attack could also be possible in Javascript and not only by installing an application.
Bummer! Hardly anything you can do about it except hardening JS interpreter so it doesn't execute such code in a way that triggers the bug.

Originally Posted by mithrandir View Post
If we could ensure (somehow) that the neo900 is invulnerable to this kind of attack this could be a strong argument for potential buyers.
Originally Posted by sulu View Post
There's a thread about rowhammer in the Pyra forums too [1], and I guess what Nikolaus said there would also apply to the Neo900.

[1] https://pyra-handheld.com/boards/thr...whammer.78436/
Originally Posted by HNS/Pyra
On the other hand we can't do anything actively about that (we can't change the memory controller or DRAM chips).
Originally Posted by joerg_rw View Post
There's nothing we could do on a hw design level to mitigate that. It's about the way RAM and the memory controller work
Let's see what (software) solutions they come up with for Android phones. tuning refresh time and spoiling rapid RAM access from "exposed services" like JS is probably the only way to go

/j
 

The Following 9 Users Say Thank You to joerg_rw For This Useful Post:
Reply

Tags
neo900, thank you!

Thread Tools

 
Forum Jump


All times are GMT. The time now is 21:29.