11.21.22

Reddit is a Corporate Clique of Censorship and Perception Manipulation

Posted in BSD, Deception, GNU/Linux, Microsoft at 11:13 am by Dr. Roy Schestowitz

Video download link | md5sum 958edc11f9e8571f7347add2095557c8
Reddit Is Not What It Claims
Creative Commons Attribution-No Derivative Works 4.0

Summary: Reddit is mistaken by a lot of people for a “social” place where every ordinary person can share news and views; nothing could be further from the truth

THE issues associated with Reddit have been covered here many times before. Among them: last month's comment on censorship and deceit in Reddit, Microsoft AstroTurfers in Reddit, and covert censorship on Reddit even 7+ years ago.

Reddit isn’t an extension of reality but a filter. It actively suppresses certain points of view on behalf of paying clients such as Microsoft and Bill Gates. It also posthumously exploits Aaron Swartz by lying about him.

“Reddit isn’t an extension of reality but a filter.”Someone has noted that people oughtn’t “use Reddit for Linux or BSD related questions”. This was quite a few months ago and “[t]his is not unique to Reddit,” insists the author, “but it generally relates to many social [sic] places on the Internet, specifically those with point based voting. By the very nature by which these point based places work, they not only attract, but often nurture the most hollow and miserable people. Reddit and other places like it are often toxic and superfluous.”

Perception manipulation or Perception Management (pseudo-technical term) is what’s sooner or later becoming the business model.

All social control media is inherently toxic and undesirable. Later on today we’ll publish another article and video about the antisocial TikTok — a network of exploitation that took such things to new levels. █

Permalink Leave Your Comment Mail Send this to a friend

07.27.22

Microsoft’s Crimes Against the Competition, Notably BSD and GNU/Linux, Persist Albeit Disguised as ‘Security’ (UEFI ‘Secure’ Boot, TPM, Pluton…)

Posted in BSD, Deception, GNU/Linux, Microsoft, Security, Windows at 6:33 pm by Dr. Roy Schestowitz

Video download link | md5sum fa8de7ae67136fb0cf4c4ab97d0ee0ed
Attacking BSD and Linux in Name of Security
Creative Commons Attribution-No Derivative Works 4.0

Summary: Microsoft’s so-called “encryption” (with back doors) is the latest Trojan horse by which to prevent dual-booting with GNU/Linux (or just booting GNU/Linux at all!) and it’s part of Microsoft’s delaying tactics as the share of Windows rapidly decreases, giving way/rise to BSD and Apple’s stuff, along with GNU/Linux and the Gentoo-based ChromeOS

THE Linux hawks already know that UEFI ‘secure’ boot is a scam and not a particularly new scam, either. The warnings about this approach were voiced more than 20 years ago [1, 2], but names have changed somewhat, e.g. "Pluton". The people who want us to embrace such fake ‘security’ are either lying or exceptionally dumb. One example of that is Matthew Garrett, who never studied security and compensates for his insecurities by defaming people who know better. No wonder such a scam is mostly promoted by people who don’t even have a Bachelors degree in a computing-related discipline.

As noted in the video above, they belatedly come to grips with the fact that Microsoft’s so-called “encryption” (back doors [1, 2]) is used by Microsoft against Linux. It was never about security or privacy, it’s a false promise.

Chris Murphy, at ICBM’s (IBM’s) fake ‘community’, writes that “Windows 10/11 increasingly enables Bitlocker (full disk encryption)” and points out that this is causing problems for the “future of dual booting Windows and Fedora”; calling it “full disk encryption” is misleading as there are back doors. What sort of “encryption” is that? People who call it “full disk encryption” are relaying misinformation and unwittingly attack Linux, along with other “useful idiots” who pretend it’s in the name of “security”. It’s not. It never was.

“Without antagonism, things will continue to worsen.”There’s now a long discussion thread about this in Phoronix, which is sponsored by AMD gifts. Don’t forget that AMD is a foremost proponent of Microsoft lockdown at chip level (“Pluton”). We used to respect and cite Phoronix, but lately Phoronix became a WSL apologist. It’s a site that thinks Microsoft entering Mesa is “good” (it’s for WSL, i.e. for an attack on GNU/Linux).

It’s also curious that ICBM (IBM) brought up this issue. ICBM has long loved TPM/Palladium, so don’t expect Red Hat to put up any meaningful resistance to what Microsoft does in order to de facto ban Linux. Heck, Red Hat was the employer of the “engineer” (Garrett) who put the Trojan horse there in the first place, conflating control by Microsoft with “security”. He helped Microsoft thwart antitrust action.

As MinceR put it today: “once again, we see how Microsoft “loves” Linux…”

There has been lots of evidence already that UEFI only makes security worse, not better. It also locked MinceR out of his own computer a couple of weeks ago.

Microsoft wants to herd people into Windows and then say it “supports” ‘Linux’ whilst in fact alluding to WSL. We need to speak out against it. Without antagonism, things will continue to worsen. █

Permalink Leave Your Comment Mail Send this to a friend

01.31.22

Avoiding Strings and Bear Traps: OpenBSD (or Any Other Project Which Already Self-Hosts Its Code) Does Not Need Microsoft’s Money or GitHub’s ‘Free’ Hosting

Posted in BSD, Free/Libre Software, Microsoft at 1:47 pm by Dr. Roy Schestowitz

Video download link | md5sum 0283e608a78e3353c7946c8f0261bddb
Self-Determination for OpenBSD
Creative Commons Attribution-No Derivative Works 4.0

Summary: OpenBSD — like Linux (kernel.org) — has full control of its code; a mirror in GitHub (in theory everybody can create one, but that mirror can be disregarded completely) would add nothing of practical value to the OpenBSD project or its technical integrity

IN “Microsoft GitHub Exposé — Part XVI“ (published hours ago) we offered a ‘modest proposal’ or remarked on OpenBSD’s risk of being ‘captured’ by Microsoft and its proprietary software prison. We wrongly emphasised copyleft aspects or were misguided to stress the risk of plagiarism through Copilot, despite knowing that many BSD developers don’t really care about such matters (even where attribution is required).

“…OpenBSD is the sort of project that tends to attract geeks, not so-called ‘normies’ (for development), and GitHub has a large pool of “low-quality” code, as people in the OpenBSD mailing lists have correctly pointed out.”As a result of some input I’ve decided to do a quick video to explain the greater factor for OpenBSD to consider; it’s about loss of autonomy, including the loss of freedom of expression. Microsoft recently became notorious for its misuse of power over projects which use GitHub for hosting. Microsoft confiscates projects from the original developers, it silences Microsoft critics, and it does all sorts of other nasty things. If OpenBSD truly values its freedom (it does!), then it will fully appreciate its existing control of the whole development pipeline. There’s little or almost nothing to be gained by opening up to GitHub; OpenBSD is the sort of project that tends to attract geeks, not so-called ‘normies’ (for development), and GitHub has a large pool of “low-quality” code, as people in the OpenBSD mailing lists have correctly pointed out.

