| 00:32.19 | whitequark | http://arstechnica.com/information-technology/2012/06/amd-to-add-arm-processors-to-boost-chip-security/ |
| 00:32.57 | whitequark | one of the rare times I see a situation and see a nanonote as an immediately useful solution |
| 00:36.27 | wpwrak | you want to add a nanonote to the cpu ? |
| 00:36.55 | whitequark | naw |
| 00:37.04 | *** join/#qi-hardware Ayla (~paul@ACaen-252-1-213-138.w86-215.abo.wanadoo.fr) |
| 00:37.10 | whitequark | just recalled a new Cory Doctorow's book |
| 00:37.33 | whitequark | they used a small and presumably somewhat trusted computer to do a key signing party |
| 00:38.37 | whitequark | (they) the book is 1984, but in 2014. you got the idea. I'm too sleepy now to explain it properly anyway. |
| 00:39.06 | wpwrak | (small computer) ah, i see. yes, the ben is quite good at being small ;-) |
| 00:39.38 | whitequark | while I'm not absolutely sure that NN's CPU does not contain backdoors (I haven't examined the actual silicon), that would have a really really low probability |
| 00:39.52 | whitequark | and it definitely does not have backdoors as features |
| 00:40.15 | whitequark | the next-NN with M1 SoC should fix this problem |
| 00:40.22 | wpwrak | CPU backdoors would also be kinda tricky |
| 00:40.30 | whitequark | yes |
| 00:40.35 | wpwrak | fpgas could still have "backdoors" ;-) |
| 00:40.37 | whitequark | besides that, NN does not have any wireless ifaces |
| 00:40.49 | whitequark | which makes it quite perfectly safe for the task |
| 00:40.54 | wpwrak | mine do, sometimes :) |
| 00:41.17 | whitequark | well, a cpu backdoor would require extensible software cooperation |
| 00:41.30 | whitequark | so I don't think it's even a theoretically realistic scenario |
| 00:41.56 | whitequark | after all, if you're _that_ paranoid, you can do RSA with a calculator |
| 00:41.59 | whitequark | or a pen and a piece of paper |
| 00:42.06 | whitequark | definitely no backdoors there. |
| 00:42.40 | wpwrak | someone whispering numbers to make you miscalculate |
| 00:42.46 | whitequark | (fpgas) yeah, I won't blindly trust a fab to not alter the netlist. but I would evaluate the complexity of such a task, and again, it is not realistic at all |
| 00:43.12 | whitequark | not significantly more realistic than (/me drops a pen on the floor) that pen tunneling through the floor. |
| 00:43.17 | *** join/#qi-hardware Ayla (~paul@ACaen-252-1-213-138.w86-215.abo.wanadoo.fr) |
| 00:43.29 | whitequark | it's possible according to quantum mechanics, just not very probable :D |
| 00:43.57 | whitequark | besides which, netlists were OCR'd with a microscope and a polarizer, and if you have the sources |
| 00:44.06 | whitequark | (see: visual6502.org) |
| 00:44.19 | whitequark | it's all verifiable, through hard |
| 00:44.34 | whitequark | but military supposedly does that verification, and so could any interested party |
| 00:45.35 | whitequark | wpwrak: are you perfectly sure that your C compiler doesn't have a, say, self-reproducible `login' backdoor which it inserts in `login' and `cc' itself, but which does not appear in the sources? |
| 00:45.40 | whitequark | gcc is built with gcc for ages |
| 00:45.54 | whitequark | have it always had digital signatures? were they enforced? |
| 00:46.28 | kristianpaul | remenber gnu's ftp was compromised time ago |
| 00:47.00 | whitequark | I often think that when working with security, you just need to go to the extreme. not to do something practical, but just to evaluate the risk |
| 00:47.09 | whitequark | what once seemed impossible is easy now |
| 00:47.18 | whitequark | e.g. trusted computing |
| 00:47.29 | whitequark | people would laugh on this idea in '85 |
| 00:47.58 | whitequark | (or should I write "trusted" each time?..) |
| 00:48.07 | whitequark | [that is, quoted.] |
| 00:48.20 | wpwrak | my paranoia knows limits :) |
| 00:48.52 | whitequark | wpwrak: would you consider someone placing a supplementary core as a backdoor in your CPU 20 years ago? |
| 00:49.01 | whitequark | or, for current CPUs, there is SMM |
| 00:49.08 | whitequark | which is technically an undetectable backdoor |
| 00:51.20 | whitequark | it's not paranoia and I'm not going to throw away my Galaxy SII because it has a trusted computing module in the CPU (maybe because of the blobs; they're so badly written that they can be broken not because of malice but simply of stupidity) |
| 00:51.43 | kristianpaul | so what it is? |
| 00:51.53 | whitequark | an evaluation of possibilites |
| 00:52.20 | whitequark | modern CPUs are incredibly complex (they're more like SoCs already, even in PCs), and they get more complex each year |
| 00:52.32 | whitequark | it's anything but hard to hide a backdoor in a device like this |
| 00:52.53 | kristianpaul | yup |
| 00:53.04 | whitequark | for example, anyone familiar with FPGAs could confirm that it's easy to make a special long command stream that |
| 00:53.10 | whitequark | will instantly throw you to ring0 |
| 00:53.17 | whitequark | or just instantly smm |
| 00:53.30 | whitequark | enough, you're pwned. |
| 00:53.46 | whitequark | you can even hide it in microcode if you want |
| 00:54.23 | whitequark | besides which, AMD openly states that they put a backdoor in the CPU. |
| 00:54.33 | whitequark | what else do you fucking need?! |
| 00:57.08 | whitequark | ... and silence was an answer to him :) |
| 00:57.13 | whitequark | whatever, I'm gonna get some sleep. |
| 00:57.22 | whitequark | 5AM here |
| 00:57.55 | kristianpaul | I was about to said that (sleep) :_) |
| 01:50.12 | *** join/#qi-hardware Textmode (~boneidle@adsl-syd-1-124.ozonline.com.au) |
| 01:52.34 | *** join/#qi-hardware wej (~j@95.211.13.35) |
| 02:36.34 | *** join/#qi-hardware wej (~j@95.211.13.35) |
| 02:52.50 | *** join/#qi-hardware rzk (~rzk@2002:5f1c:e277:1:222:4dff:fe7c:450f) |
| 02:55.31 | *** join/#qi-hardware Textmode (~boneidle@adsl-syd-1-124.ozonline.com.au) |
| 03:04.06 | *** join/#qi-hardware dandon (~dandon@88.151.79.253) |
| 03:57.38 | wolfspraul | my first practical goal for fpgatools will be an inverter :-) |
| 03:57.56 | wolfspraul | I think that's the shortest path to something that runs |
| 03:58.45 | wolfspraul | so I will take the smallest spartan-6 (xc6slx4), buy a bunch of them (like 10-20), then make the most minimal board possible to just power the chip and expose jtag |
| 03:59.17 | wolfspraul | then use fpgatools to program the chip and get the inverter to work |
| 03:59.39 | wolfspraul | oh I guess I need 2 pads for the inverter itself as well |
| 03:59.55 | *** join/#qi-hardware Textmode (~boneidle@adsl-syd-1-124.ozonline.com.au) |
| 04:00.22 | wolfspraul | inside the chip, the inverter will start at one pad, pass through an I/OLOGIC and some switch boxes before coming out negated on the other pad |
| 04:00.35 | wolfspraul | that's the plan :-) |
| 04:04.24 | wpwrak | you can develop this on milkymist ... |
| 04:21.14 | DocScrutinizer05 | reads acklog and smiles |
| 04:21.19 | DocScrutinizer05 | back* |
| 04:27.59 | *** join/#qi-hardware Textmode (~boneidle@adsl-syd-1-124.ozonline.com.au) |
| 04:48.32 | roh | re |
| 05:08.55 | pabs3 | whitequark: got a link to the AMD CPU backdoor thing? |
| 05:11.13 | *** join/#qi-hardware jekhor (~jek@46.53.195.29) |
| 05:12.08 | *** join/#qi-hardware emeb (~ericb@12.196.36.226) |
| 05:16.12 | *** join/#qi-hardware Textmode (~boneidle@adsl-syd-1-124.ozonline.com.au) |
| 06:11.21 | *** join/#qi-hardware emeb (~ericb@12.196.36.226) |
| 06:20.53 | *** part/#qi-hardware emeb (~ericb@12.196.36.226) |
| 06:39.09 | wolfspraul | wpwrak: no that would miss the point, right now |
| 06:39.17 | wolfspraul | I am working in the bitstream, and already dealing with 2+ million bits |
| 06:39.26 | wolfspraul | I don't want to deal with 10 million instead |
| 06:39.48 | wolfspraul | plus a slx4-based inverter allows me to go through the pcb-making as well |
| 06:40.19 | wolfspraul | but I'm coming at it from the side of the fpgatools, where I do need small incremental steps to work through the many many different 'things' that are on any spartan-6 chip, even the smallest |
| 06:40.46 | wolfspraul | of course after the inverter I will do a few more gates, include slices, more switch boxes, and eventually work my way up to larger chips like a slx45 |
| 06:40.58 | wolfspraul | but one by one, that's the point: inverter on slx4 :-) |
| 06:41.30 | wolfspraul | the inverter doesn't even need a slice because it uses an invert mux right in the io block |
| 06:41.46 | wolfspraul | good for me |
| 07:17.20 | *** join/#qi-hardware larsc (~lars@eisbaer.ursus-maritimus.org) |
| 08:18.12 | pabs3 | DocScrutinizer: so Nokia is joining the mobile patent wars, nice |
| 08:48.43 | lekernel | wpwrak: this wasn't a good time? huh? |
| 08:52.07 | wpwrak | lekernel: they were working on other changes that would have interfered |
| 08:54.00 | wpwrak | wolfspraul: hmm, so the difference between the FPGA in M1 and the FPGA you want to play with would merely be size but not structural variety ? in that case, can't you just ignore the extra 8 Mbits, just like you'll already ignore some ~2 Mbits your inverter doesn't need ? |
| 08:54.50 | wpwrak | wolfspraul: (pcb-making) you should really pick something simpler to get started. don't worry, even simple things can get quite hard when you do them for the first time :) |
| 08:56.10 | *** join/#qi-hardware lekernel_ (~lekernel@g231250115.adsl.alicedsl.de) |
| 09:15.02 | whitequark | DocScrutinizer05: yeah, I remember our discussion about paranoia, yes :) it'd be wrong to say that it didn't make me think |
| 09:15.12 | whitequark | pabs3: http://arstechnica.com/information-technology/2012/06/amd-to-add-arm-processors-to-boost-chip-security/ |
| 09:34.12 | whitequark | DocScrutinizer05: just found an interesting feature in SGS2 BP |
| 09:34.51 | whitequark | if you'll send 0xDEADDEAD to the BP bootloader instead of data length, then, instead of writing, it'll read entire modem RAM and send it to host |
| 09:34.57 | whitequark | yes, it can write too, and reboot |
| 09:35.06 | whitequark | and it doesn't exactly verify any signatures |
| 09:35.16 | whitequark | well, theoretically it does, but looks like someone fucked it up |
| 09:35.27 | viric | whitequark: djbclark gave them to me |
| 09:35.51 | whitequark | looks like I'm lucky on baseband modules with interesting features |
| 09:38.05 | pabs3 | interesting discovery |
| 09:39.15 | whitequark | SGS2 looks like that everywhere |
| 09:39.42 | whitequark | it's more of devboard than a phone: there are *some* locks, but they're not very difficult to bypass |
| 09:40.33 | whitequark | ... and I tried asking a Korean dev about a feature of a PMIC which was under NDA |
| 09:40.40 | whitequark | and got a helpful reply |
| 09:41.35 | whitequark | maybe osmocombb folks would be interested? |
| 09:41.41 | whitequark | the BP is based on xgold262 |
| 09:42.02 | whitequark | er, 626 |
| 09:43.11 | *** join/#qi-hardware phirsch (~phirsch@xdsl-89-0-82-22.netcologne.de) |
| 09:44.35 | lekernel | just build your own fucking BP |
| 09:44.53 | lekernel | it's really frustrating to see how many hours are spent reverse engineering proprietary stuff that becomes obsolete in 1 yr |
| 09:45.48 | viric | what is a bp? |
| 09:45.53 | whitequark | baseband processor |
| 09:46.01 | whitequark | cpu in mobile phones which talks to the GSM network |
| 09:50.27 | viric | ah ok |
| 09:54.08 | wpwrak | *hmm*. i need a C function that returns a pointer to a function just like itself. do i need more sleep/caffeine or is void * really the best i can do in terms of type safety ? |
| 10:03.24 | whitequark | hmmm |
| 10:03.26 | whitequark | interesting |
| 10:04.30 | wpwrak | nice, isn't it ? an infinitely recursive type declaration :) |
| 10:04.59 | whitequark | yeah, C isn't haskell |
| 10:05.05 | whitequark | so, only void* |
| 10:06.08 | wpwrak | and of course, typedef won't accept the same name at two places |
| 10:19.00 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 10:20.25 | whitequark | yeah |
| 10:20.32 | whitequark | that's why I said it's not haskell |
| 10:30.24 | *** join/#qi-hardware kyak (~kyak@95-24-211-156.broadband.corbina.ru) |
| 10:30.24 | *** join/#qi-hardware kyak (~kyak@unaffiliated/kyak) |
| 10:32.46 | *** join/#qi-hardware Aylax (~Aylax@ACaen-252-1-213-138.w86-215.abo.wanadoo.fr) |
| 10:53.47 | viric | wpwrak: http://c-faq.com/decl/recurfuncp.html |
| 10:54.53 | viric | the struct trick looks good to me |
| 10:55.15 | viric | if you can afford a struct. :) |
| 10:56.06 | wpwrak | oh, that's pretty nice. thanks ! |
| 11:46.54 | *** join/#qi-hardware phirsch (~phirsch@xdsl-89-0-82-22.netcologne.de) |
| 12:16.35 | *** join/#qi-hardware Aylax (~Aylax@ACaen-252-1-213-138.w86-215.abo.wanadoo.fr) |
| 12:44.30 | viric | What do you think, about GPL.... |
| 12:44.44 | viric | There is a GPL software... |
| 12:44.52 | viric | but I can download it only if I identify myself. |
| 12:45.11 | *** join/#qi-hardware DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 12:45.39 | viric | Does GPL say anything about the right to (more or less) private access to the sources? |
| 12:46.01 | *** join/#qi-hardware DocScrutinizer06 (~HaleBopp@openmoko/engineers/joerg) |
| 12:46.17 | viric | - A government website lets me download a GPL criptography software they developed, but only if I identify myself and explain why I download that. |
| 12:48.18 | DocScrutinizer06 | viric: wpwrak: this again convinced me I don't know shit about c and better resort to beating up grannies on the street and robbing their handbags |
| 12:48.39 | viric | :) |
| 12:49.08 | DocScrutinizer06 | or simply refuse coding in anything but assembler |
| 12:59.04 | lekernel | viric: opencores does a similar thing :) |
| 13:00.50 | viric | ahh |
| 13:03.30 | *** join/#qi-hardware Ayla (~paul@ACaen-252-1-213-138.w86-215.abo.wanadoo.fr) |
| 13:09.46 | *** join/#qi-hardware Ayla (~paul@ACaen-252-1-213-138.w86-215.abo.wanadoo.fr) |
| 13:13.41 | wpwrak | viric: on the first access, they can make you jump as many hoops they want. make you agree to deliver a million euro, your soul, your firstborn, droit du seigneur, whatever. |
| 13:14.02 | kristianpaul | viric: redoi |
| 13:14.13 | kristianpaul | sorry |
| 13:14.19 | wpwrak | viric: but then you're FREE to spread as many copies as you want, to whomever you want :) |
| 13:14.49 | kristianpaul | viric: redistribution is not mandatory at least you use that software i understand |
| 13:15.05 | wpwrak | DocScrutinizer: C is an amazing language. it grows with you. the better your skills get, the more you understand its perfection. |
| 13:15.30 | kristianpaul | yup, (grows part) |
| 13:15.39 | DocScrutinizer05 | the better you understand C the more you wish it never got invented ;-) |
| 13:16.16 | wpwrak | DocScrutinizer: you prefer junk languages like C++ ? :) |
| 13:16.26 | DocScrutinizer05 | eeeeeeeeeeeeEEEEEEEEEEEeeeeeeeeeeeeeek |
| 13:16.49 | DocScrutinizer05 | I'm one of those Wirth softies ;-P |
| 13:17.09 | wpwrak | aha, a quiche-eater :) |
| 13:17.15 | DocScrutinizer05 | indeed |
| 13:17.58 | wpwrak | luckily, i was able to shake that bad habit a good while ago |
| 13:18.02 | DocScrutinizer05 | strict typechecks - heaven! |
| 13:18.18 | viric | kristianpaul: I've to use that software to send my taxes report |
| 13:18.21 | wpwrak | C has strict type checking |
| 13:18.28 | DocScrutinizer05 | BWAHAHAHA |
| 13:18.42 | viric | Yes, I like the C strict type checking |
| 13:18.52 | lekernel | C? perfection? lol. |
| 13:18.59 | viric | typedef is not defining a new type, though. |
| 13:19.00 | wpwrak | some of it in the form of warnings, but you get your diagnostic when you need it |
| 13:19.04 | kristianpaul | viric: and u already go it as object form? |
| 13:19.11 | DocScrutinizer05 | bool foo() {...; return 345} |
| 13:19.12 | viric | kristianpaul: sure. a java applet. |
| 13:19.17 | viric | kristianpaul: I even run it. But it fails for me :) |
| 13:19.19 | kristianpaul | hmm |
| 13:19.42 | DocScrutinizer05 | we had that less than one week ago, in some popular shite I can't recall |
| 13:19.52 | lekernel | especially for e.g. string manipulations, which keeps infosec people fed |
| 13:20.23 | wpwrak | lekernel: my most illuminating experience with C was when i wrote a language that incorporated much of C (for a scriptable debugger). there, i learned to appreciate many of the more subtle points of that language |
| 13:20.24 | viric | talking of string manipulations, I recently discovered stpcpy |
| 13:20.46 | DocScrutinizer05 | now I recall: it was that funny vulnerability of MySQL |
| 13:20.47 | kristianpaul | i fed with binary related operations, usually perl is more ready in such cases |
| 13:20.52 | lekernel | there's also strfry() |
| 13:21.14 | DocScrutinizer05 | that made every one out of 256 auth tries succeed no matter which credentials |
| 13:22.25 | DocScrutinizer05 | and you tell me there's something like strict typechecks in C |
| 13:22.48 | lekernel | the C library is sucky as well. how do you move/rename a folder? system("mv ...") |
| 13:23.20 | kristianpaul | is not that more a posix problem (folder) ? |
| 13:23.49 | lekernel | and of course what you give to system() has to come from the aforementioned string manipulation mess |
| 13:23.49 | kyak | how does 'mv' move the folder? |
| 13:23.51 | wpwrak | lekernel: rename() will do just fine for renaming |
| 13:24.30 | lekernel | wpwrak: no, if you cross mount points it doesn't work. |
| 13:24.42 | wpwrak | lekernel: that's not a rename :) |
| 13:25.30 | wpwrak | DocScrutinizer: booleans are a perversion you quiche-eaters added. you deserve the consequences :) |
| 13:26.34 | viric | lekernel: well, some OS have different operations for move and rename |
| 13:26.40 | viric | for example. |
| 13:26.50 | DocScrutinizer05 | well, a particularly nice type we quiche-eaters added are sets, which are defined as bit fields internally |
| 13:27.02 | DocScrutinizer05 | basically a uint1 |
| 13:27.25 | viric | rename() renames a file, moving it between directories if required. |
| 13:27.27 | viric | I didn't know it. |
| 13:27.36 | viric | C89. |
| 13:28.26 | lekernel | oh and there's also memcpy vs. memmove |
| 13:28.44 | viric | of course |
| 13:29.10 | viric | that allow operations of different performance |
| 13:29.48 | lekernel | now if you think that sort of thing doesn't waste developer time, look at this: https://bugzilla.redhat.com/show_bug.cgi?id=638477 |
| 13:30.07 | DocScrutinizer05 | well, lemme guess. memmove remapping if possible? |
| 13:30.22 | lekernel | viric: wrong. the test for the direction of copy at the beginning of memmove() is unnoticeable. |
| 13:30.45 | viric | ah you mean it could check if it overlaps or not? |
| 13:31.13 | DocScrutinizer05 | it could simply tweak the mmu table |
| 13:31.44 | lekernel | DocScrutinizer05: no it's much simpler than that. copying memory. only if you use memcpy() you must make sure your two regions don't overlap. |
| 13:31.44 | viric | hm I think you miss what's memmove about :) |
| 13:31.50 | DocScrutinizer05 | which e.g. NeXTStep did per definitionem for inter-process messages |
| 13:32.14 | larsc | language flamewars, always so much fun |
| 13:32.15 | lekernel | as if, your brain was available to pollute it with such details |
| 13:32.29 | kristianpaul | larsc: :) |
| 13:32.38 | wolfspraul | larsc: hey sorry. what was your comment about 'ast generator' about the other day? |
| 13:32.44 | viric | Let's see if C11 addresses any of that ;) |
| 13:32.45 | wolfspraul | I didn't get it |
| 13:32.59 | wolfspraul | (that was in #milkymist, about migen) |
| 13:33.49 | wolfspraul | my question comes down to "what is the difference between an 'ast generator' and a 'proper language'?" |
| 13:35.24 | DocScrutinizer05 | lekernel: well, seems a straightforward pretty natural approach. I know if my two pointers point to unrelated objects or if I just want to shift a mem-area by a few bytes "in place" |
| 13:35.52 | viric | DocScrutinizer05: but that could be checked |
| 13:36.01 | DocScrutinizer05 | what for? |
| 13:36.26 | DocScrutinizer05 | AIUI it *gets* checked, in memmove |
| 13:37.07 | viric | only have one function: memcpy |
| 13:37.13 | DocScrutinizer05 | I mean, it's not a mandatory prerequisite that mem overlaps to use memmove on it |
| 13:37.17 | viric | if the regions overlap, run memmove. If not, run memcpy. |
| 13:37.21 | larsc | wolfspraul: well with a ast generator you basically write in another language, a metalanguage if you want to say so. which can be very powerful. |
| 13:38.01 | *** join/#qi-hardware Ayla (~paul@ACaen-252-1-213-138.w86-215.abo.wanadoo.fr) |
| 13:38.13 | viric | I meant the opposite. if overlap, memcpy. If not, memmove. |
| 13:38.18 | DocScrutinizer05 | if you however know your areas never can overlap (a very usual case), why use a function with a useless check? |
| 13:38.20 | viric | because memmove can be implemented faster. |
| 13:38.51 | viric | amh |
| 13:38.52 | viric | no |
| 13:38.53 | viric | the opposite. |
| 13:38.55 | viric | ;) |
| 13:39.07 | lekernel | viric: really you can gain 10 nanoseconds or so on a modern machine. is it really worth all the wasted hours on that bugzilla report? no. |
| 13:39.49 | viric | lekernel: I agree I agree |
| 13:41.08 | lekernel | DocScrutinizer05: because developers make mistakes. |
| 13:41.50 | DocScrutinizer05 | lekernel: 10ns??? >> The memory areas may overlap: copying takes place as though the bytes in src are first copied into a temporary array that does not overlap src or dest, and the bytes are then copied from the temporary array to dest. |
| 13:42.24 | DocScrutinizer05 | seems to include a malloc |
| 13:42.45 | lekernel | yes, 10ns. in all implementations I've seen it's only about the direction of copy. |
| 13:42.47 | lekernel | no, there's no malloc |
| 13:43.03 | DocScrutinizer05 | I'd expect a tinmy bit longer than 10ns for this to complete |
| 13:43.05 | lekernel | just a test at the beginning to determine the copy direction |
| 13:44.12 | DocScrutinizer05 | now if that's true then this manpage is pretty buggy and fuckedup |
| 13:44.31 | lekernel | the subtlety is in the "as though" ... |
| 13:44.35 | DocScrutinizer05 | as the result of the operation may differ vastly in certain situations |
| 13:44.55 | DocScrutinizer05 | e.g. memove IO memmapped area |
| 13:45.45 | DocScrutinizer05 | there a complete mem mapping swap for each switch between read and write a byte or word could take pretty looooong |
| 13:45.58 | lekernel | I don't think you're supposed to use the regular libc memmove on weird memory-mapped I/O... it doesn't even guarantee the size/alignment of accesses |
| 13:46.12 | DocScrutinizer05 | hehe, true |
| 13:46.26 | DocScrutinizer05 | but manpages are supposed to be accurate |
| 13:47.35 | wolfspraul | larsc (in absence) ok, thanks. I still don't get it :-) |
| 13:47.38 | wolfspraul | but that's ok |
| 13:48.24 | wolfspraul | "language" for me is a set of rules, grammar, syntax, vocabulary/keywords, etc. |
| 13:48.41 | wolfspraul | it's used to express something, that someone (or some program) can understand, or interpret in some way |
| 13:48.50 | lekernel | wolfspraul: if you write vhdl or verilog, you have a single language that expresses the logic more or less directly |
| 13:48.57 | wolfspraul | I'm just not familiar with the term 'ast generator' |
| 13:49.00 | DocScrutinizer05 | lekernel: btw the rationale of "because developers make mistakes" clearly suggests to abandon C all together and rather use a proper lang like pascal or modula, which comes with runtime checks for all those more commonly done mistakes, like array-index out of bounds, etc |
| 13:49.52 | kristianpaul | pascal? no again ;-) |
| 13:50.17 | lekernel | with the migen "ast generator", you are writing python (the "metalanguage") that manipulates fragments of verilog-style logic |
| 13:51.06 | wolfspraul | maybe I should look at migen more and then I would get it |
| 13:51.08 | lekernel | wolfspraul: does it make sense? |
| 13:51.25 | wolfspraul | no, doesn't |
| 13:51.28 | wolfspraul | but no problem, don't worry |
| 13:51.36 | wolfspraul | interstingly googling for 'ast generator' also yields very little |
| 13:53.09 | lekernel | DocScrutinizer05: ...and as you can see I'm writing python and moving milkymist software to lua those days :) |
| 13:55.00 | viric | wolfspraul: verilog or vhdl is lekernels' assembler, and let's say he's writing a compiler in python, for some his language to that assembler. |
| 13:55.26 | viric | or a python lib that emits that assembler (vhdl/verilog). something like this? |
| 13:55.37 | kristianpaul | assembler? |
| 13:55.41 | kristianpaul | thats the net list |
| 13:55.44 | viric | metaphoric |
| 13:55.51 | wolfspraul | :-) |
| 13:55.51 | viric | analogy to software |
| 13:55.56 | kristianpaul | hmm |
| 13:55.57 | wolfspraul | this is why I love 'ast generator' |
| 13:56.10 | wolfspraul | I think this is not a widely understood term at all, given how hard it is to even google for a definition |
| 13:56.21 | viric | So an ast generator is not cooking chicken? |
| 13:56.23 | DocScrutinizer05 | lekernel: btw differences between the supposed operation of memmove and the way it's probably done in real world also may arise easily in context of multitasking |
| 13:56.32 | wolfspraul | I did find a 82 page 2008 paper from a german university |
| 13:56.39 | wolfspraul | I don't need an 'ast generator' |
| 13:56.40 | wolfspraul | :-) |
| 13:57.16 | lekernel | DocScrutinizer05: totally. but the C language has the concept of a traditional single-core CPU built in (through pointers), so it's not appropriate here. |
| 13:57.19 | DocScrutinizer05 | when a concurrent process looks at first byte of dest to determine if origin is already free to rewrite it |
| 13:58.05 | DocScrutinizer05 | sure you usually solve those issues with mutex etc |
| 13:58.30 | DocScrutinizer05 | or define memmove section to be atomic |
| 14:00.46 | *** join/#qi-hardware Ayla (~paul@ACaen-252-1-213-138.w86-215.abo.wanadoo.fr) |
| 14:03.36 | DocScrutinizer05 | ~wiki ast generator |
| 14:03.47 | DocScrutinizer05 | thought as much |
| 14:05.47 | DocScrutinizer05 | http://en.wikipedia.org/wiki/Abstract_syntax_tree ?? |
| 14:08.23 | DocScrutinizer05 | or http://en.wikipedia.org/wiki/Andrew_S._Tanenbaum ? ;-P |
| 14:10.55 | lekernel | 1st one ;) |
| 14:12.39 | DocScrutinizer05 | if it's about Abstract Syntax Tree then I wonder why anybody would need a generator for that, since my approach always been I think of code in AST in my head, and then convert it to any arbitrary lang and syntax. That's what I always called "I don't mind which languge to use - I can program" - until somebody pointed me to http://c-faq.com/decl/recurfuncp.html :-S |
| 14:13.52 | DocScrutinizer05 | .s/I can program/ I know to design programs/ |
| 14:14.30 | kristianpaul | ast generator is an excuse in the absence of floss synthesizers that could allow those language extensions for our topic i think |
| 14:17.47 | viric | mh I think it'd need a book covering state machines clear design and implementation (for software, in C for example). |
| 14:18.27 | kristianpaul | C conding style? :-) |
| 14:18.29 | viric | because it's one of those things I start with a big function and some 'if/else' clauses.. then a switch... and soon some mess with out of band information... |
| 14:18.53 | viric | C and C++ approaches to state machines would be nice |
| 14:19.29 | viric | well, you can imagine that every program is some state machine, but with the state spread in multiple variables :) |
| 14:31.22 | DocScrutinizer05 | btw http://c-faq.com/ptrs/funccall.html kinda reassured me I understand a tiny bit of C at least |
| 14:31.37 | whitequark | on ASTs |
| 14:32.11 | viric | As for function pointers... I like to declare function types, and instead of pointers to functions. |
| 14:32.22 | viric | typedef int fptr(char x); |
| 14:32.24 | viric | then I use: |
| 14:32.32 | *** join/#qi-hardware larsc (~lars@eisbaer.ursus-maritimus.org) |
| 14:32.41 | viric | fptr *x = myfunction; x('z'); |
| 14:33.05 | whitequark | even in this context, I assume, AST is not some free-form structure resembling a free-form algorithm. If you have verilog, you can resemble it with AST form, which allows you to manipulate the code very conveniently (compared to e.g. string functions or regexen) |
| 14:33.17 | whitequark | basically AST is an incredibly simple storage structure |
| 14:33.17 | DocScrutinizer05 | viric: that's sth I feel familiar with |
| 14:33.24 | whitequark | nested s-exps resemble an AST |
| 14:33.41 | viric | I hate the "typedef int (*fptr)(char x)" kind of parenthesis. :) |
| 14:33.57 | viric | but these later looks much more spread. |
| 14:33.59 | whitequark | C is not a programming language |
| 14:34.00 | lekernel | DocScrutinizer05: I disagree with many things that Paul Graham writes, but I think there are some good ideas in this one http://www.paulgraham.com/hundred.html |
| 14:34.10 | whitequark | it's a PDP-11 assembler which thinks it's a compiler |
| 14:34.56 | viric | Using function typedefs, instead of pointers-to-function, allows using the typedef for the prototypes. |
| 14:35.27 | viric | Therefore throwing a bad declaration. |
| 14:35.36 | viric | in case of bad types. |
| 14:36.23 | viric | as here: http://sprunge.us/LNaW |
| 14:37.58 | viric | the line 3 can't be typed if the typedef were of function pointer. |
| 14:38.45 | viric | maybe there is a good reason why most people use typedef of function pointers, but I don't know it still. |
| 14:42.08 | larsc | wolfspraul: for a language you have grammar, syntax, etc and a parser which will take care of generating a AST from code written in that language. In migen you don't have that, but rather construct the AST by hand |
| 14:45.36 | lekernel | well, you'll have it later for special cases. but keeping the low-level stuff accessible is good - we need it for many things... |
| 14:51.07 | kristianpaul | but migen intentions is not been a language is it? i understand as the result of frustating of generating SoC by hand, now implmented in a "friendly" scripting language no? |
| 14:52.18 | kristianpaul | s/frustating/frustation |
| 14:52.18 | qi-bot | kristianpaul meant: "but migen intentions is not been a language is it? i understand as the result of frustation of generating SoC by hand, now implmented in a "friendly" scripting language no?" |
| 14:52.58 | lekernel | migen is a "toolbox" for generating large synchronous systems. anything that makes SoC design great can go into it. |
| 14:53.56 | kristianpaul | oh, so is not milkymist centric at all |
| 14:54.17 | lekernel | no. the milkymist specific stuff is in the milkymist-ng repository. |
| 14:54.56 | kristianpaul | hmm |
| 14:56.13 | lekernel | here's another project using migen: https://github.com/brandonhamilton/rhino-tools |
| 14:59.09 | kristianpaul | oh, migen include dsp ASTs as well? |
| 15:00.18 | DocScrutinizer05 | lekernel: well, I agree partially on http://www.paulgraham.com/hundred.html POV |
| 15:00.26 | lekernel | if your question is whether migen flow can be used for DSP, then yes |
| 15:00.34 | DocScrutinizer05 | that's why I dislike C |
| 15:00.57 | lekernel | the "AST" (FHDL) is just like verilog... and can do pretty much everything verilog does, as long as you have a single clock |
| 15:01.23 | DocScrutinizer05 | C is all about premature optimization and concept tainted by hw-related axioms/paradigms |
| 15:01.45 | lekernel | DocScrutinizer05: and therefore you do assembler instead? ;) |
| 15:02.46 | DocScrutinizer05 | actually assembler is more honest in that regard |
| 15:03.17 | kristianpaul | DocScrutinizer05: you code in forth as well? |
| 15:03.25 | DocScrutinizer05 | I used to |
| 15:03.37 | DocScrutinizer05 | in the early 80s |
| 15:04.36 | DocScrutinizer05 | pretty nice lang, after a week to get accustomed to it |
| 15:06.17 | viric | 'rhino'... I had some bad time with java rhino. |
| 15:06.42 | DocScrutinizer05 | we used to program a Z80 based realime video manipulation hardware in a lang 99% overlapping with forth |
| 15:07.54 | DocScrutinizer05 | the whole forth code had to get interpreted 25 times per second, on a fixed pace (today you call that realtime) |
| 15:09.09 | DocScrutinizer05 | basically the "mainloop" had the central wait on VSYNC |
| 15:13.36 | DocScrutinizer05 | lekernel: regarding this proposition in Graham about wasting cycles for simplicity - I had a similar discussion just some 12h ago: http://mg.pov.lt/maemo-irclog/%23maemo.2012-06-17.log.html#t2012-06-17T03:03:22 http://mg.pov.lt/maemo-irclog/%23maemo.2012-06-17.log.html#t2012-06-17T03:16:31 http://mg.pov.lt/maemo-irclog/%23maemo.2012-06-17.log.html#t2012-06-17T03:24:02 |
| 15:38.04 | whitequark | a fellow hacker, who reverse engineers SGS2 RIL (modem driver), just found a backdoor |
| 15:38.31 | whitequark | if a specially-crafted incoming CSD call arrives, it passes a root shell to it |
| 15:38.39 | whitequark | why am I not surprised |
| 15:50.20 | lindi- | whitequark: that's inside the BP? |
| 15:51.58 | viric | SGS = samsung galaxy something? |
| 15:52.35 | whitequark | viric: yes |
| 15:52.39 | whitequark | lindi-: no |
| 15:53.06 | viric | and what is CSD? |
| 15:53.14 | lindi- | circuit switched data? |
| 15:53.21 | whitequark | RIL is a service which translates AT commands from dialer and stuff to the modem IPC (thankfully, it runs in its own small compartment and cannot e.g. influence RAM of the AP) |
| 15:53.21 | lindi- | whitequark: is that part of some android phones? |
| 15:53.28 | whitequark | yeah, CSD is circuit switched data |
| 15:53.43 | whitequark | RIL is generally a part of any Android phone, but different vendors provide different RILs |
| 15:53.46 | whitequark | there is a reference, FOSS one |
| 15:53.56 | whitequark | and Samsung ships this one with a backdoor in their phones |
| 15:54.10 | viric | quite an improvement over the foss. |
| 15:54.20 | whitequark | well, that's why we are writing a FOSS RIL |
| 15:54.26 | lindi- | whitequark: interesting, do you need operator help to initiate such a CSD call? |
| 15:54.47 | whitequark | lindi-: in Russia, I need to sign a contract (_very_ expensive) to be able to receive CSD calls at all |
| 15:55.03 | whitequark | obviously the operator can still initiate it at their will |
| 15:55.13 | viric | what's a csd call about? |
| 15:55.13 | whitequark | but no, other users can't do that |
| 15:55.14 | lindi- | whitequark: yeah but could I initiate such a call? |
| 15:55.18 | whitequark | viric: dialup through gsm |
| 15:55.28 | whitequark | lindi-: no, not while I'm in Russia with my current operator |
| 15:55.39 | whitequark | but I'm pretty sure it is perfectly possible in other countries/operators |
| 15:55.44 | lindi- | whitequark: yeah but I'm not in Russia |
| 15:56.01 | whitequark | lindi-: doesn't matter, incoming CSD calls are barred by my operator |
| 15:56.11 | viric | what's different between dialup through gsm, and usual voice calls? |
| 15:56.32 | whitequark | viric: just like the difference between voice and data over plain old telephony |
| 15:56.56 | whitequark | voice call is voice, and CSD is an analog modem |
| 15:57.04 | whitequark | well, it's not exactly this way, but pretty close |
| 15:57.05 | viric | an analog modem over gsm? |
| 15:57.09 | whitequark | kinda |
| 15:57.23 | viric | it's about making something analog work over something digital? |
| 15:57.34 | viric | who may want to use that? |
| 15:57.35 | whitequark | I'm not very familiar with this technology, it was already dead when I got my first cellphone |
| 15:57.38 | whitequark | well |
| 15:57.44 | whitequark | you didn't have EDGE and GPRS back then |
| 15:57.48 | whitequark | and you got to use CSD |
| 15:58.00 | DocScrutinizer05 | whitequark: (backdoor) DUH! |
| 15:58.02 | viric | ah is that about the 9600 bps internet connection? |
| 15:58.12 | whitequark | viric: 9600 is fast. |
| 15:58.27 | whitequark | DocScrutinizer05: it's not counting all other ways you could get control |
| 15:58.31 | viric | before gprs, I had 9600baud in my mobile phone, with a WAP browser |
| 15:58.44 | whitequark | DocScrutinizer05: e.g. it sprintf()s a filename into a string and then system()s |
| 15:58.46 | roh | viric: thats csd. |
| 15:58.53 | viric | Ah ok |
| 15:59.12 | viric | I remember its cost was calculated per minutes, not per amount of data transferred :) |
| 15:59.19 | roh | csd is the '9k6 data' service in 2g (gsm) |
| 15:59.19 | whitequark | viric: yeah, bloody expensive |
| 15:59.24 | roh | everything else came later. |
| 15:59.33 | viric | ah, perfect. |
| 16:00.07 | viric | hm that's why gprs mobile phones say allow to choose: "a) Only use GPRS b) fallback to GSM in case of lack of GPRS" |
| 16:00.09 | roh | everything else has much higher latency also. csd is/was much better than mobile ip now. |
| 16:00.44 | viric | I used it very rarely. |
| 16:01.00 | whitequark | DocScrutinizer05: (the system() is from Android side and not modem), but it's as solid as swiss cheese |
| 16:01.19 | whitequark | SGS2 is a funny machine, it does almost nothing to prevent your tinkering with it |
| 16:01.31 | whitequark | blobs are not obfuscated nor even optimized |
| 16:01.46 | whitequark | i.e. a simple IDA run gives away all the details |
| 16:01.50 | whitequark | they didn't even strip them. |
| 16:02.01 | DocScrutinizer05 | viric: it's a service tag on the data connection via GSM. There are tags for voice, data, fax |
| 16:02.07 | DocScrutinizer05 | just like on ISDN |
| 16:02.09 | whitequark | i.e. you have all symbols AND DEBUG INFO. |
| 16:02.13 | viric | ok |
| 16:02.36 | whitequark | as I already said, modem bootloader allows you to read/write RAM and execute arbitrary code on the BP |
| 16:02.37 | viric | whitequark: isn't it tricky about the linking, addresses, ...? |
| 16:02.51 | roh | whitequark: why do you wonder? |
| 16:03.04 | whitequark | roh: about what? |
| 16:03.11 | roh | about debug symbols etc. |
| 16:03.15 | whitequark | viric: nope, RIL is just a linux .so |
| 16:03.24 | roh | most devices i get have adb running, some even on the ip interfaces. |
| 16:03.38 | whitequark | roh: because I want a FOSS RIL, and also I want to know what this backdoor could do with my phone |
| 16:03.39 | viric | ah, with sections and all that. |
| 16:03.53 | roh | whitequark: thats only ONE backdoor possibility. |
| 16:04.05 | viric | roh: what's adb? |
| 16:04.09 | whitequark | roh: I dunno what the stock firmware has, nor do I care. I run cyanogenmod on it and it doesn't have obvious stupid holes |
| 16:04.11 | roh | i do not trust the baseband fw (thats what your ril connects to) or anything else on such systems |
| 16:04.18 | whitequark | roh: I neither |
| 16:04.30 | DocScrutinizer05 | whitequark: which modem does SGS2 have? |
| 16:04.37 | whitequark | DocScrutinizer05: xgold626 |
| 16:04.39 | roh | viric: android debug bridge. the 'debugger helper tool' |
| 16:05.08 | viric | щл |
| 16:05.10 | viric | ok |
| 16:05.10 | whitequark | roh: but baseband is isolated in this machine. it doesn't control any hardware at all |
| 16:05.13 | DocScrutinizer05 | whitequark: ooh, so it's not one of 'ours' |
| 16:05.13 | roh | so writing an opensource ril for droid is like putting one bucket of clean water in a pool full of mud. senseless. |
| 16:05.28 | roh | whitequark: bullshit. sorry. most basebands have full system access. |
| 16:05.37 | whitequark | roh: I have level 3 service manual with schematics |
| 16:05.38 | roh | including memory. |
| 16:06.08 | roh | beside the possibility to use backdoors or bugs on the app-cpu. most basebands are |
| 16:06.24 | roh | 'trusted more' than the app-cpu |
| 16:06.42 | whitequark | roh: and it only has IPC over USB for that matter. no sound routing (done by AP), no shared memory |
| 16:06.51 | *** join/#qi-hardware antgreen (~user@70.50.66.16) |
| 16:07.06 | whitequark | roh: power management is done by a separate PMIC connected to AP |
| 16:07.29 | roh | whitequark: doesnt make it better. do you think these 'ipc drivers' have any sane protections against harmful data streams? |
| 16:07.30 | whitequark | baseband power is managed by AP, through I don't know exactly to what degree, this needs further investigation. |
| 16:07.50 | DocScrutinizer05 | roh: BS, e.g. next STE modem on SG has HSI interface and doesn't control *anything* on AP |
| 16:08.00 | lindi- | whitequark: anyways, would be really good to have some public report about this |
| 16:08.04 | whitequark | roh: kernel is open-source and can (and will) be fixed, that's already ongoing. |
| 16:08.21 | roh | whitequark: most of that stuff is of the lowest possible code quality. its 'write once'-code. to be thrown away and not be reused. |
| 16:08.41 | whitequark | roh: yeah, I know and it is |
| 16:09.32 | whitequark | I'm just saying that this phone has the sanest design I've seen, ever |
| 16:09.36 | DocScrutinizer05 | http://lxr.free-electrons.com/source/net/caif/ |
| 16:09.52 | roh | DocScrutinizer05: depends on the hardware platform of course. but i havent found a single device which has a sane concept to hinder a hostile baseband from rooting the app cpu |
| 16:10.25 | whitequark | roh: apart from exploiting the (possibly buggy) USB driver, how would you do that? |
| 16:10.28 | roh | using serials instead of shared memory windows is helping for sure. just sucks when you need more than a few bytes a second |
| 16:10.46 | roh | whitequark: most devices dont use usb. usb sucks. |
| 16:10.57 | DocScrutinizer05 | HSI |
| 16:11.01 | whitequark | roh: I don't give a fuck about most devices. |
| 16:11.01 | DocScrutinizer05 | or ULPI |
| 16:11.02 | roh | usb is high-latency and wastes power. totally stupid choice |
| 16:11.19 | whitequark | DocScrutinizer05: do the words "Comneon HSIC" tell anything to you? |
| 16:11.19 | roh | DocScrutinizer05: what should that be? |
| 16:12.03 | DocScrutinizer05 | http://lxr.free-electrons.com/source/drivers/net/caif/caif_hsi.c |
| 16:12.22 | roh | DocScrutinizer05: you want me puke, right? |
| 16:12.24 | DocScrutinizer05 | whitequark: nope |
| 16:12.40 | roh | DocScrutinizer05: i will never use a device with that code on it. caif is a reason to not buy a device. |
| 16:12.49 | DocScrutinizer05 | mhm |
| 16:13.13 | DocScrutinizer05 | :shrug: |
| 16:13.32 | whitequark | DocScrutinizer05: do you know reasons of such a change of the tightly coupled baseband design? |
| 16:13.46 | whitequark | it seems surprisingly sane for phone vendors |
| 16:13.54 | whitequark | phone/bb |
| 16:13.56 | DocScrutinizer05 | what change? |
| 16:14.00 | whitequark | from shm to serial |
| 16:14.14 | roh | ulpi is just another word for 'usb' |
| 16:14.16 | DocScrutinizer05 | shm has some issues |
| 16:14.29 | *** join/#qi-hardware kyak (~kyak@95-28-74-169.broadband.corbina.ru) |
| 16:14.30 | *** join/#qi-hardware kyak (~kyak@unaffiliated/kyak) |
| 16:14.32 | DocScrutinizer05 | thanks for explaining to me, roh |
| 16:14.33 | roh | and hsi seemingly for 'make spi complicated' |
| 16:14.34 | DocScrutinizer05 | ;-P |
| 16:14.45 | roh | DocScrutinizer05: ;) |
| 16:15.15 | whitequark | roh: so, what phone would you use? a dumbphone? |
| 16:15.21 | whitequark | and if you need more features than that? |
| 16:15.32 | roh | heh. caif runs over shm and hsi, so its another layer over a layer... sigh |
| 16:15.43 | DocScrutinizer05 | dafaq |
| 16:15.53 | DocScrutinizer05 | it can run via arbitrary interfaces |
| 16:16.02 | DocScrutinizer05 | even via rs232 |
| 16:16.05 | roh | whitequark: i dont use a smartphone. phones which cannot run without recharching for atleast a week arent anything which i can work with. |
| 16:16.06 | DocScrutinizer05 | and USB |
| 16:16.18 | viric | roh: same here. :) |
| 16:16.23 | roh | DocScrutinizer05: i just checked the code, didnt see any documentation. |
| 16:18.58 | DocScrutinizer05 | http://lxr.free-electrons.com/source/net/caif/caif_usb.c http://lxr.free-electrons.com/source/drivers/net/caif/caif_serial.c |
| 16:19.00 | roh | DocScrutinizer05: but its funny how they reinvent the wheel. in the end they all do 'serial over $foo' .. why not use serials and hdlc or similar stuff which we have since the 80s? |
| 16:19.12 | DocScrutinizer05 | there's also a (rather outdated) readme |
| 16:19.24 | whitequark | http://imgur.com/uYr9d |
| 16:19.30 | whitequark | feels himself like a pick&place machine |
| 16:19.41 | DocScrutinizer05 | roh: why doesn't phonet do this? |
| 16:20.09 | DocScrutinizer05 | why doesn't GSM muxer 07.?? do it? |
| 16:20.43 | DocScrutinizer05 | CAIF is just a mux over arbitrary interfaces |
| 16:21.05 | roh | DocScrutinizer05: i dont know what phonet is? |
| 16:21.10 | DocScrutinizer05 | and it's what RIL talks to |
| 16:21.22 | roh | caif is proprietary erricson stuff |
| 16:21.32 | DocScrutinizer05 | when the modem is offering CAIF and not phonet |
| 16:21.36 | whitequark | DocScrutinizer05: is it patented? |
| 16:22.08 | roh | anyhow. i dont want to discuss choices in |
| 16:22.26 | DocScrutinizer05 | roh: you already stated you never will touch any hardware with CAIF code on it -why do you bother about docs or proprietary? |
| 16:22.59 | roh | droid or so.. since we all know that none of these protocols are made due to technical thoughts, but rather by ip and businessplan logic. |
| 16:23.02 | DocScrutinizer05 | honestly, I don't care what you think about CAIF |
| 16:23.42 | roh | sorry, but READ that code. i would bet on it that its exploitable a lot. |
| 16:24.03 | roh | its HUGE. 1300 lines for encapsuling serials in serials. wtf. |
| 16:24.56 | DocScrutinizer05 | so what? go write better code! |
| 16:25.17 | DocScrutinizer05 | it's FOSS, no? |
| 16:25.23 | whitequark | 1300 lines isn't huge for C and this stuff. just saying. |
| 16:26.34 | DocScrutinizer05 | anyway it's what STE LTE modem will talk over HSI to AP |
| 16:26.52 | DocScrutinizer05 | of next Samsung device |
| 16:27.12 | whitequark | DocScrutinizer05: oh, now that's interesting |
| 16:27.39 | DocScrutinizer05 | and since it's FOSS you're free to implement any better code for CAIF to your liking |
| 16:27.48 | roh | DocScrutinizer05: well.. i will wait for them to build useable devices again. the current market is quite dead and boring (all the same concept and laughable battery runtime) |
| 16:27.57 | DocScrutinizer05 | and stack your own RIL on top of it |
| 16:28.07 | roh | nobody needs ril. |
| 16:28.15 | DocScrutinizer05 | MEH |
| 16:28.37 | DocScrutinizer05 | nobody need this discussion |
| 16:28.48 | roh | no shit ;) |
| 16:30.22 | roh | but atleast we now know that its not 'the baseband has not control' on all hardwar but just some and the state of sw isnt 'nice' .. so no. currently there is no real protection whatsoever against hostile baseband code (and that basebands can be exploited remotely was shown on multiple security events) |
| 16:31.43 | whitequark | roh: well, the only thing I don't understand is why when I say that I can do better, you reply that it's useless |
| 16:32.14 | roh | whitequark: ril is something android specific. if you want to do better: do not use android. |
| 16:32.31 | whitequark | roh: what can I use _now_? |
| 16:32.41 | whitequark | meego? or how is that vaporware called now? |
| 16:33.02 | roh | lots of stuff. but yes. most proper devices are not build anymore or never in series. |
| 16:33.57 | whitequark | I want a phone that I can use and can have control of (not tivoized, FOSS system). android is the nearest to that goal. |
| 16:34.02 | whitequark | I don't see any system better |
| 16:34.48 | whitequark | ofcourse there's a baseline requirement that it should be an usable smartphone. i.e. a FR isn't an usable smartphone due to numerous issues. |
| 16:34.59 | roh | whitequark: i liked the N950, but then nokia decided to kill themselves and not sell it. |
| 16:35.28 | whitequark | I have nothing against N9* |
| 16:35.29 | roh | whitequark: and simply said: there is no useable smartphone at the moment. |
| 16:35.55 | lindi- | roh: if you require one week standby times then that rules out everything indeed |
| 16:36.06 | whitequark | well, you can give up if you want. I'll just fix what I can get. |
| 16:36.12 | viric | I also want one week standby. |
| 16:36.30 | roh | lindi-: well.. thats my own measurement ladder. but most do not even survive the day atm. which is really sad |
| 16:36.38 | lindi- | I just use external batteries if I need longer standby time during some trip or something |
| 16:36.56 | viric | that sounds like a mobile phone in the 90s. |
| 16:44.30 | DocScrutinizer05 | whitequark: according to roh's "rationale" every device is unsafe, vulnerable and crap |
| 16:44.36 | DocScrutinizer05 | even FR |
| 16:45.19 | roh | DocScrutinizer05: sorry, but yes. (but thats not because of my rationale, but simply because we were not allowed to fix bugs properly) |
| 16:45.26 | DocScrutinizer05 | and to like N950 is outright insane, since THIS crap has really nasty HS stuff on OMAP |
| 16:45.39 | roh | fr actually has a good runtime compared to some other 'smartphones' |
| 16:46.16 | roh | DocScrutinizer05: i liked it because it was the first device i had in my fingers which did not lagg like hell in normal scrolling |
| 16:46.20 | DocScrutinizer05 | pff, it also has vulnerable code in drivers for hw IF |
| 16:46.45 | roh | yes. like all the rest too. get used to that. |
| 16:46.50 | DocScrutinizer05 | roh: for some reason I don't enjoy to discuss with you today |
| 16:46.55 | DocScrutinizer05 | might be me |
| 16:47.12 | whitequark | so much hate |
| 16:47.21 | roh | DocScrutinizer05: sorry. i know the state of mobile phones is depressing ;) |
| 16:47.34 | DocScrutinizer05 | bwahaha |
| 16:48.30 | DocScrutinizer05 | only depressing thing for me right now is the inconsisten reasoning you offer here |
| 16:50.12 | DocScrutinizer05 | the next depressing thing for me is I have to run tests against CAIF in work, thus need to touch android (a thing I dispise) |
| 16:51.38 | whitequark | sigh |
| 16:52.10 | viric | I also like mobile phones that can turn off and on quickly |
| 16:52.59 | whitequark | viric: for what? |
| 16:53.04 | DocScrutinizer05 | viric: there's that iPhone sleeve with featurephone intergrated - maybe the thing for you? ;-) |
| 16:53.44 | viric | well, turn on and off the radio at least |
| 16:53.48 | viric | gsm. |
| 16:53.51 | viric | all that. |
| 16:54.08 | whitequark | viric: android turns radio on/off in a ~second |
| 16:54.10 | whitequark | erm |
| 16:54.12 | viric | I feel better with the phone turned off, too. :) but when I want it, i dislike waiting minutes |
| 16:54.14 | whitequark | android on SGS2. |
| 16:55.25 | viric | ok |
| 16:56.04 | DocScrutinizer05 | viric: modems take a few seconds to turn on. If you want your full inflated linuxoid OS to boot up on AP in same timespan, you got another problem not related at all to phones |
| 16:56.29 | viric | now I don't need any linuxoid os. |
| 16:56.50 | DocScrutinizer05 | what are we discussing then? |
| 16:56.55 | whitequark | ... and you get even more infested dumbphone which is one big BP. |
| 16:57.20 | viric | Yes I also dislike that. |
| 16:57.39 | viric | switched off phone is the happiest :) |
| 16:57.49 | whitequark | are you sure it is actually switched off? |
| 16:57.54 | whitequark | I'm not |
| 16:57.55 | DocScrutinizer05 | define phone! |
| 16:58.23 | DocScrutinizer05 | even: define "switched off"! |
| 16:58.27 | viric | :) |
| 16:58.32 | viric | I can easily take out the battery |
| 16:58.45 | whitequark | oh, you're one of that kind of people |
| 16:58.48 | viric | even the rtc battery is out... I've to reset the time |
| 16:58.49 | DocScrutinizer05 | and you can also take a sledgehammer |
| 16:59.12 | DocScrutinizer05 | honestly, I wonder what we're discussing here |
| 16:59.15 | viric | nah, I barely switch off the phone because I'd have to wait the boot time |
| 17:00.09 | viric | let's stop the discussion :) |
| 17:14.32 | *** join/#qi-hardware ChanServ (ChanServ@services.) |
| 17:14.32 | *** mode/#qi-hardware [+o ChanServ] by kornbluth.freenode.net |
| 17:44.59 | lekernel | roh: what is all your software compiled with, again? :) |
| 17:45.51 | *** join/#qi-hardware xwalk_ (~crosswalk@user-12l3484.cable.mindspring.com) |
| 17:53.25 | *** join/#qi-hardware kristoffer (~kristoffe@c-6ddae555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 18:36.53 | *** join/#qi-hardware jekhor (~jek@46.53.195.29) |
| 19:48.40 | lekernel | some M1 pictures http://www.falsebit.com/bit-stream/bit-stream-articles/114-blip-festival-2012-up-now-burnkit2600-m-no-carrier.html |
| 20:15.32 | lekernel | and videos http://www.youtube.com/playlist?list=PL181AAD8063FCC9DC |
| 20:17.00 | *** join/#qi-hardware Textmode (~boneidle@adsl-syd-1-124.ozonline.com.au) |
| 20:45.06 | *** join/#qi-hardware Textmode (~boneidle@adsl-syd-1-124.ozonline.com.au) |
| 21:00.42 | wpwrak | the absence of current limiting on the 8:10 card slot of the ben can be quite annoying ... |
| 21:16.24 | whitequark | wpwrak: what did you fry? |
| 21:31.41 | wpwrak | no, nothing broken. but if i use UBB to program a microcontroller circuit, the inrush current has a tendency of resetting the nanonote |
| 21:32.23 | wpwrak | and in this case, i can't leave the circuit powered, because the programming signals are shared |
| 21:33.22 | wpwrak | so it's power up, type "make prog", put the adapter in place, cut power, and then quickly hit Enter before the device discharges too much |
| 21:55.33 | whitequark | ahem. |
| 21:55.38 | whitequark | what about a current limiting resistor and a cap? |
| 21:59.10 | wpwrak | more like an inductor. a cap is already present in the ben. and yes, an inductor or such is what we should have there |
| 22:10.29 | *** join/#qi-hardware phirsch (~phirsch@xdsl-89-0-159-101.netcologne.de) |
| 22:37.15 | *** join/#qi-hardware compcube (~compcube@c-68-43-48-46.hsd1.mi.comcast.net) |
| 22:37.16 | *** join/#qi-hardware compcube (~compcube@pdpc/supporter/student/compcube) |
| 23:26.37 | whitequark | oh, yes, inductor indeed |
| 23:26.46 | whitequark | zzzzz |