Need Teensyduino source code or tarball

Status
Not open for further replies.

jplarocque

New member
Hi,

I'm looking to start using the Teensy 3.0 I ordered, but I'm having a hard time locating the source code or even a tarball of the binary distribution for Linux x86_64. I'm not interested in using Arduino, but I do need the tarball contents for the sample Makefile (also found in a few random places elsewhere on the net) and especially the C header files.

I'm uncomfortable with running binaries from untrusted sources, out of basic computer security hygiene. I've downloaded the latest Linux x86_64 distribution of Teensyduino at http://www.pjrc.com/teensy/td_115/teensyduino.64bit , but I won't run it. I decompressed the binary with upx but can't make sense of the embedded archive: I've had no luck with tar, zip, ar, or cpio.

I've been hunting for a source distribution or repository for the Teensyduino code but am turning up nothing. Does anyone know where I can find them? Paul, if you're reading this, can you share a simple tarball of the Teensyduino binary distribution for Linux x86_64?

Thanks!
 
If you run the binary, then it will install the sources and the sample makefile into the Arduino distribution. Its hard to do much on a computer if you dont trust the software from the suppliers of the tools you want to work with.

You can setup a virtual machine to run the binary in and then move the resulting directories to you main machine.
 
Last edited:
If you run the binary, then it will install the sources and the sample makefile into the Arduino distribution. Its hard to do much on a computer if you dont trust the software from the suppliers of the tools you want to work with.

You can setup a virtual machine to run the binary in and then move the resulting directories to you main machine.

It's not that I necessarily distrust Paul, but I'd also have to trust his web server's security, and the network path from A to B. Cryptographic signatures would help here, but source code would be a better start.

The virtual machine route is a last resort, because this computer's virtualization extensions are either buggy or unsupported with the tools I've tried. I did find an old tarball at http://www.pjrc.com/teensy/beta/arduino-1.0.3-teensy3-beta11-linux64.tar.gz.

I'm currently building binutils and gcc, and as I make progress I'll describe how to build a development environment using only sources from Debian (which I have made the decision to trust).
 
You may find these threads of interest.

http://forum.pjrc.com/threads/799-Firmware-loader-for-Teensy-3?highlight=cloning
http://forum.pjrc.com/threads/23812-How-does-the-upload-actually-work?highlight=proprietary

I don't speak for PJRC, but the gist of it is that Paul is keeping a few things proprietary to make it harder to clone his products, so I suspect as long as that is the case, there will be a binary blob involved. Maybe that's ok if the tool chain is open? There are a few threads describing how to develop for the Teensy using Eclipse.

For what it's worth, I'm also interested in security hygiene. Even though I'm a professional software developer, I find it daunting. Where do I obtain a processor that is free of undocumented 'features'? How do I find the time to audit an entire compiler and operating system myself? Would I even recognize some subtly underhanded code, that say decreases the entropy of a random number generator or uses a broken security setting for some cryptographic service? Etc., etc., etc.
 
Not saying you are wrong, but do you also check all sourcecode so theres no bad stuff in there ?
I mean, building your own wont help if the source is bad ... a compromised source code package is
as bad as a compromised binary. Sure that is possible to check ... but thats a tough call.
 
I'm uncomfortable with running binaries from untrusted sources, out of basic computer security hygiene. I've downloaded the latest Linux x86_64 distribution of Teensyduino at http://www.pjrc.com/teensy/td_115/teensyduino.64bit , but I won't run it.

Right now, that's the only distribution, so you're going to have to run it. Someday I might make alternate downloads. But the honest truth is many other developments are a much higher priority... among then, fixing a mac bug, enabling lower power usage, more than 6 key USB keyboard, audio APIs, and many other features that a lot of people really want. I can only do so much every day, and I believe the history of Teensy has shown pretty consistent improvements being made (even though PJRC is working with much less profit margin than the other Arduino brand board which sell for much more using comperable hardware). I do need to prioritize development time. Features that benefit the most users get the highest priority. Long-term, I do intend to build a non-Arduino install that will be a zip archive or tarball, because some people really prefer to never deal with Arduino at all. It's on my list, but because the installer gives you this now... just after the install in a directory where you can grab only the files you need and discard the rest of Arduino, it's a much lower priority.