“When following the thread,” a person told us about the E-mail discussion, “it is important to keep track of who is a developer, and thus speaks with authority, and who is on the outside.”

As we noted earlier today, this problem is a growing problem that Linux and BSDs have in common. █

Permalink Leave Your Comment Mail Send this to a friend

Microsoft GitHub Exposé — Part XVI — The Attack on the Autonomy of Free Software Carries on

Posted in BSD, Deception, Free/Libre Software, Microsoft at 8:13 am by Dr. Roy Schestowitz

Series parts:

GitHub: Where everything comes to die

Summary: In spite of clear misuse of code and of copyrights, some people are trying to export OpenBSD to Microsoft; maybe they’re ill-equipped with facts, so here’s a much-needed (and very timely) discussion of some of the issues at stake

A NUMBER of weeks from now Balabhadra (Alex) Graveley will be in court again (arrest record here). He’s a big part of the attack of Free software — an attack that he has helped his “best friend” (his words) Nat Friedman with. But today we leave Graveley aside and instead focus on the toxic legacy of his work.

As we noted earlier in the series, Graveley enabled plagiarism disguised as “Hey Hi” (AI). Graveley himself has quite a history with plagiarism, as we explained in earlier parts of the series.

“GitHub was never about sharing. It’s about hoarding, controlling and censoring aside.”It’s therefore imperative that all Free software projects think twice or thrice before “mirroring” anything in GitHub; yet more, they might as well be very wise to at least consider removing any existing mirrors. A mirror at GitHub is basically a major legal liability.

GitHub was never about sharing. It’s about hoarding, controlling and censoring aside. It wants to just swallow everything and then add some vendor lock-in such as “Issues” (with uppercase “i”; it’s like a brand, a proprietary extension to Git for bug reports that Microsoft controls and won’t let you export, at least not easily).

We recently grew concerned about efforts by unknown persons to ‘outsource’ OpenBSD to Microsoft or at least make babysteps towards that. As a reminder, Microsoft began offering funding for OpenBSD when the project was desperate for money. This is a well-documented fact and we wrote about it in 2015 when it started [1, 2]. Microsoft started this ‘funnelling’ of cash (a very high level of sponsorship) around the same year "Microsoft loves Linux" started as a ruse to Microsoft hijacking a large chunk of Free software projects by taking over GitHub (which it had started ambushing the prior year). At the moment Microsoft is listed as “Gold: $25,000 to $50,000″ (see “Microsoft Corporation”), but back then it wanted to port parts of OpenSSH to Windows, irrespective of the security lapses and back doors in Windows. As our associate put it, “Microsoft tossed them some chump change; it’s a large sum for openbsd, but for a marketing company [Microsoft] it’s so small an amount that probably no one needed to sign off on it.” Among those who donate to the OpenBSD Foundation we see Gulag (at the top), but at least Gulag isn’t promoting something like Windows or GitHub (proprietary). No project really needs GitHub; it’s just a brand and a trap. Alternatives include Sourcehut, Codeberg, and of course self-hosting with something like Gitea (we’ve coded our own in Gemini Protocol). Also viable but less freedom-oriented are Gitlab and Bitbucket, though our associate is “not sure SourceForge is still worthy” as it had its share of scandals and trust issues.

“As a reminder, the people from Microsoft do not limit themselves to the BSDs.”For Microsoft, any control over any BSD would usher in so-called ‘features’ that would mostly be beneficial to Microsoft and to Windows. There’s already discussion in progress about unwanted features that can add bloat and/or compromise security/readability (those two things are connected; the code can become less elegant and thus a lot more risky).

“We had two Gold contributors in 2020 Camiel Dobbelaar and Microsoft,” says this page in the OpenBSD site.

As a reminder, the people from Microsoft do not limit themselves to the BSDs. They had a go at Linus/Linux as well. Microsoft employees inside the Linux Foundation‘s Board, together with Microsoft operatives inside the media, tried to push Linux towards GitHub about 1.5 years ago (we wrote many articles about it back then).

Torvalds pointed out, albeit not so explicitly, that “contributions” (so-called ‘PRs’) from GitHub would likely come from people who don’t know how to use Git and E-mail, which means that the quality of the code is low and origin/motivation suspect. Didn’t we learn enough already from the University of Minnesota debacle?

“There’s moreover the risk of putting a foot in Microsoft’s doorstep (or vice versa), letting momentum be built up in the wrong platform — a platform you do not actually control, as noted by Blender well before Microsoft had ambushed GitHub (2014) and then bought it (2018).”As a rule of thumb, opening up to more people (when more code does not necessarily mean “better”) isn’t a measure of success, especially if it’s something like a kernel where security is paramount.

There’s moreover the risk of putting a foot in Microsoft’s doorstep (or vice versa), letting momentum be built up in the wrong platform — a platform you do not actually control, as noted by Blender well before Microsoft had ambushed GitHub (2014) and then bought it (2018). Remember what Blender’s ‘daddy’ Ton Roosendaal wrote.

Well, Copilot, as noted in earlier parts (we’ll come to that again some time later) will enable people to plagiarise OpenBSD code without even being aware of it. Don’t forget what Intel did to MINIX code, which was licensed as non-reciprocal. The user-hostile M.E. was secretly crafted using MINIX code; no credit or notice was given.

Thankfully, there’s some resistance to the few entrants who foolishly think “new blood” (not just blood) would come through Microsoft’s proprietary GitHub:

On Fri, Jan 21, 2022 at 11:42:08AM -0600, joshua stein wrote:
> Maybe we can do something radical like enable GitHub pull requests 
> to let people submit changes against the ports repo on GitHub

Cringe.

I sincerely hope that this doesn't happen.

Just look at the typical quality of the projects hosted on GitHub, and
you'll see how relying on a set of third-party managed tools to do your
work instead of taking the time to learn the basic tools, (tar, diff,
an email program, etc), yourself can lead to laziness and poor quality.

If people can't be bothered to do things themselves or make their own
tools to automate a process, how dedicated are they likely to be?

> I believe that the GitHub repo can be configured to also email 
> ports@openbsd.org on any submissions/comments there, so the mailing 
> list would still be in the loop on everything for anyone that 
> doesn't want to use GitHub.

So the mailing list is going to be flooded with automated mails from
GitHub, that become tedious, leading people to just skim over them
or OK them without really reviewing the content.

Honestly, I think we all want to keep the quality of the ports tree
as high as possible, and if learing to use tar and diff as a barrier to
entry for some people is doing that, I suggest we continue as we are.

Here’s more:



