**** BEGIN LOGGING AT Sat May 31 03:00:00 2014
May 31 09:20:31 <DocScrutinizer05> ~moo
May 31 09:20:32 <apt> mooooooo! I am cow, hear me moo, I weigh twice as much as you. I'm a cow, eating grass, methane gas comes out my ass. I'm a cow, you are too; join us all! type apt-get moo.
May 31 09:23:59 <DocScrutinizer05> on a sidenote: you guys must be mad to run systemd on a platform like gta02
May 31 09:24:57 <DocScrutinizer05> it's a terribly broken design that outright refuses to consider implications from embedded
May 31 09:27:39 <DocScrutinizer05> on additional sidenote: once OM tried to use another poettering botch on gta02: PolypAudio. Turned out we had to kick it, since it never really worked as expected.
May 31 09:35:39 <DocScrutinizer05> ...and have you seen recent Linus' rant at kdbus? The critics apply to all stuff Poettering and friends are doing
May 31 09:37:31 <DocScrutinizer05> Linus doesn't even comment on non-kernel stuff like systemd or PA. But Poettering and this other guy trying to touch the kernel made Linus T. utter a very clear word about what he thinks regarding qualification and quality of Poettering and the stuff he invents
May 31 09:38:49 <DocScrutinizer05> Linus clearly told GKH that there's no chance for that stuff to ever enter kernel
May 31 09:39:09 <DocScrutinizer05> basically
May 31 09:40:48 <DocScrutinizer05> https://bugs.freedesktop.org/show_bug.cgi?id=74589#c4   http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01331.html
May 31 09:42:23 <DocScrutinizer05> >> Greg - just for your information, I will *not* be merging any code from Kay into the kernel until this constant pattern is fixed. [Linus Torvalds]<< IOW, never
May 31 11:09:22 <GNUtoo-i1ssi> DocScrutinizer05: while I don't see the interest of pulseaudio, I like systemd's features
May 31 11:10:50 <GNUtoo-i1ssi> mainly the ability of overriding any .service
May 31 11:10:55 <GNUtoo-i1ssi> and the flexibility
May 31 11:11:46 <DocScrutinizer05> GNUtoo-i1ssi: sure systemd has a few nice features. But it has massive design defects
May 31 11:11:56 <GNUtoo-i1ssi> upstart is way worse...
May 31 11:11:59 <GNUtoo-i1ssi> for me:
May 31 11:12:07 <GNUtoo-i1ssi> upstart < sysvinit < systemd
May 31 11:12:25 <DocScrutinizer05> and it's terribly bloated
May 31 11:12:26 <GNUtoo-i1ssi> with sysvinit and systemd having different advantages each
May 31 11:13:01 <GNUtoo-i1ssi> well, on some embedded devices using systemd is silly
May 31 11:13:08 <DocScrutinizer05> but first and foremost (for embedded) it nukes /usr partition/volume concept
May 31 11:13:10 <GNUtoo-i1ssi> but the GTA02 has room for user tweaks
May 31 11:13:21 <GNUtoo-i1ssi> which is why systemd is nice on it
May 31 11:13:42 <GNUtoo-i1ssi> the big issue is that you need a recent kernel for using a recent systemd
May 31 11:14:45 <GNUtoo-i1ssi> (The GTA02 is more like a desktop than a very specific embedded device)
May 31 11:15:14 <GNUtoo-i1ssi> btw, you're now in charge of the Neo900?
May 31 11:15:35 <GNUtoo-i1ssi> if so I had only 1 request:
May 31 11:16:16 <GNUtoo-i1ssi> I know it's not feasible to have a wifi chip that doesn't require a non-free firmwrare, but it may be possible to have a GPS that is not in a GSM modem
May 31 11:16:20 <GNUtoo-i1ssi> like the GTA04 for instance
May 31 11:16:34 <GNUtoo-i1ssi> (The one in the GSM modem had no antenna)
May 31 11:16:43 <GNUtoo-i1ssi> that way the user can safely use the GPS
May 31 11:17:21 <GNUtoo-i1ssi> the very very good point about the neo900 is its *hardware keyboard*
May 31 11:19:02 <DocScrutinizer05> what's "unsafe" in using the GPS embedded in WWAN module?
May 31 11:20:16 <DocScrutinizer05> powering the module doesn't automatically mean you have to communicate to carrier over the air
May 31 11:21:10 <DocScrutinizer05> Neo900 will closely monitor the WWAN module and not alow it to contact to WWAN network when user doesn't want to
May 31 11:22:25 <DocScrutinizer05> so using GPS is perfectly safe (except for the very hypothetical threat of module logging your GPS positions and later on somebody reading out that from remote, knowing that there's no other way to find out about where you've been)
May 31 11:25:29 <pabs3> oh, there is GPS embedded in the WWAN? :(
May 31 11:26:08 <DocScrutinizer05> sure. What's the problem?
May 31 11:26:37 <DocScrutinizer05> you can control both completely independant of each other
May 31 11:27:29 <DocScrutinizer05> well, GPS is under control of WWAN when WWAN active, but then when WWAN is active, they got your postion to the centimeter without any GPS support
May 31 11:27:54 <DocScrutinizer05> and we can disable GPS by blocking the antenna on Neo900 any time
May 31 11:28:13 <DocScrutinizer05> we also can ensure that WWAN doesn't send any data
May 31 11:29:24 <DocScrutinizer05> I don't see any threat except the above mentioned which would need a highly sophisticated personalized attack to *your* device, to swap the firmware of the modem
May 31 11:30:27 <DocScrutinizer05> I don't see that happen since it's more effort than any other established spy techniques
May 31 11:31:31 <DocScrutinizer05> and when you're really THAT concerned about somebody to,orrow abusing the GPS fixes you needed today, you better use a dedicated GPS that you can discard after use
May 31 11:36:08 <DocScrutinizer05> for "normal" users on the other hand there are TTFF of <5s when using 3G, since the 3G networks supports alternative localizations methods to GPS which come in supplementary and even work indoors
May 31 11:46:30 <GNUtoo-i1ssi> DocScrutinizer05: use case:
May 31 11:46:41 <GNUtoo-i1ssi> the user powers off the modem
May 31 11:46:50 <GNUtoo-i1ssi> but the user still want to know where he is
May 31 11:47:02 <GNUtoo-i1ssi> and he doesn't want RRLP to get his position
May 31 11:47:05 <GNUtoo-i1ssi> or:
May 31 11:47:26 <GNUtoo-i1ssi> 2) The user doesn't want the network to get his very precise position while he uses the GPS (in case the GSM is on)
May 31 11:47:58 <GNUtoo-i1ssi> no highly sofisticated threat, just normal RRLP
May 31 11:51:05 <DocScrutinizer51> see above explanation, we not only can put "modem" into flightmode and still use GPS, we even can make sure modem *obeys* flightmode (at+cfun=0)
May 31 11:51:32 <GNUtoo-i1ssi> paulk-aldrin: hi, ^^^
May 31 11:52:11 <paulk-aldrin> hi
May 31 11:52:20 <DocScrutinizer51> and GSM gets better position than GPS when active, nevertheless we can make sure GPS stays inactive  by disabling antenna
May 31 11:52:27 <GNUtoo-i1ssi> great, how is thhat enforced?
May 31 11:52:36 <paulk-aldrin> GNUtoo-i1ssi, can we PM/XMPP?
May 31 11:52:41 <GNUtoo-i1ssi> yes, one second
May 31 11:53:23 <GNUtoo-i1ssi> paulk-aldrin: I don't see you on XMPP
May 31 11:53:26 <DocScrutinizer51> by blocking GPS antenna and monitoring WWAN antenna, plus other means
May 31 11:53:38 <GNUtoo-i1ssi> DocScrutinizer51: ah, can we block WWAN antenna?
May 31 11:53:42 <GNUtoo-i1ssi> like with a GPIO?
May 31 11:54:11 <DocScrutinizer51> GNUtoo-i1ssi: not block but monitor and kill modem when it cocks up
May 31 11:54:55 <DocScrutinizer51> advantage: we KNOW sth very fishy going on, and we blocked it nevertheless
May 31 11:55:39 <GNUtoo-i1ssi> ok, how do we monitor it?
May 31 11:55:55 <DocScrutinizer51> in hw 
May 31 11:56:30 <DocScrutinizer51> some detectors sense any RF or unusual behavior at large
May 31 11:57:33 <DocScrutinizer51> which is catching more than only stealth LLRP
May 31 11:57:57 <DocScrutinizer51> RRLP
May 31 11:58:43 <DocScrutinizer51> it also catches stealth SMS, and generally modem acting dead while actually it isn't
May 31 11:59:20 <GNUtoo-i1ssi> ah, but that's not integrated in the neo900?
May 31 12:00:08 <DocScrutinizer51> again: when you're logged in to WWAN then nowadays nobody needs GPS to get a faster more precise fix of your pos. 
May 31 12:00:29 <DocScrutinizer51> of course that's integrated into every Neo900
May 31 12:01:32 <DocScrutinizer51> Neo900 willbe the most safe mobile phone hw you can get, even with GPS embedded in WWAN
May 31 12:02:18 <DocScrutinizer51> :)
May 31 12:02:45 <GNUtoo-i1ssi> "monitoring WWAN antenna" -> how's that done?
May 31 12:02:50 <GNUtoo-i1ssi> gpio input ?
May 31 12:02:57 <DocScrutinizer51> RF detector
May 31 12:02:58 <GNUtoo-i1ssi> adc?
May 31 12:03:01 <GNUtoo-i1ssi> what's that?
May 31 12:03:11 <GNUtoo-i1ssi> (is that inside the Neo900)?
May 31 12:03:25 <DocScrutinizer51> well think of an ancient detector AM radio
May 31 12:03:34 <DocScrutinizer51> yes
May 31 12:03:39 <GNUtoo-i1ssi> wow
May 31 12:03:41 <DocScrutinizer51> integrated
May 31 12:03:48 <GNUtoo-i1ssi> thanks a lot!!!!
May 31 12:03:58 <DocScrutinizer51> it senses modem sending RF
May 31 12:04:59 <DocScrutinizer51> don't forget who told you first about it :)
May 31 12:05:25 <DocScrutinizer51> I developed that security concept
May 31 12:06:57 <DocScrutinizer51> it's superior to any hardware switch to power down the modem, since it also *detects* any ongoing attack immediately
May 31 12:07:27 <DocScrutinizer51> similar to a honeypot
May 31 12:08:06 <GNUtoo-i1ssi> wow
May 31 12:08:16 <GNUtoo-i1ssi> yes, I always try to cite the source of what I say
May 31 12:08:43 <GNUtoo-i1ssi> sometimes I forgott the source and In that case I tell the person to check by him/her self
May 31 12:11:21 <DocScrutinizer51> believe me, I will very clearly publish all the know attack vectors we closed, how we did, and which are maybe still open. Neo900 should be fit to pass any security audit for even the hardest requirements "Angy phone"
May 31 12:12:45 <DocScrutinizer51> one possible attack vector we won't close is the recording of GPS pos inside modem done by a rogue firmware
May 31 12:12:57 <DocScrutinizer51> as explained above
May 31 12:13:22 <DocScrutinizer51> so using GPS is not 100.000 percent safe
May 31 12:13:43 <DocScrutinizer51> but a very goog 99.99 percent
May 31 12:13:49 <DocScrutinizer51> good
May 31 12:14:39 <DocScrutinizer51> when you want to be 100.00 percent save, use a dedicated GPS device and discard/detroy it after use
May 31 12:15:46 <DocScrutinizer51> for Neo900 you're anyway free to never ever enable the GPS antenna and that's it for GPS
May 31 12:16:23 <DocScrutinizer51> btw we also notice when modem powers up the GPS engine (RRLP)
May 31 12:16:46 <DocScrutinizer51> it will fail, but nevertheless we detect it
May 31 12:17:01 <DocScrutinizer51> (honeypot)
May 31 12:17:24 <DocScrutinizer51> hope you appreciate the concept
May 31 12:19:17 <DocScrutinizer51> (how's that done? GPIO, ADC) yes, one of both
May 31 12:19:33 <DocScrutinizer51> ant asserting an IRQ to APE
May 31 12:19:52 <DocScrutinizer51> and* but ant is also ok ;)
May 31 12:20:52 <DocScrutinizer51> we have almost a dozen monitors sitting on all kinds of signals and values, e.g modem power consumpton
May 31 12:23:08 <DocScrutinizer51> we also will see what can get done to checksum the modem firmware (though that's a weak check, easily circumvented by rogue firmware - when it knows it has to)
May 31 12:26:36 <DocScrutinizer51> for WLAN firmware I think a non-free blob that user can hack is better than any immutable firmware in ROM, and anyway what can a WLAN dongle do to threat your safety that it doesn't do per definition of its operation mode and purpose?
May 31 12:28:02 <DocScrutinizer51> it's no threat to integrity of the core system, no matter what
May 31 12:29:17 <DocScrutinizer51> it only sees the data you send to it anyway. OK the encryption my be flawed, but wasn't it already on all WLAN to begin with?
May 31 12:29:30 <DocScrutinizer51> may*
May 31 12:30:19 <DocScrutinizer51> and of course you're free to encrypt the data on APE before WLAN module even sees it
May 31 12:31:07 <DocScrutinizer51> wait, isn't that called wpa-supplicant? ;)
May 31 12:31:43 <DocScrutinizer51> ~ping
May 31 12:31:43 <apt> ~pong
May 31 12:32:43 <DocScrutinizer51> ohmy, at least it wll be in hanlogs :D
May 31 12:32:54 <DocScrutinizer51> chanlogs*
May 31 12:34:07 <DocScrutinizer51> from where I probably should get it and put it to the neo900.org FAQ
May 31 12:36:07 <DocScrutinizer51> you know that the incredibly "safe" blackphone (Zimmerman, ZRTP) is using a shared-ram approach for modem afaik? Ridiculous!
May 31 12:36:23 <pabs3> ick
May 31 12:40:01 <DocScrutinizer51> dos1: new slogan? "Neo900: open to hackers, closed to the NSA"
May 31 12:40:31 <dos1> :)
May 31 12:41:55 <dos1> some basic stuff about our security model regarding the modem was in my slides at PIWO talk: http://neo900.org/piwo/piwo.pdf
May 31 12:42:33 <DocScrutinizer51> aaah,waited for that :)
May 31 12:42:58 <dos1> more detailed article about it still pending to be written - reorganization stole too much of our attention recently :c
May 31 12:43:00 <DocScrutinizer51> mobile, so no links
May 31 12:43:33 <paulk-aldrin> we all know the blackphone is a scam :)
May 31 12:43:48 <DocScrutinizer51> indeed, dam organizational issues
May 31 12:44:00 <paulk-aldrin> I wanted to write about it but didn't have time
May 31 12:44:07 <DocScrutinizer51> almost killed me
May 31 12:44:08 <paulk-aldrin> DocScrutinizer05, are you considering an OMAP4 now that Goldelico is off the project?
May 31 12:44:21 <DocScrutinizer51> nope
May 31 12:44:24 <paulk-aldrin> there is apparently very good mainline support for it, too
May 31 12:44:31 <paulk-aldrin> I'm not sure the suspend/resume concerns are valid
May 31 12:44:33 <pabs3> dos1: please do publish that, probably the most important marketing that could be done for Neo900 
May 31 12:44:39 <DocScrutinizer51> OMAP3 for maemo compatibility
May 31 12:44:46 <paulk-aldrin> meh
May 31 12:44:56 <DocScrutinizer51> once maemo ported, we go omap5
May 31 12:44:59 <dos1> paulk-aldrin: well, considering that Goldelico is working on OMAP5 Pyra, then it's not really connected to each other
May 31 12:45:21 <paulk-aldrin> so omap3 or omap5 but why not omap4?
May 31 12:45:34 <paulk-aldrin> I'm unsure about the maturity of omap5
May 31 12:45:52 <dos1> neo900 has two boards - just replace one with CPU and get shiny omap5 upgrade :)
May 31 12:46:05 <paulk-aldrin> in how many years?
May 31 12:46:14 <dos1> omap4 has some issues afaik? but DocScrutinizer51 will probably tell you more
May 31 12:46:27 <paulk-aldrin> I'm interested in knowing which issues
May 31 12:46:35 <DocScrutinizer51> I know of some issues in OMAP4
May 31 12:46:54 <DocScrutinizer51> but they are not publicly known
May 31 12:47:03 <paulk-aldrin> such as?
May 31 12:47:22 <DocScrutinizer51> wake IRQ get lost under certain conditions
May 31 12:47:47 <paulk-aldrin> seriously? there are plenty of android devices using omap4 and they work perfectly
May 31 12:48:08 <DocScrutinizer51> thus your modem buffer fills with inbound data while APE happily idles
May 31 12:48:37 <DocScrutinizer51> paulk-aldrin: I worked on modsem firmware for many of those
May 31 12:48:50 <paulk-aldrin> ok
May 31 12:48:55 <dos1> paulk-aldrin: such cpu upgrade would be a much easier project with all this n900-related stuff being already done and irrevelant anymore, so I don't think it would be "years", rather "months"
May 31 12:49:17 <DocScrutinizer51> we had to tweak protocols of e.g. HSI beyond specs to amke it work
May 31 12:49:29 <paulk-aldrin> interesting
May 31 12:50:20 <DocScrutinizer51> TI stated "wontfix. Will vanish in OMAP5"
May 31 12:50:31 <paulk-aldrin> I see
May 31 12:50:44 <paulk-aldrin> what's the omap5 mainline status?
May 31 12:50:55 <DocScrutinizer51> nfc
May 31 12:51:05 <DocScrutinizer51> I'm EE
May 31 12:51:22 <DocScrutinizer51> ;)
May 31 12:51:29 <paulk-aldrin> yeah ok but someone has to deal with it
May 31 12:51:33 <DocScrutinizer51> afk, walking
May 31 12:51:37 <paulk-aldrin> ok
May 31 12:52:18 <pabs3> paulk-aldrin: I see some omap5 device-tree files in my linux git tree
May 31 12:52:50 <pabs3> one dts for "TI OMAP5 uEVM board"
May 31 12:53:07 <dos1> Pyra is omap5 based, so some support for sure must be already there
May 31 12:55:36 <DocScrutinizer05> and back :)
May 31 12:56:50 <paulk-aldrin> sure but I'm afraid it's incomplete
May 31 12:57:02 <paulk-aldrin> especially regarding power management
May 31 12:57:50 <DocScrutinizer05> dos1: already?
May 31 12:58:12 <paulk-aldrin> well it's running for sure
May 31 12:58:15 <paulk-aldrin> at FOSDEM, it was
May 31 12:58:50 <paulk-aldrin> and also, note that the dm3730 also has lost irq issues, with the rtc alarm
May 31 12:59:06 <DocScrutinizer05> DT is a current "innovation" in kernel, it's not the SoC's fault when support is sparse and not yet complete
May 31 12:59:24 <dos1> yep, I doubt they would find the project feasible if at least some initial mainline support with some good perspectives for future wasn't already there
May 31 12:59:31 <DocScrutinizer05> OH? RTC lost IRQ?
May 31 12:59:42 <DocScrutinizer05> is that a documemted SiErr?
May 31 13:00:13 <paulk-aldrin> DocScrutinizer05, I don't exactly remember what's going on exactly but Neil brown wrote about it
May 31 13:00:20 <paulk-aldrin> not entirely sure it's a hardware issue
May 31 13:00:22 <DocScrutinizer05> I's sure TI made a device similar to Zoom and Blaze for OMAP5
May 31 13:00:24 <paulk-aldrin> but the result is the same
May 31 13:00:52 <DocScrutinizer05> no, not really. Anything sw can (and will) get fixed
May 31 13:01:07 <DocScrutinizer05> SiErr are unrecoverable
May 31 13:01:40 <DocScrutinizer05> you only might be lucky to find a (however nasty) workaround
May 31 13:02:09 <DocScrutinizer05> for the OMAP4 IRQ SiErr the workaround been to patch peripherals to repeat the IRQ
May 31 13:02:23 <DocScrutinizer05> something that *we* quite obviously can't do
May 31 13:02:31 <paulk-aldrin> ok
May 31 13:03:08 * DocScrutinizer05 just figures a hw IRQ repeated ;-P
May 31 13:03:16 <DocScrutinizer05> repeater*
May 31 13:04:06 <DocScrutinizer05> only needs a NAND gate to to gate the 32k clock to the SoC IRQ/GPIO pin X-P
May 31 13:04:08 <paulk-aldrin> hell, why not?
May 31 13:05:42 * DocScrutinizer05 also idly wonders if that SiErr been somehow related to edge triggered IRQ only
May 31 13:06:32 <DocScrutinizer05> there's been a reason why for ISA bus they eventually switched from initial edge IRQ to level triggered IRQ
May 31 13:06:59 <DocScrutinizer05> avoud edge trigger whenever possible
May 31 13:07:07 <DocScrutinizer05> it's BAD[TM]
May 31 13:07:36 <paulk-aldrin> does level-triggered IRQs make the issue disappear?
May 31 13:07:41 <paulk-aldrin> do*
May 31 13:07:50 <DocScrutinizer05> only use edge for extremely lightweight IRQ with handlers that don't service the IRQ source
May 31 13:08:01 <DocScrutinizer05> I can't recall
May 31 13:08:06 <paulk-aldrin> ok
May 31 13:08:33 <DocScrutinizer05> I however guess the joint forces of RIM TI Samsung LG and dunno whom else will have tested it
May 31 13:08:56 <DocScrutinizer05> and not least ST-Ericsson 
May 31 13:11:12 <DocScrutinizer05> (I'm just EE) well, most of the time :-) http://talk.maemo.org/showthread.php?p=1427567#post1427567
May 31 13:12:03 <paulk-aldrin> :)
May 31 13:15:19 <paulk-aldrin> I have to go, keep up the good work
May 31 13:15:31 <DocScrutinizer05> sure, will try to do
May 31 13:15:36 * DocScrutinizer05 waves
**** ENDING LOGGING AT Sun Jun 01 02:59:58 2014