Active Topics
-
[M7] [Announce] HP41cx (0)
to Applications by Halftux - 7 hrs, 47 mins ago -
Camera phone competition March 2023 "Endless" (21)
to General by Maemish - 1 day, 6 hrs ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (9)
to SailfishOS by biketool - 3 days, 10 hrs ago - more...
|
2016-06-30
, 10:44
|
|
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.
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: | ||
|
|
2016-07-27
, 12:34
|
|
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
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: | ||
|
|
2016-07-27
, 14:16
|
|
Posts: 89 |
Thanked: 194 times |
Joined on Feb 2010
|
#2824
|
Originally Posted by YuppieNalle
Seems to work ok on sailfish.
Systemd could work just fine in the future
| The Following 4 Users Say Thank You to JohnHughes For This Useful Post: | ||
 |
|
2016-07-27
, 19:40
|
|
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.
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: | ||
|
|
2016-10-24
, 17:16
|
|
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
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
www.mygnu.de
| The Following 3 Users Say Thank You to mithrandir For This Useful Post: | ||
|
|
2016-10-24
, 18:11
|
|
Posts: 2,222 |
Thanked: 12,651 times |
Joined on Mar 2010
@ SOL 3
|
#2827
|
Originally Posted by mithrandir
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 seems to be no 100% reliable way to secure a device in software against such an attack.
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: | ||
|
|
2016-10-24
, 19:16
|
|
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
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
www.mygnu.de
|
|
2016-10-24
, 20:48
|
|
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.
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: | ||
|
|
2016-10-24
, 21:33
|
|
Posts: 2,222 |
Thanked: 12,651 times |
Joined on Mar 2010
@ SOL 3
|
#2830
|
Originally Posted by mithrandir
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.
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.
Originally Posted by mithrandir
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
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
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
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
/j
| The Following 9 Users Say Thank You to joerg_rw For This Useful Post: | ||
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