On 21/01/22 11:42 -0600, joshua stein wrote:
> On Fri, 21 Jan 2022 at 18:29:27 +0100, Marc Espie wrote:
> > In my opinion, our main issue is the lack of new blood.
> > 
> > We have chronically fewer people who can give okays than ports waiting.
> > 
> > One big "meta" stuff that needs doing is pointing out (especially from
> > new guys) what can be improved in the documentation of the porting process...
> > sometimes pointing people in the right direction.
> > 
> > Informal poll: what thing weirded you guys out the first time you touched
> > OpenBSD ports coming from other platforms.
> > 
> > What kind of gotcha can we get rid of, so that "new ports" will tend to
> > be squeaky clean, infrastructure-wise, and ready for import.
> > 
> > Maybe we'd need an FAQ from people coming from elsewhere explaining the
> > main differences to (say) deb, rpm, freebsd ?...
> 
> Using CVS and dealing with tarballs is probably pretty 
> ancient-feeling for many outsiders.  I don't know that more 
> documentation is really the problem.
> 
> I personally tend to ignore most ports@ emails that aren't diffs I 
> can easily view in my e-mail client because it's a hassle to save 
> the attachment, tar -t it to see what its directory structure is, 
> untar it in the proper place, try to build it, then provide feedback 
> by copying parts of the Makefile to an e-mail or doing some other 
> work to produce a diff.
> 
> Maybe we can do something radical like enable GitHub pull requests 
> to let people submit changes against the ports repo on GitHub, do 
> review and feedback on those on GitHub, and once it's been approved 
> by a developer, that developer can do the final legwork of 
> committing it to CVS and closing the pull request (since we can't 
> commit directly to the Git repo).
> 
> I believe that the GitHub repo can be configured to also email 
> ports@openbsd.org on any submissions/comments there, so the mailing 
> list would still be in the loop on everything for anyone that 
> doesn't want to use GitHub.
> 

Big NO. We use CVS, deal with it. If you want to help people who are lazy
to cvs diff and send an email, write a script that that does a submission
for them automatically in a format we prefer.

If you want to use git, fine, you can send git diffs to the mailing list.

If someone does not have enough brain to figure out how to do things our way
then we probably do not want that submission either.

On the other hand, I think the issue here is not the version control system
or the development method we are using, but the lack of interest or need.

The openbsd ports and packages are quiet good compared to others and things
just work. There is always room for imrovement of course.

Marc Espie received this reply:

On Fri, 21 Jan 2022 at 18:29:27 +0100, Marc Espie wrote:
> In my opinion, our main issue is the lack of new blood.
> 
> We have chronically fewer people who can give okays than ports waiting.
> 
> One big "meta" stuff that needs doing is pointing out (especially from
> new guys) what can be improved in the documentation of the porting process...
> sometimes pointing people in the right direction.
> 
> Informal poll: what thing weirded you guys out the first time you touched
> OpenBSD ports coming from other platforms.
> 
> What kind of gotcha can we get rid of, so that "new ports" will tend to
> be squeaky clean, infrastructure-wise, and ready for import.
> 
> Maybe we'd need an FAQ from people coming from elsewhere explaining the
> main differences to (say) deb, rpm, freebsd ?...

Using CVS and dealing with tarballs is probably pretty 
ancient-feeling for many outsiders.  I don't know that more 
documentation is really the problem.

I personally tend to ignore most ports@ emails that aren't diffs I 
can easily view in my e-mail client because it's a hassle to save 
the attachment, tar -t it to see what its directory structure is, 
untar it in the proper place, try to build it, then provide feedback 
by copying parts of the Makefile to an e-mail or doing some other 
work to produce a diff.

Maybe we can do something radical like enable GitHub pull requests 
to let people submit changes against the ports repo on GitHub, do 
review and feedback on those on GitHub, and once it's been approved 
by a developer, that developer can do the final legwork of 
committing it to CVS and closing the pull request (since we can't 
commit directly to the Git repo).

I believe that the GitHub repo can be configured to also email 
ports@openbsd.org on any submissions/comments there, so the mailing 
list would still be in the loop on everything for anyone that 
doesn't want to use GitHub.

They seem to rather conveniently overlook a very big problem; the moment they put their code in GitHub they give Microsoft implicit if not explicit permission to misuse this code. In the case of copyleft/GPL-licensed software, it facilitates widespread GPL violations/infringement of one’s code, without even being aware of it. That’s the dimension (mission creep) added without prior warning some time last year. You cannot opt out. Don’t people take that as a clear warning, universally (irrespective of a project’s licence)?

“They seem to rather conveniently overlook a very big problem; the moment they put their code in GitHub they give Microsoft implicit if not explicit permission to misuse this code.”GitHub needs to go the way of the dodo, not adopted for so-called ‘mass appeal’ (a fallacy; coding isn’t for the masses at the level of kernel).

In the words of our associate, “the e-mail messages are myopically focused on the technical aspects as per the public lists; what is equally important is to observe reuse of Microsoft tactics to disrupt and control” (a subject we wrote about a very long time ago, partly based on internal Microsoft documents).

Our associate concludes that “it is important to highlight the control that self-hosting of version control and bug tracking gives. Also for those that do not want to or cannot self-host, then there are many alternatives which are far better than Microsoft GitHub. See the list from earlier.” █

“A couple of years ago this guy called Ken Brown wrote a book saying that Linus stole Linux from me… It later came out that Microsoft had paid him to do this…”

–Andrew S Tanenbaum, father on MINIX

Permalink Leave Your Comment Mail Send this to a friend

01.09.22

Why Kristall (the Gemini Client) Has Become My Default Browser (It Does Web Sites, Too)

Posted in BSD, Free/Libre Software, GNU/Linux at 11:39 am by Dr. Roy Schestowitz

Video download link | md5sum 90c0aa5859cd25ad1e0e3e75e2364e97
Kristall on Debian GNU/Linux With KDE
Creative Commons Attribution-No Derivative Works 4.0

Summary: Kristall is a very impressive piece of software, developed very actively (last commit 1.5 months ago) by Felix “xq” Queißner

LAST night I installed the Qt-based Kristall, which had become trivial to install on GNU/Linux and other platforms. No need to compile anything, just to download a single file and then run it.

“Some distros even added it to their software repositories.”In the video above I show some of the features that in my humble opinion make Kristall better than Lagrange, at least for KDE users. Kristall integrates better into the desktop, it can handle Web pages in a rudimentary (and relatively privacy-safe) fashion, it can handle multimedia such as images, and it uses the term “free software”. It uses a copyleft (GPL 3.0) licence and we hope it’ll decide to delete GitHub, then use Free software for Git hosting. Felix “xq” Queißner did some impressive job with this software, which we warmly recommend. It’s available for Windows, GNU/Linux, MacOS X and various BSDs. Some distros even added it to their software repositories. ArchLinux (via AUR) and Void Linux are among those in the GNU/Linux camp; OpenBSD has that as well. █