You could set up a virtual machine, run the installer within the virtual machine, and then copy the modified arduino. You'll find the sample makefile and necessary source code in hardware/teensy/cores after the installer has run. Just copy the files you want to a shared folder, USB stick or whatever way you can get files off the virtual machine, and then delete the rest.

I really don't want to hear complaining that you can't use a virtual machine. Virtual machines are easy to set up with complete isolation from the host system. If you're really paranoid, you can even shut the virtual machine down after install and then mount its disk image as read-only without execute permission and whatever other security measures you like (perhaps automatic ascii conversion of files, so source code is CR-NL converted and any binary files are corrupted). You can use a virtual machine to run the installer and capture the source code, so get to it!

All the source is placed by the installer into that "hardware/teensy" directory. The installer does a LOT of other stuff to Arduino to make this process very easy for beginners (much of it you can see source files where are installed to a "src" directory). As you get farther into this, you'll probably develop an appreciation for how many details need to be just right, especially for the Arduino IDE to seamlessly support the many different options and features which Arduino was never designed to support. Without taking advantage of those features, you're going to have quite a lot of work to do. Setting up a virtual machine to capture a pile of source code, which is all files you can inspect with your text editor, is a relatively minor part of the amount of work you'll need to do.


Edit: before you delete that virtual machine, also copy Arduino's "examples" and "libraries" directories. The installer adds lots of small patches (to the source... everything in those dirs is only source code). You'll want to save all that library source in case any of your projects need to use some of those libraries. Many published Arduino projects depend on certain libraries. The examples are also pretty helpful, and only pure source, so make sure you get those before deleting the virtual machine.
 
Last edited:
Oh, also, if you want to build your own ARM toolchain that exactly machines the one Teensyduino installs, here is the complete source code:

https://github.com/PaulStoffregen/ARM-Toolchain

Here is a blog article I wrote regarding the PJRC patches. Of course you can just read the patch files, but putting the exact modifications in context would take a LOT of work, unless you're already extremely familiar with all parts of the GNU toolchain. I wrote this article not necessarily to explain the rationale to an untrusting party, but rather to help anyone else who might try to build the toolchain with similar options and on all 3 systems and would run into the same problems. Hopefully my patches can save others the same frustrations?

http://www.dorkbotpdx.org/blog/paul/gnu_toolchain_crosscompile_challenges

Then again, if you don't trust me, maybe that article could be misleading info to throw you off some nefarious changes? LOL. Really, I did spend a good full day writing that blog article, in hopes it might someday save someone the same frustrations I faced building the toolchain. Maybe it'll help you too?

The source above is unmodified files from Code Sourcery (hopefully can can trust them) and my patches are separate files. If you run my build script (which is a shell script, so you can inspect every line), you'll see it extracts the original sources and applies the patches.

If you only trust source directly from the FSF website, well, you might compare Code Sourcery's files to the FSF ones. They're the primary contributor of most ARM patches to the toolchain, so any changes you do find are likely to be on mail lists or pending inclusion to the FSF version.
 
Last edited:
Here is the last piece you'll need to obtain a 100% source code solution:

http://www.pjrc.com/teensy/beta/load_linux_only.c

The GUI-based Teensy Loader is proprietary. This command line version is GPL. The GPL one available on the website hasn't been updated for Teensy3 yet (and doing so is an extremely low priority). However, this beta copy works with Teensy3 on Linux. If you need to run on Windows or Mac (which seems unlikely, given everything you're written), well, the code for Windows and Mac hasn't yet been updated in this version. You'd need to examine the Linux code and apply those changes to the other systems.

For Linux, this command line copy works great. You'll need to edit the sample makefile (from hardware/teensy/cores/teensy3 in the virtual machine) to run this GPL version, instead of "teensy_post_compile". The command line version has a usage print to help. There's also some documentation about integrating with a makefile here: (just remember, the copy on this page only works for Teensy2)

http://www.pjrc.com/teensy/loader_cli.html

If you want the automatic reboot feature using 100% open source, you'll need to connect another Teensy and use the "rebootor code" available at that page. But it can work just fine if you press the pushbutton.
 
I guess I'm a bit slow on the uptake, but just where are the security risks re: a embedded micro-controller like the teensy unless you design them into the product? If one were worried about undocumented NSA-style easter eggs, simply never allow the unit to connect to the internet as a first step. An air gap is a almost 100% effective solution. A friend of mine enjoyed two desktops at his work place for that reason - complete hardware separation for the internal and external networks.

