| --- Day changed Wed Apr 10 2013 | ||
| @juiceme | How I'd do it, I would ditch using CAL alltogether. The way I see it it's not necessary to store the lock code in CAL anyway. I'd encrypt the whole /home partition and use the lock key to recover the passcode for encfs... | 00:00 |
|---|---|---|
| @juiceme | That way it would be fairly secure to off-line attacks, and the lockscreen would protect from on-line attacs. | 00:01 |
| coderus | Jonni: next try. /dev/crypto /dev/omap_sec ? | 00:02 |
| coderus | Jonni: i'm stuck at libbb5. I see devicelockd using it for ann CAL operations. Are you really changed only devicelockd, not libbb5? | 00:05 |
| -!- peterleinchen [~user@dsbg-4db59f3b.pool.mediaWays.net] has quit [Quit: [BX] Reserve your copy of BitchX-1.2c01-svn for the Nintendo Gameboy today!] | 00:27 | |
| rikanee | juiceme: you're forgetting the part where the NAND isn't actually locked in Open Mode | 01:24 |
| rikanee | the tools are just refusing to write ;) | 01:24 |
| -!- rikanee [~rika@unaffiliated/rikanee] has quit [Ping timeout: 245 seconds] | 01:43 | |
| -!- rikanee [~rika@unaffiliated/rikanee] has joined #ubiboot | 01:51 | |
| -!- rikanee [~rika@unaffiliated/rikanee] has quit [Ping timeout: 252 seconds] | 02:32 | |
| -!- rikanee [~rika@unaffiliated/rikanee] has joined #ubiboot | 02:33 | |
| -!- rikanee [~rika@unaffiliated/rikanee] has quit [Client Quit] | 02:34 | |
| -!- rikanee [~rika@unaffiliated/rikanee] has joined #ubiboot | 02:34 | |
| -!- TMavica [TMavica@1-36-77-246.static.netvigator.com] has joined #ubiboot | 04:42 | |
| TMavica | hi | 04:44 |
| TMavica | after 3 times loading harmattan, now can go in.. | 04:51 |
| TMavica | using 090413 | 04:52 |
| TMavica | https://dl.dropbox.com/u/37229054/output.txt | 04:55 |
| TMavica | https://dl.dropbox.com/u/37229054/ubiboot.log | 05:18 |
| TMavica | https://dl.dropbox.com/u/37229054/ubiboot.dmesg | 05:18 |
| @juiceme | morning | 07:28 |
| @juiceme | TMavica, thanks for the logs, I'll check them. | 07:30 |
| -!- rikanee [~rika@unaffiliated/rikanee] has quit [Quit: kthxbye] | 09:52 | |
| -!- rikanee [~rika@unaffiliated/rikanee] has joined #ubiboot | 10:43 | |
| @juiceme | rikanee, hi | 11:35 |
| rikanee | ohai, juiceme. | 11:36 |
| @juiceme | I was thinking about this "the tools are just refusing to write" | 11:36 |
| rikanee | juiceme: yeah, notice how usually a lock on the NAND would lock the entire NAND. | 11:36 |
| @juiceme | I think it's partly this but doesn't it require some magic to access the protected areas? | 11:36 |
| rikanee | juiceme: if you try to dd to and from CAL area, it doesn't stop you. | 11:37 |
| @juiceme | by magic I mean some write cycle using specific bytes | 11:37 |
| @juiceme | oh that really so? | 11:37 |
| rikanee | well, fwiw, there are lock bytes set on the region. | 11:37 |
| @juiceme | I was aware I can read everything but I did not now write is possible too... | 11:38 |
| rikanee | not really lock bytes, lock flags. | 11:38 |
| rikanee | once you start writing with the CAL library, it sees the flags and refuses write. | 11:38 |
| rikanee | I would definitely not advise manually writing ConF entries though. | 11:38 |
| @juiceme | that makes sense, because I wondered how would HW protection _really_ be arranged, since the mtd partition's boundaries are arbitrary anyway :) | 11:39 |
| @juiceme | but if that is the case, what would prevent creating tools that could access the needed locations directly? | 11:40 |
| rikanee | juiceme: the only problem is, CAL structure is unknown, and the middleware to screw with it isn't quite open. | 11:40 |
| @juiceme | as replacement for the Harmattan tools... | 11:40 |
| rikanee | (note: there's a flag in flash_erase to clear the LOCK flags, but that entails erasing the partition. Notice how when you reflash, the View-openmode image is rewritten into CAL, which is now "unlocked", without wiping it) | 11:41 |
| @juiceme | but it's well known fact that obfuscation is no replacement for encryptin, ever... | 11:41 |
| @juiceme | s/encryptin/encryption/ | 11:41 |
| @juiceme | from Jonni's openmode flashing method yesterday I kind of gathered that once the View-openmode image image is removed, subsequent flashing does not recreate it any more? | 11:43 |
| @juiceme | That the image is actually written to CAL only when the device boots the first time to Harmattan | 11:44 |
| Jonni | juiceme: flashing never creates it, it is always created only on 1st boot on secure mode | 11:44 |
| @juiceme | yes, that's how I understood it. | 11:44 |
| rikanee | still, that means that the area can be unlocked without totally wiping it. | 11:44 |
| Jonni | just pointing out that "recreate" word is wrong since flashing has never created it in the 1st place | 11:45 |
| @juiceme | so when flashing to closedmode and immediately flashing to openmode the filesystem preparation routines cannot any longer access CAL in write mode. | 11:45 |
| Jonni | and tools have no checking, there is no such thing as refusing to write | 11:46 |
| Jonni | if tools refuse to write, its because its locked | 11:46 |
| @juiceme | ok, how is the locking done, then, on HW level? | 11:46 |
| Jonni | juiceme: exactly | 11:46 |
| Jonni | bootloader locks the hw before xloader loads the kernel. | 11:47 |
| @juiceme | Because as I understand, the mtd partition's boundaries are defined by the string NOLO gives by kernel, I mean I could propably pass something totally different there as the partition table and that would be recognized as the layout? | 11:47 |
| rikanee | juiceme: that's not exactly… safe. | 11:48 |
| rikanee | although it is worth a try, if you relocate CAL to mtd4 area. | 11:48 |
| @juiceme | well, not safe but what I am after here, is the implementation details | 11:48 |
| Jonni | juiceme: its locked before kernel even loads, so even if you define custom boundaries, the hw is still locked | 11:48 |
| rikanee | Jonni: I think what he meant was that those blocks on the MTD aren't flagged as locked | 11:48 |
| Jonni | but yes, you could do trickery that cal is in mtd4 area, which is still unlocked. | 11:49 |
| @juiceme | so what is the granularity of locking, is it done in 4k blocks or something? | 11:49 |
| rikanee | well, assuming Harmattan respects those new boundaries, there's just one flaw - device isn't protected from flasher attacks. | 11:50 |
| @juiceme | ah, so it could me circumvented taht way? Then it's not HW property? | 11:50 |
| rikanee | juiceme: Harmattan and NOLO would be reading two different CAL areas | 11:50 |
| @juiceme | s/me/be/ s/taht/that/ | 11:50 |
| rikanee | Harmattan sees an unlocked CAL area, while NOLO sees its locked CAL area with no PIN required to flash. | 11:51 |
| @juiceme | yes, but if that works then it's not HW protected. | 11:51 |
| @juiceme | because I am after something like "if there is a mapping table in MMU or CPU logic that prevents CS signal to WR pin when accessing area XXX" | 11:52 |
| rikanee | also, since you're moving the boundaries between flash partitions, make sure you make a "hole" in the parameters you're passing to Harmattan, or else you risk people being able to flash kernels ACROSS the real MTD1 boundary | 11:52 |
| rikanee | which is Very Very Very Bad | 11:52 |
| @juiceme | if that ^^^ is true then it's protected :) | 11:52 |
| rikanee | juiceme: well, we really don't want to be the ones to find that out ;) | 11:53 |
| @juiceme | If I had devices to burn then it would be easy to find out :P | 11:53 |
| Jonni | its safest not to mess up with CAL | 11:53 |
| Jonni | its just invitation to bricks | 11:54 |
| Jonni | thats why I didnt want to use mtd4&5 in my env, much nicer just to use 0p1 partition | 11:54 |
| @juiceme | well it's safest not to do parachuting/diving/motorcycling/... still people do it :) | 11:54 |
| @juiceme | And that's all well and good, and why ubiboot-02 is lot safer than -01 | 11:55 |
| rikanee | juiceme: speaking of which, I still haven't switched my config over from 01 to 02, I'll probably do it tomorrow. | 11:56 |
| Jonni | but yes, if you manage to get for example mtd5 to be cal, then you have fully working openmode device without need to patch the packages. | 11:56 |
| @juiceme | but as happened with the one device you bricked with flash-erase, devices like that might be rescued if it would be possible to recreate CAL entries on open mode... | 11:57 |
| rikanee | juiceme: I think that's more of a "NOLO freaking out" though | 11:57 |
| Jonni | that requires that you have backed up the CAL in the 1st place, ie its too late if you have managed to erase it without backup | 11:57 |
| @juiceme | well yes, in that case it would be quite difficult to get anything running there | 11:57 |
| rikanee | juiceme: it'd all be so much easier if CAL structure was understood. | 11:58 |
| rikanee | that way, it could probably be recreated, or copied from another device. | 11:58 |
| Jonni | cal structure is easy, you can copy and create the blocks quite easily with libcal. | 11:59 |
| @juiceme | how individual are the CAL entries between devices, would it be possible to copy a working configuration from one to another, and then only change the bits that identify the device like IMSI's etc..? | 11:59 |
| Jonni | but it cannot be copied from another device, as imei etc blocks are device specific and they must match the modem, otherwise it wont work | 11:59 |
| Jonni | as modem will refuse to work if cal has missmatch | 12:00 |
| rikanee | juiceme: the MAC address and IMEI would have to be blanked out, but that's the only major roadblock I'm aware of | 12:00 |
| @juiceme | but you propably could change that back, the IMEI's written on the device box | 12:00 |
| rikanee | Jonni: that sucks if it's true on Harmattan devices, as IIRC on the N900, WiFi and BT addresses were missing, while IMEI was simply copied back from BB5 | 12:00 |
| rikanee | *once CAL was wiped, on the N900 | 12:01 |
| @juiceme | If you have any kernel logs saved anywhere, you can look up those fromn there in case you don't have the original box any more :) | 12:01 |
| rikanee | actually, one has to wonder about the actual relevance of the CAL partition, when NOLO could simply extract burned-in addresses from hardware devices and pass them to the kernel. | 12:03 |
| @juiceme | But I am wondering if there's any post-production data that's saved there that would need to be correct, like on BTS'es the power level calibration, RX sensitivity tables and FHS pahse calibration data is measured on the final acceptance test and written to compensation tables in device memory. | 12:03 |
| rikanee | on, crap, yeah, right. | 12:04 |
| @juiceme | So how is it with phones these days? | 12:04 |
| rikanee | s/on/oh/ | 12:04 |
| rikanee | juiceme: I totally forgot that after messing with/replacing antennas, you must calibrate the device in the Nokia RF testbench. | 12:04 |
| @juiceme | Of course that is data which might be saved on the baseband chip itself... | 12:05 |
| rikanee | well, that we don't know. | 12:05 |
| @juiceme | on another note alltogether... | 12:12 |
| @juiceme | I just did something quite funny actually :) :) | 12:12 |
| @juiceme | I booted ubiboot from ubiboot :) | 12:13 |
| TMavica | juiceme have you chk the log? | 12:13 |
| rikanee | juiceme: kexec party? | 12:13 |
| @juiceme | as I just made another 02 kernel, and just thought, why should I _flash_it to test it when I have uboboot :) | 12:13 |
| @juiceme | TMavica, looks quite ordinary to me. | 12:14 |
| @juiceme | how is your booting to Harmattan now, it does not work every time, but sometimes OK? | 12:14 |
| TMavica | does not work everytime | 12:16 |
| TMavica | i now in harmattan, now try reboot and enter again | 12:16 |
| @juiceme | rikanee, I just wasnted to see if adding "dsme -d -p /lib/dsme/libstartup.so -l syslog -v 7" before "bme_RX-71 -l syslog -v 7 -c /usr/lib/hwi/hw/rx71.so -d" would enable me to run bmestat, but it still does not work, the socket "/tmp/.bmesrv" is still missing :( | 12:18 |
| @juiceme | TMavica, fromthe logs I see the boot is interrupted by WD_32 | 12:18 |
| @juiceme | so there is still some watchdog related problems. | 12:19 |
| TMavica | i reboot in harmattan and enter harmattan is ok this time, i try boot again | 12:22 |
| TMavica | not everytimes success | 12:24 |
| @juiceme | TMavica, I see you have the latest watchdog corrections, you are using the image zImage_2.6.32.54-ubiboot-02_090413 | 12:24 |
| @juiceme | but it's good to know that you CAN boot to Harmattan at all. Now we only need to find out why it cannot be done every time. | 12:25 |
| TMavica | yes | 12:26 |
| @juiceme | When the boot fails, you eventually come back to the menu, right? | 12:26 |
| @juiceme | so it never any longer complains about the charger problems? | 12:26 |
| TMavica | yes, reboot self and go menu again | 12:26 |
| TMavica | yes, charger problem no more | 12:27 |
| @juiceme | that's good to know :) | 12:27 |
| TMavica | i dont know it is related to fastern9 or not, i uninstalled it. | 12:27 |
| @juiceme | well, the original proble at least was not related to fastern9. I know this because it was tried on freshly flashed device, with nothing yet installed. | 12:28 |
| TMavica | whats autoboot means in ubiboot.conf? | 12:29 |
| @juiceme | TMavica, sorry, was in a quick meeting | 12:57 |
| @juiceme | autoboot setting means, if you want to boot directly to some kernel on the list, without selecting. Useful if you have just one kernel you use with Nitdroid for example. | 12:58 |
| @juiceme | then just set autoboot to the number of the kernel you want to boot, and when you touch the icon, it will boot straight to that without requiring another touch to a kernel. | 12:59 |
| TMavica | ok | 12:59 |
| TMavica | i found there is new zimage for android | 13:00 |
| -!- TMavica [TMavica@1-36-77-246.static.netvigator.com] has quit [Read error: Connection reset by peer] | 13:47 | |
| -!- TMavica [~TMavica@1-36-77-246.static.netvigator.com] has joined #ubiboot | 13:49 | |
| @juiceme | Jonni, it wouldn'd matter what is the PR level of the device when flashing ubiboot kernel on it, right? | 14:13 |
| @juiceme | basically what I am after, is that if I have a PR1.1 device, forexample then I could clean-flash it, immediately flash ubiboot and "tar -cvf" the partitions. | 14:15 |
| @juiceme | then, cleanflash with PR1.2 and repeat process. | 14:16 |
| @juiceme | thdn, same with PR1.3 package... | 14:16 |
| @juiceme | later on, at any given?moment I can then restore the tarfiles, and have a device that boots up fresh at any PR levdl I wish to have. | 14:18 |
| @juiceme | ... hmm lotsa typos using n9 console... | 14:19 |
| rikanee | juiceme, yup, you could in deed do that, the firmware version check's only with Flasher ;) | 15:06 |
| Jonni | or if you have 8 mmcblk partitions you can even make menues to boot between different pr images :) | 15:11 |
| rikanee | Jonni: and presumably, 64GB of eMMC ;) | 15:13 |
| TMavica | @juiceme why need long time to load android logo | 15:22 |
| @juiceme | TMavica, hi, the reason it takes so _long_ time to boot android is because the zimage.pr13 does not have the l2fix :) | 17:22 |
| @juiceme | what the "l2fix" does, it is a kernel patch that causes L2 cache to be switchd on early in the kexec process. Without that patch the device will spend quite some time before eventually it will after some time execute such a code that causes a context switch that activates the cache. | 17:24 |
| @juiceme | for same reason, when bootin Harmattan the original open mode kernel takes a long time to load when compared to the l2-fixed kernel. | 17:25 |
| @juiceme | Jonni, having all 3 PR level Harmattan OS'es (or even more, if you want to install old r&d images...) would be quite a collection :) | 17:26 |
| @juiceme | Jonni, one other thing came to my mind... If I would leave the NOLO to an older version and load a freshly saved PR1.3 image baked on another device, I could use devicelock on an open mode kernel, right? Since if I remember correctly the CAL-wrlock was not implemented in PR1.1 release..? | 17:29 |
| TMavica | ic | 17:33 |
| @juiceme | oc | 17:33 |
| @juiceme | TMavica, sure it would be possible to compile nitdroid kernel with l2fix. | 17:34 |
| @juiceme | I maybe should look into it soma day, but las time I wanted to try that, I could not find the latest sources... | 17:35 |
| @juiceme | s/soma/some/ | 17:35 |
| TMavica | it is not big deal, LOL. at least I wish to can success boot to harmattan, no need boot serveral times | 17:44 |
| Jonni | juiceme: cal rwlock was implemented PR1.0 onwards, only thing that was changed in PR1.1 that flasher triggered open mode even on ram loading of kernel. | 17:47 |
| @juiceme | ah, okay. | 17:47 |
| @juiceme | I guess no devices were ever shipped with PR1.0, at least all I have seen are PR1.1 and newer. | 17:48 |
| Jonni | devices were shipped with PR1.0, I still have atleast one N9 with PR1.0 | 17:48 |
| @juiceme | that's the early ones then. | 17:49 |
| coderus | juiceme: afaik drunkdebugger already reused your l2fix to new nitdroid kernel with ubiboot ;) | 17:52 |
| @juiceme | coderus, excellent :) | 17:53 |
| @juiceme | where can I get it from? | 17:53 |
| Jonni | I'm just thinking could there even be any benefits for having pr1.0 nolo and having possibility to ram boot custom kernels in secure mode... ohwell I cant really think of a use case. | 17:54 |
| TMavica | juiceme, i using this: http://downloads.nitdroid.com/e-yes/n9/ubiboot/zImage | 17:55 |
| coderus | juiceme: it's not released. you can ask him privately, i think. | 17:55 |
| @juiceme | I might do so. Or better, if I got the official latest sources I could do it myself and upload to ubiboot page... | 17:57 |
| coderus | juiceme: well, i know l2fix not the only change he did ;) | 18:14 |
| -!- TMavica [~TMavica@1-36-77-246.static.netvigator.com] has quit [] | 18:15 | |
| -!- TMavica [~TMavica@1-36-77-246.static.netvigator.com] has joined #ubiboot | 18:17 | |
| -!- TMavica [~TMavica@1-36-77-246.static.netvigator.com] has quit [] | 23:44 | |
Generated by irclog2html.py 2.12.1 by Marius Gedminas - find it at mg.pov.lt!