Permalink Leave Your Comment Mail Send this to a friend

03.07.21

How To Deal With Your Raspberry Spy — Part V: All The Rest

Posted in BSD, Free/Libre Software, GNU/Linux at 2:19 am by Guest Editorial Team

By Gavin L. Rebeiro

Cover

Copyright

1 Acknowledgements

2 Introduction

2.1 Prerequisite Knowledge
2.2 Apparatus

3 Fundamentals

3.1 Communication
3.2 Kernel Ring Buffer
3.3 Drivers
3.4 Operating Systems
3.5 Special Files

4 Doing The Task

4.1 Preparing The Boot Media
4.2 Connecting Physical Components
4.3 Using Picocom
4.4 OS Installation

5 YOU ARE HERE ☞ Thanks

6 OpenPGP Key

A Malicious Hardware

B Linux Kernel Source Tree Analysis

C Digital Multimeter Tests

Summary: The final part of a series on liberating the Raspberry Spy from an untrustworthy OS that secretly adds Microsoft keys and proprietary software repositories of Microsoft (see Part I, Part II, Part III, and Part IV)

THIS part is mostly addenda.

Chapter 5: Thanks

We’d like to take the opportunity to thank you, the reader. We believe everyone deserves a computing education; however, the topics of computing freedom and how computing affects our basic human rights are neglected in computing education today; at E2EOPS PRESS we strive to change this. Our goal is to inform, educate, and inspire. Computing is also a lot of fun! We want everyone to experience the joys of computing. We hope you enjoyed this issue of our periodical as much as we enjoyed bringing it to you!

Our work requires research, equipment, and infrastructure to deliver. We strive for the best quality in all we do. If you would like to support us, there are several ways you can do so. Any support we get from you enables us to bring you the best we possibly can.

We distribute all our periodicals via peer-to-peer technology. There are things we publish that some people don’t want out in the open. Thus, if you can contribute to the peer-to-peer sharing, you would be helping us out immensely!

If you would like to support us by making a cash donation, we have a Paypal account that you can send donations to:

• https://www.paypal.com/donate?hosted_button_id=B5VPZJBKLL2S6

For those that like to use QR codes, you can use the following QR code to donate to our Paypal.

If you’d like to donate in some other way, you can send an email to donations@e2eops.io and have a chat with us about it.

For encrypted communications, you can use the OpenPGP Key provided in chapter 6.

And, as always, happy hacking!

Chapter 6: OpenPGP Key

At E2EOPS PRESS, we take your privacy seriously. If you want to send us an encrypted message, you can do so with the following OpenPGP key:

Appendix A: Malicious Hardware

While doing research for this issue, I often ran into USB-to-UART bridges of the “FTDI” variety. Upon further digging,
an ugly bit of history surfaced. The FTDI modules have a reputation for sabotaging people’s hardware.

Sadly, we live in a world where this sort of thing is the norm. Pay close attention to the products you buy. You need
to practice vigilance in order to defend your computing freedom. Remember, you have control over your wallet. Don’t support malicious actors, if you have the choice (in this case you almost certainly do).

Appendix B: Linux Kernel Source Tree Analysis

The directory trees rooted at /sys and /proc are mapping of Linux kernel data structures and interfaces; you can read up on these in the Linux kernel source tree from:

• linux/Documentation/filesystems/sysfs.rst
• linux/Documentation/filesystems/proc.rst

You don’t have a local, up-to-date, copy of the Linux kernel source tree? You really should. Note that some of this
documentation is hilariously out-of-date; use the git log on a file to see the last time parts of a file was given an up-date:

 $ git log -p filename

This should give you what you need. Since the Linux kernel is developed with Git, it pays dividends to learn at least
the fundamentals of Git.

It’s a frequent occurence that people ask me how to make sense of the Linux kernel. You need the following prerequisites:

• A familiarity with the C programming language. The syntax is easy to pick up for most people because a lot of the popular programming languages in use today are based on C. Most operating systems today are written in C; the same goes for embedded systems. If you don’t have a good grasp of C, you can kiss any hopes on working on this stuff goodbye. C is not as hard as people make it out to be; just look at real code and don’t waste your time on pointless exercises. Start with the smallest real-world programs you can find – like echo(1); once you get the simple stuff, get more ambitious and look at more complicated things. The following resource is also invaluable to the novice C programmer: C reference.

• To make sense of other people’s C code (particularly spaghetti), you need a good source code tagging system. I recommend GNU Global because it works well on most Bourne Shells. Using GNU Global will enable you to look up definitions for things like functions and structs in C code easily.

• You need to learn GNU Autotools to automate the workflow of building makefiles and such. The old “./configure && make && make install” ritual stems from GNU Autotools. Learn it and embrace it. You can build truly portable software once you learn the fundamentals of GNU Autotools. You won’t understand head nor tail of embedded programming with the Linux kernel (and several other things) unless you have a grasp on the rudiments of GNU Autotools.

• Whether you like it or not, Git is an essential part of Linux kernel development. Without a firm grasp of Git fundamentals, you won’t get anywhere. While you’re at it, you should look into the standalone utilities GNU diff and GNU patch; Git is essentially an abstraction on top of these tools.

You should now have enough pointers to begin acquiring knowledge about how to make sense of the Linux kernel (and a whole lot of other things). The aforementioned prerequisites abstract to OS and embedded development and being an effective operator of your computer. These are the tools you really need to know to get anywhere.

All of this stuff applies to several other things. Once you start learning them, you’ll see what I mean. It really isn’t a lot to take in. Knowledge of this stuff will last you a lifetime. Don’t fall for the IDE X or framework Y bullshit; those are moving targets and are deliberately broken to keep people reliant on the dictators for “support”. Educate yourself; it’s the only path to computing freedom. Become an operator; don’t be a mindless consumer.

Appendix C: Digital Multimeter Tests

As always, follow the instructions in the manual of your Digital Multimeter (DMM). RTFM extra carefully, otherwise you end up with magic smoke (why you were recommended spares).

There really are only two simple things you need to test on your UTUB:

• Voltage coming out of the UTUB TX and RX pins.

• Current from the TX and RX pins.

There’s not really much more to be said here. The one bit of general advice is to use a breadboard and some jump wires, if you have access to one; crocodile clip test leads for your DMM also make life easier. Basically, try making sure you don’t short circuit your UTUB by having DMM test leads too close to each other.

Make sure the test leads are plugged into the appropriate terminals of your DMM. Always make sure the fuse of a DMM terminal is sufficient for what you’re measuring.

You can find GPIO voltage specifications of the Raspberry Spy in the official GPIO guide. Make sure you cross-check with the right CPU model’s datasheet.

