Another DCL CVE and once again, a buffer overflow doesn't work on Itanium.
It works on Alpha, and on the brand new x86-64 port with modern security features. But it doesn't work on Itanium. (As with my CVE, all you are reported to get is a process crash on Itanium).
Question: Was Itanium the safer architecture (at least in some ways)
that we have all been looking for ?
On 6/1/2026 1:57 PM, Simon Clubley wrote:
Another DCL CVE and once again, a buffer overflow doesn't work on Itanium. >>
It works on Alpha, and on the brand new x86-64 port with modern security
features. But it doesn't work on Itanium. (As with my CVE, all you are
reported to get is a process crash on Itanium).
The patch was also released for VMS Itanium.
Question: Was Itanium the safer architecture (at least in some ways)
that we have all been looking for ?
Probably.
Just the obscurity of the ISA and rarity of HW makes it a much
less likely target.
On 2026-06-01, Arne Vajh|+j <arne@vajhoej.dk> wrote:
On 6/1/2026 1:57 PM, Simon Clubley wrote:
Another DCL CVE and once again, a buffer overflow doesn't work on Itanium. >>>
It works on Alpha, and on the brand new x86-64 port with modern security >>> features. But it doesn't work on Itanium. (As with my CVE, all you are
reported to get is a process crash on Itanium).
The patch was also released for VMS Itanium.
Yes. To fix the process crash. They did they same thing for my CVE as well.
Question: Was Itanium the safer architecture (at least in some ways)
that we have all been looking for ?
Probably.
Just the obscurity of the ISA and rarity of HW makes it a much
less likely target.
This is about technical merits, not about how popular it may be.
The real question is: do you have to work harder on Itanium to try to
turn a buffer overflow into something that can be exploited and so far
the answer appears to be yes.
On 6/1/2026 2:13 PM, Simon Clubley wrote:
On 2026-06-01, Arne Vajhoj <arne@vajhoej.dk> wrote:
On 6/1/2026 1:57 PM, Simon Clubley wrote:
Another DCL CVE and once again, a buffer overflow doesn't work on Itanium. >>>>
It works on Alpha, and on the brand new x86-64 port with modern security >>>> features. But it doesn't work on Itanium. (As with my CVE, all you are >>>> reported to get is a process crash on Itanium).
The patch was also released for VMS Itanium.
Yes. To fix the process crash. They did they same thing for my CVE as well.
I think the release notes only talk about risk of process crash on
all 3 platforms for this patch.
But given the power of supervisor mode, then DCL problems have
to be taken seriously - there could be something exploitable.
Question: Was Itanium the safer architecture (at least in some ways)
that we have all been looking for ?
Probably.
Just the obscurity of the ISA and rarity of HW makes it a much
less likely target.
This is about technical merits, not about how popular it may be.
The real question is: do you have to work harder on Itanium to try to
turn a buffer overflow into something that can be exploited and so far
the answer appears to be yes.
Itanium got NX bit. And may have other features as well not present
in Alpha.
On 2026-06-01, Arne Vajh|+j <arne@vajhoej.dk> wrote:
On 6/1/2026 2:13 PM, Simon Clubley wrote:
On 2026-06-01, Arne Vajh|+j <arne@vajhoej.dk> wrote:I think the release notes only talk about risk of process crash on
On 6/1/2026 1:57 PM, Simon Clubley wrote:
Another DCL CVE and once again, a buffer overflow doesn't work on Itanium.
It works on Alpha, and on the brand new x86-64 port with modern security >>>>> features. But it doesn't work on Itanium. (As with my CVE, all you are >>>>> reported to get is a process crash on Itanium).
The patch was also released for VMS Itanium.
Yes. To fix the process crash. They did they same thing for my CVE as well. >>
all 3 platforms for this patch.
It's an 8.5 Arne. :-) That's not a process crash. That's a confirmed exploitable vulnerability. (At least on Alpha/x86-64).
Much more interesting however is who actually added this code to DCL ?
Was it added in Nashua by one of the original VMS Engineering team or
one of the outsourced teams ?
Regardless of developer location (including if the developer was in the
US or in Europe) I hope any other code by this developer (or developers)
has also been closely examined for similar mistakes.
Given the peer review process that VSI engineers have talked about in
the past, I do wonder also how it got past peer review.
Question: Was Itanium the safer architecture (at least in some ways)
that we have all been looking for ?
Another DCL CVE and once again, a buffer overflow doesn't work on
Itanium.
It works on Alpha, and on the brand new x86-64 port with modern
security features. But it doesn't work on Itanium. (As with my CVE,
all you are reported to get is a process crash on Itanium).
Question: Was Itanium the safer architecture (at least in some ways)
that we have all been looking for ?
Interesting question isn't it ?
Simon.
Another DCL CVE and once again, a buffer overflow doesn't work on Itanium.
It works on Alpha, and on the brand new x86-64 port with modern security >features. But it doesn't work on Itanium. (As with my CVE, all you are >reported to get is a process crash on Itanium).
Question: Was Itanium the safer architecture (at least in some ways)
that we have all been looking for ?
Interesting question isn't it ?
On 6/1/2026 3:15 PM, Simon Clubley wrote:
It's an 8.5 Arne. :-) That's not a process crash. That's a confirmed
exploitable vulnerability. (At least on Alpha/x86-64).
You can speculate about Itanium being different. But I have not
seen anything in what VSI has published that indicate Itanium is
different from this one.
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
Question: Was Itanium the safer architecture (at least in some ways)
that we have all been looking for ?
No. The whole VLIW thing actually seems like a way to conceal various
kinds of bugs which could turn out to be vulnerabilities.
If you want safety, you want the iAPX 432. Or maybe that Honeywell capability machine.
On 2026-06-01, Scott Dorsey <kludge@panix.com> wrote:
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
Question: Was Itanium the safer architecture (at least in some ways)
that we have all been looking for ?
No. The whole VLIW thing actually seems like a way to conceal various
kinds of bugs which could turn out to be vulnerabilities.
Although as Michael S points out, Itanium does have an interesting feature.
If you want safety, you want the iAPX 432. Or maybe that Honeywell
capability machine.
Oh god, having modern capability-based hardware (and the software to go
with it) would be _nice_.
In article <10vmhf6$2tlpl$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
Oh god, having modern capability-based hardware (and the software to go >>with it) would be _nice_.
Ask and ye shall receive: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.arm.com/architecture/cpu/morello https://cheri-alliance.org/discover-cheri/cheri-products/
Get a hold of Morello Board isn't easy, though, and most of the
other designs are soft cores targeting FPGAs at the moment.
On 2026-06-02, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
Get a hold of Morello Board isn't easy, though, and most of the
other designs are soft cores targeting FPGAs at the moment.
Oh boy, I had totally forgotten about that work and I had thought
in the past it was just a research project that unfortunately had
not gone anywhere. It's interesting (to put it mildly!) to see
something viable might come out of this work after all.
In article <10vp6ei$3ke9b$1@dont-email.me>, clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
On 2026-06-02, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
Get a hold of Morello Board isn't easy, though, and most of the
other designs are soft cores targeting FPGAs at the moment.
Oh boy, I had totally forgotten about that work and I had thought
in the past it was just a research project that unfortunately had
not gone anywhere. It's interesting (to put it mildly!) to see
something viable might come out of this work after all.
It isn't going anywhere /quickly/. My employer was offered a Morello
board for six months in 2021 or '22. We concluded that while it would be interesting, there were more immediate commercial priorities. We'd need enough hardware, indefinitely, to run all our production testing to keep
a CHERI build going, and that wasn't on offer.
PPS: On a more serious note, is it going to take a global scale
disaster to finally invest resources into making things well and
truly "really secure" instead of just "pretend secure" ?
The military have brute-force answers to that, via air gaps, but
nobody want to buy such systems. Few are willing to pay for any
security overheads.
In article <10vrqda$bvkh$1@dont-email.me>, clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
PPS: On a more serious note, is it going to take a global scale
disaster to finally invest resources into making things well and
truly "really secure" instead of just "pretend secure" ?
What is "really secure"? The military have brute-force answers to that,
via air gaps, but nobody want to buy such systems. Few are willing to pay
for any security overheads.
John Dallman <jgd@cix.co.uk> wrote:
clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
PPS: On a more serious note, is it going to take a global scale
disaster to finally invest resources into making things well and
truly "really secure" instead of just "pretend secure" ?
What is "really secure"? The military have brute-force answers to that,
via air gaps, but nobody want to buy such systems. Few are willing to pay
for any security overheads.
Air gaps aren't really secure. One platoon of Marines can get through
most typical air gaps.
On 6/5/2026 5:49 PM, Scott Dorsey wrote:
John Dallman <jgd@cix.co.uk> wrote:
clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
PPS: On a more serious note, is it going to take a global scale
disaster to finally invest resources into making things well and
truly "really secure" instead of just "pretend secure" ?
What is "really secure"? The military have brute-force answers to that,
via air gaps, but nobody want to buy such systems. Few are willing to pay >>> for any security overheads.
Air gaps aren't really secure. One platoon of Marines can get through
most typical air gaps.
I didn't see a smiley. Is this joke or do you really not know
what is meant by an air gap in the IT world.
On 6/5/2026 10:37 PM, Scott Dorsey wrote:
bill-a <bill.gunshannon@gmail.com> wrote:
On 6/5/2026 5:49 PM, Scott Dorsey wrote:
John Dallman <jgd@cix.co.uk> wrote:
clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
PPS: On a more serious note, is it going to take a global scale
disaster to finally invest resources into making things well and
truly "really secure" instead of just "pretend secure" ?
What is "really secure"? The military have brute-force answers to
that,
via air gaps, but nobody want to buy such systems. Few are willing
to pay
for any security overheads.
Air gaps aren't really secure.-a One platoon of Marines can get through >>>> most typical air gaps.
I didn't see a smiley.-a Is this joke or do you really not know
what is meant by an air gap-a in the IT world.
I do.-a It means there's no network connection and you're relying only
on usually-pitiful physical security measures to keep your system
isolated.
Yeah, much more pitiful than putting it in the cloud where everyone and their dog has access to it.
On a side note, I saw some very interesting methods to try and breach airgaps.-a Like having a secure and a non-secure terminal side by side
on a desk so you could copy data manually from one to the other.
Security is not always a second thought.-a Sometimes it is openly
despised.-a :-)
In article <10vp6ei$3ke9b$1@dont-email.me>, >clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
On 2026-06-02, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
Get a hold of Morello Board isn't easy, though, and most of the
other designs are soft cores targeting FPGAs at the moment.
Oh boy, I had totally forgotten about that work and I had thought
in the past it was just a research project that unfortunately had
not gone anywhere. It's interesting (to put it mildly!) to see
something viable might come out of this work after all.
It isn't going anywhere /quickly/. My employer was offered a Morello
board for six months in 2021 or '22. We concluded that while it would be >interesting, there were more immediate commercial priorities. We'd need >enough hardware, indefinitely, to run all our production testing to keep
a CHERI build going, and that wasn't on offer.
John Dallman <jgd@cix.co.uk> wrote: >>clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
PPS: On a more serious note, is it going to take a global scale
disaster to finally invest resources into making things well and
truly "really secure" instead of just "pretend secure" ?
What is "really secure"? The military have brute-force answers to that,
via air gaps, but nobody want to buy such systems. Few are willing to pay >>for any security overheads.
Air gaps aren't really secure. One platoon of Marines can get through
most typical air gaps.
On 6/5/2026 10:37 PM, Scott Dorsey wrote:
bill <bill.gunshannon@gmail.com> wrote:
On 6/5/2026 5:49 PM, Scott Dorsey wrote:
John Dallman <jgd@cix.co.uk> wrote:
clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
PPS: On a more serious note, is it going to take a global scale
disaster to finally invest resources into making things well and
truly "really secure" instead of just "pretend secure" ?
What is "really secure"? The military have brute-force answers to that, >>>>> via air gaps, but nobody want to buy such systems. Few are willing to pay >>>>> for any security overheads.
Air gaps aren't really secure. One platoon of Marines can get through >>>> most typical air gaps.
I didn't see a smiley. Is this joke or do you really not know
what is meant by an air gap in the IT world.
I do. It means there's no network connection and you're relying only
on usually-pitiful physical security measures to keep your system isolated.
Yeah, much more pitiful than putting it in the cloud where everyone and >their dog has access to it.
On a side note, I saw some very interesting methods to try and breach >airgaps. Like having a secure and a non-secure terminal side by side
on a desk so you could copy data manually from one to the other.
Security is not always a second thought. Sometimes it is openly
despised. :-)
I see some uptick in the availability of CHERI based hardware;
whether it's enough for industrial uptake, I don't know.
OpenTitan, SCI Semiconductor, et al, seem bullish on it, but
they all seem focused on the embedded space right now.
The embedded world, where one team controls hardware and software, is the easiest place to get some commitment.
On 2026-06-04, John Dallman <jgd@cix.co.uk> wrote:
In article <10vrqda$bvkh$1@dont-email.me>,
clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
PPS: On a more serious note, is it going to take a global scale
disaster to finally invest resources into making things well and
truly "really secure" instead of just "pretend secure" ?
What is "really secure"? The military have brute-force answers to that,
via air gaps, but nobody want to buy such systems. Few are willing to pay
for any security overheads.
Good question.
First of all, I should hold myself to my own standards and say "much
more secure" instead of "really secure" in keeping with my position
that you can only make things safer and not safe.
Some ideas (and I will probably think of more right after I post this :-))
1) We need CHERI or something like it. There are very good reasons why
I was so excited something like that might finally become a reality.
We need it to be cheap and commonplace and something that "just is"
in the same way that, say, cheap hobbyist dev boards are now "just are"
so people now use them to explore new ideas.
People don't build widespread systems around new concepts until general >availability is guaranteed.
2) Linus is on the wrong side of the microkernel argument. There was a >performance argument 30 years ago, but that argument no longer exists
in today's world. We need to get today's monolithic and fully privileged >kernels broken up and isolated into a microkernel infrastructure.
Next time you get some Linux patch notifications, spend some time
reading the kernel ones and following the CVEs and then remember all
those bugs are running in one single fully privileged address space.
Microkernels are a lot more secure and robust than monolithic kernels.
3) Intel and AMD need to knock off this operating system below the
user's operating system stuff that the user's operating system can't
even see. I know why they (claim) they do, but that's extreme
arrogance and a disaster in the making. That should be under the full
control of the user and the user's OS at all times.
4) All operating systems (at least the public facing server ones) should
run with mandatory access control security (ie: something like SELinux)
at all times to try to help keep a successful breach contained.
5) Our software architectures are way too complex. Complex systems are
way more vulnerable than a more simple, more cleanly defined architecure >because there many more paths with unanticipated side effects.
6) We need to find a way of moving away from opaque binary firmware and
other blobs from vendors. Even _if_ there are no backdoors, someone
could still discover exploitable vulnerabilities that we may be able
to do absolutely nothing about.
7) If a government agency comes across a vulnerability, they need to be >forced by law to disclose it to the vendor so it can be fixed instead
of holding onto it for some perceived short-term gain. If they can find
it, then so can others.
8) No government mandated backdoors in hardware or software.
Any additions to this list ?
Yup, it's the usual chicken-and-egg problem for something without
immediately demonstrable benefits.
The application software people aren't going to do the work to
support CHERI unless there's fast hardware available and end-user
demand.
In article <10vugtq$15a62$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
2) Linus is on the wrong side of the microkernel argument. There was a >>performance argument 30 years ago, but that argument no longer exists
in today's world. We need to get today's monolithic and fully privileged >>kernels broken up and isolated into a microkernel infrastructure.
Next time you get some Linux patch notifications, spend some time
reading the kernel ones and following the CVEs and then remember all
those bugs are running in one single fully privileged address space.
Microkernels are a lot more secure and robust than monolithic kernels.
This bears some scrutiny. In particular, what are the assumed characteristics of microkernels that make them more secure
and/or robust, in your estimation?
3) Intel and AMD need to knock off this operating system below the
user's operating system stuff that the user's operating system can't
even see. I know why they (claim) they do, but that's extreme
arrogance and a disaster in the making. That should be under the full >>control of the user and the user's OS at all times.
Agreed, but it's not just Intel and AMD. It's also ARM and
(increasingly) the RISC-V ecosystem.
This also opens up a whole can of worms about what that stuff
does and when, and interfaces between the hardware platform and
the operating system _should_ exist. If we really do everything
that is in UEFI or ACPI or SMM in the OS, then we're going to
need to have some pretty fundamental conversations first.
4) All operating systems (at least the public facing server ones) should >>run with mandatory access control security (ie: something like SELinux)
at all times to try to help keep a successful breach contained.
This conflates MAC with containment; that is, it mandates a
particular shape of a solution instead of starting with the
fundamental problem and driving to a solution.
Absolutely we need containment of breaches. Is MAC the best way
to get that?
PPS: On a more serious note, is it going to take a global scale
disaster to finally invest resources into making things well and
truly "really secure" instead of just "pretend secure" ?
What is "really secure"? The military have brute-force answers to that,
via air gaps, but nobody want to buy such systems. Few are willing to pay
for any security overheads.
bill <bill.gunshannon@gmail.com> wrote:
On 6/5/2026 5:49 PM, Scott Dorsey wrote:
John Dallman <jgd@cix.co.uk> wrote:
clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
PPS: On a more serious note, is it going to take a global scale
disaster to finally invest resources into making things well and
truly "really secure" instead of just "pretend secure" ?
What is "really secure"? The military have brute-force answers to that, >>>> via air gaps, but nobody want to buy such systems. Few are willing to pay >>>> for any security overheads.
Air gaps aren't really secure. One platoon of Marines can get through
most typical air gaps.
I didn't see a smiley. Is this joke or do you really not know
what is meant by an air gap in the IT world.
I do. It means there's no network connection and you're relying only
on usually-pitiful physical security measures to keep your system isolated.
On 6/5/2026 10:37 PM, Scott Dorsey wrote:
bill <bill.gunshannon@gmail.com> wrote:
On 6/5/2026 5:49 PM, Scott Dorsey wrote:
John Dallman <jgd@cix.co.uk> wrote:
clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
PPS: On a more serious note, is it going to take a global scale
disaster to finally invest resources into making things well and
truly "really secure" instead of just "pretend secure" ?
What is "really secure"? The military have brute-force answers to that, >>>>> via air gaps, but nobody want to buy such systems. Few are willing to pay >>>>> for any security overheads.
Air gaps aren't really secure. One platoon of Marines can get through >>>> most typical air gaps.
I didn't see a smiley. Is this joke or do you really not know
what is meant by an air gap in the IT world.
I do. It means there's no network connection and you're relying only
on usually-pitiful physical security measures to keep your system isolated.
Yeah, much more pitiful than putting it in the cloud where everyone and >their dog has access to it.
On a side note, I saw some very interesting methods to try and breach >airgaps. Like having a secure and a non-secure terminal side by side
on a desk so you could copy data manually from one to the other.
Security is not always a second thought. Sometimes it is openly
despised. :-)
In article <n8ikv7FtdetU2@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:
On 6/5/2026 10:37 PM, Scott Dorsey wrote:
bill <bill.gunshannon@gmail.com> wrote:Yeah, much more pitiful than putting it in the cloud where everyone and
On 6/5/2026 5:49 PM, Scott Dorsey wrote:
John Dallman <jgd@cix.co.uk> wrote:
clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote: >>>>>>
PPS: On a more serious note, is it going to take a global scale
disaster to finally invest resources into making things well and >>>>>>> truly "really secure" instead of just "pretend secure" ?
What is "really secure"? The military have brute-force answers to that, >>>>>> via air gaps, but nobody want to buy such systems. Few are willing to pay
for any security overheads.
Air gaps aren't really secure. One platoon of Marines can get through >>>>> most typical air gaps.
I didn't see a smiley. Is this joke or do you really not know
what is meant by an air gap in the IT world.
I do. It means there's no network connection and you're relying only
on usually-pitiful physical security measures to keep your system isolated. >>
their dog has access to it.
I worked on Google Cloud, and I used secure and insecure
military networks while deployed in a combat environment.
I'd posit that cloud infrastucture run by Google is verifiably
orders of magnitude more secure than a deployed military
network.
On a side note, I saw some very interesting methods to try and breach
airgaps. Like having a secure and a non-secure terminal side by side
on a desk so you could copy data manually from one to the other.
Security is not always a second thought. Sometimes it is openly
despised. :-)
Sometimes that is an operational necessity, and sometimes it
goes from non-secure to secure.
True story: I was embedded with an Afghan Army unit. I was a
Marine communications officer, but I'm also a Marine: that means
I am expected to operate outside of my primary MOS and put
together combat ops when required. My ANA guys were in a log
unit, but didn't have the uparmored or heavy weapons
capabilities that I did; which meant I spent a lot of time
outside the wire running security and commanding them. Fun
times.
Anyway, at one point, some ricky-recon ANGLICO Captain shows up
out of nowhere and says, "I want to support you!" Uh, ok, guy,
support me with what, precisely? By this time I'd been running
missions for months, and it wasn't clear what he was bringing to
the table other than a few extra guns that, honestly, I really
didn't need.
I never did figure it out. He wanted to attach to one of my
convoys, so I told him, "ok, good to go, sir: please send me
your manifest over SIPR so I can integrate it into mine."
See, before going outside the wire on a mission, I had to put
together an op-order and a manifest listing all of my assets:
vehicles, radios, weapons, Marines and Navy personnel (we don't
have doctors or medics in the Marine Corps; we get all of that
from the US Navy, so I had sailors attached to my team, and at
one point an Army medic showed up and we kept him, so I had a
soldier too); basically, anything with a serial number or a
pulse had to be listed on the manifest, which had to be sent up
to the division level so they could track everything that was
operationally active. So my secret squirrel ANGLICO ninja guy
wants to join this mission and he's bringing his own vehicle and
weapons and all of that, so I ask him for his gear list, and I
ask him to send it to me on the "secure" network, because that's
where all of that stuff was stored and sent around and so on.
So naturally he sends me his manifest (incomplete) on NIPR (the
"Non-secure Internet Protocol Router": no, really, that's what
it's called; "SIPR" is the "Secure Internet Protocol Router") so
now I have to sit there in the CoC, reading this stuff off of a
laptop on the NIPR network, and typing it into another laptop,
connected to the SIPR network.
To add insult to injury, we go to DFL and Ricky Recon shows up
with like two other people that weren't on the manifest, in a
different vehicle than the one he'd said he was going to be in,
with a bunch of weapons he didn't tell me about, but he is
rolling Ready For War. "What the hell? Who is this?" "Oh, he's
coming along with us...." "He's not on the manifest. I have to
call this in and add him."
Long story short, nothing this guy had sent me was accurate, so
I called up my CoC, explained the situation; they pushed it up
to Divison, and Division was _pissed_: at me. I was pissed that
division was pissed and that this guy was wasting my time.
Meanwhile, the ANA guys are starting to honk at me because they
want to get going. So do I, guys, so do I. Sadly, I was
looking at having to delay by an hour or more to fix all of this
manfist asshattery, or leaving the War Badger behind.
I left him behind; never heard from the guy again. I guess he
found someone else to "support."
I don't know if this is an argument _for_ or _against_ close
physical proximity for airgapped terminals.
On 2026-06-08, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
In article <10vugtq$15a62$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
2) Linus is on the wrong side of the microkernel argument. There was a >>>performance argument 30 years ago, but that argument no longer exists
in today's world. We need to get today's monolithic and fully privileged >>>kernels broken up and isolated into a microkernel infrastructure.
Next time you get some Linux patch notifications, spend some time
reading the kernel ones and following the CVEs and then remember all >>>those bugs are running in one single fully privileged address space.
Microkernels are a lot more secure and robust than monolithic kernels.
This bears some scrutiny. In particular, what are the assumed
characteristics of microkernels that make them more secure
and/or robust, in your estimation?
More secure:
Outside of the core functionality, which must remain in kernel mode,
the rest of the kernel components, and especially the vendor supplied
and third-party device drivers, are isolated in non-privileged
user-mode processes and are only physically capable of talking to the
rest of the kernel via highly structured interfaces.
There are drivers and components even in a microkernel that if you
manage to compromise you could still use to do damage but you now
face the harder job of getting to them because they are isolated
in user processes behind those message interfaces.
It also means you can't use the compromise of a secondary driver without >security implications in itself as a jumping-off point to go and compromise >the critical parts of the kernel as they no longer share the same address >space.
Also remember what I said: "More secure", not "secure".
More robust:
A crash in a driver or kernel component does not mean failure of the
system (in most cases). A suitably designed microkernel means that
restart of the failed component/driver may very well also be possible.
3) Intel and AMD need to knock off this operating system below the
user's operating system stuff that the user's operating system can't
even see. I know why they (claim) they do, but that's extreme
arrogance and a disaster in the making. That should be under the full >>>control of the user and the user's OS at all times.
Agreed, but it's not just Intel and AMD. It's also ARM and
(increasingly) the RISC-V ecosystem.
I thought ARM was restricted to the TrustZone stuff for user applications.
I wasn't aware of the SMM stuff because I'm more used to using ARM in >embedded environments. I've had a look and it appears more sane than >Intel/AMD but I still don't like it.
I have not been able to find anything about RISC-V SMM mode so I don't
know if they call it something else that I am unable to find.
This also opens up a whole can of worms about what that stuff
does and when, and interfaces between the hardware platform and
the operating system _should_ exist. If we really do everything
that is in UEFI or ACPI or SMM in the OS, then we're going to
need to have some pretty fundamental conversations first.
I don't really care where it is, provided _I_, and not my government
or my closed-source dodgy binary blob vendor are in control. In reality >however, that means it needs to be quite high up in the stack, with
(as you correctly point out) open specifications for everything.
Also in reality, and sadly also based on history, that is indeed looking
like the OS.
4) All operating systems (at least the public facing server ones) should >>>run with mandatory access control security (ie: something like SELinux) >>>at all times to try to help keep a successful breach contained.
This conflates MAC with containment; that is, it mandates a
particular shape of a solution instead of starting with the
fundamental problem and driving to a solution.
Absolutely we need containment of breaches. Is MAC the best way
to get that?
MAC policies can very tightly lock down resources for different services >running on the same server. For example, different services can be given >access to different collections of network ports, which malware cannot >override. Likewise, you can tightly label different parts of filesystems
with various MAC labels.
Running one service per container may be a partial solution, but you
still need a container-specific firewall because by removing MAC, you
have just given the malware the ability to open whatever ports it wants,
at least within the container. Also, at some point, those different
services may need to share data so you are back to the controlling access
to the filesystem problem.
Having said that, I would welcome suggestions about alternatives.
On 6/8/2026 9:19 AM, Dan Cross wrote:
In article <n8ikv7FtdetU2@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:
On 6/5/2026 10:37 PM, Scott Dorsey wrote:
bill <bill.gunshannon@gmail.com> wrote:
On 6/5/2026 5:49 PM, Scott Dorsey wrote:
John Dallman <jgd@cix.co.uk> wrote:
clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote: >>>>>>>
PPS: On a more serious note, is it going to take a global scale >>>>>>>> disaster to finally invest resources into making things well and >>>>>>>> truly "really secure" instead of just "pretend secure" ?
What is "really secure"? The military have brute-force answers to that, >>>>>>> via air gaps, but nobody want to buy such systems. Few are willing to pay
for any security overheads.
Air gaps aren't really secure. One platoon of Marines can get through >>>>>> most typical air gaps.
I didn't see a smiley. Is this joke or do you really not know
what is meant by an air gap in the IT world.
I do. It means there's no network connection and you're relying only
on usually-pitiful physical security measures to keep your system isolated.
Yeah, much more pitiful than putting it in the cloud where everyone and
their dog has access to it.
I worked on Google Cloud, and I used secure and insecure
military networks while deployed in a combat environment.
I know it's done. Kinda shoots down the "zero trust" concept when you
put all your data in the hands of people you have no reason to trust.
I'd posit that cloud infrastucture run by Google is verifiably
orders of magnitude more secure than a deployed military
network.
As the the guy responsible for designing, building and operating
deployed military networks as well as doing a stint with DISA
inspecting and verifying them I would definitely disagree.
The only time any data is secure is when it is in your hands
and your hands only. Just like a secret. Two people can keep
a secret, if one of them is dead.
On a side note, I saw some very interesting methods to try and breach
airgaps. Like having a secure and a non-secure terminal side by side
on a desk so you could copy data manually from one to the other.
Security is not always a second thought. Sometimes it is openly
despised. :-)
Sometimes that is an operational necessity, and sometimes it
goes from non-secure to secure.
Non-secure to secure is fine.
It's only a problem when it goes
the other way. I once worked in National Guard with an officer
who used to put his personal laptop on SIPRNET during exercises.
His explanation was "We're National Guard, none of this is real."
we were connected by satellite to Ft Gordon and connected to the
real world SIPRNET. If it wasn't real how did he think we were
able to talk to HUMVEEs in Iraq using Blue Force Tracker.
True story: I was embedded with an Afghan Army unit. I was a
Marine communications officer, but I'm also a Marine: that means
I am expected to operate outside of my primary MOS and put
together combat ops when required. My ANA guys were in a log
unit, but didn't have the uparmored or heavy weapons
capabilities that I did; which meant I spent a lot of time
outside the wire running security and commanding them. Fun
times.
Anyway, at one point, some ricky-recon ANGLICO Captain shows up
out of nowhere and says, "I want to support you!" Uh, ok, guy,
support me with what, precisely? By this time I'd been running
missions for months, and it wasn't clear what he was bringing to
the table other than a few extra guns that, honestly, I really
didn't need.
I never did figure it out. He wanted to attach to one of my
convoys, so I told him, "ok, good to go, sir: please send me
your manifest over SIPR so I can integrate it into mine."
See, before going outside the wire on a mission, I had to put
together an op-order and a manifest listing all of my assets:
vehicles, radios, weapons, Marines and Navy personnel (we don't
have doctors or medics in the Marine Corps; we get all of that
from the US Navy, so I had sailors attached to my team, and at
one point an Army medic showed up and we kept him, so I had a
soldier too); basically, anything with a serial number or a
pulse had to be listed on the manifest, which had to be sent up
to the division level so they could track everything that was
operationally active. So my secret squirrel ANGLICO ninja guy
wants to join this mission and he's bringing his own vehicle and
weapons and all of that, so I ask him for his gear list, and I
ask him to send it to me on the "secure" network, because that's
where all of that stuff was stored and sent around and so on.
So naturally he sends me his manifest (incomplete) on NIPR (the
"Non-secure Internet Protocol Router": no, really, that's what
it's called; "SIPR" is the "Secure Internet Protocol Router") so
now I have to sit there in the CoC, reading this stuff off of a
laptop on the NIPR network, and typing it into another laptop,
connected to the SIPR network.
To add insult to injury, we go to DFL and Ricky Recon shows up
with like two other people that weren't on the manifest, in a
different vehicle than the one he'd said he was going to be in,
with a bunch of weapons he didn't tell me about, but he is
rolling Ready For War. "What the hell? Who is this?" "Oh, he's
coming along with us...." "He's not on the manifest. I have to
call this in and add him."
Long story short, nothing this guy had sent me was accurate, so
I called up my CoC, explained the situation; they pushed it up
to Divison, and Division was _pissed_: at me. I was pissed that
division was pissed and that this guy was wasting my time.
Meanwhile, the ANA guys are starting to honk at me because they
want to get going. So do I, guys, so do I. Sadly, I was
looking at having to delay by an hour or more to fix all of this
manfist asshattery, or leaving the War Badger behind.
I left him behind; never heard from the guy again. I guess he
found someone else to "support."
I don't know if this is an argument _for_ or _against_ close
physical proximity for airgapped terminals.
What happened is exactly the way it is supposed to work.
Funny, I assumed the Marines had security people equivalent to
Army S2. They should have been handling this.
All the services have
assholes, sadly the peter principle is in full effect allowing
their rise thru the ranks.
In article <1109q72$8pnm$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
On 2026-06-08, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
In article <10vugtq$15a62$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
2) Linus is on the wrong side of the microkernel argument. There was a >>>>performance argument 30 years ago, but that argument no longer exists >>>>in today's world. We need to get today's monolithic and fully privileged >>>>kernels broken up and isolated into a microkernel infrastructure.
Next time you get some Linux patch notifications, spend some time >>>>reading the kernel ones and following the CVEs and then remember all >>>>those bugs are running in one single fully privileged address space.
Microkernels are a lot more secure and robust than monolithic kernels.
This bears some scrutiny. In particular, what are the assumed
characteristics of microkernels that make them more secure
and/or robust, in your estimation?
More secure:
Outside of the core functionality, which must remain in kernel mode,
I think if security is our major criteria, one must define what
one means by "core functionality". Is that memory management?
Handling interrupts? Process scheduling? Core block storage
abstractions, or something else?
There are drivers and components even in a microkernel that if you
manage to compromise you could still use to do damage but you now
face the harder job of getting to them because they are isolated
in user processes behind those message interfaces.
Any non-trivial message in a message-passing system must be
stored in memory somewhere, unless the message passing interface
restricts itself to only passing messages that fit in the
machine's registers, and requires the ukernel core to copy those
around. That opens up new challenges, and avenues for attack,
including speculating on the contents of messages.
Also in reality, and sadly also based on history, that is indeed looking >>like the OS.
I'm not sure it _can_ be the OS. Consider the "boot problem":
you've got a fancy secure ukernel-based OS, but the OS image:
the ukernel and all the little programs that make it up, are
copied into a file or files on a block storage device that's at
the far end of a PCIe link. But on a lot of systems you need
systems software running on the cores you want to boot your OS
to configure those links and kick of the LTSSM to bring them up
before you can load the OS.
MAC policies can very tightly lock down resources for different services >>running on the same server. For example, different services can be given >>access to different collections of network ports, which malware cannot >>override. Likewise, you can tightly label different parts of filesystems >>with various MAC labels.
Running one service per container may be a partial solution, but you
still need a container-specific firewall because by removing MAC, you
have just given the malware the ability to open whatever ports it wants,
at least within the container. Also, at some point, those different >>services may need to share data so you are back to the controlling access >>to the filesystem problem.
Well, note that I didn't say "containers" I said "containment",
which is different.
I have no doubt that MAC policies can do it. I question whether
focusing on a MAC policy as the solution ignores the larger
problem, and if other mechanisms may be usefully employed here.
A capability-based system, for example, has many of the same
properties.
On 2026-06-04, John Dallman <jgd@cix.co.uk> wrote:
What is "really secure"? The military have brute-force answers to that,
via air gaps, but nobody want to buy such systems. Few are willing to pay
for any security overheads.
...
Any additions to this list ?
On 2026-06-10, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
In article <1109q72$8pnm$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
On 2026-06-08, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
In article <10vugtq$15a62$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote: >>>>>2) Linus is on the wrong side of the microkernel argument. There was a >>>>>performance argument 30 years ago, but that argument no longer exists >>>>>in today's world. We need to get today's monolithic and fully privileged >>>>>kernels broken up and isolated into a microkernel infrastructure.
This bears some scrutiny. In particular, what are the assumed
Next time you get some Linux patch notifications, spend some time >>>>>reading the kernel ones and following the CVEs and then remember all >>>>>those bugs are running in one single fully privileged address space.
Microkernels are a lot more secure and robust than monolithic kernels. >>>>
characteristics of microkernels that make them more secure
and/or robust, in your estimation?
More secure:
Outside of the core functionality, which must remain in kernel mode,
I think if security is our major criteria, one must define what
one means by "core functionality". Is that memory management?
Handling interrupts? Process scheduling? Core block storage
abstractions, or something else?
There isn't one answer to that question as it varies by microkernel
design. Simon's answer is "the smaller the kernel footprint the better". :-)
[snip]
There are drivers and components even in a microkernel that if you
manage to compromise you could still use to do damage but you now
face the harder job of getting to them because they are isolated
in user processes behind those message interfaces.
Any non-trivial message in a message-passing system must be
stored in memory somewhere, unless the message passing interface
restricts itself to only passing messages that fit in the
machine's registers, and requires the ukernel core to copy those
around. That opens up new challenges, and avenues for attack,
including speculating on the contents of messages.
Yes. Another way of looking at it is from the economic point of view.
In other words, to try and make the cost of mounting an attack against
you greater than the benefits an attacker gains from mounting that attack.
I would also argue that in addition to the technical benefits, microkernels >bring economic benefits in that they increase the costs of mounting an >attack.
Also in reality, and sadly also based on history, that is indeed looking >>>like the OS.
I'm not sure it _can_ be the OS. Consider the "boot problem":
you've got a fancy secure ukernel-based OS, but the OS image:
the ukernel and all the little programs that make it up, are
copied into a file or files on a block storage device that's at
the far end of a PCIe link. But on a lot of systems you need
systems software running on the cores you want to boot your OS
to configure those links and kick of the LTSSM to bring them up
before you can load the OS.
[snip long very interesting case]
The lack of trust is the deal breaker here.
That trust has been lost, both politically (which may be fixable
in 10-15 years), and technically (which is not fixable now we know
what those blobs and hardware contain).
You don't continue to employ a maid once they have been caught stealing
from you. Likewise, something very, very dramatic would have to
happen before trust in the current infrastructure could be restored.
So the question is: does the boot-up architecture really need to be
this complex ? Do we tradeoff, say, a 20% performance loss, to get
a far easier to verify architecture that _we_ and not the vendor
controls ?
Does that more simple architecture even have unexpected benefits such
as reduced power consumption ?
MAC policies can very tightly lock down resources for different services >>>running on the same server. For example, different services can be given >>>access to different collections of network ports, which malware cannot >>>override. Likewise, you can tightly label different parts of filesystems >>>with various MAC labels.
Running one service per container may be a partial solution, but you >>>still need a container-specific firewall because by removing MAC, you >>>have just given the malware the ability to open whatever ports it wants, >>>at least within the container. Also, at some point, those different >>>services may need to share data so you are back to the controlling access >>>to the filesystem problem.
Well, note that I didn't say "containers" I said "containment",
which is different.
Yes, I know. You did say "containment" and the only thing I know of
that currently exists which can even begin to help is MAC based security.
and that by itself may not be enough in all cases.
Containers certainly are not enough, which is why I raised them as an >example. (In the past, when I have talked about MAC based security,
some people seem to have jumped straight to containers as an alternative
for some reason.)
I have no doubt that MAC policies can do it. I question whether
focusing on a MAC policy as the solution ignores the larger
problem, and if other mechanisms may be usefully employed here.
A capability-based system, for example, has many of the same
properties.
Which is something I now would very much like to see deployed in early >general use (now I know there's finally movement in this area), so we
can see how it works against real-world security threats. There is
something potentially very exciting there but it's no good until we've
got something we can work with to see if the potential matches reality.
On 2026-06-10, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
No, what happened is not at all what happened. I suppose there
is nothing immediately classified about, say, weapons serial
numbers, but that data should never have been collected together
on NIPR in that way.
Tut, tut, Dan. They should have told you differently than that back
in your military academy... :-)
https://en.wikipedia.org/wiki/German_tank_problem
Simon.
PS: Above tone is very much good natured...
In article <110ed5h$1frq7$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
On 2026-06-10, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
The lack of trust is the deal breaker here.
That trust has been lost, both politically (which may be fixable
in 10-15 years), and technically (which is not fixable now we know
what those blobs and hardware contain).
Sadly, I'm not sure that it is. It's one thing to know _how_ to
write the software; it's another thing entirely to get it into a
CPU and get the CPU to use it. On AMD parts, for example, you
cannot easily replace the firmware on the ASP, even if you could
write it yourself; the ASP really need a signed image (measuring
and loading happens very early in boot) and the verification key
is in a secure enclave that is very difficult to replace unless
you are AMD.
Does that more simple architecture even have unexpected benefits such
as reduced power consumption ?
Probably, but if you're trading speed for simplicity, you need
more of them to handle the same workload, so you might end up
with net greater power consumption.
That said, every now and again something comes along that is a
dramatic simplication. Again, I'll use PCI as my example,
specifically MSI: Message Signaled Interrupts. The original PCI
spec defined a parallel bus with four active-low,
level-triggered lines for signaling interrupts. Figuring out
what line on what device was connected to which input on the
interrupt controller was super annoying, especially as SMP
machines started to become common. So called "PCI Interrupt
Routing" required support from the BIOS (or deep knowledge of a
particular system, which was not portable). Moreover, because
interrupts were signaled over an electrical channel independent
of memory, it was possible to get an interrupt for a completed
DMA while the DMA was still in-flight.
To address this, PCI introduced Message Signaled Interrupts,
where a particular kind of PCI message (sent over the normal
memory-oriented bus) could be used to signal an interrupt; to
make use of this, you just wrote into a pair of registers that
were exposed through a capability in PCI config space. The data
you wrote included a CPU you wanted to send the interrupt to,
and the vector your wanted to use on that CPU. It was a
dramatic simplification, faster, and avoided the entire issue
with sequencing between DMA and interrupts.
The point is, simplification can yield unexpected benefits for
system designers, but we tend towards these local maxima until
something happens that forces us to shift our focus.
Yes, I know. You did say "containment" and the only thing I know of
that currently exists which can even begin to help is MAC based security. >>and that by itself may not be enough in all cases.
Containers certainly are not enough, which is why I raised them as an >>example. (In the past, when I have talked about MAC based security,
some people seem to have jumped straight to containers as an alternative >>for some reason.)
I would point to capabilities as an alternative. seL4, Fuchsia,
etc, are examples here.
Which is something I now would very much like to see deployed in early >>general use (now I know there's finally movement in this area), so we
can see how it works against real-world security threats. There is >>something potentially very exciting there but it's no good until we've
got something we can work with to see if the potential matches reality.
I think there is some precedence here.
I suspect this has little to do with VMS, though. One wonders
if we should lobby to bring back comp.os.research ?
On 2026-06-13, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
In article <110ed5h$1frq7$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
On 2026-06-10, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
The lack of trust is the deal breaker here.
That trust has been lost, both politically (which may be fixable
in 10-15 years), and technically (which is not fixable now we know
what those blobs and hardware contain).
Sadly, I'm not sure that it is. It's one thing to know _how_ to
write the software; it's another thing entirely to get it into a
CPU and get the CPU to use it. On AMD parts, for example, you
cannot easily replace the firmware on the ASP, even if you could
write it yourself; the ASP really need a signed image (measuring
and loading happens very early in boot) and the verification key
is in a secure enclave that is very difficult to replace unless
you are AMD.
We are really screwed as a society. We just don't know it yet. :-(
We have been lulled into a false sense of complacency because we no
longer see ourselves as being threatened by existential-level threats.
Boy, are we wrong about that.
Someone who gets control over that kind of firmware at that level or
the next few levels up can use it to extort/cripple entire countries
into conforming to their will and there's not a damn thing they can
do about it.
Firmware, BTW, written to a budget and shipped once it "appears" to work.
[snip]
Yes, I know. You did say "containment" and the only thing I know of
that currently exists which can even begin to help is MAC based security. >>>and that by itself may not be enough in all cases.
Containers certainly are not enough, which is why I raised them as an >>>example. (In the past, when I have talked about MAC based security,
some people seem to have jumped straight to containers as an alternative >>>for some reason.)
I would point to capabilities as an alternative. seL4, Fuchsia,
etc, are examples here.
Yes, I know about these, but they are implemented in software and do
not exist in production-ready OSes that you can use off the shelf.
I would also really like to see this taken to the next level and see
this functionality implemented in hardware (which takes us several
messages back. :-))
Also a line from the ACM report has stuck in my memory, which I repeat
here as a warning:
"We assume correctness of compiler, assembly code, hardware, and boot code."
https://cacm.acm.org/research/sel4-formal-verification-of-an-operating-system-kernel/
Which is something I now would very much like to see deployed in early >>>general use (now I know there's finally movement in this area), so we
can see how it works against real-world security threats. There is >>>something potentially very exciting there but it's no good until we've >>>got something we can work with to see if the potential matches reality.
I think there is some precedence here.
I suspect this has little to do with VMS, though. One wonders
if we should lobby to bring back comp.os.research ?
It is always nice to explore new ideas, and learn from them, especially
in a world that is actively moving towards implement-as-cheap-as-possible >monocultures.
Also a line from the ACM report has stuck in my memory, which I repeat
here as a warning:
"We assume correctness of compiler, assembly code, hardware, and boot code."
https://cacm.acm.org/research/sel4-formal-verification-of-an-operating-system-kernel/
In article <110s65k$1bd6t$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
Yes, I know about these, but they are implemented in software and do
not exist in production-ready OSes that you can use off the shelf.
Not true; check out Capsicum: https://www.cl.cam.ac.uk/research/security/capsicum/
I don't know what's been going on with it recently, but it's an
interesting project to follow, and showed the practicality of
the approach in real systems.
It is always nice to explore new ideas, and learn from them, especially
in a world that is actively moving towards implement-as-cheap-as-possible >>monocultures.
I don't know that we are, anymore. It seems to me that we're
heading for a world where you have to pay to play, and doing so enthusiastically, as fast as we can. It's weird to me that so
many people are putting so much faith into LLMs so quickly, but
here we are; the VC money is obviously subsidizing the costs for
now, but once that dries up.... Anyway, my point is, I think "implement-as-cheap-as-possible" might be going away.
Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
Also a line from the ACM report has stuck in my memory, which I repeat
here as a warning:
"We assume correctness of compiler, assembly code, hardware, and boot code." >>
https://cacm.acm.org/research/sel4-formal-verification-of-an-operating-system-kernel/
IIRC compiler correctness and translation to binary was handled in later work. They did not prove compiler correctness, rather they were able to correlate compiler generated code with source and prove that generated
code matches semantics of the source.
So, what remains is hardware, and boot code.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 70 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 39:14:50 |
| Calls: | 948 |
| Calls today: | 2 |
| Files: | 1,325 |
| Messages: | 280,644 |