I am incredibly grateful for all the work Paul has done to support not only the platform but the environment here as well. The combination of hardware/software developer is a rare one. I wish I could give back as much as he has given, for example, I have yet been unable to enjoy the fruits of his labors re: Teensyduino 1.16 because I'm on vacation with three kids to help take care of. Not much sleep, no real opportunities to test. But I will help when I can get to it.

Last but not least, how much more likely would it be for ARM to design a 'back door' into their chips than for Paul to do so for his code? On the software side, given how complex gcc has become, how hard would it be to do it there? Think return vs. investment required. How many more systems can be compromised if you have a secret handshake for the hardware/software underlying it all vs. targeting a specific software toolchain from a developer with a comparatively small (but hopefully rapidly growing!) market share?

Are the paranoid individuals among us capable of forcing ARM / Atmel / PIC to disclose their hardware designs? Didn't think so. Can anyone be expected to review GCC or any other kind of modern compiler with any sort of certainty re: vulnerabilities? Don't think so either. I get that you may want to stick to good practices re: security, but your best bet in that case is to have a machine for sensitive tasks, and another for development work. Linux and other distros don't need creme de la creme CPUs to run on, are perfectly good for good coding work in C for a microcontroller platform whose EEPROM, SRAM, etc. is pretty limited.
 
Last edited:
Constantin, I believe all of us who have been around here for a while are impressed with Paul's generosity and integrity. Your point about sticking to good security practices is spot on. How does one minimize one's exposure to security risks? A bug is sometimes all it takes to create a vulnerability.

The question of likelihood is a hard one. Some in the open software community promote the trope, "with many eyes all bugs are shallow". The first problem with this is that there are commonly used bits of open source code that require rare expertise to evaluate; the second problem is that there is so much software that even small probabilities add up. I believe the situation for open source is better than closed source, but in general bugs are not rare and the incentives for bad actors are large.

Maintaining an effective air gap isn't simple. Usually there's a need to copy information across the gap and sometimes there are unintended pathways for doing so. For example, there have been bugs in USB drivers over the years. The code is tricky enough that developers sometimes copy code with bugs intact from presumed good sources. Even a VM does not necessarily provide an air gap. I've seen code in malware that detects which VM it is executing under and selects exploit tactics accordingly.

It's no accident that the Teensy devices are so popular with security researchers. They are ideal for penetration testing. For example, a USB keyboard can have a Teensy embedded in it with code to exploit the host it is inserted into.

I'm not trying to scare everyone away from the computers. The benefits far outweigh the risks, but I do believe as developers, we should strive to get out in front of the risks so that we can offer safer solutions to our users and customers.
 
As I see it, the complexity of modern computer systems and even embedded CPUs makes it statistically impossible to exclude the presence of bugs, intended or not. Thus, we have to live with the risk that such bugs may exist and hence might want to think of ways to minimize potential impacts on things we really care about. For example, a math teacher of mine who used to work as a programmer at a ATM manufacturer gave us several examples re: the complexity and comprehensiveness of the code in ATM machines to ensure that they worked properly. This, on a machine, whose UI inputs are extremely limited, whose mechanicals are hidden behind multiple layers of hardware protection, etc.

Along similar lines, I am happy to accept the possibility that someone may penetrate the systems I have set up in the past. I do what I think is reasonable, others may shake their head in disbelief re: my naivete... But I neither have the time nor the expertise to review the infrastructure that allows my computer systems to function. I assume that the folk who do the software and hardware development are usually acting in good faith and that the systems I maintain will therefore resist the efforts of most crackers / hackers. It also means making backups of the things I care about and storing them in safe places, i.e. risk mitigation. Remember, the first to know outside NYC that something had happened at the WTC towers during 9/11 were the co-locations that hosted the backup systems for the financial companies in those towers...

That said, behavior is also big determinant - seeking out torrents, P2P stuff is one of the best ways I can think of to attract all sorts of interesting stuff, whether its planted by the MPAA, RIAA, FBI, etc. I am not looking forward to the day that my kids are allowed to have CPUs in the home... I'll likely keep them on a separate guest network to keep their gear away from the other gear in the home. But realistically, I should be boning up on how to make my network more resistant to inside attacks now... i.e. routing all traffic through SSH tunnels between machines, and so on. Just where to find the time?
 