You may end up needing to buy some resistors to get the right voltage and current. You can find background information useful to the novice hardware hacker from the excellent Sparkfun tutorial on pull-up resistors; follow the appropriate links to fill out gaps in your knowledge. However, most UTUBs are usable out-of-the-box (OOTB) so you shouldn’t really have much issue here. But it doesn’t hurt (unless you zap yourself) to get a bit of electronics background knowledge since you’re playing around with wires and electricity!

Index

[Editor’s note: this corresponds to the PDF version of the document]

lsblk -f, 28
sd(4), 34
/dev/ttyUSB0, 23
/proc, 43
/sys, 43
FTDI, 41
apropos(1), 18
cmdline.txt, 29
config.txt, 29
console=fb, 29
cp210x, 23, 24
dmesg(1), 18-20, 22, 25
echo(1), 44
enable_uart=1, 29
grep(1), 20
lsmod(8), 20, 25
lspci -k, 26
lsusb -t, 26
mknod(1), 24
modinfo(8), 19, 20, 23
picocom(1), 17, 24, 32,
33, 35
ttyUSB0, 23, 24
usbcore, 23
usbserial, 23
DMM, 15
EHCI, 20
HCI, 20
idProduct, 25
idVendor, 25
jump wires, 14
kernel ring buffer, 18
KRB, 18
OHCI, 20
PCI, 20
QC, 15
textttmodinfo(8), 25
UART, 17
UTUB, 13, 14 █

Permalink Leave Your Comment Mail Send this to a friend

03.06.21

How To Deal With Your Raspberry Spy — Part IV: Doing The Task

Posted in BSD, GNU/Linux, Hardware, Kernel at 7:59 pm by Guest Editorial Team

By Gavin L. Rebeiro

Cover

Copyright

1 Acknowledgements

2 Introduction

2.1 Prerequisite Knowledge
2.2 Apparatus

3 Fundamentals

3.1 Communication
3.2 Kernel Ring Buffer
3.3 Drivers
3.4 Operating Systems
3.5 Special Files

4 YOU ARE HERE ☞ Doing The Task

4.1 Preparing The Boot Media
4.2 Connecting Physical Components
4.3 Using Picocom
4.4 OS Installation

5 Thanks

6 OpenPGP Key

A Malicious Hardware

B Linux Kernel Source Tree Analysis

C Digital Multimeter Tests

Summary: We now spell out the steps taken to actually replace the Raspberry Pi OS with something more trustworthy (for background see Part I, Part II, and Part III)

We’ve now covered enough ground to make the installation of
NetBSD on our Raspberry Spy (over our UTUB) a relatively painless matter.

Let’s go through the process in little steps.

4.1 Preparing The Boot Media

I’m going to grab the appropriate NetBSD image by taking hints from the following:

• NetBSD/evbarm on Raspberry Pi tells us everything we need to know to pick the right image. All the sections here related to booting are worth reading at least once. Also read sections about consoles and serial consoles at least once.

• Raspberry Pi boot modes is useful if you want to dig deeper into the booting mechanisms of the Raspberry Spy. USB mass storage boot is particularly useful for booting off USB. Trust me, you don’t want to muck around with SD cards; they’re a nightmare.

• NetBSD/evbarm can be referenced for general information about NetBSD on ARM boards.

The above links should give you a good idea of what’s going on and what needs to be done with regards to putting a NetBSD on a boot media that goes into a Raspberry Spy.

Let’s go through a concrete example.

My Raspberry Spy is of the model “3 B+” variety so I’m dealing with an ARM64 CPU architecture. We’ll follow along the instructions outlined in Installation procedure for NetBSD/evbarm; pay close attention to the section “NetBSD/evbarm subdirectory structure”; I follow these instructions as I explore Index of pub/NetBSD/NetBSD-9.1/evbarm-aarch64/.

I grab the appropriate image like so:

$ mkdir ~/Downloads/netbsd
$ cd ~/Downloads/minted
$ wget https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.1/evb c
 → arm-aarch64/binary/gzimg/arm64.img.gz

Now that we’ve got the image, we can write it to our boot media. I’m going to assume you have an appropriate reader already plugged into your GNU/Linux box. I’ve got my USB thumb drive as “/dev/sdg” on my system. Use the right block device file on your system¹. We base our procedure along the lines of “Installation for ARMv7 and AArch64 devices with U-Boot” section from Installation procedure for NetBSD/evbarm:

$ gzip --decompress --keep arm64.img.gz
# dd if=arm64.img of=/dev/sdg bs=1M conv=sync
 → status=progress
$ lsblk -f | grep sdg

We’re going to ignore the minutiae of writing to block devices, bootloaders, and other adjacent topics related to the utilities we just used; that’s left for another time. We care about learning how to use a serial console in this project so we must stay focused on our primary target.

We’re going to have a look at how to make a serial install possible via some editing of the “cmdline.txt” file that now resides in the boot media (on the boot partition which is of type “vfat”):

# mkdir /media/netbsd_image
# mount /dev/sdg1 /media/netbsd_image
# grep "console" < cmdline.txt
# root=ld0a console=fb
# grep "enable_uart" < config.txt
# enable_uart=1

The “console=fb” part is to get out OS image to use the HDMI output. We will get rid of that string from the file “cmdline.txt”. Who needs that anyway? One way to do it²:

# ed cmdline.txt
21
,p
root=ld0a console=fb
1
root=ld0a console=fb
s/console=fb//
,p
root=ld0a
wq
11
# echo ",p" | ed cmdline.txt
11
root=ld0a

Remember to check your edits!

We also ensure that “enable_uart=1” is set in the file “config.txt”:

# echo ",p" | ed config.txt
82
arm_64bit=1

kernel=netbsd.img
kernel_address=0x200000
enable_uart=1
force_turbo=0

Everything looks good! Additional useful information on the Raspberry Spy UART can be found in UART configuration. Pretty self-explanatory. That wasn’t so hard. Was it? Note that the following links document the files we’ve been messing around with:

• The Kernel Command Line
• config.txt

It’s a good idea to back up the state of your image, at this point³. We can now safely unmount our boot media and get on with the project:

# cd ~
# umount /media/netbsd_image

We change directory, before we unmount, so that we don’t get any “device busy” errors.

We’ve now got our boot media ready. Onwards!

4.2 Connecting Physical Components

Before you power up your UTUB, you should really check that the pins are working properly. The very basic test you should do is to check that the right voltage is being supplied. Check out Appendix C.

The pins on our UTUB and Raspberry Spy that we’re interested are the following:

• Raspberry Spy: Pin6 (Ground), Pin8 (GPIO14, TXD), Pin10 (GPIO15, RXD). You can find the layout in the official GPIO page.

