DocScrutinizer05 changed the topic of #qi-hardware to: Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs and http://irclog.whitequark.org/qi-hardware
<zrafa> OMG, that thing is set as GPIO for the keyboard
<zrafa> !
<zrafa> I want to kill myself
<sung> do any of you know what an ethernet network transformer is for?
<whitequark> sung: sure
<sung> i'm reading through schematics and i was wondering why ethernet pins aren't going str8 to a jack
<sung> but rather hittnig up a network transformer, and then a jack
<whitequark> ethernet uses differential signalling; the transformer removes DC offsets and allows pulses to pass through
<whitequark> DC offset*
<whitequark> since you have a twisted pair, any voltage that's induced in the pair due to external interference is induced with roughly same magnitude in both wires
<sung> ohhhh.
<sung> okay, so just because an IC has a PHY, doesnt necessarily mean it has a built-in network transfoemrmer
<whitequark> there's also Power over Ethernet, which puts 48V between some two pairs
<whitequark> with a transformer, you can still use them for data
<whitequark> yeah, putting a transformer into an IC is a pain ;D
<sung> bro, thank you.
<sung> and it looks like i can find ethernet jacks called magjack that has it builton
<whitequark> yes, plenty
<whitequark> "magjack" though? not sure. I always seen some noname chinese connectors, never with a fancy name like that
<sung> https://www.sparkfun.com/products/8534 is what i'm looking at
<whitequark> sparkfun is super overpriced in general
<whitequark> $1.95 seems ok though
<sung> my end goal is to get an rt5350f ic and basically make my own vocore
<sung> and i don't care if it costs me 10 times what the vocore costs because i'm trying to learn stuff while i do it
<sung> what i've learned so far is that It's Hard(tm)
atommann has joined #qi-hardware
xiangfu has joined #qi-hardware
atommann has quit [Ping timeout: 272 seconds]
atommann has joined #qi-hardware
xiangfu has quit [Remote host closed the connection]
viric has quit [Ping timeout: 255 seconds]
viric has joined #qi-hardware
wolfspraul has joined #qi-hardware
wej has joined #qi-hardware
wej_ has quit [Ping timeout: 250 seconds]
porchaso0 has quit [Ping timeout: 246 seconds]
jow_laptop has quit [Ping timeout: 246 seconds]
panda|z has quit [Ping timeout: 246 seconds]
jow_laptop has joined #qi-hardware
panda|z has joined #qi-hardware
wolfspraul has quit [Ping timeout: 245 seconds]
apelete has quit [*.net *.split]
dos1 has quit [*.net *.split]
pcercuei has joined #qi-hardware
wolfspraul has joined #qi-hardware
porchao has joined #qi-hardware
valhalla has quit [Ping timeout: 246 seconds]
valhalla has joined #qi-hardware
wolfspraul has quit [Ping timeout: 240 seconds]
wolfspraul has joined #qi-hardware
dos1 has joined #qi-hardware
apelete has joined #qi-hardware
xiangfu has joined #qi-hardware
xiangfu has quit [Remote host closed the connection]
atommann has quit [Quit: Leaving]
wolfspraul has quit [Ping timeout: 245 seconds]
wolfspraul has joined #qi-hardware
wolfspraul has quit [Ping timeout: 272 seconds]
wolfspraul has joined #qi-hardware
methril has joined #qi-hardware
methril has quit [Remote host closed the connection]
methril has joined #qi-hardware
methril has quit [Remote host closed the connection]
viric has quit [Ping timeout: 260 seconds]
viric has joined #qi-hardware
dandon has quit [Quit: .]
xiangfu has joined #qi-hardware
<kyak> scary..
<whitequark> not really
<whitequark> if you have two compilers that were not designed to be used as a pair, you can detect it in any case very easily
<whitequark> i.e. in worst case you just need to write a very bad and slow compiler that can compile your existing compiler yourself.
<kyak> yeah, you have to write your own trustworthy compiler
<kyak> easy, right? :)
<whitequark> huh? no
<whitequark> not at all
<whitequark> I need to write *any* compiler
<whitequark> then I compile each of them with one another twice
<whitequark> the thing is, in general it is not possible to insert such backdoor (this could be even logically proven, but I'll just say it's obvious)
<whitequark> so you have to rely on matching specific code in codebases you know.
<kyak> you have to write a compiler
<whitequark> so?
<whitequark> writing a compiler is straightforward
<whitequark> especially when you don't need to be 1) fast 2) complete 3) display sensible errors for incorrect code
<whitequark> without these requirements, it's not only straightforward, it's just trivial
<kyak> ok, you've written a compiler. Now, every time you compile it, you will get a bugged binary
<kyak> and every time you use that bugged binary , you get another bugged binary
<whitequark> most important fragment:
<whitequark> >This countermeasure will only fail if both A and T are infected in exactly the same way. The second compiler can be malicious; it just has to be malicious in some different way: i.e., it can't have the same triggers and payloads of the first.
<whitequark> in essence, the effort required to detect this hack is not even within an order of magnitude of effort that is required to produce it. it's way, way easier
<whitequark> and this process in fact happens in the wild all the time, e.g. when clang and gcc bootstrap each other
<viric> kyak: the fun is that Ken wrote the C compilers in the go toolchain :)
<kyak> whitequark: ok, i'm reading now
<viric> would you trust compilers from Ken?
<whitequark> no; they created C.
<whitequark> economically, likely the worst thing to ever happen to computing.
xiangfu has quit [Remote host closed the connection]
pcercuei has quit [Ping timeout: 255 seconds]
<viric> :)
<kyak> whitequark: ok, i get it
<kyak> whitequark: so, when clang and gcc "DDC" each other, is V and W bit-to-bit equivavelnt? :)
<whitequark> kyak: compiler bootstrapping does, in fact, check bit-for-bit equivalence
<whitequark> as part of natural testing process
<whitequark> but it's not really about that
<whitequark> my point is that, for example, LLVM's history is public and cryptographically signed, and its internal structures change a LOT
<whitequark> ditto for GCC. it's simply not possible to write a payload that would work on future versions of LLVM; you can't predict the future
<whitequark> so even if *at some point in past* this happened, it's not working anymore
<kristianpaul> zrafa: yeah..
<kristianpaul> rx pin keyboard :p
<kristianpaul> you already need more help? :)
pcercuei has joined #qi-hardware
<kyak> whitequark: i'm thinking if DDC would work for cross-compilers.. For example, gcc-arm - is there any compiler other than gcc that can compile gcc-arm?
pcercuei_ has joined #qi-hardware
pcercuei has quit [Ping timeout: 250 seconds]
pcercuei_ has quit [Ping timeout: 250 seconds]
pcercuei has joined #qi-hardware
<whitequark> clang, of course
<ysionneau> clang can compile gcc ? :)
<ysionneau> cool!
<whitequark> what? of course clang can compile gcc
<whitequark> why is this even a question/
<larsc> maybe gcc requires some strange gcc extetensions ;)
<ysionneau> I would expect GCC to contain crappy code that only GCC could ever compile :)
<ysionneau> that would not surprise me at all
<whitequark> larsc: well, it sorta does
<whitequark> it won't compile on a strict C99 compiler afaik
<whitequark> maybe with some hacks
<mth> I thought that GCC recently switched to C++
<viric> they started to welcome c++ code
<viric> clang is more or less designed to compile what compiled in gcc, no? :)
<ysionneau> that's the goal yes
<viric> so no wonder that it can build gcc
<ysionneau> but there is always some code somewhere that depends on some gcc specific behaviour
<whitequark> viric: indeed
<ysionneau> and that will break on clang
<whitequark> although it rejects the more egregious hacks
<ysionneau> this is becoming less and less true though
<larsc> clang for example does not support variable sized arrays on the stack
<larsc> which is only support by gcc by accident
<larsc> supported
<larsc> because they needed it for ada or something
<viric> alloca ftw
<viric> :)
<whitequark> clang has alloca, of course
<viric> variable sized arrays should be doable and easy.
<whitequark> if it was the case, they would be supported
<whitequark> take a look at clang's ML for details.
<viric> that was a quick though
<viric> t
<viric> I'll read about it another day. Good that there is discusison though
<whitequark> I have no idea honestly, but I know that clang devs don't drop a feature solely because of ideological concerns or something
<whitequark> if it's not supported, it has a good reason behind it.
wolfspraul has quit [Quit: leaving]
<viric> good reasons don't mean easy agreement :)
<viric> but can be. I don't use clang at all
<whitequark> generally it is maintainability concerns
<whitequark> gcc exposes a lot of accidental implementation details
<viric> I never tried to write a compiler, so I might be not any good to judge :)
<larsc> well they are not part of the standard
<whitequark> larsc: clang implements plenty of extensions
<whitequark> if you want standard, use -pedantic :D
<whitequark> viric: oh, right, VLAs are only disabled *in C++*
<whitequark> in C they do work
<whitequark> with clang that is
<whitequark> VLAs on stack, I mean.
<pcercuei> clang not having --print-sysroot breaks my Makefiles :(
<whitequark> VLAs in structures are a completely different story
<whitequark> the former is part of C99, the latter is uh
<larsc> yea, I think that's what sneaked in through the ADA support
<whitequark> ah
<larsc> It was never meant to be in the C backend for gcc
wej_ has joined #qi-hardware
wej has quit [Ping timeout: 250 seconds]
wej_ has quit [Ping timeout: 250 seconds]
wej has joined #qi-hardware
jow_laptop has quit [Ping timeout: 240 seconds]
jow_laptop has joined #qi-hardware
pcercuei has quit [Quit: dodo]
dandon has joined #qi-hardware
<zrafa> kristianpaul: he, I am okey so far :)