Hi,

I too would like to see a tarball, I really really don't like just running binaries I downloaded form webservers, it's bad practice, it's not how linux users work.

But more so, because for me the installer is broken, I cannot appease the "Next" button when selecting the directory, it's stuck disabled, so now I'm boned (Ubuntu 13.04 64bit).

Otherwise, Impressed with my new Teensy++ 2, that I've not used yet.
 
Thanks, I was actually using that but with a sketchbook directory. I've now sandboxed Teensy away from my normal arduino install which has Gen7 and Sanguino. The whole installing thing may be a barrier to recommending this thing to at least my linux friends, I'll see how it goes from here.

I'd be programming in plain old bare metal C normally but this is intended to be an experiment in driving my 3D Printer via real USB. It uses Marlin firmware which is still rooted in the arduino libraries a bit.

Thanks again, especially for such a fast response,
Bracken.

P.S.
I don't mind not having the source so much, but "run this bin" smacks of "we do it all the wrong way".
 
Last edited:
I'm planning to overhaul my build process someday, to generate a tarball (without the Arduino stuff) as well as the installer for Arduino. But with so many other more urgent things planned, that's unlikely to happen until sometime next year.
 
Hi,

I too would like to see a tarball, I really really don't like just running binaries I downloaded form webservers, it's bad practice, it's not how linux users work.

But more so, because for me the installer is broken, I cannot appease the "Next" button when selecting the directory, it's stuck disabled, so now I'm boned (Ubuntu 13.04 64bit).

Otherwise, Impressed with my new Teensy++ 2, that I've not used yet.
Please do not make any asserions as to how users work with Linux based on you own preferences. I started with Linux before Win3.11 was released to the public and have no problems using Paul's installer.
 
I'm planning to overhaul my build process someday, to generate a tarball (without the Arduino stuff) as well as the installer for Arduino. But with so many other more urgent things planned, that's unlikely to happen until sometime next year.

That sounds excellent. :D


Headroom, sorry if I offended you, this being the internet there is of course always an exception to anything anyone says, apparently I forgot for a moment that Slackware exists.
 
Paul, thanks for all your valuable pointers on your toolchain. Again, I don't mean to imply you have any malicious intent. I've simply made the decision long ago that for my development machine, I only run software from highly-vetted sources (Debian and builds of software from signed tarballs, published from sources like the FSF)--sources where if something were compromised/backdoored, it would be too expensive to mount an attack specifically to target me; and if it were a general backdoor, a lot of noise would be made upon the discovery of the issue due to the number of people affected. Everything is a tradeoff, and my decisions are, while paranoid, all about risk management.

Constantin, maybe you misinterpreted. Obviously I have to make concessions in trusting various hardware bits. On a theoretical level, there's all kinds of room in a device like the Teensy 3.0 to fit something malicious and hide it from me as a developer. But I'm not worried about that, because I'm not using my Teensy for security-sensitive tasks; I'm ensuring that the Teensy development that I do on a "secure machine" will not compromise the security of that machine. My development _is_ done on a secure machine, because how else am I going to trust anything I write myself?

Anyway, I alotted another system to play with Teensyduino, and got good results. Very good results, in fact. I appreciate all the nuance and attention to detail you've put into the whole hardware and software package, Paul. As someone who's never used Arudino, I was up and running with a crude port of a C program to Arduino and OctoWS2811 in hours; Teensyduino itself and the loader were painless. Nevertheless, Arduino (and remoting into another machine for development) doesn't fit my workflow; after seeing the hardware in action, I'm motivated again to get back on the project of developing a recipe to build a toolchain from clean sources on Debian Wheezy. I'll still be posting my results as they develop.
 
I generally prioritize my development time on efforts that will bring the greatest benefit to the most people, and also to a lesser extent on things I personally find fun or challenging, and also somewhat towards keeping PJRC running with a sustainable business model..... but mainly so I can do fun and challenging things that benefit lots of people.....

At this very moment, I'm feeling another round of work on the CC3000 WiFi library is probably a better use of my time than another lengthy reply on this Linux software format topic. But rest assured, I do hear and understand these arguments. Long term, I will take this into consideration, but of course it'll be balanced against a lot of other priorities, since there's always only limited development time.
 
Status
Not open for further replies.
Back
Top