• UTUB: I’ve got a CP2104 UTUB so I’ve got to only worry about the pins marked TX, RX, and GND. I have other pins on the module but they’re not relevant for this task.

We won’t be using any of the voltage pins on the boards because it’s more prone to errors. Just use the USB power supply that comes with your Raspberry Spy.

Don’t plug anything into power for the following sequence. Connect the jump-wires like so:

• Ground on UTUB to Ground (Pin6) on Raspberry Spy.

• TX on UTUB to RX (Pin10) on Raspbery Spy.

• RX on UTUB to TX on (Pin8) Raspberry Spy.

“We won’t be using any of the voltage pins on the boards because it’s more prone to errors.”Don’t make the rookie mistake of matching TX with TX and RX with RX; TX always goes to RX and RX always goes to TX. Keep this in mind, always, when working with UARTs. Colour-coding your jump-wires helps.

We’ll just go over the order of attaching the stuff to do with power on our devices:

• Attach the USB power adapter to the Raspberry Pi without plugging the adapter into the power outlet.

• Attach the UTUB to your GNU/Linux box.

• Attach your USB power adapter to your power outlet.

The logic for the above procedure is that you can ensure that your serial interface is up and running before you start getting input from your Raspberry Spy.

4.3 Using Picocom

Using picocom(1) is simple. All we need to do is select the correct baud rate and give the right device file as a parameter to picocom(1).

I’ll give you an extract from the manual page to enlighten you:

In effect, picocom is not an "emulator" per-se. It is a
simple program that opens, configures, manages a serial
port (tty device) and its settings, and connects to it
the terminal emulator you are, most likely, already
→ using
(the terminal window application, xterm, rxvt, system
console, etc).
When picocom starts it opens the tty (serial port)
given as its non-option argument. Unless the
--noinit option is given, it configures the port to
the settings specified by the option-arguments (or
to some default settings), and sets it to "raw"
mode. If --noinit is given, the initialization and
configuration is skipped; the port is just opened.
Following this, if standard input is a tty, picocom
sets the tty to raw mode. Then it goes in a loop
where it listens for input from stdin, or from the
serial port. Input from the serial port is copied
to the standard output while input from the standard
input is copied to the serial port. Picocom also
scans its input stream for a user-specified control
character, called the escape character (being by
default C-a). If the escape character is seen, then
instead of sending it to the serial-device, the
program enters "command mode" and waits for the next
character (which is called the "function
character"). Depending on the value of the function
character, picocom performs one of the operations
described in the COMMANDS section below.

We use “C-a C-x” (Ctrl+a followed by Ctrl+x)⁴ to tell picocom(1) to exit; for more, RTFM; in particular, pay close attention to the “COMMANDS” section.

Make sure you’ve set up all the physical connections, as advised. It’s time to attach our UTUB to our GNU/Linux box and then make sure we invoke picocom(1) correctly:

# picocom --baud 115200 /dev/ttyUSB0
picocom v3.1

port is         : /dev/ttyUSB0
flowcontrol     : none
baudrate is     : 115200
parity is       : none
databits are    : 8
stopbits are    : 1
escape is       : C-a
local echo is   : no
noinit is       : no
noreset is      : no
hangup is       : no
nolock is       : no
send_cmd is     : sz -vv
receive_cmd is  : rz -vv -E
imap is         : 
omap is         :
emap is         : crcrlf,delbs
logfile is      : none
initstring      : none
exit_after is   : not set
exit is         : no

Type [C-a] [C-h] to see available commands
Terminal ready

It really is that simple. You’ve now got a serial terminal ready and listening.

4.4 OS Installation

Now that you’ve got a serial terminal operational, all we have to do to install NetBSD on the Raspberry Spy is to plug the USB power adapter into the power outlet. Keep a close eye on what goes on in the output of your serial terminal:

...
[   7.4246937] root device:
[  11.6252523] use one of: mue0 sd0[a-p] ddb halt reboot
[  11.6252523] root device: sd0
[  13.9755661] dump device (default sd0b):
[  15.7257992] file system (default generic):
...

You should be promoted to pick a root device. I pick “sd0” as it’s the first ’disk’ offered by NetBSD (which can only be my boot media)⁵. I go for the suggested defaults, for everything else. No need to overcomplicate things, at this point.

You will probably see your Raspberry Spy reboot once or twice during the OS install process. Just pass the same parameters for the boot device, and you should be good to go.

Eventually, you should be met with the following:

...
NetBSD/evbarm (arm64) (constty)
...

login:

If you login as “root”, you should have a nice login shell presented to you.

And we are done! You’ve successfully done some tinkering over a serial terminal. That wasn’t so hard. Was it? You can shutdown your device (halt the OS) like so:

# shutdown -p now
...
[   910.5814809] The operating system has halted.
[   910.5814809] Please press any key to reboot.

You can now disconnect the power supply from your Raspberry Spy. Then just send “C-a C-x” to picocom(1); after which, you should see:

...
Terminating...
Thanks for using picocom
#

Welcome to the world of serial terminals; hack your heart out! █
____
¹ The command lsblk -f should help you out here. Don’t wipe the wrong device by accident.
² If you use another text editor, that’s fine. You really should learn ed(1) at some point though, especially if you want to get into embedded systems.
³ At least keep track of the files that you tweaked. If you use some sort of version-control-system, you get bonus points.
⁴ I don’t know why the manual doesn’t bother to explicitly mention that these are GNU-Emacs-style key sequences.
⁵ See the NetBSD sd(4) manpage for details.

Permalink Leave Your Comment Mail Send this to a friend

How To Deal With Your Raspberry Spy — Part III: Fundamentals

Posted in BSD, Free/Libre Software, GNU/Linux at 6:12 am by Guest Editorial Team

By Gavin L. Rebeiro

Cover

Copyright

1 Acknowledgements

2 Introduction

2.1 Prerequisite Knowledge
2.2 Apparatus

3 YOU ARE HERE ☞ Fundamentals

3.1 Communication
3.2 Kernel Ring Buffer
3.3 Drivers
3.4 Operating Systems
3.5 Special Files

4 Doing The Task

4.1 Preparing The Boot Media
4.2 Connecting Physical Components
4.3 Using Picocom
4.4 OS Installation

5 Thanks

6 OpenPGP Key

A Malicious Hardware

B Linux Kernel Source Tree Analysis

C Digital Multimeter Tests

Summary: Following the introductory and preliminary parts (Part I and Part II) we dive deeper into the steps taken to replace the Raspberry Pi’s GNU- and Linux-based OS with something like NetBSD

Now that you know what you need to get started, let’s gently walk through an overview of the fundamental ideas and topics that we’ll be engaging and experimenting with.

The order of topics may seem strange at first but things should make sense as you move on.

3.1 Communication

If we want two computers to communicate, there needs to be some protocol that they both speak.

If we want two computers to communicate, there needs to be a physical medium over which they can communicate.

Almost all computers and their peripherals communicate over USB these days. But when it comes to getting into the nitty-gritty details, you will often find UART humbly serving the same purpose it has for decades of computing. Fortunately for us, almost every embedded system these days supports UART; this includes the Raspberry Spy.

“Why bother with this anachronistic technology? Glad you asked!”We’ll be using our UTUB to install a new OS on our Raspberry Spy over a serial interface (UART). The program that we’ll be using to do this serial communication is picocom(1).

Why bother with this anachronistic technology? Glad you asked! Once you know how to operate something like a UTUB and a program like picocom(1), you can “break into” several devices and modify them how you wish. Routers, motherboards,
embedded systems, etc. all tend to have some sort of serial interface on them. Once you learn the basics, you are equipped to liberate yourself and gain more computing freedom.

But wait. Isn’t all this embedded stuff way too difficult and only for “experts”? HOGWASH! You can do it too. Don’t
fall for the propaganda. You are perfectly capable of doing a bit of serial hacking to liberate your devices. You paid for them, after all. You should be able to do whatever you want with them (and you will). Onwards!

3.2 Kernel Ring Buffer

What on earth is a “kernel ring buffer” (KRB)? Ever heard of dmesg(1)? dmesg(1) is what you use to read the KRB. Not so scary now. Is it?

Why is the KRB important? Well: when you plug in (or out) a device, you can see the messages show up in the KRB. If you learn how to pay attention to the KRB, when you are working with hardware, you will become a lot better at trouble-shooting your own problems. Take strings you don’t understand and plop them into your favourite search engine; try the apropos(1) command as well.

As we progress with our project, we’ll see how to leverage dmesg(1) to our advantage. Learning proper use of dmesg(1)
is an essential skill if you want to improve and maintain your computing freedom; dmesg(1) allows you to demystify the inner workings of your computer and get clues on how to fix problems yourself.

3.3 Drivers

Say you plug in your mouse or keyboard into your computer; or even plug them out. The software responsible for translating the physical signals from the mouse or keyboard, to the intermediary physical devices, to the more abstract layers of your operating system (like stuff you see on the screen) is called the kernel; this is the “Linux” part of GNU/Linux.

The kernel is the layer of software that sits between the physical hardware and the more abstract levels of software that gives you an “operating system”. When you plug in or out your keyboard or mouse, the Kernel has programs which recognise those types of devices and then loads the appropriate software required to use those physical devices; such software are called “device drivers”.

All of the above is a bit vague. Let’s take a look at what this looks like in practice; I’m going to plug out and plug back in my mouse while staring at dmesg(1):

1   # dmesg --human --follow
2   ...
3   [Feb19 17:26] usb 7-4: USB disconnect, device number 2
4   [ +25.036175] usb 7-4: new low-speed USB device number
            → 4 using ohci-pci
5   [ +0.193047] usb 7-4: New USB device found, 
            → idVendor=0461, idProduct=4d81, bcdDevice= 2.00
6   [ +0.000006] usb 7-4: New USB device strings: Mfr=0,
            → Product=2, SerialNumber=0
7   [ +0.000004] usb 7-4: Product: USB Optical Mouse
8   [ +0.007570] input: USB Optical Mouse as 
            → /devices/pci0000:00/0000:00:16.0/usb7/7-4/7-4:1.0/0 c
            → 003:0461:4D81.0005/input/input18
9   [ +0.000303] hid-generic 0003:0461:4D81.0005: 
            → input,hidraw3: USB HID v1.11 Mouse [USB Optical
            → Mouse] on usb-0000:00:16.0-4/input0

We’ll briefly analyse this output and introduce a few important tools in the process.

The first thing to note is this string “using ohci-pci”. It’s time to bring in the Linux-specific tool modinfo(8); let’s take a look at what we’re dealing with:

1 $ modinfo ohci_pci
2   name:        ohci_pci
3   filename:    (builtin)
4   softdep:     pre: ehci_pci
5   license:     GPL
6   file:        drivers/usb/host/ohci-pci
7   description: OHCI PCI platform driver

That output is quite self-explanatory. We see the name of the kernel module; we see that its a builtin kernel module (which means it’s compiled into the kernel). “softdep” stands for soft dependency. We see that the license is GPL. We see the location in the kernel source tree this kernel module resides. And, finally, we see a short description of the kernel module.

I hope, at the point, you’ve realised that “kernel module” is synonymous with “driver”. See? Not that complicated.

So what does this have to do with our USB mouse? Well: when it comes to interfaces, there’s usually a few things that sit between your device and the userspace of your operating system. I’ll leave it as a research project for you to figure out what “HCI”, “OHCI”, “EHCI”, “PCI”, etc. mean.

The next crucial bit of driver information here is the “hid-generic” part; find out what this kernel module does with modinfo(8).

The next thing I want you to do is have a look at the output of the Linux-specific tool lsmod(8); Note the column headers. grep(1) through the lsmod(8) output for the following strings:

• usbhid
• hid_generic
• hid

The “USB HID v1.11 Mouse” from our dmesg(1) output should give us a good idea of what’s going on here. Don’t know what
“USB HID” means? Look it up. Find out what the above kernel modules do, from the stuff you’ve already learned so far.

Let’s take a look at some sample lsmod(8) output:

1 $ cat <(lsmod | head -n 1) <(lsmod | grep hid)
2 Module                     Size Used by
3 mac_hid               16384  0
4 hid_generic           16384  0
5 usbhid                57344  0
6 hid                  135168  2 usbhid,hid_generic

You’ve now got a bit of background knowledge to make sense of what’s going on when you plug things in and out of your GNU/Linux unit.

3.4 Operating Systems

We’re going to be a bit adventurous with our choice of OS to put on the Raspberry Spy. We’re going to go with NetBSD; this is a great OS for embedded systems and one you should be familiar with if you plan on doing any embedded work.

NetBSD is an OS with its own kernel and userspace. Thus, NetBSD runs the NetBSD kernel and NetBSD userspace utilities; this is in contrast to the Linux kernel and GNU userspace (GNU/Linux)¹.

NetBSD is quite a beginner-friendly BSD because it has ample documentation; the fact that NetBSD has the primary focus of portability also means you can learn a great deal about portability from several perspectives.

A side note here. Avoid usage of package managers. They are bad for your freedom; to most people, package managers are entirely opaque systems that turn the computer operator into a mere consumer. Learn how to build your software from source code. This way you see all the dependencies².

The opaque package manager is exactly how the Raspberry Spy Foundation smuggled in spyware into the Raspberry Spy. If you build all your programs from source code, you would be less vulnerable to these espionage tactics³.

You should be the operator of your computer, not a “user”. A “user” is effectively being “used” because they are treated like stupid consumers that get dictated to by other people. Don’t fall for this “user” trap. Be the operator of your computer; take back control; education is the true path to computing freedom.

Note that a lot of these operating systems we’re talking about follow some version of the POSIX specification (with varying degrees of compliance).

3.5 Special Files

It’s important to understand how special files relate to device drivers. What’s a special file? Glad you asked.

Let’s take a look at our friend dmesg(1) as we plug in our UTUB:

1  [Feb22 12:13] usb 7-1: new full-speed USB device number
    → 3 using ohci-pci
2  [ +0.202882] usb 7-1: New USB device found,
    → idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
3  [ +0.000006] usb 7-1: New USB device strings: Mfr=1,
    → Product=2, SerialNumber=3
4  [ +0.000003] usb 7-1: Product: CP2104 USB to UART
    → Bridge Controller
5  [ +0.000003] usb 7-1: Manufacturer: Silicon Labs
6  [ +0.000003] usb 7-1: SerialNumber: 010C48B4
7  [ +0.024088] usbcore: registered new interface driver
    → usbserial_generic
8  [ +0.000010] usbserial: USB Serial support registered
    → for generic
9  [  +0.003272] usbcore: registered new interface driver
    → cp210x
10 [  +0.000025] usbserial: USB Serial support registered
    → for cp210x
11 [  +0.000081] cp210x 7-1:1.0: cp210x converter detected
12 [  +0.010528] usb 7-1: cp210x converter now attached to
    → ttyUSB0

Bit of a mouthful. Let’s break it down into pieces that we can actually digest:

• Take a look at the Linux kernel modules usbcore, usbserial, and cp210x with modinfo(8). Not so scary now. Is it?

• Next, have a look at the line “usb 7-1: cp210x converter now attached to ttyUSB0”. You should understand all the lines leading up to this one; however, we need to do a bit of digging to find out what this whole “ttyUSB0” business is about. We’ll look into some other helpful things in the process.

Here we have a special file called ttyUSB0; So uh where is this file? Let’s see:

1  $ find / -name "ttyUSB0" 2> /dev/null
2  /dev/ttyUSB0
3  /sys/class/tty/ttyUSB0
4  /sys/devices/pci0000:00/0000:00:16.0/usb7/7-1/7-1:1.0/t c
       → tyUSB0
5  /sys/devices/pci0000:00/0000:00:16.0/usb7/7-1/7-1:1.0/t c
       → tyUSB0/tty/ttyUSB0
6  /sys/bus/usb-serial/devices/ttyUSB0
7  /sys/bus/usb-serial/drivers/cp210x/ttyUSB0

The path we really want here is “/dev/ttyUSB0”⁴. Time to do a quick check:

1  $ ls -al /dev/ttyUSB0
2  crw-rw---- 1 root dialout 188, 0 Feb 22 12:13
      → /dev/ttyUSB0

The “c” in “crw-rw–” tells us that this is a character file. The “188, 0” tells us that the “major” and “minor” number, respectively, of this special “character file”. These files are created with mknod(1). The following can be a useful pointer, when you are lost:

1  $ file --mime /dev/ttyUSB0
2  /dev/ttyUSB0: inode/chardevice; charset=binary

Good stuff. We’re getting somewhere. To find a full list of what these major and minor numbers refer to, we can have a look in the Linux kernel source tree:

1  $ less linux/Documentation/admin-guide/devices.txt
2 ...
3  188 char       USB serial converters
4           0 = /dev/ttyUSB0     First USB
                    → serial converter
5           1 = /dev/ttyUSB1     Second USB
                    → serial converter
6             ...
7 ...

That’s that part demystified. Isn’t learning great? Now you know where to get the right numbers if you want to use mknod(1) manually on GNU/Linux systems⁵.

Now what does all of this mean? We essentially have “cp210x” which is a discrete Linux kernel module; this Linux kernel module is then “attached” to the special file ttyUSB0; it’s this special file ttyUSB0 that the program picocom(1) will be attached to, in order to perform serial communications.

You can also see where the different parameters like “idVendor” and “idProduct” come from by taking a look at the appropriate path in the Linux kernel source tree:

1  find ./ -regex ".*cp210x.*"
2  ./drivers/usb/serial/cp210x.c
3  $ less drivers/usb/serial/cp210x.c
4  ...
5  { USB_DEVICE(0x10C4, 0xEA60) }, /* Silicon Labs
        → factory default */
6  ...

On GNU/Linux systems, you should also take a look at the path /usr/share/misc/usd.ids:

1  $ less /usr/share/misc/usb.ids
2  ...
3  10c4 Silicon Labs
4  ...
5           ea60 CP210x UART Bridge
6  ...

Now let’s have a look at what it looks like when we pull out our UTUB:

1  $ dmesg --human --follow
2  ...
3  [Feb22 15:45] usb 7-1: USB disconnect, device number 3
4  [ +0.000384] cp210x ttyUSB0: cp210x converter now
       → disconnected from ttyUSB0
5  [ +0.000164] cp210x 7-1:1.0: device disconnected

There you have it! You should understand what’s going on in that output, with your new knowledge of Linux kernel internals. Remember, tools like lsmod(8), modinfo(8), and dmesg(1) are the first things you should look at when you plug things in and out of your GNU/Linux box. This stuff is incredibly simple, if you know where to look; now you know where to look! No need to be afraid.

Finally, we have the commands:

 $ lscpi -k

and

 $ lsusb -t

You now know enough to figure out yourself what you get from lspci -k and lsusb -t⁶.

You now have a healthy dose of knowledge injected into your grey matter to enable you to handle special files on GNU/Linux systems⁷. █
_____
¹ Technically, there’s also different bootloaders to worry about but we’re going to ignore bootloaders for now as we have enough to deal with. It’s also very unfair to GNU to just call it “userspace”; GNU gave the world things like the GNU Compiler Collection and GNU Autotools – things without which much of software today wouldn’t exist; there seems to be mass amnesia in the computing world around this, whether it be deliberate or not. And guess what? GNU was about freedom, first and foremost.
² i.e., how much junk the software you want to use depends on. It’s a great way to filter out bloatware. You will also be able to learn to spot “common denominator” programs software of a certain type depends on. Often, this will enable you to refine your criteria for a program in order to find exactly what you need – opposed to what you think you need (or what others make you think you need).
³ However, don’t think you’re entirely immune, if you compile everything from source. Much has been infiltrated at the source code level.
⁴ The other paths are just as interesting. See Appendix B for details on the specifics.
⁵ A skill every GNU/Linux operator should have.
⁶ Don’t know what the options mean? RTFM.
⁷ Some of this special file handling knowledge applies to other POSIX-like operating systems as well, with minor details changed.