hpr-knowledge-base/hpr_transcripts/hpr2814.txt

Episode: 2814
Title: HPR2814: Spectre and Meltdown and OpenBSD and our future
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2814/hpr2814.mp3
Transcribed: 2025-10-19 17:12:24

---

This is HBR episode 2,814 entitled Spectre and Meltdown and OpenBSD and Our Future.
It is posted my first time post-men floater too and in about 21 minutes long and carry
my clean flag.
The summary is a discussion about CPU and our future with them, where are we going?
This episode of HBR is brought to you by AnanasThost.com.
With 15% discount on all shared hosting with the offer code HBR15, that's HBR15.
Better web hosting that's honest and fair at AnanasThost.com.
Hello, my name is ZenFloater2 and I portray a squirrel that was a former human being converted
by aliens in the 1960s into a squirrel, claws and all.
At any rate, everybody's got a special handle, you know, it's like the days of the CB sets
in the 1970s, smokey in the bandit, the snowman.
Anyway, ZenFloater2 is my handle because I like squirrels.
So I live in a forest in Eastern Oklahoma, a forest that was declared to be protected
by the Supreme Court in 1972 and it's on Native American land.
And today, in this audio, I thought I would discuss the issue of Spectrum Meltdown and
Security in general.
And as you know, Spectrum Meltdown are flaws that were discovered in any CPU that had
speculative execution or speculative processing, which is where the processor runs out and,
you know, if there's three possible branches that the program could take, it tries to
compute answers for all three so that they're ready.
So when the CPU gets to that point, you know, it can just run through and execute that
speculative decision.
At any rate, this flaw was discovered in January, a year ago, January of 1998, I believe,
I'm sorry, January of 2018, what am I saying?
And it's caused a lot of problems for Intel.
It also affects AMD chips, it affects the risk series of chips that were based on the
IBM PowerPC that was, you know, the power plant of Macintosh just from years ago.
It affects a lot of chips.
I have a couple of CPUs in this house that are not affected, one of which is an old Dell
mini-10 that has an Intel N450 atom.
Now that particular processor does not have this bug, it doesn't have the design problem.
And also, if you own a Raspberry Pi of any kind, the Raspberry Pi is based on an arm chip
made by a Broadcom, I believe, and none of those are affected by specter meltdown, they're
all clean.
So I'm kind of an oddball, I don't really fit in on hacker public radio, perhaps, because
I'm an open BSD user and there's just not many open BSD people around here, but I've
been using open BSD since I started studying it around 4849 version and started actually
using it full time 5.1 or 5.2, I can't remember which, I think I started the letter part
of 5.1 and then from 5.2 forward, we're currently fixing to have version 6.5 out now, so I've
been using open BSD for about a decade.
And you know, Intel has released a lot of patches for this in the last year, the last
of which they had everybody recall, one of the popular ways to address the problem is
to do a bias update, and the last patch they gave out made the processor reboot, as you
know.
And so Dell and everybody withdrew that patch as soon as they found out, based on Intel's
advice that the patch was bad, and it wouldn't work with all their processors.
Anyway, depending on which news article you read, it could take anywhere from 5 years
to well over a decade before the chip manufacturers resolved this issue, because they're going
to have to redesign the physical hardware.
You know, this won't be fixed with microcode, they're going to have to redesign the physical
hardware of the CPU to be able to get around it.
It's a design flaw that has shown up in a lot of chips all the way back to the Pentium
4 in the Intel lineup.
But it didn't affect every Intel chip, as I just said, the Intel N450 Adam in my Dell
many 10, which is, you know, 12-year-old tiny little, what is it, 9-inch notebook?
That thing is not affected, that's a dual core, and OpenBSD recently decided to fix the
problem by simply turning the speculative processing off on the CPU from inside their
software as a version 6.4, and so half my cores are dead on my servers now.
I'm only running with half my cores, you run top, and you know, core 0, core 2, core
4, they're running, but the cores 1, 3, 5, you know, all the odd ones, they're dead.
You've never seen any processing going on on them, and that was the only way they could
figure to fix it, because the Intel patches don't work.
And so all of the Linux distributions, Mac OS X Windows, everybody, none of those patches
really work.
I mean, they're just a band-aid for the problem, as everybody knows, or should know.
And so, in the last year, I've been trying to figure out ways to get around it, and you
know, the funny thing about OpenBSD, I just want to talk about OpenBSD for a minute,
is over the years, if you have anybody that knows or runs OpenBSD over the years, you've
noticed that they've been slowly spending more and more time developing for the AMD 64
architecture, you know, the Intel 64 bit AMD 64 architecture, and that's their prime
architecture, and that's also the one that's affected.
And over the years, Vax and VMS has gone away, they no longer support that architecture.
Of course, that's understandable, I mean, that's an old machine.
There's just few people left that are running them, and over time, they'll probably drop
off Spark, and eventually the PowerPC, they'll quit supporting that.
And everybody knows that the I-36 platform is dying, it's going away.
So they'll quit supporting that, even though I-36 is still a pretty good platform for
the embedded market, I understand, even last tour of all, it's made a statement about
that here recently in the last month or two.
But OpenBSD is way too stuck on the AMD 64 platform, and that really puzzled me, because
if you've decided that your chip is so insecure that you're running on it, you have to turn
half of it off, I would think that OpenBSD would want to move, or take its users, encourage
its users anyway, to move off that platform to another processor.
And, you know, there just aren't many options here, because when you look at these two
vulnerabilities, as I just said, even the risk chips, the latest risk chips, what is it
risk A?
Did I think they've got a risk 9 that's either coming out or has already come out, which
is modeled after the old IBM PowerPC chip, you know, it's all open-source stuff, that's
affected by it too, unfortunately, it's got the same design flaw, I don't know who else
is making chips, I heard something about some people in India making your risk chip, but
I don't know that they manage to get around the design flaw either.
So, and of course, you know, China's making risk-based chips, in fact, I think isn't their
latest supercomputer, that supposedly the largest one in the world now is based on risk
chips, I believe, custom boards that they made.
So at any rate, yeah, that particular design went across several chips, but it didn't
affect the Raspberry Pi, hopefully, hopefully it won't affect the next version of Raspberry
Pi to come out in 2020.
There won't be any new Raspberry Pi this year from when I understand, but the next Raspberry
Pi, hopefully, will have more than a gig of RAM and be a little faster and support much
more.
So, we'll see what that looks like in a year's time.
But at any rate, considering how we're not going to get out of this no matter what you
do, you'd have to run a Raspberry Pi or be fortunate enough to have an old computer like
I do in Intel N450, which I'm not running at the moment, by the way, I could be, but
I'm not.
I've got it over here.
It's getting hard to find an operating system, even an Linux operating system, any more
that will run comfortably in one gigabyte of RAM.
That's the problem with the N450, and you know, the RAM is soldered on that motherboard,
and it's tuned for one gig, and I don't think you can upgrade it, so.
At any rate, perhaps your only choice might be one of those good old IBM X200s, you know,
with Lieber boot, but I'm not sure they might be affected by Spectre meltdown as well,
so that might not be a good option for you either.
I haven't bothered to check if that particular Intel Core 2 Dual is immune from it.
I think it's probably affected by one of them anyway, one of the variants of meltdown.
So we don't have too many chips that we can run on that you could trust other than the
Raspberry Pi right now, which is something that you could buff the shelf.
Of course, OpenBSD, people have ported it to, there is a port that I think they've got
for the Raspberry Pi 2, just like NetBSD has when I believe Clat 2 is running NetBSD on
a Raspberry Pi 2 or something like that.
Several people have tried that.
Of course, you know, they've got their own Raspberry in addition that you could run on
it, and that's what I'm running on mine at the moment.
Not really doing anything with it is just sort of a toy, but, you know, again, there's
only so much you can do in one gigabyte of memory, it won't make for a good desktop,
but it might make for a moderate server, I guess, you know.
If you're seriously worried about this issue, I think most people aren't really worried
about this issue, and I think that's really a problem.
It's like most people aren't really worried about being spied on by Google or the NSA or
something like that, and that's really a problem.
So, anyway, in the last month or so, after thinking about this issue, stewing over it
for eight or nine months, trying to decide what I was going to do, you know, was I going
to go out and maybe buy an old Spark unit or something and turn that into a server.
I went through several possibilities, and so far I haven't done anything.
I'm still running OpenBSD, currently version 6.4, I believe, on my I7 equipped server,
and half the processors shut down, but, you know, half the cores, or whatever you want
to call it, are shut down on it.
The speculative processing is turned off intentionally because the Intel patches don't
work.
They don't work.
I mean, even if you apply them, they don't keep you safe anyway.
They just slow the computer down, it's sort of a waste of time.
Nonetheless, my OpenBSD server still runs, you know, it still functions, it's just not
functioning super fast.
Anyway, I drug out a 10-year-old computer here, it's a Lenovo, what is it?
The V780A, I believe.
I think that's what it is.
With six gigabytes of RAM, which is a strange amount of RAM for a computer to have.
It's an i5 processor that I think is clocked up to 2.3 gigahertz, something like that.
And it's got a really weird 750 gigabyte hard drive, which is also very unusual, but,
you know, back in the day, this is a hot laptop.
It is a 17-inch laptop, and it has a built-in Nvidia chipset, too, by the way, that you
can run the bumblebee on if you had a regular Linux distribution and have switchable graphics
for your games.
Of course, it has a DVD player in it, and it has this Broadcom BCM 4313 Wi-Fi in it that
requires proprietary drivers.
Anyway, I got the bug and decided I'm going to park up and be a Steve for a while and start
playing with Triscoll.
And so I have Triscoll 8 loaded on this machine, and I've been doing some reading.
And Triscoll 9, which is supposed to come out this year, is supposed to support the
Raspberry Pi.
And I have a mindset that if they do that, I might just be switching off of OpenBSD and
running Triscoll 9 on a Raspberry Pi and trying to replace my server.
That's what I'm going to try to do.
And I'm going to have a very interesting project because, you know, Linux doesn't exactly
do what the P.F. firewall does in OpenBSD, but I'm going to try to emulate it as best
as possible.
And my goal is to try to create a Wi-Fi router and also a server using Raspberry Pi's
and Triscoll.
That's what we're going to try to do.
And that will happen this summer sometime when all this stuff comes out.
And Triscoll 9 comes out.
There's no point in me trying to do it with Triscoll 8 because Triscoll 8 currently does
not have any ARM support, but they're supposed to have ARM support of some kind.
Hopefully it'll be for the Raspberry Pi.
But I won't promise that that's going to happen because that would seem weird, wouldn't
it?
Because Triscoll really doesn't support close source hardware.
And unfortunately, the Raspberry Pi, all the Raspberry Pi devices are pretty much close
source stuff from what I understand.
They're not.
They don't have a free software, they're running on free software because of the design
of the board, I guess, and perhaps the NDAs they have with these commercial providers.
So maybe the next Raspberry Pi will fix all that I don't know.
Of course, the other possibilities that I have would be to try to run OpenBSD on one
of the other single board computers.
Like I believe they have a port for maybe it's the Beaglebone Black.
And I don't know what else, but the biggest problem with OpenBSD is Wi-Fi support on these
single board computers.
For instance, you can run OpenBSD on a Raspberry Pi.
Now it just doesn't have any Wi-Fi support because you know the drivers are closed on
that thing.
Apparently, there is an NDA to get Raspberry and running on it, but currently there's
no way to get OpenBSD or NetBSD or even FreeBSD to use the Wi-Fi router in host AP mode
or any other mode.
So that's kind of a problem and that's what puts those groups behind where Triscoll
might be able to get around that a little more quickly and probably run a little faster.
But to conclude this podcast, it does strike me a strange that there is an effort, in other
words, a major push with an OpenBSD to find another board, single processor board or
multiple boards and start shoving the developers over to port OpenBSD to those boards.
Because as time rolls along, you know, like I said, they've shut down the Vax port.
It's gone.
Spark will be gone soon.
I-386 will be gone soon.
Power PC will be gone soon because they're getting older.
People are not going to be wearing those anymore.
You know, the old, the old risk-based IBM powered power PCs.
And so OpenBSD is just going to be sitting on this Intel AMD 64 platform and, you know,
they've already pretty much admitted that that's a broken chip and it's going to be broken
for every decade.
And you know, even when they fix it in a decade's time, people are going to find problems
with the Intel chip.
Because of the silly management engine they've got back there and everything else, I mean,
I vote we just ditch the whole thing, right?
Ditch AMD, ditch Intel, put our foot down and say, hey, no more management engine and
no more nonsense with Spectrum meltdown.
We've had enough, you know.
This is something that Intel should have piled a big bunch of money on and fixed it for
the i9, but what are they doing?
They're selling the i9 chip out in the open market.
And it's still got the same problems, still, still has the same problems with Spectrum
meltdown.
I mean, they got a patch over now, but it's still a broken chip.
And if I bought a i9 and put OpenBSD on it, well, half the processes are going to be
shut down on it.
So what's the point in running it?
I mean, from my viewpoint, if I could get OpenBSD on a Raspberry Pi and get the Wi-Fi
router supported, I'd probably do it because I'd have use of all four cores.
And it would start getting very competitive with like an i5 running at the same speed.
It really would because when you shut down half the cores in an i5, all of a sudden the
performance is about like that of a Raspberry Pi.
So anyway, that's my predicament.
And I thought I would talk about tonight and go ahead and include this podcast.
It was nice to meet you all.
And I hope you have a good day.
And we'll make some more audio podcasts on this project as things become available.
The most interesting part will be how I decide to replicate OpenBSD in Linux because that's
going to be a trick in itself.
Anyway, have a great day, everybody.
You've been listening to Hecopublic Radio at HecopublicRadio.org.
We are a community podcast network that releases shows every weekday, Monday through Friday.
Today's show, like all our shows, was contributed by an HPR listener like yourself.
If you ever thought of recording a podcast, then click on our contributing to find out
how easy it really is.
Hecopublic Radio was founded by the Digital Dove Pound and the Infonomicon Computer Club
and is part of the binary revolution at binrev.com.
If you have comments on today's show, please email the host directly, leave a comment on
the website or record a follow-up episode yourself.
On this otherwise stated, today's show is released under Creative Commons, Attribution,
ShareAlive, 3.0 license.