**** BEGIN LOGGING AT Thu Aug 15 02:59:58 2019 Aug 15 03:00:04 rcn-ee : it is there in the version (4.14.108) I am using, I was asking whether it will be available in future builds too Aug 15 03:01:57 rcn-ee currently no updates has been made to greybus kernel module Aug 15 03:14:55 vaishnav98_: oh i enabled it for you, going forward it will always be enabled. Aug 15 03:16:55 rcn-ee Thanks a lot :) Aug 15 03:21:15 Hi, should the pocketbeagle show up as a USB serial device when plugged in (running latest "IOT" debian image) to a linux host? Aug 15 03:21:36 I'm having trouble having it recognized as a virtual ethernet device as well Aug 15 04:36:57 hdanak: yes, composite serial (CDC-ACM) + network (RNDIS) + network (CDC-ECM) Aug 15 04:37:14 + mass-storage I think (tiny read-only images with getting started guide and such), assuming that's still a thing Aug 15 04:39:21 yeah I compiled those kernel modules, still not picking up any devices when I plug it in (and wait for boot etc) Aug 15 04:39:33 bad cable? Aug 15 04:39:39 I'm wondering if I'm using the correct image? It's "Debian 9.5 2018-10-07 4GB SD IoT" Aug 15 04:39:53 yep Aug 15 04:39:53 bad cable, I hadn't even thought of that, yes I'll check Aug 15 04:40:02 it might be a power-only cable actually Aug 15 04:40:14 yep those are unfortunately a thing Aug 15 04:40:28 even though they're not just bad cables for data but also for power Aug 15 04:40:43 so if that's it, do yourself a favor by cutting it in half and tossing it in the trash Aug 15 04:42:29 (the data lines are needed for the usb battery charger detection protocol, which means that a cable without data wires will cause devices to limit their charge current to some low value) Aug 15 04:45:17 ah lovely, that was it! Aug 15 04:45:43 thanks a lot, I don't think I would not have thought about that before a lot of pain Aug 15 04:46:00 *I would have Aug 15 04:46:55 well, on the topic of things people don't always talk about: when writing an image to sd card, be sure to verify the data on sd card afterwards (some programs like Etcher will do that for you, but if you use e.g. dd you'd have to do it yourself) Aug 15 04:48:45 since when sd cards wear out, they don't politely give write errors, instead their typical failure mode is a bunch of random bit flips in some pages Aug 15 04:50:27 even if this doesn't seem to happen to people very often, needless to say you don't want to end up trying to debug the baffling problems that can cause :) Aug 15 07:04:58 i read somewhere that dd can be replaced with cat, but ive not repeated their claimed results Aug 15 07:05:23 sure it can be, but with the same concerns Aug 15 07:05:35 for me, cat behaves badly and the bs=32m is very important Aug 15 07:06:13 yeah cat probably results in sub-optimal write patterns Aug 15 07:07:41 it'll also fill up the write buffer in the kernel, which sucks... though I think dd does that too unless you're using oflag=direct or oflag=dsync Aug 15 07:07:58 using oflag=direct along with a suitably large block size is probably best Aug 15 07:08:44 (32M seems a bit excessive, probably 4M or 8M suffices) Aug 15 07:09:16 though I guess it's better to use a write chunk size that's a bit too large than one that's a bit too small Aug 15 07:12:10 i didn't know about oflag, i will read about it Aug 15 07:13:01 i suppose youd also want to tee it off into an md5sum when making the image, then check it when its flashed Aug 15 07:13:29 yes Aug 15 07:13:56 or crc really is all thats needed Aug 15 07:14:10 (and make sure you're reading from sd card when verifying and not accidently from disk cache. I think using oflag=direct and/or iflag=direct should prevent that) Aug 15 07:17:19 crc would suffice, but md5sum is far more commonly available than a crc utility, and there won't be a performance difference since the limiting factor will be reading from sd card Aug 15 07:21:50 better standardised too Aug 15 18:59:33 hello guys, i build a can bus with two beaglebone black using comms cape, the communication by using socketcan is good, but unstable, so i'm now trying with python, but i have a problem with it. The message can't be send. Here is my python code. And I've update the BB-cape-overlay, just not work. Aug 15 18:59:40 https://pastebin.com/z9kQEDNA Aug 15 19:00:42 https://pastebin.com/0CdLN07Z Aug 15 19:48:56 https://pastebin.com/1XejczqN Aug 15 19:49:08 hello guys, i build a can bus with two beaglebone black using comms cape, the communication by using socketcan is good, but unstable, so i'm now trying with python, but i have a problem with it. The message can't be send. Here is my python code. And I've update the BB-cape-overlay, just not work. Aug 15 19:49:55 when asking a question here, especially about an obscure topic, please just stay connected and have patience, instead of leaving and then repeating your question again an hour later Aug 15 19:50:21 sorry, i have to restart my PC Aug 15 19:50:42 https://pastebin.com/BwS0mS4b Aug 15 19:50:53 then just say "brb" when leaving and "back" when back Aug 15 19:51:30 ok, i'll remember next time Aug 15 19:51:40 a minor note: since you're using python3 (as you should), the first line of your script should be #!/usr/bin/python3 Aug 15 19:52:18 and remove the try...except, it makes it impossible to know what went wrong Aug 15 19:52:39 ok Aug 15 19:52:52 also, Message is a class, you need to make an instance of it Aug 15 19:53:04 right now you're modifying the class itself and then trying to send that :P Aug 15 19:53:48 also, "although "communication by using socketcan is good, but unstable" is rather vague, it does not sound like the sort of problem that will be fixed by switching to a different programming language Aug 15 19:54:11 (though it's hard to say for sure due to the vagueness of the problem description) Aug 15 19:54:25 File "send.py", line 23 Aug 15 19:55:13 because i use soketcan with console Aug 15 19:56:03 like cansend and candump, and sometime the receive was not good Aug 15 19:56:49 i send it one time, but the other node recevie like 5 times the same message Aug 15 19:57:08 I don't know if you just tried to paste a multi-line error into chat, but if so, don't. "< jimmy27> File "send.py", line 23" was all you said. use pastebin to share any multi-line output Aug 15 19:57:17 that sounds really strange Aug 15 19:57:38 ok Aug 15 19:58:14 https://pastebin.com/cphG7TNR Aug 15 20:01:04 it helps if you first read the error message and fix the obvious syntax error :P correct indentation is required in python Aug 15 20:05:17 https://pastebin.com/NUbRmh3N Aug 15 20:07:48 there's not much information about how to write a python code using python-can, do you have any resource about it? thanks a lot Aug 15 20:07:52 also, you don't actually need to share the error at all since I've already explained that passing the Message class to bus.send() is complete nonsense. (but at least you'll now get tracebacks in the future) Aug 15 20:08:24 https://python-can.readthedocs.io/en/master/ Aug 15 20:09:09 (note that "from __future__ import print_function" is a python2 thing, you can ignore that since you're using python3) Aug 15 20:09:36 the only part of that example you need it now they construct the message Aug 15 20:10:33 (they're using a try..except in that example to show how to incept failures to send the message but until you have a useful way to handle such errors I would not recommend using any try...except) Aug 15 20:10:39 *intercept Aug 15 20:11:05 it looks like the library has detailed documentation Aug 15 20:12:01 it won't teach you python programming basics, but that's obviously not the job of the python-can documentation :P Aug 15 20:13:06 thanks mate! Aug 15 20:13:59 the way you construct the bus also differs from what I see in the documentation Aug 15 20:15:17 it looks like you should use something like bus = can.interface.Bus(bustype='socketcan', channel='can1') Aug 15 20:16:16 oh I guess there are two ways Aug 15 20:16:30 I see now the way you do it is also mentioned Aug 15 20:17:12 though 'socketcan_ctypes' is deprecated and should be replaced by 'socketcan' Aug 15 20:17:55 and just passing the configuration to the Bus constructor seems a lot cleaner to me than sticking it into this global can.rc variable Aug 15 20:18:43 but that's up to you... it seems that if you use the global configuration you can also put the config in a config file instead of in the code, which may be nice for some applicatoins Aug 15 23:49:27 hello Aug 15 23:49:29 please let me know, where can I find BROM description? Aug 15 23:49:45 does it always try to boot from SD at first? Aug 16 00:01:56 nexgen2: the details of bootrom behaviour can be found in the AM335x Technical Reference Manual, but the short answer is: on the BBB by default bootrom checks { eMMC, μSD, uart0 (xmodem), usb0 (rndis } in that order Aug 16 00:03:06 how can I boot from SD if something bootable is present on the eMMC? Aug 16 00:03:20 if you power on with the S2 button (aka the boot mode button) held down then the boot order (for bootrom) becomes { SPI flash, μSD, usb0 (rndis), uart0 (xmodem) } Aug 16 00:04:17 thanks for letting me know Aug 16 00:04:26 you can (and should) let go of the S2 button once the power led turns on (or to be technical, 20 milliseconds after the power led turns on) Aug 16 00:05:14 SPI flash is an additional storage option? Aug 16 00:05:22 it is connected to some pins? Aug 16 00:05:49 note that this only determines where bootrom looks for u-boot (or rather, the MLO which contains the u-boot SPL), u-boot typically makes its own decisions with regard to where to load linux from Aug 16 00:06:29 there is no SPI flash on beaglebones (except the BeagleBone Enhanced if I remember correctly) but you're free to connect one if you have some reason for it Aug 16 00:06:53 does default angstrem uboot looks into a text file to choose a kernel to boot? Aug 16 00:07:14 angstrom has not been the default for many, many years. this was before I started using beaglebones so I don't know anything about it Aug 16 00:07:26 are uboot and kernel bound to each another somehow? Aug 16 00:07:38 nope Aug 16 00:07:55 in general they are not, however it is recommended to use the u-boot that came with whatever image you want to use Aug 16 00:08:06 they are uncoupled the same way as grub from a bootable image? Aug 16 00:08:31 nexgen2: u-boot = x86 bios + grub... Aug 16 00:08:45 in theory, but in practice there can still be trouble... for example, current debian images normally use u-boot overlays, but this isn't supported by old u-boot versions Aug 16 00:08:49 then what BROM is? Aug 16 00:09:12 a very basic bios that you have no control other then 16/8 gpio.. Aug 16 00:09:18 does not BROM do hardware initialization like DDR> Aug 16 00:09:26 nope Aug 16 00:09:55 is it reflashable? Aug 16 00:10:08 B"ROM".. Aug 16 00:10:10 is there a source for BBB BROM somewhere? Aug 16 00:10:11 bootrom is hard-baked into the SoC basically just does very rudimentary setup of the processor and loads the next stage into the internal SRAM Aug 16 00:10:24 it will not do any board-specific setup such as DDR memory Aug 16 00:10:36 how can I be sure there is no a trojan for TrustZone? Aug 16 00:11:00 nexgen2: is this a college test your working on? Aug 16 00:11:33 rcn-ee[m], please explain your question Aug 16 00:12:13 you can't, but trustzone is not really supported anyway (technically there's a secure monitor, but it is only used to handle a small number of Secure Monitor Calls used to write to special registers that are not directly writable by the OS) Aug 16 00:12:45 there's no secure-world kernel on AM335x GP devices Aug 16 00:13:00 as which compared to? Aug 16 00:13:15 ? Aug 16 00:13:58 Cortex A8 is stated to have a TrusZone? Is TI version any different? Aug 16 00:15:17 I feel like I literally just answered that Aug 16 00:16:06 it means BBB CPU does not meet Cortex A8 specs? Aug 16 00:16:25 nexgen2: it's r2p1 Cortex-A8 with neon... Aug 16 00:16:58 and I feel like you're asking questions about things you don't really understand yet yourself Aug 16 00:17:13 sorry, I even do not know what r2p1 is Aug 16 00:17:24 version Aug 16 00:17:47 zmatt, may be, I am trying to get into this area of knowledge Aug 16 00:17:49 nexgen2: thumb2 works unlike the r1p3's we used on the Beagle/xM Aug 16 00:18:01 also, I think it's r3p2 Aug 16 00:18:11 are these revisions? Aug 16 00:18:15 yep, definitely r3p2 Aug 16 00:18:29 yes, cortex-a8 revisions Aug 16 00:18:36 r3p2 is the last revision Aug 16 00:19:54 anyway, the short summary is: even though the cortex-a8 core itself has trustzone support, it is not usable on GP versions of the AM335x, which is what's used on the BBB Aug 16 00:20:08 can you please point me to a public explanation of this interesting issue related to TrustZone being revision specific for a Cortex A8 CPU? Aug 16 00:20:37 nexgen2: support@ti.com can help you. ;) Aug 16 00:20:47 except for a tiny bit of initialization after reset and a tiny SMC handler, everything on the BBB runs in public (aka "non-secure") world Aug 16 00:20:47 nexgen2: has nothing to do with the cortex-a8 Aug 16 00:20:55 it's just how it's setup on the AM335x Aug 16 00:21:05 may be TZ is just not usable by end users but still usable by a trojan injected on the factory? Aug 16 00:21:51 nexgen2: if you want to be able to trust hardware, you'll have to design your own processor and create it by soldering transistors together Aug 16 00:21:58 have fun Aug 16 00:22:05 haha, very smart Aug 16 00:22:24 I still can choose AllWinner Aug 16 00:22:29 lol Aug 16 00:22:36 is it any better in terms of security? Aug 16 00:22:36 I'd trust a TI SoC a lot more than an AllWinner one Aug 16 00:22:46 lol, and your worried about TI's trojans'!!! China already back-doored that one.. Aug 16 00:23:22 there is known method for a root escalation Aug 16 00:23:26 I'm not concerned about trustzone on the BBB... if somewhere were going on in secure world, that would be observable anyway Aug 16 00:23:30 it's something you can detect Aug 16 00:23:32 but for a client mode it does not matter Aug 16 00:23:58 I would prefer something with backdoors but without already injected active trojans Aug 16 00:24:12 also, it's hard to imagine what that trojan could do, given that it only has 1KB of ram that's private to secure world Aug 16 00:24:49 is not all RAM related to TZ not readable from outside? Aug 16 00:25:10 there's reason to believe TI would put a trojan in their hardware... it would be easy to discover and cause terrible damage to their reputation Aug 16 00:25:52 unless they are forced to do so by NSA or by above regulations Aug 16 00:26:05 "RAM related to TZ" is meaningless... trustzone doesn't specify anything about RAM Aug 16 00:26:07 otherwise no way to a public market Aug 16 00:26:08 nexgen2: for all things trustzone: https://developer.arm.com/ip-products/security-ip/trustzone Aug 16 00:26:27 nexgen2: you just seem really paranoid about a topic you know very little about Aug 16 00:26:40 trustzone is irrelevant on the BBB Aug 16 00:27:01 sounds good, though hardly believable Aug 16 00:27:12 what you do or do not believe is not my problem Aug 16 00:27:42 sure, thank you very much for your earlier suggestions Aug 16 00:29:04 nexgen2: besides, DEFCON was last week, nothing is "secure" today, till all the things pointed out is fixed. ;) Aug 16 00:29:11 does a lack of TZ depend on BBB release year or revision? Aug 16 00:29:13 but I'm pretty security-paranoid myself, have dug a fair bit into bootrom on the AM335x, have dumped and partially reverse-engineerd the secure part of bootrom on the DM814x (a direct ancestor of the AM335x) to see what it does Aug 16 00:29:14 like revC Aug 16 00:29:30 based on all that, my opinion is: there's no need to worry about bootrom Aug 16 00:29:45 nexgen2: all 1Ghz Aam335x are the same die revision.. Aug 16 00:30:20 no, it applies to all AM335x SoCs, and I think all TI SoCs in general (except maybe the latest ones, I don't know much about those yet) Aug 16 00:30:24 it looks like a BBB much better in terms of security than X86? Aug 16 00:30:31 X86 is horrible Aug 16 00:30:48 X86 is pretty much irredeemable with regard to security Aug 16 00:31:06 nexgen2: BBB isn't secure.. it wasn't designed for that.. it was designed for usablity.. Aug 16 00:31:14 cannot DMA be isolation by software on X86? Aug 16 00:31:17 well it all depends on "secure" Aug 16 00:31:22 secure what? from who? Aug 16 00:31:25 *isolated Aug 16 00:31:37 I have no idea what you mean by that Aug 16 00:31:44 it's only isolated if you dump a bucket of cement on it and throw it into the ocean.. Aug 16 00:31:50 lol Aug 16 00:32:22 unfortunately (or not) I do not know who indicates my very weak security by joke attacks Aug 16 00:32:50 regardless, a lot of security goals are achievable in theory, but fail in practice because all software sucks Aug 16 00:33:31 rcn-ee[m], I meant DMA with blobbed controllers can allow device firmwares to pawn main system Aug 16 00:34:06 Is not OpenBSD better than average software in terms of security? Aug 16 00:34:27 it's easier then that.. While testing efi boot, i noticed u-boto doesn't scrub memory, hence if you reboot, and halt.. EVERYTHING is still in DDR3. ;) Aug 16 00:34:29 nexgen2: again your words sound like you just read a few random things you don't really understand Aug 16 00:35:22 nexgen2: dunno, openssl certainly has had plenty of vulnerabilities Aug 16 00:36:01 as for DMA isolation I offer to use such chains like: Main system + disk encryption for iSCSI blocks -> DMA free old ethernet -> iSCSI -> another host for devices -> SATA -> HDDs Aug 16 00:36:09 wait never mind, I tohught openssl was part of the openbsd project, but I think I'm confusing it with openssh Aug 16 00:36:50 OpenBSD offers LibreSSL Aug 16 00:36:57 nexgen2: so go run OpenBSD: https://www.openbsd.org/armv7.html#hardware we aren't going to support it.. Aug 16 00:37:15 nexgen2: yeah now you're definitely just saying random things Aug 16 00:37:22 and this definitely has nothing to do with the bbb anymore Aug 16 00:37:35 that is why I have already purchased a few of BBB boards, going to try grsec Linux and OpenBSD on them Aug 16 00:37:53 'grsec' oh god.. Aug 16 00:38:09 feel free to dump your money on them Aug 16 00:38:11 GrSecurity patch Aug 16 00:38:21 I will use an old free one Aug 16 00:38:28 4.9.x Aug 16 00:38:45 will it work on BBB? Aug 16 00:38:49 4.9.x = spectre... your owned. ;) Aug 16 00:39:06 it is only for client side programs Aug 16 00:39:11 like SSH client Aug 16 00:39:13 * zmatt distances himself from this conversation and does to do something useful Aug 16 00:39:29 not server usage Aug 16 00:39:57 nexgen2: if it's "client" only, why bother with "GrSecurity".. Aug 16 00:40:19 I am still concerned and would like to learn grsec on BBB Aug 16 00:40:41 Why? they violated the GPL and no one gives a crap about them anymore.. Aug 16 00:40:45 if it works I will have a skill to switch to a more recent grsec quickly if having a chance Aug 16 00:41:20 grsec pax is known to protect from unknown errors in code Aug 16 00:42:00 so does gcc.. Aug 16 00:42:45 does not grsec 4.9 do it better than linux v5x? Aug 16 00:43:14 anything worth a damn was already implemented by kees and pushed into mainline. Aug 16 00:43:31 there are so many interesting grsec features I would like to try and experiment with them Aug 16 00:43:43 sounds good Aug 16 00:43:47 or just use mainline... Aug 16 00:43:56 then what is a CLI to manage such features? Aug 16 00:44:18 "command line interface".. Aug 16 00:44:20 gradm alternative Aug 16 00:44:22 your fingers and keyboard.. Aug 16 00:44:35 may be some command to read a man for Aug 16 00:45:46 nexgen2: yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo pick on, they all have their own tools to manage... Aug 16 00:46:40 thanks, apparmor may be a lighter alternative to grsec Aug 16 00:46:53 but what about pax, paxctl or something like it? Aug 16 00:48:16 nexgen2: use what ever you want.. Aug 16 00:48:47 I would like to try pax and compare to mainline then Aug 16 00:49:12 it's your time/money feel free to waste them.. Aug 16 00:49:25 it is possible to apply both grsec patch and deblob libre patch to a RT (real time) kernel? Aug 16 00:49:49 go ask grsec, libre, and RT.. Aug 16 00:49:52 will it still keep compatibility with BBB? Aug 16 00:50:16 not my problem. ;) Aug 16 00:50:28 :) thanks Aug 16 00:59:02 can you please also indicate in which terms BBB is more secure than an old X86 Aug 16 00:59:08 like P1-P3? Aug 16 00:59:14 without IntelME Aug 16 01:00:50 no Aug 16 01:01:38 you do not want or do no know or there is nothing more secure on BBB? Aug 16 01:02:11 use google.com Aug 16 01:02:22 I tried already Aug 16 01:02:43 X86 microcode can be an issue, anything else? Aug 16 01:02:44 DMA? Aug 16 01:03:09 there is no PCI on BBB either Aug 16 01:03:31 your trying wrong. ;) Aug 16 01:03:54 can you please let me know a few of keywords? Aug 16 01:04:02 BIOS, UEFI Aug 16 01:04:23 negative rings of CPU, SMM Aug 16 01:04:33 anything more? Aug 16 01:05:12 Spectre is present in both though Aug 16 01:05:22 in A8 and Intel Aug 16 01:05:38 in P1 it is most likely even not present Aug 16 01:05:47 in P2 is much less exploitable Aug 16 01:05:59 than in a modern CPU Aug 16 01:06:16 A7 is immune according to google Aug 16 01:07:32 so AllWinner A7 is even more secure because of Spectre less at least? Aug 16 01:08:23 and there are options of FreeBIOS and Libreboot for old X86 Aug 16 01:08:54 how BBB is better? **** ENDING LOGGING AT Fri Aug 16 03:05:29 2019