2014-04-11 00:05 <Web-aptosid876_> ello
2014-04-11 00:07 <w3bspl0it> working on a device with secure boot
2014-04-11 00:07 <w3bspl0it> boot loader is signed and verfies kernel
2014-04-11 00:07 <w3bspl0it> need to disable secure boot
2014-04-11 00:07 <w3bspl0it> i had some thoughts
2014-04-11 00:08 <w3bspl0it> access boot loader in memory but UART is disabled for that
2014-04-11 00:09 <w3bspl0it> all interrupts are disabled
2014-04-11 00:11 <w3bspl0it> possible to boot from sd card but verfication still in place
2014-04-11 00:13 <wpwrak> that's ... on the ben ?
2014-04-11 00:13 <w3bspl0it> streaming player
2014-04-11 00:19 <wpwrak> then i suppose how you design your "secure boot" would depend on what sort of hardware that player has ...
2014-04-11 00:23 <w3bspl0it> Roku 3 streaming player
2014-04-11 00:33 arielenter has joined #qi-hardware
2014-04-11 00:40 arielenter has quit [Quit: Leaving.]
2014-04-11 00:59 dos1 has quit [Ping timeout: 252 seconds]
2014-04-11 01:12 atommann has joined #qi-hardware
2014-04-11 02:15 arielenter has joined #qi-hardware
2014-04-11 02:58 arielenter has quit [Read error: Connection timed out]
2014-04-11 03:21 unclouded has joined #qi-hardware
2014-04-11 03:34 xiangfu has joined #qi-hardware
2014-04-11 03:42 arielenter has joined #qi-hardware
2014-04-11 04:01 Luke-Jr has quit [Remote host closed the connection]
2014-04-11 04:02 Luke-Jr has joined #qi-hardware
2014-04-11 04:05 arielenter has quit [Read error: Connection timed out]
2014-04-11 04:06 arielenter has joined #qi-hardware
2014-04-11 04:40 arielenter has quit [Quit: Leaving.]
2014-04-11 04:43 arielenter has joined #qi-hardware
2014-04-11 04:44 w3bspl0it has quit []
2014-04-11 04:59 wolfspraul has joined #qi-hardware
2014-04-11 05:07 jekhor has joined #qi-hardware
2014-04-11 05:15 arielenter has quit [Read error: Connection timed out]
2014-04-11 05:22 michael_lee has joined #qi-hardware
2014-04-11 05:42 michael_lee has quit [Remote host closed the connection]
2014-04-11 05:59 Luke-Jr has quit [Remote host closed the connection]
2014-04-11 05:59 Luke-Jr has joined #qi-hardware
2014-04-11 06:03 Luke-Jr has quit [Remote host closed the connection]
2014-04-11 06:08 Luke-Jr has joined #qi-hardware
2014-04-11 06:11 arielenter has joined #qi-hardware
2014-04-11 06:14 Luke-Jr has quit [Read error: Connection reset by peer]
2014-04-11 06:15 arielenter has quit [Client Quit]
2014-04-11 06:16 Luke-Jr has joined #qi-hardware
2014-04-11 07:23 jekhor_ has joined #qi-hardware
2014-04-11 07:26 jekhor has quit [Ping timeout: 240 seconds]
2014-04-11 07:31 jekhor_ has quit [Read error: Connection reset by peer]
2014-04-11 07:31 jekhor_ has joined #qi-hardware
2014-04-11 07:37 gbraad_ has joined #qi-hardware
2014-04-11 07:37 gbraad_ has joined #qi-hardware
2014-04-11 07:38 gbraad has quit [Ping timeout: 246 seconds]
2014-04-11 07:47 jekhor_ has quit [Read error: Connection reset by peer]
2014-04-11 07:50 jekhor has joined #qi-hardware
2014-04-11 08:18 wolfspraul has quit [Quit: leaving]
2014-04-11 08:18 wolfspraul has joined #qi-hardware
2014-04-11 08:20 atommann has quit [Ping timeout: 276 seconds]
2014-04-11 08:21 sb0 has joined #qi-hardware
2014-04-11 08:33 atommann has joined #qi-hardware
2014-04-11 08:37 wolfspraul has quit [Quit: leaving]
2014-04-11 08:38 wolfspraul has joined #qi-hardware
2014-04-11 08:49 jekhor has quit [Read error: Connection reset by peer]
2014-04-11 08:50 jekhor has joined #qi-hardware
2014-04-11 09:29 wolfspraul has quit [Ping timeout: 240 seconds]
2014-04-11 09:31 wolfspraul has joined #qi-hardware
2014-04-11 09:55 snufkintardis has joined #qi-hardware
2014-04-11 09:59 snufkintardis has quit [Ping timeout: 240 seconds]
2014-04-11 10:17 atommann has quit [Quit: Leaving]
2014-04-11 10:32 wolfspra1l has joined #qi-hardware
2014-04-11 10:35 wolfspraul has quit [Ping timeout: 240 seconds]
2014-04-11 10:38 xiangfu has quit [Ping timeout: 245 seconds]
2014-04-11 11:19 <DocScrutinizer05> OUCH! tivoization or what?
2014-04-11 11:20 <DocScrutinizer05> you want to "root" a tivoized device? forget it, probably simply not worth it, even IF possible
2014-04-11 11:23 <whitequark> ehh, plenty of cases where the vendor is a complete idiot
2014-04-11 11:23 <whitequark> e.g. galaxy s ii
2014-04-11 11:24 <whitequark> the "secure boot" key is zeroed :D
2014-04-11 11:24 <whitequark> and there's some code which indicates that they never actually bothered to turn off "development mode" in production
2014-04-11 11:29 <DocScrutinizer05> secure boot is da shite, usually the core developers don't bother or even hate it. It's a management decision that makes implementation of tivoization a product requirement
2014-04-11 11:31 <DocScrutinizer05> a quote from infobot about ~'#maemo aegis':
2014-04-11 11:31 <DocScrutinizer05> http://www.developer.nokia.com/Community/Wiki/Harmattan:Developer_Library/Developing_for_Harmattan/Harmattan_security/Security_guide , or "The purpose of this framework is: ... to make sure that the platform meets the requirements set by third party software that requires a safe execution environment.", or http://en.wikipedia.org/wiki/Trusted_Computing#Criticism, or  http://en.qi-hardware.com/w/images/1/10/ME_382_LockedUpTechnology2.
2014-04-11 11:31 <DocScrutinizer05> gif
2014-04-11 11:31 <wpwrak> "secure boot" has valid purposes. but you rarely see it used for them.
2014-04-11 11:32 <DocScrutinizer05> the "valid purposes" are pretty hard to implement and deploy, without producing negative impact on user's freedom
2014-04-11 11:32 <wpwrak> of course, why make the effort to make something better for the customer if it's so much more fun to just be an asshole ? :)
2014-04-11 11:33 <wpwrak> well, sometimes the priority isn't freedom but security. e.g., think of a password safe. you _want_ it to be hard to mess with its internals.
2014-04-11 11:33 <DocScrutinizer05> Nokia claimed aegis was "for the user's security", in fact it been one huge PITA
2014-04-11 11:34 <DocScrutinizer05> you can't protect your password vault by any other means than forbidding installation of any software that's not certified by a central authority
2014-04-11 11:35 <DocScrutinizer05> http://www.youtube.com/watch?v=0cbS_lDJuJg
2014-04-11 11:37 <wpwrak> well, i plan to give anelok a bit more flexibility. i want to leave it to the user to install certificates, or to revoke them. that would include the certificate they use to install certificates.
2014-04-11 11:40 <DocScrutinizer05> then you need to ship the device with this TPM infra already set up and engaged, and you need to deploy the root cert private key in a separate channel to user
2014-04-11 11:42 <DocScrutinizer05> and of course each root cert needs to be unique
2014-04-11 11:43 <DocScrutinizer05> otherwise rogue-user is using the privkey you send to him, to compromise/root devices you send to other customers
2014-04-11 11:47 <DocScrutinizer05> then each user basically needs a tool to sign installation packages in a trusted environment with his unique private key
2014-04-11 11:49 <DocScrutinizer05> dunno what's your benchmark for "trusted environment" in the latter, maybe a standard PC would satisfy your security requirements
2014-04-11 11:50 <DocScrutinizer05> anyway you must be sure about that environment not compromising your private key or the packages you sign
2014-04-11 11:51 <DocScrutinizer05> and obviously you don't want to install the privkey to anelok, no matter how trusted you consider this environment. So on-platform signing is a nogo
2014-04-11 11:54 <DocScrutinizer05> at this point you should stand back a step or two, look at the whole picture and ask "what's the purpose of this exercise?"
2014-04-11 11:55 <DocScrutinizer05> avoid rogue software getting installed on your secure device aka anelok? can as well egt implemented with proper usual unix/posix permissions/capabilities
2014-04-11 11:56 <DocScrutinizer05> no root password, no installation of rogue software
2014-04-11 12:03 <DocScrutinizer05> nota bene to avoid flashing a new kernel by rogue hax0r you don't need any of that cert and TPM/tivoization crap. You just need to make sure the flashing is asking for a unique password assigned to your particular device
2014-04-11 12:08 <DocScrutinizer05> IOW as long as yur ROM bootloader has a feature to flash new kernel but doesn't allow readout of the kernel on device, it's absolutely sufficient when you hardcode your individual unlock key for the TPM storage to your kernel before flashing it
2014-04-11 12:12 <DocScrutinizer05> of course it's even better when your lowest stage bootloader (aka ROMBL) already asks for a password to allow anything to run on the device, during boot
2014-04-11 12:13 <wpwrak> (separate channel) correct. each user needs to get a "personal" master certificate. plus is encouraged to change it, so that not even the issuer has a way of knowing.
2014-04-11 12:13 <DocScrutinizer05> this way nobody who doesn't know your password could install any software at all to the device. Still no PKI and certs and stuff needed
2014-04-11 12:14 <wpwrak> (environment) anelok can still generate private keys. that's not insecure because what those keys are protecting is anelok itself. so if it's already compromised, you don't make things worse.
2014-04-11 12:15 <DocScrutinizer05> but also not better
2014-04-11 12:15 <wpwrak> better than "safe" ? :)
2014-04-11 12:15 <DocScrutinizer05> better than "already compromised"
2014-04-11 12:16 <wpwrak> well yes, but if it's gone, it's gone.
2014-04-11 12:16 <wpwrak> you can't put the genie back in the bottle
2014-04-11 12:17 <DocScrutinizer05> exactly, the whole thing is a bloated monster to establish... snakeoil, usually. Or tivoization which means you assign root to somebody else (manuf) and you don't own your own device anymore
2014-04-11 12:18 <wpwrak> the latter is not the idea. you get all the keys you want. the device may or may not come with "immutable" flash. (would be a nice order-time option)
2014-04-11 12:18 <wpwrak> if "immutable", you can't even blank it. if "mutable", you (or anyone else) can.
2014-04-11 12:19 <DocScrutinizer05> sure somebody could run your original kernel in a virtual machine, on anelok, thus tricking you into thinking the device is still "clean". But could they *really* or is this just a theoretical attack vector that doesn't fit through the eye of the needle of your actual hardware resources?
2014-04-11 12:20 <wpwrak> blanking means that all keys are deleted. so the device can't access things it has access to before blanking. but of course you could then install any malicious firmware you want.
2014-04-11 12:20 <wpwrak> kernel ? anelok doesn't run linux. it's just a lowly cortex M0+
2014-04-11 12:21 <DocScrutinizer05> doesn't matter
2014-04-11 12:21 <DocScrutinizer05> call it kernel or call it main()
2014-04-11 12:22 <DocScrutinizer05> I don't see how cert PKI helps in all this
2014-04-11 12:23 jekhor has quit [Ping timeout: 250 seconds]
2014-04-11 12:24 DocScrutinizer51 has quit [Quit: ZNC - http://znc.sourceforge.net]
2014-04-11 12:24 <wpwrak> i'm not talking about the global scheme, with verisign, thawte, cacert, turktrust, and all these. that's obviously pointless.
2014-04-11 12:24 DocAvalanche has joined #qi-hardware
2014-04-11 12:25 DocAvalanche is now known as DocScrutinizer51
2014-04-11 12:25 <DocScrutinizer05> grrrrr, ZNC acting up
2014-04-11 12:25 <wpwrak> i'm not talking about the global scheme, with verisign, thawte, cacert, turktrust, and all these. that's obviously pointless.
2014-04-11 12:25 <wpwrak> the issuer would be anelok.com. then you're free to do what you want.
2014-04-11 12:25 <DocScrutinizer05> me neither does
2014-04-11 12:25 <wpwrak> anyway, gotta run. dentist's appintment.
2014-04-11 12:25 <DocScrutinizer05> eeew
2014-04-11 12:27 <DocScrutinizer05> (ZNC) hmm
2014-04-11 12:27 <DocScrutinizer05> roh: did you boot andromeda?
2014-04-11 12:28 <DocScrutinizer05> (thus lagrange)
2014-04-11 12:28 <DocScrutinizer05> nevermind
2014-04-11 12:37 kyak has quit [Read error: Operation timed out]
2014-04-11 12:45 kyak has joined #qi-hardware
2014-04-11 13:36 pcercuei has joined #qi-hardware
2014-04-11 13:42 jekhor has joined #qi-hardware
2014-04-11 13:48 Luke-Jr has quit [Excess Flood]
2014-04-11 13:48 Luke-Jr has joined #qi-hardware
2014-04-11 15:15 pcercuei has quit [Ping timeout: 240 seconds]
2014-04-11 15:19 jekhor has quit [Ping timeout: 258 seconds]
2014-04-11 15:28 arielenter has joined #qi-hardware
2014-04-11 15:44 jekhor has joined #qi-hardware
2014-04-11 15:47 <wpwrak> (eew) naw, dental procedures are pretty tame nowadays. well, if you go to a capable dentist. if you choose one whose principal professional experience is with four-legged patients, you may get what you deserve :)
2014-04-11 15:48 arielenter has quit [Ping timeout: 276 seconds]
2014-04-11 16:03 arielenter has joined #qi-hardware
2014-04-11 16:05 <larsc> or just compensate their lack of talent with enough NO ;)
2014-04-11 16:15 grrk-bzzt has joined #qi-hardware
2014-04-11 16:15 <grrk-bzzt> Hello
2014-04-11 16:15 <grrk-bzzt> What's the state of Qi-Hardware?
2014-04-11 16:30 <DocScrutinizer51> 42  ;)
2014-04-11 16:31 jekhor has quit [Ping timeout: 250 seconds]
2014-04-11 16:32 <wpwrak> stable, unchanging, unyielding :)
2014-04-11 16:35 <DocScrutinizer51> or
2014-04-11 16:35 <DocScrutinizer51> !top10
2014-04-11 16:35 <qi-bot> Top10(words): 1. wpwrak(512310) 2. whitequark(201439) 3. wolfsprau(157938) 4. DocScrutinizer05(142757) 5. wolfspraul(106528) 6. kristianpaul(98809) 7. kyak(84433) 8. roh(69305) 9. viric(61479) 10. larsc(37457)
2014-04-11 16:36 <DocScrutinizer51> !status
2014-04-11 16:51 <kyak> !stat DocScrutinizer05
2014-04-11 16:51 <qi-bot> DocScrutinizer05: 142757 words, 834121 letters, 14095 lines, 10.13 words/line, 153 actions, 661 smilies, 1592 questions, 524 joins, 0 kicks, 1 modes, 144 nicks, 1 topics, time wasted: 1 year 39 weeks 1 day 6 hours 20 minutes , 65.31 idle-factor.
2014-04-11 16:51 <kyak> !stat
2014-04-11 16:51 <qi-bot> kyak: 84436 words, 488750 letters, 8784 lines, 9.61 words/line, 26 actions, 1561 smilies, 1546 questions, 379 joins, 0 kicks, 0 modes, 3 nicks, 0 topics, time wasted: 2 years 50 weeks 6 days 2 hours 40 minutes , 178.05 idle-factor.
2014-04-11 16:52 <wpwrak> !stat
2014-04-11 16:52 <qi-bot> wpwrak: 512311 words, 2892069 letters, 34425 lines, 14.88 words/line, 129 actions, 13972 smilies, 5538 questions, 330 joins, 0 kicks, 0 modes, 4 nicks, 0 topics, time wasted: 2 years 51 weeks 4 days 22 hours 43 minutes , 45.68 idle-factor.
2014-04-11 16:53 * wpwrak wasted almost an entire week more than kyak ! :)
2014-04-11 16:53 <kyak> wpwrak: you produced 3 Mb of text :)
2014-04-11 16:53 <kyak> in 3 years
2014-04-11 16:53 <wpwrak> about 10% of my 1st hard disk :)
2014-04-11 16:53 <kyak> --)
2014-04-11 17:16 <eintopf> :/
2014-04-11 17:16 <whitequark> !stat
2014-04-11 17:16 <qi-bot> whitequark: 201440 words, 1171987 letters, 21310 lines, 9.45 words/line, 256 actions, 413 smilies, 2665 questions, 173 joins, 0 kicks, 0 modes, 32 nicks, 0 topics, time wasted: 2 years 46 weeks 1 day 11 hours 23 minutes , 71.19 idle-factor.
2014-04-11 17:39 jekhor has joined #qi-hardware
2014-04-11 17:47 <grrk-bzzt> wpwrak, stable as in "dead"?
2014-04-11 17:47 <grrk-bzzt> !stat
2014-04-11 17:47 <qi-bot> grrk-bzzt: 6 words, 33 letters, 2 lines, 3.00 words/line, 0 actions, 0 smilies, 1 questions, 0 joins, 0 kicks, 0 modes, 0 nicks, 0 topics, time wasted: 1 hour 26 minutes , 43.00 idle-factor.
2014-04-11 17:57 <Web-aptosid876_> !stat
2014-04-11 17:57 <qi-bot> Web-aptosid876_: 2556 words, 13676 letters, 262 lines, 9.76 words/line, 0 actions, 19 smilies, 41 questions, 3 joins, 0 kicks, 0 modes, 0 nicks, 0 topics, time wasted: 1 week 1 day 7 hours 16 minutes , 45.63 idle-factor.
2014-04-11 18:04 <eintopf> !stat
2014-04-11 18:04 <qi-bot> eintopf: 1677 words, 8895 letters, 307 lines, 5.46 words/line, 1 actions, 40 smilies, 30 questions, 37 joins, 0 kicks, 0 modes, 8 nicks, 0 topics, time wasted: 1 year 4 weeks 3 days 8 hours 26 minutes , 1859.11 idle-factor.
2014-04-11 18:04 <eintopf> oh
2014-04-11 18:09 <kristianpaul> !stat
2014-04-11 18:09 <qi-bot> kristianpaul: 98810 words, 542534 letters, 13510 lines, 7.31 words/line, 319 actions, 3258 smilies, 2120 questions, 544 joins, 0 kicks, 0 modes, 0 nicks, 0 topics, time wasted: 2 years 40 weeks 4 days 9 hours 48 minutes , 108.12 idle-factor.
2014-04-11 18:09 <wpwrak> grrk-bzzt: more like the pyramids. relaxed, majestetic, not worried by what hurries past them, but yes, not dancing and jumping around either.
2014-04-11 18:16 <grrk-bzzt> That was a strange explanation
2014-04-11 18:19 <wpwrak> thanks ;-)
2014-04-11 18:31 <larsc> I'd say it is suspended until further notice
2014-04-11 18:33 <wpwrak> excellent explanation of heartbleed: http://xkcd.com/1354/
2014-04-11 18:46 jekhor has quit [Ping timeout: 250 seconds]
2014-04-11 18:50 <wpwrak> larsc: one could say we're here, engines running, but idling
2014-04-11 18:55 <larsc> My engines are off and the dust covers are on ;)
2014-04-11 18:58 <wpwrak> careful. they're still idling. noxious gases may build up under those covers.
2014-04-11 19:00 <eintopf> we need some upstarter project to search the mh370
2014-04-11 19:00 <eintopf> via echolons
2014-04-11 19:02 <wpwrak> there was some crowdsearching where a satellite imaging company made some images available
2014-04-11 19:02 porchaso0 has joined #qi-hardware
2014-04-11 19:03 <eintopf> mhh
2014-04-11 19:03 porchao has quit [Ping timeout: 240 seconds]
2014-04-11 19:03 <wpwrak> alas, only of a very tiny and in the end completely irrelevant region
2014-04-11 19:04 <eintopf> now I got some news about "all are alive and the plane was hijacked from terrorsit"
2014-04-11 19:05 <eintopf> wpwrak: I don't understand some point at the at86rf231 datasheet :(
2014-04-11 19:05 <eintopf> they describe a "Frame Receive Procedure" which doesn't work
2014-04-11 19:19 <wpwrak> eintopf: first, consider this: http://pics.nase-bohren.de/instruction-manual.jpg
2014-04-11 19:20 <wpwrak> and which part of the procedure do you disagree with ?
2014-04-11 19:21 <eintopf> :)
2014-04-11 19:22 <eintopf> page 126 figure 10-1 desribes "Transactions between AT86RF231 and Microcontroller during Receive"
2014-04-11 19:22 <eintopf> First IRQ_2 occures (IRQ_\RX_START)
2014-04-11 19:23 <eintopf> which indicates that's an rx interrupt, so I make a spinlock for is_rx or something else
2014-04-11 19:23 <eintopf> then waiting for the IRQ3 (IRQ_TRX_END)
2014-04-11 19:23 <eintopf> but I can't to that
2014-04-11 19:23 <wpwrak> i don't like thw word "spinlock" in this context, but go on ...
2014-04-11 19:23 <eintopf> , because the RX_START interrupt occurs after SFD
2014-04-11 19:24 <eintopf> wpwrak: yes I know :(
2014-04-11 19:24 <eintopf> page 39 describes when IRQ2 (RX_START) occurs
2014-04-11 19:24 <wpwrak> (after SFD) correct, even after PHR (page 39, figure on top)
2014-04-11 19:24 <wpwrak> yeah :)
2014-04-11 19:24 <eintopf> ah, we understand :)
2014-04-11 19:25 <eintopf> wpwrak: I don't know if I really need only the TRX_END irq for tx/rx
2014-04-11 19:25 <eintopf> because then I need a spinlock is_tx
2014-04-11 19:26 <eintopf> because I don't know what I am doing when TRX_END occurs
2014-04-11 19:26 <wpwrak> true, there is a race condition
2014-04-11 19:26 <wpwrak> what you could do is:
2014-04-11 19:26 <eintopf> maybe read the TRX_STATE
2014-04-11 19:26 <wpwrak> - if you're in RX mode, any TRX_END means that something has arrived
2014-04-11 19:27 <eintopf> yea... and I get the TRX_STATE also when I reading out the IRQ_STATUS
2014-04-11 19:27 <eintopf> that's the first receiving byte
2014-04-11 19:27 <wpwrak> - if you're in TX mode, first enter PLL_ON and make sure you've arrived there. then check TRX_END. and only then you're really in TX mode.
2014-04-11 19:28 <wpwrak> you can set it up to do this, yes. careful, though: the 230 can't do that.
2014-04-11 19:28 <wpwrak> only 231/232/233
2014-04-11 19:28 <eintopf> ... :(
2014-04-11 19:28 <eintopf> okay, thanks
2014-04-11 19:28 <wpwrak> of course, the 230 has many other interesting problems ;-)
2014-04-11 19:29 <eintopf> I tought there would be also some IRQ's for a successful statechange
2014-04-11 19:29 <eintopf> but there is nothing...
2014-04-11 19:31 <eintopf> wpwrak: but why the hell they describe the receive procedure like this
2014-04-11 19:31 <eintopf> it doesn't work for me
2014-04-11 19:33 <eintopf> I need to write a mail to atmel
2014-04-11 19:34 <larsc> wpwrak: do you know any production ready things that use 6lowpan?
2014-04-11 19:35 <wpwrak> i'm not even sure what PLL_ON does if you're in BUSY_RX. it seems that it would wait until the frame ends, then return to RX_ON, and then execute the PLL_ON
2014-04-11 19:36 <wpwrak> larsc: hmm no, but then i don't have much of an industry overview
2014-04-11 19:38 <wpwrak> (assuming you mean "finished" products, not just components. else there are some adapters, including of course atben/atusb :)
2014-04-11 19:38 <eintopf> ah, I need to change the SPI_CMD_MODE for the trx state...
2014-04-11 19:38 <eintopf> wpwrak: :/
2014-04-11 19:38 <larsc> we may or may not (I can't neither deny or confirm at this point ;)) want to build a demo showing interoptability with 3rd party 6lowpan solutions
2014-04-11 19:39 <eintopf> it works with contiki
2014-04-11 19:39 <eintopf> point to point
2014-04-11 19:40 <eintopf> but not tinyOS, the tinyOS 6lowpan stack isn't rfc complaint
2014-04-11 19:40 <eintopf> (I mean the BLIP stack)
2014-04-11 19:41 <eintopf> larsc: I run also coap on my linux system
2014-04-11 19:41 <wpwrak> larsc: linux-based ? (your end)
2014-04-11 19:42 <larsc> yes
2014-04-11 19:42 <larsc> but also contiki
2014-04-11 19:43 <wpwrak> contiki .. the suffering :)
2014-04-11 19:44 <eintopf> wpwrak: http://sourceforge.net/p/libcoap/code/ci/master/tree/str.c#l18
2014-04-11 19:44 <eintopf> look at this code
2014-04-11 19:44 <eintopf> I don't understand it
2014-04-11 19:44 <eintopf> it's for the libcoap implementation which is also for contiki
2014-04-11 19:45 <eintopf> coap_malloc(sizeof(str) + size + 1);
2014-04-11 19:45 <eintopf> str is a char * and why "+ size"
2014-04-11 19:45 <eintopf> always fun on a x86_64 bit system
2014-04-11 19:46 <larsc> str is not char *
2014-04-11 19:46 <eintopf> okay char
2014-04-11 19:46 <wpwrak> larsc: the problem is that a lot of that stuff seems to be in industrial settings and they're generally not very "open"
2014-04-11 19:47 <whitequark> contiki is truly horrible
2014-04-11 19:47 <eintopf> then he makes a str *
2014-04-11 19:47 <larsc> str is a struct
2014-04-11 19:47 <larsc> sizeof(str) is the size of that struct
2014-04-11 19:48 <eintopf> mhh
2014-04-11 19:48 <eintopf> then all things makes sense
2014-04-11 19:48 <eintopf> s->s = ((unsigned char *)s) + sizeof(str);
2014-04-11 19:49 <eintopf> he not allocate new memory
2014-04-11 19:49 <eintopf> some pointer magic
2014-04-11 19:49 <eintopf> mhh
2014-04-11 19:50 <wpwrak> it looks like the sort of code that can give you heartbleed ...
2014-04-11 19:50 <eintopf> :D
2014-04-11 19:50 <whitequark> wpwrak: it's written in C. of course it is!
2014-04-11 19:50 <wpwrak> especially COAP_SET_STR in http://sourceforge.net/p/libcoap/code/ci/master/tree/str.h
2014-04-11 19:50 <wpwrak> that's almost begging to be misunderstood
2014-04-11 19:51 <eintopf> wpwrak: the libcoap uses also autoconf defines in API headers
2014-04-11 19:51 <eintopf> but I have a workaround for that
2014-04-11 19:52 <wpwrak> whitequark: people who complain about C being "dangerous" are just cowards who try to avoid being held responsible for their mistakes :)
2014-04-11 19:52 <eintopf> the complete buildsystem is a autoconf without automake :(
2014-04-11 19:53 <wpwrak> a first step in the right direction. now just get rid of the rest of autocrap ...
2014-04-11 19:53 <whitequark> wpwrak: or the direct opposite? they have a sense of responsibility, and so they don't want to use a tool which amplifies their mistakes by several orders of magnitude
2014-04-11 19:54 <eintopf> wpwrak: you don't like autotools?
2014-04-11 19:54 <whitequark> I mean, building a house with lead paint is dangerous, and no amount of "don't lick lead paint if you wanna live" is going to convince anyone to change building codes
2014-04-11 19:54 <whitequark> even if lead paint is marginally cheaper than modern synthetic ones
2014-04-11 19:55 <wpwrak> eintopf: i'd rather depilate my testicles than use that steaming pile of bovine feces ...
2014-04-11 19:56 <whitequark> using C in 2014 is building a house painted with lead and lined with asbestos, and replying to the complaints of cancer and developmental delays that "omg, but there is already 1000 houses built like that, and we had a WHOLE BUCKET of lead paint, it's not like you can let that just *rot*."
2014-04-11 19:56 <eintopf> wpwrak: ah, I used google translator to understand your sentence
2014-04-11 19:56 <eintopf> that's funny :)
2014-04-11 19:57 <wpwrak> whitequark: you're still young. there's still plenty of time to learn to appreciate the greatness of C :)
2014-04-11 19:58 <whitequark> wpwrak: it's funny, considering that I know C well enough I could write a compiler *shrug*
2014-04-11 19:59 <eintopf> wpwrak: it works with the TRX_STATUS in the IRQ_STATUS request
2014-04-11 20:00 <whitequark> people seem to have a weird sense of pride in using horrible tools. true, using your homemade chainsaw without eye or hand protection probably raises your self-worth, but it doesn't help those maimed by the parts flying around at subsonic speeds
2014-04-11 20:02 <wpwrak> whitequark: i didn't question your proficiency in C but your understanding of its majesty ;-)
2014-04-11 20:02 <whitequark> in your own home, you can use whatever you want. the second you publish a new project in C, your fucking fingers need to be chopped off, to prevent damage to those green enough who dared to actually use that
2014-04-11 20:02 <whitequark> it's a public safety issue, more or less
2014-04-11 20:03 <larsc> na, you just shouldn't use dangerous tools if you are not trained to use them
2014-04-11 20:03 <wpwrak> alright alright, now go back, play some 2048, and thank the creator that linux is written in Ada ;-)
2014-04-11 20:03 <whitequark> a tool has no need to be majestic. a hammer isn't. I don't even *want* a majestic hammer, regardless of its safety. I want one that drives nails in
2014-04-11 20:04 <wpwrak> or .. what was it ... Rubbysh ? :)
2014-04-11 20:04 <whitequark> larsc: sure. but there is no consensus on who is considered trained, neither there is any wide understanding of that statement
2014-04-11 20:04 <whitequark> so it simply doesn't work in practice
2014-04-11 20:05 <eintopf> wpwrak: do you think I can also remove the tx_complete, for wait_for_completion? But I need to control that we don't send something if we already sending something
2014-04-11 20:05 wolfspra1l has quit [Quit: leaving]
2014-04-11 20:05 <whitequark> wpwrak: hence "new projects". it's not realistic to rewrite all of the old C code, not least because you will introduce 9 other bugs for 1 memory safety bug fixed
2014-04-11 20:06 <wpwrak> eintopf: isn't the upper layer already taking care of that ? problem is that you can't return before you're done (i think)
2014-04-11 20:06 <eintopf> yes
2014-04-11 20:06 <wpwrak> eintopf: hence the ###### above would have to be changed, too, if you want to avoid the "no return" restriction
2014-04-11 20:07 <eintopf> mhh
2014-04-11 20:07 <larsc> I agree that the current situation is very bad and we are kind of heading to the abyss and something has to change
2014-04-11 20:08 * wpwrak imagines a mime angrily pounding against an imaginary glass wall. you can see him hammer but you can't hear him scream
2014-04-11 20:08 <larsc> but I don't think that switching to "safe" languages will solve things
2014-04-11 20:08 <larsc> what we need is formal verification
2014-04-11 20:08 <larsc> of every instruction
2014-04-11 20:09 <whitequark> that's entirely unrealistic
2014-04-11 20:09 <whitequark> safe languages achieve comparatively huge benefit (memory safety) with comparatively little cost
2014-04-11 20:09 <wpwrak> and until then, perhaps a bit of a review process. that was the main failing that heartbleed showed.
2014-04-11 20:09 jekhor has joined #qi-hardware
2014-04-11 20:10 <whitequark> wpwrak: that as well. gotofail wouldn't be solved by safe languages.
2014-04-11 20:11 <wpwrak> yup. that's another one.
2014-04-11 20:12 <whitequark> however, not everything (including stuff directly caused by C's braindead execution model) would be solved by review
2014-04-11 20:12 <whitequark> e.g. this piece https://code.google.com/p/nativeclient/issues/detail?id=245 was reviewed by a bunch of guys who are on the top of the food chain, and it still slipped through, with disastrous consequences if deployed.
2014-04-11 20:13 <whitequark> (explanation at http://blog.regehr.org/archives/213 → Type 3 functions)
2014-04-11 20:14 <whitequark> there is *absolutely no reason whatsoever* to leave the sign bit stuff undefined in the standard. there is even less reason to not enable -fwrapv by default in every single compiler that exists. yet, it persists.
2014-04-11 20:15 <wpwrak> that cast doesn't look very "top of the foodchain"
2014-04-11 20:15 <larsc> the thing is we have tools to catch these kind of errors
2014-04-11 20:15 <kyak> code review has to be automated
2014-04-11 20:15 <kyak> using tools, right
2014-04-11 20:15 <wpwrak> for the rest ... yes, if you change the semantics of something without changing its type, you can get tricky bugs
2014-04-11 20:15 <whitequark> larsc: how many C projects are using those tools? 0.0001%?
2014-04-11 20:16 <kyak> formal verification is becoming more and more popular in recent years
2014-04-11 20:16 <sb0> whitequark, what do you think of lisp machines?
2014-04-11 20:16 <wpwrak> e.g., i don't particularly like "int" or its malleability. of course, you could play it safe and use a "struct". yet few people do.
2014-04-11 20:16 <whitequark> larsc: it's true we have them today. that wasn't the case a few years ago. the vast majority of people writing C are uneducated and will be uneducated on that matter for decades to come, probably.
2014-04-11 20:16 <whitequark> sb0: nothing in particular
2014-04-11 20:17 <whitequark> locking the machine to a single execution model dictated by a single language seems a bit silly
2014-04-11 20:17 <sb0> can't the same be said of traditional CPUs - made to run C?
2014-04-11 20:17 <whitequark> they're not
2014-04-11 20:17 <larsc> C is made to run on theses cpus
2014-04-11 20:18 <larsc> not vice versa
2014-04-11 20:18 <whitequark> I mean, show me evidence they are. the execution model of C isn't even similar to any existing CPU
2014-04-11 20:18 <wpwrak> wasn't RISC pretty much in spired by C and friends ?
2014-04-11 20:19 <whitequark> wpwrak: the first time I hear that
2014-04-11 20:19 <whitequark> sb0: the quirks of C standard very specifically come from the desire to specify the smallest possible subset of operations all interesting CPU support, while remaining backwards-compatible
2014-04-11 20:20 <wpwrak> the older designs have ... more complicated histories. and frankly, i can't quite fathom what monster they would have designed the VAX architecture for. maybe Algol 68.
2014-04-11 20:20 <whitequark> wpwrak: hm? weren't CISCs designed to be written by hand?
2014-04-11 20:21 <whitequark> I mean, compilers didn't change very much since they first appeared, and it was always common knowledge that compiled code uses a tiny fraction of instructions CISCs provide
2014-04-11 20:21 <wpwrak> you mean assembler ? well yes, some of them do make it almost look like a high-level language ...
2014-04-11 20:21 <whitequark> oh, that may be what you've referred to "inspired by C"
2014-04-11 20:21 <whitequark> I would say "designed to be compiled to", yes, I believe that was one of the goals
2014-04-11 20:22 <larsc> I always get dizy when I think about that stuff like the whole Linux kernel runs with full privileges
2014-04-11 20:24 <wpwrak> (cisc) fond memories of MOVC5 come to mind. memmove (not just memcpy !) and memset, all rolled into one single machine instruction ...
2014-04-11 20:25 <sb0> yeah; and it's architecturally very messy. e.g. you can access a USB stick either with fuse + libusb, or with kernel fs + usb mass storage driver
2014-04-11 20:26 <wpwrak> and then there's of course POLYH ...
2014-04-11 20:26 <whitequark> fuse is horrible.
2014-04-11 20:26 <whitequark> nothing that uses fuse ever works reliably.
2014-04-11 20:26 <whitequark> eventually, the server dies, and you have processes stuck on IO forever, and you just want to go somewhere and die
2014-04-11 20:26 <whitequark> (╯°□°）╯︵ ┻━┻
2014-04-11 20:28 <sb0> that's besides the point - and if you "kill" e.g. the ext4 module, bad things will happen too
2014-04-11 20:28 <whitequark> but you can't kill the ext4 module.
2014-04-11 20:28 <whitequark> and fuse servers will happily go and die themselves. tangentially related, they also often try to provide FS over network.
2014-04-11 20:29 <whitequark> FS over network is such a horrible idea it needs to be taught in school right next to Hitler
2014-04-11 20:29 <sb0> but the ext4 module can crash... the only reason it doesn't crash often is its code is better debugged than many fuse servers
2014-04-11 20:29 <wpwrak> (POLYH computes a polynom of arbitrary degree with 128-bit floating-point numbers. surprisingly, they limited the degree to <= 31. guess someone decided it would be inappropriate for the CPU to spend more than a day on a single instruction ...)
2014-04-11 20:30 <whitequark> sb0: well, my point is that in practice, literally no fuse servers I have tried were even remotely usable
2014-04-11 20:30 <wpwrak> whitequark: in russian school, they teach hitler
2014-04-11 20:31 <whitequark> even when the code technically works well (most of the time) (e.g. sshfs), the leaky abstraction of FS over network makes it a pain to use
2014-04-11 20:31 <whitequark> wpwrak: in russia, hitler teaches YOU
2014-04-11 20:31 <sb0> but nothing prevents people from writing a fuse server that has the same quality and stability as the ext4 kernel module
2014-04-11 20:32 <whitequark> sb0: nothing also prevents people to writing perfect X.509 deserializers on the first try
2014-04-11 20:32 <whitequark> somehow that doesn't happen
2014-04-11 20:32 <wpwrak> :)
2014-04-11 20:32 <sb0> in fact, it should be easier, since debugging userland crashes is easier then debugging kernel crashes
2014-04-11 20:33 <wpwrak> and you have valgrind
2014-04-11 20:33 <whitequark> I'm not analyzing the reason everything fuse related is shit. I'm stating the fact: it invariably is
2014-04-11 20:33 <whitequark> I would be happy for that to not be the case
2014-04-11 20:33 <wpwrak> zrafa: you hear him ?
2014-04-11 20:34 <whitequark> wpwrak: (valgrind... which is a very complex and expensive way to fix something that only happens because C is dumb)
2014-04-11 20:34 <sb0> guess that's because fewer people dare touch kernel modules than fuse - i.e. only people who know how to code to a good extent will even think about writing a kernel module
2014-04-11 20:34 <kyak> i'm using sshfs very regularly. Sometimes strange things happen, but not more oftern than with samba for example
2014-04-11 20:34 <whitequark> kyak: all network filesystems are broken to various degree
2014-04-11 20:34 <kyak> whitequark: so i need to stop using my NAS immediately?? :)
2014-04-11 20:34 <whitequark> the model that works is sync of local folders, not direct access to remote by software which can't even detect a disconnect properly or was written without regard to delays
2014-04-11 20:35 <larsc> kyak: stop using networks!
2014-04-11 20:36 <whitequark> it's... systems design 101. don't pretend that remote things are local. don't replace an interface with another one with a much wider range of failure modes without even adding a way to observe those failures
2014-04-11 20:36 <larsc> that would have alsoavoided the heartbleed bug
2014-04-11 20:36 <kyak> and also prevent this conversaion from happening
2014-04-11 20:37 <larsc> probably the best benefit ;)
2014-04-11 20:37 <kyak> whitequark: common, give us something positive today!
2014-04-11 20:37 <whitequark> kyak: you're not dead yet
2014-04-11 20:38 * kyak hides
2014-04-11 20:38 <wpwrak> darn. so this isn't hell yet ?
2014-04-11 20:38 <kyak> hell no!
2014-04-11 20:42 <larsc> whitequark: he said something positive
2014-04-11 20:44 <kyak> positive doesn't arouse much discussion :)
2014-04-11 20:49 Luke-Jr has quit [Remote host closed the connection]
2014-04-11 20:58 dandon has quit [Remote host closed the connection]
2014-04-11 21:08 dos1 has joined #qi-hardware
2014-04-11 21:27 <wpwrak> indeed. instant discussion death :)
2014-04-11 21:38 <wpwrak> zrafa: btw, did you try to flash over swd ?
2014-04-11 21:45 arielenter has quit [Quit: Leaving.]
2014-04-11 21:46 arielenter1 has joined #qi-hardware
2014-04-11 21:54 zrafa has quit [Ping timeout: 240 seconds]
2014-04-11 21:54 zrafa has joined #qi-hardware
2014-04-11 22:19 jekhor has quit [Ping timeout: 252 seconds]
2014-04-11 22:56 mth has quit [Read error: Connection reset by peer]
2014-04-11 22:56 mth has joined #qi-hardware
2014-04-11 22:58 sb0 has quit [Quit: Leaving]
2014-04-11 23:16 rz2k has joined #qi-hardware
2014-04-11 23:19 arielenter1 has quit [Ping timeout: 276 seconds]
2014-04-11 23:45 arielenter has joined #qi-hardware
2014-04-11 23:54 arielenter has quit [Quit: Leaving.]