On Thu, 4 Jan 2024 22:09:12 -0500, Arne Vajhøj wrote:
I was not comparing "Linux port to Alpha" with "VSI actual port of VMS
to x86-64" but to "hypothetical port of VMS to being on top of Linux
kernel".
Remember, I’m not talking about porting the whole of VMS, just the part that users care about: userland executables and DCL command procedures. That’s it.
[lots of interesting stuff omitted]
From another time and place, a DEC Usenix paper from way back in 1992 discussing a kernel-swap project: http://fossies.org/linux/freevms/doc/Usenix_VMS-on-Mach.PS
From a reference to that work: "In 1992, a development team from Digital Equipment described a proof-of-concept implementation of VMS on Mach
3.0. ... Their work provided independent confirmation that multiple OS personalities could be supported on the Mach microkernel. At the same
time, it exposed certain limitations. For example, it proved impossible
to accurately emulate VMS scheduling policies using Mach.
As another example, it was not possible to emulate VMS’ strong isolation
of kernel resource usage by different users.
Preliminary measurements also
suggested that layering VMS on Mach resulted in unacceptable performance overhead.
On Fri, 5 Jan 2024 19:59:12 -0500, Stephen Hoffman wrote:
[lots of interesting stuff omitted]
From another time and place, a DEC Usenix paper from way back in 1992
discussing a kernel-swap project:
http://fossies.org/linux/freevms/doc/Usenix_VMS-on-Mach.PS
From a reference to that work: "In 1992, a development team from
Digital Equipment described a proof-of-concept implementation of VMS on
Mach 3.0. ... Their work provided independent confirmation that
multiple OS personalities could be supported on the Mach microkernel.
At the same time, it exposed certain limitations. For example, it
proved impossible to accurately emulate VMS scheduling policies using
Mach.
That can be blamed on the limitations of Mach. People still seem to
think microkernels are somehow a good idea, but they really don’t help much, do they?
As another example, it was not possible to emulate VMS’ strong
isolation of kernel resource usage by different users.
Would the Linux cgroups functionality (as commonly used in the various container schemes) help with this?
Preliminary measurements also suggested that layering VMS on Mach
resulted in unacceptable performance overhead.
No big surprise -- microkernel trouble yet again.
On 2024-01-06 02:48:42 +0000, Lawrence D'Oliveiro said:
That can be blamed on the limitations of Mach. People still seem to
think microkernels are somehow a good idea, but they really don’t help
much, do they?
With current hardware including cores and performance and with newer message-passing designs such as OKL4 and ilk, some things are looking
rather better.
As another example, it was not possible to emulate VMS’ strong
isolation of kernel resource usage by different users.
Would the Linux cgroups functionality (as commonly used in the various
container schemes) help with this?
No.
Designers of VAX/VMS chose a memory management model closer to that of Multics, where much of the rest of hardware and software in the industry diverged from that lotsa-rings memory management design.
Containers are arguably fundamentally about product-licensing arbitrage,
too.
Microkernels are in use all over the place nowadays, seL4-, L4-, and OKL4-derived.
For a small development team—and VSI is tiny—kernel transplantation doesn't gain much from a technical basis, once the platform port is completed. It might help with future ports, sure.
On Sat, 6 Jan 2024 13:36:59 -0500, Stephen Hoffman wrote:
On 2024-01-06 02:48:42 +0000, Lawrence D'Oliveiro said:
That can be blamed on the limitations of Mach. People still seem to
think microkernels are somehow a good idea, but they really don’t help >>> much, do they?
With current hardware including cores and performance and with newer
message-passing designs such as OKL4 and ilk, some things are looking
rather better.
Hope springs eternal in the microkernel aficionado’s breast. ;)
As another example, it was not possible to emulate VMS’ strong
isolation of kernel resource usage by different users.
Would the Linux cgroups functionality (as commonly used in the various
container schemes) help with this?
No.
Designers of VAX/VMS chose a memory management model closer to that of
Multics, where much of the rest of hardware and software in the industry
diverged from that lotsa-rings memory management design.
Seems you are confusing two different things here. I am aware of the user/ >supervisor/exec/kernel privilege-level business, but you did say "resource >usage by different *users*". cgroups are indeed designed to manage that.
Remember that my proposal for adopting the Linux kernel would get rid of >every part of VMS that currently runs at higher than user mode. It's only >their own user-mode code that customers would care about.
Containers are arguably fundamentally about product-licensing arbitrage,
too.
I don't use them that way. I use them as a cheap way to run up multiple
test installations of things I am working on, instead of resorting to full >VMs. Typically it only takes a few gigabytes to create a new userland for
a container. E.g. on this machine I am using now:
root@theon:~ # du -ks /var/lib/lxc/*/rootfs/
1700060 /var/lib/lxc/debian10/rootfs/
7654028 /var/lib/lxc/debian11/rootfs/
876568 /var/lib/lxc/debian12/rootfs/
Microkernels are in use all over the place nowadays, seL4-, L4-, and
OKL4-derived.
Really?? Can you name some deployments? How would performance compare with >Linux? Because, let's face it, Linux is the standard for high-performance >computing.
For a small development team—and VSI is tiny—kernel transplantation
doesn't gain much from a technical basis, once the platform port is
completed. It might help with future ports, sure.
Which was my point all along: if they'd done this for the AMD64 port from
the beginning, they would have shaved *years* off the development time.
And likely ended up with a somewhat larger (remaining) customer base than >they have now.
But that's not what he actually said: you omitted the critical word, "kernel", as in _kernel resources_ used by different users.
Remember that my proposal for adopting the Linux kernel would get rid of >>every part of VMS that currently runs at higher than user mode. It's
only their own user-mode code that customers would care about.
You think that's easy, but it is clear that you really don't understand
the issues involved.
Containers started as a way to run multiple versions of some very large programs with disparate library and other dependencies on a single
system, and grew into a mechanism for managing resources generally.
Every Mac on the planet runs more or less a version of Mach+BSD.
The Intel ME embedded in most Intel CPUs runs Minix3.
On Sat, 6 Jan 2024 20:31:22 -0000 (UTC), Dan Cross wrote:
But that's not what he actually said: you omitted the critical word,
"kernel", as in _kernel resources_ used by different users.
Since *all* resources are defined (and managed) as such by the kernel, I
fail to see what the distinction is.
cgroups let you manage CPU time usage and CPU affinity (are CPUs a
"kernel" resource?), memory usage (is that a "kernel" resource?), I/O
usage (is that a "kernel" resource?), RDMA usage (is that a "kernel" >resource?), numbers of processes created (is that "kernel" resource?)
etc etc.
Otherwise, feel free to explain what the distinction is between a "user" >resource and a "kernel" resource.
Remember that my proposal for adopting the Linux kernel would get rid of >>>every part of VMS that currently runs at higher than user mode. It's
only their own user-mode code that customers would care about.
You think that's easy, but it is clear that you really don't understand
the issues involved.
The poster I was replying to already conceded this point.
Containers started as a way to run multiple versions of some very large
programs with disparate library and other dependencies on a single
system, and grew into a mechanism for managing resources generally.
You are thinking of Docker.
Which is just one kind of "container"
technology. Remember that "containers" as such do not exist as a built-in >primitive in the Linux kernel: they are constructed out of a bunch of >lower-level primitives, including cgroups and the various kinds of >namespaces. This allows for very different kinds of technologies to be
built that call themselves "containers". And for them to coexist.
Every Mac on the planet runs more or less a version of Mach+BSD.
And doesn't exactly do so well.
Back when Apple sold servers, I remember a
review of MySQL running on OS X Server versus Linux, on the same hardware.
Linux ran circles around Apple's microkernel-based OS. On the company's
own hardware.
The Intel ME embedded in most Intel CPUs runs Minix3.
Bad, bad example. ><https://arstechnica.com/information-technology/2017/05/the-hijacking- >flaw-that-lurked-in-intel-chips-is-worse-than-anyone-thought/>
On Sat, 6 Jan 2024 13:36:59 -0500, Stephen Hoffman wrote:
On 2024-01-06 02:48:42 +0000, Lawrence D'Oliveiro said:
That can be blamed on the limitations of Mach. People still seem to
think microkernels are somehow a good idea, but they really don’t help >>> much, do they?
With current hardware including cores and performance and with newer
message-passing designs such as OKL4 and ilk, some things are looking
rather better.
Hope springs eternal in the microkernel aficionado’s breast. ;)
As another example, it was not possible to emulate VMS’ strong
isolation of kernel resource usage by different users.
Would the Linux cgroups functionality (as commonly used in the various
container schemes) help with this?
No.
Designers of VAX/VMS chose a memory management model closer to that of
Multics, where much of the rest of hardware and software in the
industry diverged from that lotsa-rings memory management design.
Seems you are confusing two different things here. I am aware of the user/supervisor/exec/kernel privilege-level business, but you did say “resource usage by different *users*”. cgroups are indeed designed to manage that.
Remember that my proposal for adopting the Linux kernel would get rid
of every part of VMS that currently runs at higher than user mode. It’s only their own user-mode code that customers would care about.
Containers are arguably fundamentally about product-licensing arbitrage, too.
I don’t use them that way. I use them as a cheap way to run up multiple
test installations of things I am working on, instead of resorting to
full VMs. Typically it only takes a few gigabytes to create a new
userland for a container. E.g. on this machine I am using now:
root@theon:~ # du -ks /var/lib/lxc/*/rootfs/
1700060 /var/lib/lxc/debian10/rootfs/
7654028 /var/lib/lxc/debian11/rootfs/
876568 /var/lib/lxc/debian12/rootfs/
Microkernels are in use all over the place nowadays, seL4-, L4-, and
OKL4-derived.
Really?? Can you name some deployments? How would performance compare
with Linux? Because, let’s face it, Linux is the standard for high-performance computing.
For a small development team—and VSI is tiny—kernel transplantation
doesn't gain much from a technical basis, once the platform port is
completed. It might help with future ports, sure.
Which was my point all along: if they’d done this for the AMD64 port
from the beginning, they would have shaved *years* off the development
time. And likely ended up with a somewhat larger (remaining) customer
base than they have now.
First, complete the 64-bit API, after all these years. It's a fairly well-defined task, but I don't know how big it is.
*glances at thicket of C API definitions*
*rolls eyes at itemlists*
*sighs and drags BASIC forward to 64-bit and OO*
On 2024-01-06 15:30:00 +0000, John Dallman said:
First, complete the 64-bit API, after all these years. It's aThere's no way to do that without breaking source-level
fairly well-defined task, but I don't know how big it is.
compatibility, and probably not without also doing a migration to a
parallel set of 64-bit APIs.
Basically, the image activator examines the image and decides which implementation to activate within; the existing 32- and 64-bit implementation, or 64-bit new.
In article <unk7ka$24i3c$1@dont-email.me>, seaohveh@hoffmanlabs.invalid (Stephen Hoffman) wrote:
On 2024-01-06 15:30:00 +0000, John Dallman said:
First, complete the 64-bit API, after all these years. It's aThere's no way to do that without breaking source-level
fairly well-defined task, but I don't know how big it is.
compatibility, and probably not without also doing a migration to a
parallel set of 64-bit APIs.
Basically, the image activator examines the image and decides which
implementation to activate within; the existing 32- and 64-bit
implementation, or 64-bit new.
I was presuming that the 64-bit VMS APIs would have 64-bit specific names,
as the 64-bit versions that already do, as best I know. That would means there were a full set of APIs, both 32-bit and 64-bit, at OS level, in
the same implementation.
Cross-compiled MACRO-32 code could then gradually transition between them,
by source adaptation. Higher-level languages could offer compiler options
for selecting APIs.
Or does this not make sense?
On Tue, 9 Jan 2024 14:43:06 -0500, Stephen Hoffman wrote:
*sighs and drags BASIC forward to 64-bit and OO*
BASIC ... you got to be kidding, right?
If kids wanted to learn programming these days, I would point them at
Python.
And again, what you are interested here in has been available for many
years via Sector 7.
Or use the same names, and just link against different versions of
the libraries, located in suitable architecture-specific
directories, as selected by the build script.
I suspect that all direct calls to LIB$ and SYS$ no matter if it is
Macro-32 or Fortran or C would have to be manually edited to use
new 64 bit capable version, but that the various language RTL
could switch to 64 bit capable versions transparently.
I was presuming that the 64-bit VMS APIs would have 64-bit specific
names ...
In article <unkdkr$25et9$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 9 Jan 2024 21:06 +0000 (GMT Standard Time), John Dallman wrote:
I was presuming that the 64-bit VMS APIs would have 64-bit specific
names ...
Or use the same names, and just link against different versions of the >>libraries, located in suitable architecture-specific directories, as >>selected by the build script.
Linux did it with different versions in different directories with the
same name. Solaris did it with different names. In the end the Solaris route was much less frustrating to debug.
On Tue, 9 Jan 2024 21:06 +0000 (GMT Standard Time), John Dallman wrote:
I was presuming that the 64-bit VMS APIs would have 64-bit specific
names ...
Or use the same names, and just link against different versions of the >libraries, located in suitable architecture-specific directories, as
selected by the build script.
On 2024-01-06 15:30:00 +0000, John Dallman said:
First, complete the 64-bit API, after all these years. It's a fairly
well-defined task, but I don't know how big it is.
There's no way to do that without breaking source-level compatibility, and probably not without also doing a migration to a parallel set of 64-bit APIs.
Basically, the image activator examines the image and decides which implementation to activate within; the existing 32- and 64-bit implementation,
or 64-bit new.
This implementation and this migration would also provide an opportunity to toss
out the most problematic parts of the existing APIs. *stares at password hash
APIs* *glances at thicket of C API definitions* *rolls eyes at itemlists* *sighs
and drags BASIC forward to 64-bit and OO*
Some work in the linker and in the image activator here, and a whole lot of work
in the various user and kernel APIs, and work in app code ranging from build procedures to an app overhaul. And work in the docs too, of course.
On Tue, 9 Jan 2024 14:43:06 -0500, Stephen Hoffman wrote:
*glances at thicket of C API definitions*
The design of VMS system calls, with lots of arguments, most of them optional, is really bad for a language that don’t allow argument passing
by keyword. But I would say that’s the fault of the language.
*rolls eyes at itemlists*
I always thought they were kind of neat. What’s a better alternative for exensibility?
*sighs and drags BASIC forward to 64-bit and OO*
BASIC ... you got to be kidding, right?
If kids wanted to learn programming these days, I would point them at
Python.
Ok, correct me if I'm wrong.
As far as I know, totally 64 bit apps can be implemented on VMS. So,
what's the problem. The fact that there is also that 32 bit capability hanging around should not be a detriment, right?
I seriously doubt that any Basic users would take advantage of a
conversion to 64 bit addresses. So why bother?
In article <unkd47$25cg2$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj) wrote:
I suspect that all direct calls to LIB$ and SYS$ no matter if it is
Macro-32 or Fortran or C would have to be manually edited to use
new 64 bit capable version, but that the various language RTL
could switch to 64 bit capable versions transparently.
With a sufficiently regular naming scheme, a compiler could make substitutions, but I don't know if the current scheme will cope.
On 1/9/2024 3:19 PM, Lawrence D'Oliveiro wrote:
BASIC ... you got to be kidding, right?Bigot alert ....
If kids wanted to learn programming these days, I would point them at
Python.
I seriously doubt that any [noddy] users would take advantage of a
conversion to 64 bit addresses. So why bother?
On 9 Jan 2024 22:56:47 -0000, Scott Dorsey wrote:
In article <unkdkr$25et9$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 9 Jan 2024 21:06 +0000 (GMT Standard Time), John Dallman wrote:
I was presuming that the 64-bit VMS APIs would have 64-bit specific
names ...
Or use the same names, and just link against different versions of the >>>libraries, located in suitable architecture-specific directories, as >>>selected by the build script.
Linux did it with different versions in different directories with the
same name. Solaris did it with different names. In the end the Solaris
route was much less frustrating to debug.
Solaris never ran on 2 dozen different architectures though, did it?
In article <unkjij$26ao8$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On 9 Jan 2024 22:56:47 -0000, Scott Dorsey wrote:
In article <unkdkr$25et9$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 9 Jan 2024 21:06 +0000 (GMT Standard Time), John Dallman
wrote:
I was presuming that the 64-bit VMS APIs would have 64-bit specific
names ...
Or use the same names, and just link against different versions of the >>>>libraries, located in suitable architecture-specific directories, as >>>>selected by the build script.
Linux did it with different versions in different directories with the
same name. Solaris did it with different names. In the end the
Solaris route was much less frustrating to debug.
Solaris never ran on 2 dozen different architectures though, did it?
Not at the same time. Only two at the same time.
On Tue, 9 Jan 2024 18:33:13 -0500, Dave Froble wrote:
I seriously doubt that any [noddy] users would take advantage of a
conversion to 64 bit addresses. So why bother?
In the x86-32/x86-64 situation in particular, the 32-bit architecture is known for being register-poor. This is alleviated somewhat in the 64-bit extensions. This means a compiler can generate more efficient code using
the 64-bit instructions.
On 1/9/2024 4:35 PM, John Dallman wrote:
In article <unkd47$25cg2$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhj)
wrote:
I suspect that all direct calls to LIB$ and SYS$ no matter if it is
Macro-32 or Fortran or C would have to be manually edited to use
new 64 bit capable version, but that the various language RTL
could switch to 64 bit capable versions transparently.
With a sufficiently regular naming scheme, a compiler could make
substitutions, but I don't know if the current scheme will cope.
If the arguments are simple buffer addresses, then maybe the
compiler could do something.
But what with more complex data structures like item lists?
A Fortran compiler could add a 64 to the function name called and
could pass a 64 bit descriptor instead of a 32 bit descriptor for
a string. But I can't imagine it changing all the addresses
in an item list from INTEGER*4 to INTEGER*8.
On Tue, 9 Jan 2024 14:32:48 -0500, Stephen Hoffman wrote:
And again, what you are interested here in has been available for many
years via Sector 7.
I?m not sure they did a comprehensive enough job. For instance, I remember the previous time this came up, reading between the lines in one of their case studies, the original customer scenario mentioned using DECnet, but
that was missiong from the description of the solution.
As far as I know, totally 64 bit apps can be implemented on VMS. So, what's the
problem. The fact that there is also that 32 bit capability hanging around should not be a detriment, right?
On 2024-01-09, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 9 Jan 2024 14:32:48 -0500, Stephen Hoffman wrote:
And again, what you are interested here in has been available for many
years via Sector 7.
I?m not sure they did a comprehensive enough job. For instance, I remember >> the previous time this came up, reading between the lines in one of their
case studies, the original customer scenario mentioned using DECnet, but
that was missiong from the description of the solution.
DECnet should not be in use in today's security world and a customer
should have been forced away from using DECnet anyway due to external auditing and security standards.
On 2024-01-09, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 9 Jan 2024 14:32:48 -0500, Stephen Hoffman wrote:
And again, what you are interested here in has been available for many
years via Sector 7.
I?m not sure they did a comprehensive enough job. For instance, I
remember the previous time this came up, reading between the lines in
one of their case studies, the original customer scenario mentioned
using DECnet, but that was missiong from the description of the
solution.
DECnet should not be in use in today's security world and a customer
should have been forced away from using DECnet anyway due to external auditing and security standards.
2. Run DECnet phase IV. Install pyDECnet on any host in your LAN that supports python (I use a dedicated raspberry pi).
On 2024-01-09, Dave Froble <davef@tsoft-inc.com> wrote:
As far as I know, totally 64 bit apps can be implemented on VMS. So, what's the
problem. The fact that there is also that 32 bit capability hanging around >> should not be a detriment, right?
Try using RMS in totally 64-bit mode. Unless there's been further
development since, not everything in RMS had a 64-bit address option.
Simon.
Nowadays, the whole Internet is built on the concept of running secure protocols over insecure channels. Those secure protocols can in turn be channels for older, insecure protocols--this is not rocket science.
On 1/10/24 6:40 AM, Simon Clubley wrote:
On 2024-01-09, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:.
On Tue, 9 Jan 2024 14:32:48 -0500, Stephen Hoffman wrote:
And again, what you are interested here in has been available for many >>>> years via Sector 7.
I?m not sure they did a comprehensive enough job. For instance, I remember >>> the previous time this came up, reading between the lines in one of their >>> case studies, the original customer scenario mentioned using DECnet, but >>> that was missiong from the description of the solution.
DECnet should not be in use in today's security world and a customer
should have been forced away from using DECnet anyway due to external
auditing and security standards.
.
.
Hogwash. DECnet can be made just as secure as any IP communication by
simply using IP transports. A couple of simple examples:
1. Run DECnet phase V. Use DECnet-over-IP, and encrypt it with IPSEC
before it ever leaves your host. This not only encrypts all of your
DECnet traffic but it means that DECnet proxies are now as secure as
your IPSEC profile.
1a. If you are running OpenVMS on x86, TCP/IP Services does not
currently provide IPSEC and Multinet is not yet available. However,
VMware ESXi does support IPSEC. You can configure your ESXi host to do
the encryption for you. You just need to do your DECnet-over-IP traffic using IPv6.
2. Run DECnet phase IV. Install pyDECnet on any host in your LAN that supports python (I use a dedicated raspberry pi). This will be your
DECnet router. Isolate DECnet traffic to its own VLAN. All off-LAN
DECnet traffic is encrypted by the pyDECnet host, again, likely using IPSEC.
More security that this is possible. If you have a security requirement
this doesn't meet, let me know.
On 1/10/2024 8:43 AM, Simon Clubley wrote:
On 2024-01-09, Dave Froble <davef@tsoft-inc.com> wrote:
As far as I know, totally 64 bit apps can be implemented on VMS. So, what's the
problem. The fact that there is also that 32 bit capability hanging around >>> should not be a detriment, right?
Try using RMS in totally 64-bit mode. Unless there's been further
development since, not everything in RMS had a 64-bit address option.
My understanding, which could be totally wrong, is that the major concept of "64
bit" is about addresses.
On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
On 1/10/2024 8:43 AM, Simon Clubley wrote:
On 2024-01-09, Dave Froble <davef@tsoft-inc.com> wrote:
As far as I know, totally 64 bit apps can be implemented on VMS. So, what's the
problem. The fact that there is also that 32 bit capability hanging around
should not be a detriment, right?
Try using RMS in totally 64-bit mode. Unless there's been further
development since, not everything in RMS had a 64-bit address option.
My understanding, which could be totally wrong, is that the major concept of "64
bit" is about addresses.
And that is exactly what I am talking about. Not everything in RMS had
a 64-bit addressing API the last time I checked.
Simon.
On 1/11/2024 8:56 AM, Simon Clubley wrote:
On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
On 1/10/2024 8:43 AM, Simon Clubley wrote:
On 2024-01-09, Dave Froble <davef@tsoft-inc.com> wrote:
As far as I know, totally 64 bit apps can be implemented on VMS. So, what's the
problem. The fact that there is also that 32 bit capability hanging around
should not be a detriment, right?
Try using RMS in totally 64-bit mode. Unless there's been further
development since, not everything in RMS had a 64-bit address option.
My understanding, which could be totally wrong, is that the major concept of "64
bit" is about addresses.
And that is exactly what I am talking about. Not everything in RMS had
a 64-bit addressing API the last time I checked.
Simon.
Then I have to ask, "so what?"=
If RMS doesn't fit your requirements, then don't use it.
What does it matter how RMS works internally?
Perhaps I'm just the old dog that cannot learn new tricks?
On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
On 1/11/2024 8:56 AM, Simon Clubley wrote:
On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
On 1/10/2024 8:43 AM, Simon Clubley wrote:
On 2024-01-09, Dave Froble <davef@tsoft-inc.com> wrote:My understanding, which could be totally wrong, is that the major concept of "64
As far as I know, totally 64 bit apps can be implemented on VMS. So, what's the
problem. The fact that there is also that 32 bit capability hanging around
should not be a detriment, right?
Try using RMS in totally 64-bit mode. Unless there's been further
development since, not everything in RMS had a 64-bit address option. >>>>
bit" is about addresses.
And that is exactly what I am talking about. Not everything in RMS had
a 64-bit addressing API the last time I checked.
Then I have to ask, "so what?"=
You claimed that "totally 64 bit apps can be implemented on VMS".
I am showing you why that is not the case.
If RMS doesn't fit your requirements, then don't use it.
Everyone uses RMS, even if it hidden from you by the language. The RMS references are still in the executable you create however.
On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
On 1/11/2024 8:56 AM, Simon Clubley wrote:
On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
On 1/10/2024 8:43 AM, Simon Clubley wrote:
On 2024-01-09, Dave Froble <davef@tsoft-inc.com> wrote:
As far as I know, totally 64 bit apps can be implemented on VMS. So, what's the
problem. The fact that there is also that 32 bit capability hanging around
should not be a detriment, right?
Try using RMS in totally 64-bit mode. Unless there's been further
development since, not everything in RMS had a 64-bit address option. >>>>>
My understanding, which could be totally wrong, is that the major concept of "64
bit" is about addresses.
And that is exactly what I am talking about. Not everything in RMS had
a 64-bit addressing API the last time I checked.
Simon.
Then I have to ask, "so what?"=
You claimed that "totally 64 bit apps can be implemented on VMS".
I am showing you why that is not the case.
If RMS doesn't fit your requirements, then don't use it.
Everyone uses RMS, even if it hidden from you by the language. The RMS references are still in the executable you create however.
What does it matter how RMS works internally?
Perhaps I'm just the old dog that cannot learn new tricks?
As above, you claimed that "totally 64 bit apps can be implemented on VMS".
I am showing you why that is not the case.
In article <unkd47$25cg2$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhj) wrote:
I suspect that all direct calls to LIB$ and SYS$ no matter if it is
Macro-32 or Fortran or C would have to be manually edited to use new 64
bit capable version, but that the various language RTL could switch to
64 bit capable versions transparently.
With a sufficiently regular naming scheme, a compiler could make substitutions, but I don't know if the current scheme will cope.
On Tue, 9 Jan 2024 14:32:48 -0500, Stephen Hoffman wrote:
And again, what you are interested here in has been available for many
years via Sector 7.
I’m not sure they did a comprehensive enough job. For instance, I
remember the previous time this came up, reading between the lines in
one of their case studies, the original customer scenario mentioned
using DECnet, but that was missiong from the description of the
solution.
Why would anybody pick the Linux kernel for a
transplant, over the other candidates?
On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
On 1/11/2024 8:56 AM, Simon Clubley wrote:
On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
On 1/10/2024 8:43 AM, Simon Clubley wrote:
On 2024-01-09, Dave Froble <davef@tsoft-inc.com> wrote:
As far as I know, totally 64 bit apps can be implemented on VMS. So, what's the
problem. The fact that there is also that 32 bit capability hanging around
should not be a detriment, right?
Try using RMS in totally 64-bit mode. Unless there's been further
development since, not everything in RMS had a 64-bit address option. >>>>>
My understanding, which could be totally wrong, is that the major concept of "64
bit" is about addresses.
And that is exactly what I am talking about. Not everything in RMS had
a 64-bit addressing API the last time I checked.
Simon.
Then I have to ask, "so what?"=
You claimed that "totally 64 bit apps can be implemented on VMS".
I am showing you why that is not the case.
If RMS doesn't fit your requirements, then don't use it.
Everyone uses RMS, even if it hidden from you by the language. The RMS references are still in the executable you create however.
What does it matter how RMS works internally?
Perhaps I'm just the old dog that cannot learn new tricks?
As above, you claimed that "totally 64 bit apps can be implemented on VMS".
I am showing you why that is not the case.
Simon.
On 1/11/2024 1:17 PM, Simon Clubley wrote:
On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
On 1/11/2024 8:56 AM, Simon Clubley wrote:
On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
On 1/10/2024 8:43 AM, Simon Clubley wrote:
On 2024-01-09, Dave Froble <davef@tsoft-inc.com> wrote:My understanding, which could be totally wrong, is that the major concept >>>>> of "64
As far as I know, totally 64 bit apps can be implemented on VMS. So, >>>>>>> what's the
problem. The fact that there is also that 32 bit capability hanging around
should not be a detriment, right?
Try using RMS in totally 64-bit mode. Unless there's been further
development since, not everything in RMS had a 64-bit address option. >>>>>
bit" is about addresses.
And that is exactly what I am talking about. Not everything in RMS had >>>> a 64-bit addressing API the last time I checked.
That is correct. Practically only data related fields in RAB64
supports 64 bit addresses.
Then I have to ask, "so what?"=
You claimed that "totally 64 bit apps can be implemented on VMS".
I am showing you why that is not the case.
I guess that depends on what is meant by "totally 64 bit".
If it means that all addresses stored in process space whether
user code or VMS code are stored as 64 bit then it indeed seems
unlikely.
It it means that in user code all addresses are 64 bit, then that
should be doable.
If RMS doesn't fit your requirements, then don't use it.
Everyone uses RMS, even if it hidden from you by the language. The RMS
references are still in the executable you create however.
In practice yes.
In theory one can use SYS$QIO(W) for all IO and bypass RMS. But
it is very cumbersome (especially if one cannot use RMS for stuff
like finding IFI).
Arne
On 1/11/2024 3:48 PM, Arne Vajhøj wrote:
On 1/11/2024 1:17 PM, Simon Clubley wrote:
On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
If RMS doesn't fit your requirements, then don't use it.
Everyone uses RMS, even if it hidden from you by the language. The RMS
references are still in the executable you create however.
In practice yes.
In theory one can use SYS$QIO(W) for all IO and bypass RMS. But
it is very cumbersome (especially if one cannot use RMS for stuff
like finding IFI).
And if one is using a database product that has nothing to do with RMS ???
Um, if I have a 64-bit app, that would mean I have complete access to
P0, P1, P2 space. Now, I choose to put some data structures in P0
space, does that mean that the app is suddenly no longer "totally 64-bit"?
I've written 64-bit apps. I've certainly never had to copy data from P2 space to P0 space because of some limitation. I've used both 32-bit and 64-bit item lists and descriptors, including dynamic descriptors. None
of the system services or RTL routines I used had any problem accepting
my parameters. Where in all of this, in your definition, has my app
stopped becoming a 64-bit app?
For me, it is ok for the documentation to say that a certain item needs
to be in P0 space. I have no problem putting there and I still have a
64-bit app with full access to 64-bit address space. Nothing the system requires to be in P0 space is dynamic. It is set it up and forget it
(at least as far as anything I can remember using).
On 1/12/2024 12:08 AM, Dave Froble wrote:
On 1/11/2024 3:48 PM, Arne Vajhøj wrote:
On 1/11/2024 1:17 PM, Simon Clubley wrote:
On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
If RMS doesn't fit your requirements, then don't use it.
Everyone uses RMS, even if it hidden from you by the language. The RMS >>>> references are still in the executable you create however.
In practice yes.
In theory one can use SYS$QIO(W) for all IO and bypass RMS. But
it is very cumbersome (especially if one cannot use RMS for stuff
like finding IFI).
And if one is using a database product that has nothing to do with RMS ???
I would still expect that database product to use RMS to open
the database file even if the actual IO is done by
SYS$QIO(W) / SYS$IO_PERFORM(W) or via memory mapped file.
Arne
On 2024-01-11, Mark Berryman <mark@theberrymans.com> wrote:
Um, if I have a 64-bit app, that would mean I have complete access to
P0, P1, P2 space. Now, I choose to put some data structures in P0
space, does that mean that the app is suddenly no longer "totally 64-bit"? >>
No, not if it is your choice instead of some API restriction.
I've written 64-bit apps. I've certainly never had to copy data from P2
space to P0 space because of some limitation. I've used both 32-bit and
64-bit item lists and descriptors, including dynamic descriptors. None
of the system services or RTL routines I used had any problem accepting
my parameters. Where in all of this, in your definition, has my app
stopped becoming a 64-bit app?
The moment you are forced to keep something at a location that can be
reached by a 32-bit address because of an API restriction that does not
have a 64-bit alternative, such as those seen in the RMS APIs.
That includes if the language RTL is doing the 32-bit API access for you without it ever being explicit in your code.
For me, it is ok for the documentation to say that a certain item needs
to be in P0 space. I have no problem putting there and I still have a
64-bit app with full access to 64-bit address space. Nothing the system
requires to be in P0 space is dynamic. It is set it up and forget it
(at least as far as anything I can remember using).
Yes, but that's doesn't meet David's claim of being able to create a pure 64-bit application. I was replying to that and nothing else.
Simon.
On 1/12/2024 7:23 AM, Arne Vajhøj wrote:
On 1/12/2024 12:08 AM, Dave Froble wrote:
On 1/11/2024 3:48 PM, Arne Vajhøj wrote:
On 1/11/2024 1:17 PM, Simon Clubley wrote:
On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
If RMS doesn't fit your requirements, then don't use it.
Everyone uses RMS, even if it hidden from you by the language. The RMS >>>>> references are still in the executable you create however.
In practice yes.
In theory one can use SYS$QIO(W) for all IO and bypass RMS. But
it is very cumbersome (especially if one cannot use RMS for stuff
like finding IFI).
And if one is using a database product that has nothing to do with
RMS ???
I would still expect that database product to use RMS to open
the database file even if the actual IO is done by
SYS$QIO(W) / SYS$IO_PERFORM(W) or via memory mapped file.
Your expectation would be wrong.
File opens without RMS use QIO to open a file.
I will state that the RMS PARSE routine is used to parse a filename.
On Thu, 11 Jan 2024 15:51:26 -0500, Stephen Hoffman wrote:
Why would anybody pick the Linux kernel for a transplant, over the
other candidates?
Because it already has the widest support for available hardware, and filesystems, and network protocol stacks, and security layers, and virtualization/containerization technologies, and other legacy
emulators, and other apps.
In short, it’s the place that will maximize your choices for other,
future migrations.
And that next port after x86-64 gets somewhat easier,
should LLVM support be available on the target platform.
On 1/12/2024 2:57 PM, Dave Froble wrote:
On 1/12/2024 7:23 AM, Arne Vajhøj wrote:
On 1/12/2024 12:08 AM, Dave Froble wrote:
On 1/11/2024 3:48 PM, Arne Vajhøj wrote:I would still expect that database product to use RMS to open
On 1/11/2024 1:17 PM, Simon Clubley wrote:
On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
If RMS doesn't fit your requirements, then don't use it.
Everyone uses RMS, even if it hidden from you by the language. The RMS >>>>>> references are still in the executable you create however.
In practice yes.
In theory one can use SYS$QIO(W) for all IO and bypass RMS. But
it is very cumbersome (especially if one cannot use RMS for stuff
like finding IFI).
And if one is using a database product that has nothing to do with RMS ??? >>>
the database file even if the actual IO is done by
SYS$QIO(W) / SYS$IO_PERFORM(W) or via memory mapped file.
Your expectation would be wrong.
It happens frequently.
File opens without RMS use QIO to open a file.
How does it get the FID?
On Fri, 12 Jan 2024 14:57:11 -0500, Dave Froble wrote:
I will state that the RMS PARSE routine is used to parse a filename.
That’s just a convenience. You can reimplement it yourself, with the help of ACP/XQP QIO calls like IO$_ACCESS.
On 1/12/2024 3:22 PM, Arne Vajhøj wrote:
On 1/12/2024 2:57 PM, Dave Froble wrote:
On 1/12/2024 7:23 AM, Arne Vajhøj wrote:
On 1/12/2024 12:08 AM, Dave Froble wrote:
On 1/11/2024 3:48 PM, Arne Vajhøj wrote:
On 1/11/2024 1:17 PM, Simon Clubley wrote:
On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
If RMS doesn't fit your requirements, then don't use it.
Everyone uses RMS, even if it hidden from you by the language.
The RMS
references are still in the executable you create however.
In practice yes.
In theory one can use SYS$QIO(W) for all IO and bypass RMS. But
it is very cumbersome (especially if one cannot use RMS for stuff
like finding IFI).
And if one is using a database product that has nothing to do with
RMS ???
I would still expect that database product to use RMS to open
the database file even if the actual IO is done by
SYS$QIO(W) / SYS$IO_PERFORM(W) or via memory mapped file.
Your expectation would be wrong.
It happens frequently.
File opens without RMS use QIO to open a file.
How does it get the FID?
I'll post pieces of code to keep this short, well, relatively ..
300$: MOVAB WRK_QIO,R9 ; Set $QIO parameter block address
MOVAQ WRK_Q_IOSB,QIO$_IOSB(R9) ; I/O status block
MOVZWL WRK_W_VMSCHN,QIO$_CHAN(R9); Set VMS channel number
MOVZWL #<IO$_ACCESS!IO$M_ACCESS>,QIO$_FUNC(R9)
MOVAQ WRK_Q_FIBDSC,QIO$_P1(R9) ; FIB descriptor address
MOVAQ WRK_Q_FILDSC,QIO$_P2(R9) ; Filename specification descrip
tor address
CLRQ QIO$_P3(R9) ; Clear (p3,p4)
MOVAB WRK_ATRLST,QIO$_P5(R9) ; Attributes requested
;
; Set-up the FIB
;
MOVAB WRK_FIB,R6 ; Base of FIB
CLRQ (R6)+ ; Clear (1,2)
CLRQ (R6)+ ; (3,4)
CLRQ (R6)+ ; (5,6)
CLRQ (R6)+ ; (7,8)
CLRQ (R6)+ ; (9,10)
CLRQ (R6) ; (11,12)
MOVAB WRK_FIB,R6 ; Base of FIB
MOVL R6,WRK_Q_FIBDSC+DSC$A_POINTER
MOVW #<12*4>,WRK_Q_FIBDSC+DSC$W_LENGTH
MOVZWL TBL_ACCTL[R4],FIB$L_ACCTL(R6)
MOVL NAM$W_DID(R8),FIB$W_DID(R6)
MOVW NAM$W_DID+4(R8),FIB$W_DID+4(R6)
---
;
700$: $QIOW_G (R9) ; Issue the $QIO
Ok, that's just snips. You'd need the entire sources to actually follow
the details. But, the thing is, no part of RMS was used to open the file.
I usually do the SYS$OPEN, grab the FID from the NAM block,
SYS$CLOSE and then do SYS$QIOW with IO$_ACCESS | IO$M_ACCESS.
On 1/12/2024 3:26 PM, Lawrence D'Oliveiro wrote:
On Fri, 12 Jan 2024 14:57:11 -0500, Dave Froble wrote:But that would be pretty stupid. Like re-inventing the wheel.
I will state that the RMS PARSE routine is used to parse a filename.
That’s just a convenience. You can reimplement it yourself, with the
help of ACP/XQP QIO calls like IO$_ACCESS.
Should DEC ever upgrade the $PARSE, you've already got that.
On 1/12/2024 6:46 PM, Dave Froble wrote:
On 1/12/2024 3:22 PM, Arne Vajhøj wrote:
On 1/12/2024 2:57 PM, Dave Froble wrote:
On 1/12/2024 7:23 AM, Arne Vajhøj wrote:
On 1/12/2024 12:08 AM, Dave Froble wrote:
On 1/11/2024 3:48 PM, Arne Vajhøj wrote:
On 1/11/2024 1:17 PM, Simon Clubley wrote:
On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
If RMS doesn't fit your requirements, then don't use it.
Everyone uses RMS, even if it hidden from you by the language. The RMS >>>>>>>> references are still in the executable you create however.
In practice yes.
In theory one can use SYS$QIO(W) for all IO and bypass RMS. But
it is very cumbersome (especially if one cannot use RMS for stuff >>>>>>> like finding IFI).
And if one is using a database product that has nothing to do with RMS ???
I would still expect that database product to use RMS to open
the database file even if the actual IO is done by
SYS$QIO(W) / SYS$IO_PERFORM(W) or via memory mapped file.
Your expectation would be wrong.
It happens frequently.
File opens without RMS use QIO to open a file.
How does it get the FID?
I'll post pieces of code to keep this short, well, relatively ..
300$: MOVAB WRK_QIO,R9 ; Set $QIO parameter block address >> MOVAQ WRK_Q_IOSB,QIO$_IOSB(R9) ; I/O status block
MOVZWL WRK_W_VMSCHN,QIO$_CHAN(R9); Set VMS channel number
MOVZWL #<IO$_ACCESS!IO$M_ACCESS>,QIO$_FUNC(R9)
MOVAQ WRK_Q_FIBDSC,QIO$_P1(R9) ; FIB descriptor address
MOVAQ WRK_Q_FILDSC,QIO$_P2(R9) ; Filename specification descrip
tor address
CLRQ QIO$_P3(R9) ; Clear (p3,p4)
MOVAB WRK_ATRLST,QIO$_P5(R9) ; Attributes requested
;
; Set-up the FIB
;
MOVAB WRK_FIB,R6 ; Base of FIB
CLRQ (R6)+ ; Clear (1,2)
CLRQ (R6)+ ; (3,4)
CLRQ (R6)+ ; (5,6)
CLRQ (R6)+ ; (7,8)
CLRQ (R6)+ ; (9,10)
CLRQ (R6) ; (11,12)
MOVAB WRK_FIB,R6 ; Base of FIB
MOVL R6,WRK_Q_FIBDSC+DSC$A_POINTER
MOVW #<12*4>,WRK_Q_FIBDSC+DSC$W_LENGTH
MOVZWL TBL_ACCTL[R4],FIB$L_ACCTL(R6)
MOVL NAM$W_DID(R8),FIB$W_DID(R6)
MOVW NAM$W_DID+4(R8),FIB$W_DID+4(R6)
---
;
700$: $QIOW_G (R9) ; Issue the $QIO
Ok, that's just snips. You'd need the entire sources to actually follow the >> details. But, the thing is, no part of RMS was used to open the file.
I usually do the SYS$OPEN, grab the FID from the NAM block,
SYS$CLOSE and then do SYS$QIOW with IO$_ACCESS | IO$M_ACCESS.
You know something I don't.
I have grabbed the FID from NAM and used that to access
the file for like 35 years.
And now I see that you just specify DID in FIB and give
filename as P2.
With the point being that SYS$PARSE return actual DID and
a zero FID in NAM while SYS$OPEN return both DID and FID
in NAM.
Clever.
Arne
On 2024-01-10, Mark Berryman <mark@theberrymans.com> wrote:
On 1/10/24 6:40 AM, Simon Clubley wrote:
On 2024-01-09, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:.
On Tue, 9 Jan 2024 14:32:48 -0500, Stephen Hoffman wrote:
And again, what you are interested here in has been available for many >>>>> years via Sector 7.
I?m not sure they did a comprehensive enough job. For instance, I remember >>>> the previous time this came up, reading between the lines in one of their >>>> case studies, the original customer scenario mentioned using DECnet, but >>>> that was missiong from the description of the solution.
DECnet should not be in use in today's security world and a customer
should have been forced away from using DECnet anyway due to external
auditing and security standards.
.
.
Hogwash. DECnet can be made just as secure as any IP communication by
simply using IP transports. A couple of simple examples:
1. Run DECnet phase V. Use DECnet-over-IP, and encrypt it with IPSEC
before it ever leaves your host. This not only encrypts all of your
DECnet traffic but it means that DECnet proxies are now as secure as
your IPSEC profile.
1a. If you are running OpenVMS on x86, TCP/IP Services does not
currently provide IPSEC and Multinet is not yet available. However,
VMware ESXi does support IPSEC. You can configure your ESXi host to do
the encryption for you. You just need to do your DECnet-over-IP traffic
using IPv6.
2. Run DECnet phase IV. Install pyDECnet on any host in your LAN that
supports python (I use a dedicated raspberry pi). This will be your
DECnet router. Isolate DECnet traffic to its own VLAN. All off-LAN
DECnet traffic is encrypted by the pyDECnet host, again, likely using IPSEC. >>
More security that this is possible. If you have a security requirement
this doesn't meet, let me know.
I am amused and saddened that whenever I raise this issue, people immediately assume that I am talking about MITM attacks only and address that only.
The fact is that MITM attacks are only a small part of the attack surface. Far more common are attacks against the listening services themselves from connections you initiate, not those you intercept.
For example, in 2) above, how does this address clients on an authorised
VLAN being able to send malformed packets to a server with an inappropriately fully-privileged EVL listener that has a dodgy message parser built into it ?
I also find it amusing that whenever I raise this issue, there is nothing
in the DECnet world that protects data in motion and you all have to
suggest a protocol that came from the rival TCP/IP world instead. :-)
PS: I wonder if, 2 years on, whether VSI has got around to fixing those issues in DECnet Phase IV yet ?
On 1/12/2024 3:22 PM, Arne Vajhøj wrote:
On 1/12/2024 2:57 PM, Dave Froble wrote:
On 1/12/2024 7:23 AM, Arne Vajhøj wrote:
On 1/12/2024 12:08 AM, Dave Froble wrote:
On 1/11/2024 3:48 PM, Arne Vajhøj wrote:
On 1/11/2024 1:17 PM, Simon Clubley wrote:
On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
If RMS doesn't fit your requirements, then don't use it.
Everyone uses RMS, even if it hidden from you by the language.
The RMS
references are still in the executable you create however.
In practice yes.
In theory one can use SYS$QIO(W) for all IO and bypass RMS. But
it is very cumbersome (especially if one cannot use RMS for stuff
like finding IFI).
And if one is using a database product that has nothing to do with
RMS ???
I would still expect that database product to use RMS to open
the database file even if the actual IO is done by
SYS$QIO(W) / SYS$IO_PERFORM(W) or via memory mapped file.
Your expectation would be wrong.
It happens frequently.
File opens without RMS use QIO to open a file.
How does it get the FID?
I'll post pieces of code to keep this short, well, relatively ..
; Parse the file specification, using the RMS $PARSE service
;
MOVAB WRK_FAB,R8 ; Load FAB address
MOVAB WRK_NAM,FAB$L_NAM(R8) ; Set name block address
MOVL DSC$A_POINTER(R3),FAB$L_FNA(R8)
CVTWB DSC$W_LENGTH(R3),FAB$B_FNS(R8)
$PARSE FAB = R8 ; Invoke RMS parsing service
BLBS R0,200$ ; Continue if all is okay
BRW ERRORS ; Else return with error code
;
; Set up the filename descriptor for the ACP access
;
200$: MOVL FAB$L_NAM(R8),R8 ; Point to NAM block
MOVZBL NAM$B_ESL(R8),R0 ; Length of expanded string
MOVL NAM$L_ESA(R8),R1 ; Address of expanded string
LOCC #^A"]",R0,(R1) ; Find end of directory
SUBW3 #1,R0,WRK_Q_FILDSC+DSC$W_LENGTH
ADDL3 #1,R1,WRK_Q_FILDSC+DSC$A_POINTER
On 1/12/2024 6:46 PM, Dave Froble wrote:
On 1/12/2024 3:22 PM, Arne Vajhøj wrote:
On 1/12/2024 2:57 PM, Dave Froble wrote:
On 1/12/2024 7:23 AM, Arne Vajhøj wrote:
On 1/12/2024 12:08 AM, Dave Froble wrote:
On 1/11/2024 3:48 PM, Arne Vajhøj wrote:
On 1/11/2024 1:17 PM, Simon Clubley wrote:
On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
If RMS doesn't fit your requirements, then don't use it.
Everyone uses RMS, even if it hidden from you by the language. >>>>>>>> The RMS
references are still in the executable you create however.
In practice yes.
In theory one can use SYS$QIO(W) for all IO and bypass RMS. But
it is very cumbersome (especially if one cannot use RMS for stuff >>>>>>> like finding IFI).
And if one is using a database product that has nothing to do with >>>>>> RMS ???
I would still expect that database product to use RMS to open
the database file even if the actual IO is done by
SYS$QIO(W) / SYS$IO_PERFORM(W) or via memory mapped file.
Your expectation would be wrong.
It happens frequently.
File opens without RMS use QIO to open a file.
How does it get the FID?
I'll post pieces of code to keep this short, well, relatively ..
; Parse the file specification, using the RMS $PARSE service
;
MOVAB WRK_FAB,R8 ; Load FAB address
MOVAB WRK_NAM,FAB$L_NAM(R8) ; Set name block address
MOVL DSC$A_POINTER(R3),FAB$L_FNA(R8)
CVTWB DSC$W_LENGTH(R3),FAB$B_FNS(R8)
$PARSE FAB = R8 ; Invoke RMS parsing service
BLBS R0,200$ ; Continue if all is okay
BRW ERRORS ; Else return with error code
;
; Set up the filename descriptor for the ACP access
;
200$: MOVL FAB$L_NAM(R8),R8 ; Point to NAM block
MOVZBL NAM$B_ESL(R8),R0 ; Length of expanded string
MOVL NAM$L_ESA(R8),R1 ; Address of expanded string
LOCC #^A"]",R0,(R1) ; Find end of directory
SUBW3 #1,R0,WRK_Q_FILDSC+DSC$W_LENGTH
ADDL3 #1,R1,WRK_Q_FILDSC+DSC$A_POINTER
Please don't use that code. Looking for a hard-coded closing
bracket? Oh pleeeze...
Use the various NAM$B_DIR,NAM$L_DIR fields or use $FILESCAN.
...
On 1/12/2024 6:46 PM, Dave Froble wrote:
On 1/12/2024 3:22 PM, Arne Vajhøj wrote:
On 1/12/2024 2:57 PM, Dave Froble wrote:
On 1/12/2024 7:23 AM, Arne Vajhøj wrote:
On 1/12/2024 12:08 AM, Dave Froble wrote:
On 1/11/2024 3:48 PM, Arne Vajhøj wrote:
On 1/11/2024 1:17 PM, Simon Clubley wrote:
On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
If RMS doesn't fit your requirements, then don't use it.
Everyone uses RMS, even if it hidden from you by the language. The RMS >>>>>>>> references are still in the executable you create however.
In practice yes.
In theory one can use SYS$QIO(W) for all IO and bypass RMS. But
it is very cumbersome (especially if one cannot use RMS for stuff >>>>>>> like finding IFI).
And if one is using a database product that has nothing to do with RMS ???
I would still expect that database product to use RMS to open
the database file even if the actual IO is done by
SYS$QIO(W) / SYS$IO_PERFORM(W) or via memory mapped file.
Your expectation would be wrong.
It happens frequently.
File opens without RMS use QIO to open a file.
How does it get the FID?
I'll post pieces of code to keep this short, well, relatively ..
; Parse the file specification, using the RMS $PARSE service
;
MOVAB WRK_FAB,R8 ; Load FAB address
MOVAB WRK_NAM,FAB$L_NAM(R8) ; Set name block address
MOVL DSC$A_POINTER(R3),FAB$L_FNA(R8)
CVTWB DSC$W_LENGTH(R3),FAB$B_FNS(R8)
$PARSE FAB = R8 ; Invoke RMS parsing service
BLBS R0,200$ ; Continue if all is okay
BRW ERRORS ; Else return with error code
;
; Set up the filename descriptor for the ACP access
;
200$: MOVL FAB$L_NAM(R8),R8 ; Point to NAM block
MOVZBL NAM$B_ESL(R8),R0 ; Length of expanded string
MOVL NAM$L_ESA(R8),R1 ; Address of expanded string
LOCC #^A"]",R0,(R1) ; Find end of directory
SUBW3 #1,R0,WRK_Q_FILDSC+DSC$W_LENGTH
ADDL3 #1,R1,WRK_Q_FILDSC+DSC$A_POINTER
Please don't use that code. Looking for a hard-coded closing
bracket? Oh pleeeze...
Use the various NAM$B_DIR,NAM$L_DIR fields or use $FILESCAN.
I immediately stopped looking when I saw that LOCC.
I'll post pieces of code to keep this short, well, relatively ..
; Parse the file specification, using the RMS $PARSE service
;
MOVAB WRK_FAB,R8 ; Load FAB address
MOVAB WRK_NAM,FAB$L_NAM(R8) ; Set name block address
MOVL DSC$A_POINTER(R3),FAB$L_FNA(R8)
CVTWB DSC$W_LENGTH(R3),FAB$B_FNS(R8)
$PARSE FAB = R8 ; Invoke RMS parsing service
BLBS R0,200$ ; Continue if all is okay
BRW ERRORS ; Else return with error code
;
; Set up the filename descriptor for the ACP access
;
200$: MOVL FAB$L_NAM(R8),R8 ; Point to NAM block
MOVZBL NAM$B_ESL(R8),R0 ; Length of expanded string
MOVL NAM$L_ESA(R8),R1 ; Address of expanded string
LOCC #^A"]",R0,(R1) ; Find end of directory
SUBW3 #1,R0,WRK_Q_FILDSC+DSC$W_LENGTH
ADDL3 #1,R1,WRK_Q_FILDSC+DSC$A_POINTER
On 2024-01-12, Dave Froble <davef@tsoft-inc.com> wrote:
I'll post pieces of code to keep this short, well, relatively ..
; Parse the file specification, using the RMS $PARSE service
;
MOVAB WRK_FAB,R8 ; Load FAB address
MOVAB WRK_NAM,FAB$L_NAM(R8) ; Set name block address
MOVL DSC$A_POINTER(R3),FAB$L_FNA(R8)
CVTWB DSC$W_LENGTH(R3),FAB$B_FNS(R8)
$PARSE FAB = R8 ; Invoke RMS parsing service
BLBS R0,200$ ; Continue if all is okay
BRW ERRORS ; Else return with error code
That's 32-bit code without a 64-bit version available. :-)
;
; Set up the filename descriptor for the ACP access
;
200$: MOVL FAB$L_NAM(R8),R8 ; Point to NAM block
MOVZBL NAM$B_ESL(R8),R0 ; Length of expanded string
MOVL NAM$L_ESA(R8),R1 ; Address of expanded string
LOCC #^A"]",R0,(R1) ; Find end of directory
SUBW3 #1,R0,WRK_Q_FILDSC+DSC$W_LENGTH
ADDL3 #1,R1,WRK_Q_FILDSC+DSC$A_POINTER
Likewise. :-) I see others have already commented on the hardcoded "]". :-)
Sorry David, but that code could not be used in a pure 64-bit application. :-)
Simon.
PS: "$ set response/mode=good_natured" just in case it's not clear...
Outside of some stuff from DEC, I've never seen <> used in place of [].
Don't know why both are valid. Never seen anything of that nature elsewhere.
As for the "]", yeah, something bad, but it's been there for 40 years
now,and never a single issue. I guess I can live with that experience.
And I do agree, is is bad coding.
Outside of some stuff from DEC, I've never seen <> used in place of [].
Don't know why both are valid. Never seen anything of that nature elsewhere.
Uh, Simon, what does 64 bit have to do with this?
On 2024-01-10, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
Nowadays, the whole Internet is built on the concept of running secure
protocols over insecure channels. Those secure protocols can in turn be
channels for older, insecure protocols--this is not rocket science.
Things like SSL only protect data in motion. It does nothing to help you
if the server software on the receiving end of that SSL connection has a vulnerability within it.
On Thu, 11 Jan 2024 13:48:37 -0000 (UTC), Simon Clubley wrote:
On 2024-01-10, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
Nowadays, the whole Internet is built on the concept of running secure
protocols over insecure channels. Those secure protocols can in turn be
channels for older, insecure protocols--this is not rocket science.
Things like SSL only protect data in motion. It does nothing to help you
if the server software on the receiving end of that SSL connection has a
vulnerability within it.
Not sure why that?s relevant to the issue of whether to support DECnet or not.
On 2024-01-16, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Thu, 11 Jan 2024 13:48:37 -0000 (UTC), Simon Clubley wrote:
On 2024-01-10, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
Nowadays, the whole Internet is built on the concept of running
secure protocols over insecure channels. Those secure protocols can
in turn be channels for older, insecure protocols--this is not rocket
science.
Things like SSL only protect data in motion. It does nothing to help
you if the server software on the receiving end of that SSL connection
has a vulnerability within it.
Not sure why that’s relevant to the issue of whether to support DECnet
or not.
The server software with the vulnerability could be the DECnet stack
running on that server.
BTW, has anyone been able to do a $ show proc/priv against the EVL listener PID and are you able to post the output ?
I notice that no-one, including Mark yet, has posted this, so I wonder
just how many of you are actually running the DECnet Phase IV stack on
your machines.
On 2024-01-16, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Thu, 11 Jan 2024 13:48:37 -0000 (UTC), Simon Clubley wrote:
On 2024-01-10, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
Nowadays, the whole Internet is built on the concept of running secure >>>> protocols over insecure channels. Those secure protocols can in turn be >>>> channels for older, insecure protocols--this is not rocket science.
Things like SSL only protect data in motion. It does nothing to help you >>> if the server software on the receiving end of that SSL connection has a >>> vulnerability within it.
Not sure why that?s relevant to the issue of whether to support DECnet or
not.
The server software with the vulnerability could be the DECnet stack
running on that server.
BTW, has anyone been able to do a $ show proc/priv against the EVL listener PID and are you able to post the output ?
I notice that no-one, including Mark yet, has posted this, so I wonder
just how many of you are actually running the DECnet Phase IV stack on
your machines.
Simon.
On Wed, 17 Jan 2024 13:11:31 -0000 (UTC), Simon Clubley wrote:
The server software with the vulnerability could be the DECnet stack
running on that server.
Any reason why you think DECnet is particularly prone to introducing
security holes, per se?
On 1/17/2024 8:11 AM, Simon Clubley wrote:
BTW, has anyone been able to do a $ show proc/priv against the EVL listener >> PID and are you able to post the output ?
Full priv on my VMS 8.4-2L2 Alpha and 9.2-1 x86-64.
Well, rather old, on a VAX/VMS V7.2 system.
$ show proc/priv/id=90
17-JAN-2024 21:37:35.63 User: DECNET Process ID: 00000090
Node: DFE90A Process name: "EVL"
Authorized privileges:
ACNT ALLSPOOL ALTPRI AUDIT BUGCHK BYPASS CMEXEC CMKRNL
IMPERSONATDIAGNOSE DOWNGRADE EXQUOTA GROUP GRPNAM GRPPRV IMPORT
LOG_IO MOUNT NETMBX OPER PFNMAP PHY_IO PRMCEB PRMGBL
PRMMBX PSWAPM READALL SECURITY SETPRV SHARE SHMEM SYSGBL
SYSLCK SYSNAM SYSPRV TMPMBX UPGRADE VOLPRO WORLD
On 2024-01-17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Wed, 17 Jan 2024 13:11:31 -0000 (UTC), Simon Clubley wrote:
The server software with the vulnerability could be the DECnet stack
running on that server.
Any reason why you think DECnet is particularly prone to introducing
security holes, per se?
Because, at best, it has only had a very small fraction of the effort
spent on probing it that the mainstream network stacks have had.
On 2024-01-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/17/2024 8:11 AM, Simon Clubley wrote:
BTW, has anyone been able to do a $ show proc/priv against the EVL listener >>> PID and are you able to post the output ?
Full priv on my VMS 8.4-2L2 Alpha and 9.2-1 x86-64.
Thank you for checking Arne. Seeing this still being the case on x86-64
was an unpleasant surprise.
So, that's two full years VSI have had to look at this and they have
done nothing.
I wonder if they are sitting on any other issues that are just a weakness
at the moment, but may become an actual vulnerability if either further probing is done, or if another unrelated issue is discovered and these
are chained together with that new issue.
For those of you with the premium support contracts who are worried about this, then a formal _polite_ request to VSI to answer the above question
and to ask when the DECnet issues will be fixed might be in order.
You may have more luck getting them to fix these issues than I have had.
On 2024-01-16, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Thu, 11 Jan 2024 13:48:37 -0000 (UTC), Simon Clubley wrote:
On 2024-01-10, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
Nowadays, the whole Internet is built on the concept of running secure >>>> protocols over insecure channels. Those secure protocols can in turn be >>>> channels for older, insecure protocols--this is not rocket science.
Things like SSL only protect data in motion. It does nothing to help you >>> if the server software on the receiving end of that SSL connection has a >>> vulnerability within it.
Not sure why that?s relevant to the issue of whether to support DECnet or
not.
The server software with the vulnerability could be the DECnet stack
running on that server.
BTW, has anyone been able to do a $ show proc/priv against the EVL listener PID and are you able to post the output ?
I notice that no-one, including Mark yet, has posted this, so I wonder
just how many of you are actually running the DECnet Phase IV stack on
your machines.
On 2024-01-17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Wed, 17 Jan 2024 13:11:31 -0000 (UTC), Simon Clubley wrote:
The server software with the vulnerability could be the DECnet stack
running on that server.
Any reason why you think DECnet is particularly prone to introducing
security holes, per se?
Because, at best, it has only had a very small fraction of the effort
spent on probing it that the mainstream network stacks have had.
On 1/18/24 6:06 AM, Simon Clubley wrote:
On 2024-01-17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Wed, 17 Jan 2024 13:11:31 -0000 (UTC), Simon Clubley wrote:
The server software with the vulnerability could be the DECnet stack
running on that server.
Any reason why you think DECnet is particularly prone to introducing
security holes, per se?
Because, at best, it has only had a very small fraction of the effort
spent on probing it that the mainstream network stacks have had.
Simon's postings would tend to indicate that he believes that anything
not subject to constant probing by hundreds or thousands of hack.., er, security researchers is just full of latent bugs waiting to be discovered.
Sorry, I am only infrequently on this forum.
On my system EVL runs with exactly the privs I specified earlier but I
did do some digging.
EVL is started by netacp in whatever account netacp is running using the command file sys$system:evl.com. EVL neither raises nor lowers privs.
The startup command file normally looks like this:
$ ! Copyright (c) 1987 Digital Equipment Corporation. All rights reserved. $ SET NOON
$ IF "''EVL$COMMAND'" .NES. "" THEN EVL$COMMAND
$ RUN SYS$SYSTEM:EVL
$ PURGE/KEEP=3 EVL.LOG
$ LOGOUT/BRIEF
However, sometime in the dim and distant past (meaning I no longer
remember when or why) I inserted this line:
$ SET PROCESS/PRIVILEGES=(NOALL,SYSNAM,OPER,SYSPRV,NETMBX,TMPMBX)
which is why EVL is limited in privs on my system. Anyone concerned can
make the same edit.
On 1/18/24 6:06 AM, Simon Clubley wrote:
On 2024-01-17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Wed, 17 Jan 2024 13:11:31 -0000 (UTC), Simon Clubley wrote:
The server software with the vulnerability could be the DECnet stack
running on that server.
Any reason why you think DECnet is particularly prone to introducing
security holes, per se?
Because, at best, it has only had a very small fraction of the effort
spent on probing it that the mainstream network stacks have had.
Simon's postings would tend to indicate that he believes that anything not subject to constant probing by hundreds or thousands of hack.., er, security researchers is just full of latent bugs waiting to be discovered.
It might help to remember that the IP stack was designed by committee and implemented by an even more diverse group, some good at programming, some not so
much. DECnet, however, was designed and implemented by a much smaller group, which often leads to much better code. I suspect, but don't know for sure, that
the designers and implementers were also essentially the same people. (They were also very good).
Also, once upon a time, DECnet was a more diverse network than the internet. Until the internet went public in the early 90s, it was quite limited in scope,
consisting mainly of some government institutions, some government contractors,
and some universities. DECnet, however, was used to implement a number of world-wide networks consisting of many diverse endpoints. There was some probing that went on but not a whole lot. For one, with DECnet the source was
too easy to trace and, for another, if any of the probes were successful I never
heard of it (I was on SPAN at the time). This was all DECnet phase IV. After
the internet went public, these networks ran multiple protocols in parallel, including TCP/IP and DECnet. As DEC equipment was phased out at these sites, so
was DECnet. But it somehow managed to survive without issue all those years. (The only known problems were caused by local misconfigurations by people who didn't read the manual and simply accepted defaults that should have been better. None were cause by the stack itself.)
Finally, as I mentioned in an earlier post, it is trivial in today's world to isolate one's DECnet stack from anything other than trusted hosts. On any network where I have been involved, it some host were compromised, and if that
host were to try to probe DECnet, none of its packets would even reach the DECnet interface of any host that was actually running DECnet.
There are, after all, many ways to implement security.
My two cents.
Mark Berryman
Finally, as I mentioned in an earlier post, it is trivial in today's
world to isolate one's DECnet stack from anything other than trusted
hosts. On any network where I have been involved, it some host were compromised, and if that host were to try to probe DECnet, none of its packets would even reach the DECnet interface of any host that was
actually running DECnet.
DECnet, however, was designed and implemented by a
much smaller group, which often leads to much better code.
On 2024-01-17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Wed, 17 Jan 2024 13:11:31 -0000 (UTC), Simon Clubley wrote:
The server software with the vulnerability could be the DECnet stack
running on that server.
Any reason why you think DECnet is particularly prone to introducing
security holes, per se?
Because, at best, it has only had a very small fraction of the effort
spent on probing it that the mainstream network stacks have had.
DECnet had an address space so restricted, it make the 32-bit IP address space seem expansive.
And whose dumb idea was it to tie the DECnet address
to the MAC address?
And whose dumb idea was it to tie the DECnet addressIt is pretty smart. No need for an extra protocol.
to the MAC address?
Different objectives. Internet Protocol was designed to be able to be adaptable to almost any kind of computer. DECnet was only for DEC OSes.
On Thu, 18 Jan 2024 13:06:21 -0000 (UTC), Simon Clubley wrote:
On 2024-01-17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Wed, 17 Jan 2024 13:11:31 -0000 (UTC), Simon Clubley wrote:
The server software with the vulnerability could be the DECnet stack
running on that server.
Any reason why you think DECnet is particularly prone to introducing
security holes, per se?
Because, at best, it has only had a very small fraction of the effort
spent on probing it that the mainstream network stacks have had.
But we already know it is an insecure protocol, and we already know how to run such things securely, as I pointed out before.
On 1/18/24 6:06 AM, Simon Clubley wrote:
On 2024-01-17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Wed, 17 Jan 2024 13:11:31 -0000 (UTC), Simon Clubley wrote:
The server software with the vulnerability could be the DECnet stack
running on that server.
Any reason why you think DECnet is particularly prone to introducing
security holes, per se?
Because, at best, it has only had a very small fraction of the effort
spent on probing it that the mainstream network stacks have had.
Simon's postings would tend to indicate that he believes that anything
not subject to constant probing by hundreds or thousands of hack.., er, >security researchers is just full of latent bugs waiting to be discovered.
It might help to remember that the IP stack was designed by committee
and implemented by an even more diverse group, some good at programming,
some not so much. DECnet, however, was designed and implemented by a
much smaller group, which often leads to much better code. I suspect,
but don't know for sure, that the designers and implementers were also >essentially the same people. (They were also very good).
Also, once upon a time, DECnet was a more diverse network than the
internet. Until the internet went public in the early 90s, it was quite >limited in scope, consisting mainly of some government institutions,
some government contractors, and some universities. DECnet, however,
was used to implement a number of world-wide networks consisting of many >diverse endpoints. There was some probing that went on but not a whole
lot. For one, with DECnet the source was too easy to trace and, for
another, if any of the probes were successful I never heard of it (I was
on SPAN at the time). This was all DECnet phase IV. After the internet
went public, these networks ran multiple protocols in parallel,
including TCP/IP and DECnet. As DEC equipment was phased out at these
sites, so was DECnet. But it somehow managed to survive without issue
all those years. (The only known problems were caused by local >misconfigurations by people who didn't read the manual and simply
accepted defaults that should have been better. None were cause by the
stack itself.)
Finally, as I mentioned in an earlier post, it is trivial in today's
world to isolate one's DECnet stack from anything other than trusted
hosts. On any network where I have been involved, it some host were >compromised, and if that host were to try to probe DECnet, none of its >packets would even reach the DECnet interface of any host that was
actually running DECnet.
There are, after all, many ways to implement security.
My two cents.
On 1/18/2024 3:38 PM, Lawrence D'Oliveiro wrote:
DECnet had an address space so restricted, it make the 32-bit IP address
space seem expansive.
16 bit is less than 32 bit.
If DEC had known how large DECnet networks would become, then they
would probably have chosen 32 bit.
But it is difficult to predict the future.
And whose dumb idea was it to tie the DECnet address
to the MAC address?
It is pretty smart. No need for an extra protocol.
On 2024-01-18, Mark Berryman <mark@theberrymans.com> wrote:
Sorry, I am only infrequently on this forum.
On my system EVL runs with exactly the privs I specified earlier but I
did do some digging.
EVL is started by netacp in whatever account netacp is running using the
command file sys$system:evl.com. EVL neither raises nor lowers privs.
The startup command file normally looks like this:
$ ! Copyright (c) 1987 Digital Equipment Corporation. All rights reserved. >> $ SET NOON
$ IF "''EVL$COMMAND'" .NES. "" THEN EVL$COMMAND
$ RUN SYS$SYSTEM:EVL
$ PURGE/KEEP=3 EVL.LOG
$ LOGOUT/BRIEF
However, sometime in the dim and distant past (meaning I no longer
remember when or why) I inserted this line:
$ SET PROCESS/PRIVILEGES=(NOALL,SYSNAM,OPER,SYSPRV,NETMBX,TMPMBX)
which is why EVL is limited in privs on my system. Anyone concerned can
make the same edit.
Because that command is being run in the same process as the EVL listener
it will not help constrain an attacker. This is because all an attacker
needs to do in their shellcode is to reenable those privileges.
On 1/18/24 11:38 AM, Simon Clubley wrote:
On 2024-01-18, Mark Berryman <mark@theberrymans.com> wrote:
Sorry, I am only infrequently on this forum.
On my system EVL runs with exactly the privs I specified earlier but I
did do some digging.
EVL is started by netacp in whatever account netacp is running using the >>> command file sys$system:evl.com. EVL neither raises nor lowers privs.
The startup command file normally looks like this:
$ ! Copyright (c) 1987 Digital Equipment Corporation. All rights reserved.
$ SET NOON
$ IF "''EVL$COMMAND'" .NES. "" THEN EVL$COMMAND
$ RUN SYS$SYSTEM:EVL
$ PURGE/KEEP=3 EVL.LOG
$ LOGOUT/BRIEF
However, sometime in the dim and distant past (meaning I no longer
remember when or why) I inserted this line:
$ SET PROCESS/PRIVILEGES=(NOALL,SYSNAM,OPER,SYSPRV,NETMBX,TMPMBX)
which is why EVL is limited in privs on my system. Anyone concerned can >>> make the same edit.
Because that command is being run in the same process as the EVL listener
it will not help constrain an attacker. This is because all an attacker
needs to do in their shellcode is to reenable those privileges.
IIRC, you managed to crash EVL using an insecure setup. Crashing a
process is much different that convincing a process to run bogus code
and, of course, simply crashing EVL causes its process to exit.
With a secure setup, you can't get your malformed packets into EVL.
However, if you'd like to show how you can get EVL to run bogus code, in
any setup, then you will have raised a very valid concern. Until then,
I have addressed what concern you have raised.
As I have already mentioned, that only protects data in transit.
Things like SSL only protect data in motion.
On Fri, 19 Jan 2024 13:11:31 -0000 (UTC), Simon Clubley wrote:
As I have already mentioned, that only protects data in transit.
Relevance being?
By "insecure setup", you mean using a network stack as supplied out of
the box by a vendor selling "the world's most secure operating system" ?
On 2024-01-19, Mark Berryman <mark@theberrymans.com> wrote:.
Because that command is being run in the same process as the EVL listener >>> it will not help constrain an attacker. This is because all an attacker
needs to do in their shellcode is to reenable those privileges.
IIRC, you managed to crash EVL using an insecure setup. Crashing a
process is much different that convincing a process to run bogus code
and, of course, simply crashing EVL causes its process to exit.
By "insecure setup", you mean using a network stack as supplied out of
the box by a vendor selling "the world's most secure operating system" ?
That DECnet uses cleartext credentials for network connections, both
within the cleartext network protocol, and usernames and passwords
stored within the hopefully-protected DECnet database, was straight out
of 1990.
On Thu, 11 Jan 2024 13:48:37 -0000 (UTC), Simon Clubley wrote:
Things like SSL only protect data in motion.
How exactly is a network protocol supposed to operate when not ?in
motion??
On Fri, 19 Jan 2024 13:11:31 -0000 (UTC), Simon Clubley wrote:
As I have already mentioned, that only protects data in transit.
Relevance being?
On 1/19/24 11:44 AM, Simon Clubley wrote:
On 2024-01-19, Mark Berryman <mark@theberrymans.com> wrote:.
.
.
Because that command is being run in the same process as the EVL listener >>>> it will not help constrain an attacker. This is because all an attacker >>>> needs to do in their shellcode is to reenable those privileges.
IIRC, you managed to crash EVL using an insecure setup. Crashing a
process is much different that convincing a process to run bogus code
and, of course, simply crashing EVL causes its process to exit.
By "insecure setup", you mean using a network stack as supplied out of
the box by a vendor selling "the world's most secure operating system" ?
No, by insecure setup I mean you allowed an untrusted host, and one not running DECnet, access to another host's DECnet stack.
On 2024-01-20, Mark Berryman <mark@theberrymans.com> wrote:Most likely, every public node on the Internet is behind a firewall,
On 1/19/24 11:44 AM, Simon Clubley wrote:
On 2024-01-19, Mark Berryman <mark@theberrymans.com> wrote:.
.
.
Because that command is being run in the same process as the EVL listener >>>>> it will not help constrain an attacker. This is because all an attacker >>>>> needs to do in their shellcode is to reenable those privileges.
IIRC, you managed to crash EVL using an insecure setup. Crashing a
process is much different that convincing a process to run bogus code
and, of course, simply crashing EVL causes its process to exit.
By "insecure setup", you mean using a network stack as supplied out of
the box by a vendor selling "the world's most secure operating system" ?
No, by insecure setup I mean you allowed an untrusted host, and one not
running DECnet, access to another host's DECnet stack.
Oh, I see Mark. So you mean just like every public node on the Internet is supposed to handle without instantly falling over ? :-) (And which gets
fixed when something unexpected is found ?)
Sadly, when an IP-based attack makes it through the firewall and into a
host, the host typically does worse than "fall over". It lets the
attacker in where the attacker can then do all kinds of nefarious
things. This is often not detected until long after the fact. If there
has ever been a successful attack from an external source on a VMS
system that allowed the attacker to muck around on that system, I am not aware of it. Are you?
The purpose of a firewall is to protect the IP stack of the hosts behind
it. I merely suggested a couple of ways one can firewall one's DECnet traffic, and thereby protect that stack. Nothing unusual or exceptional about it.
I ran a VMS host fully exposed to the Internet with DECnet phase V on it
for years without issue. It was a honeypot so it wanted to see as many attack attempts as possible. It was running WASD instead of Apache so
none of the attacks on the web port succeeded and none of the attacks on
the ports used by DECnet ever caused an issue. So, real word
experience, not guess work. And, no, I wouldn't try this with any other platform.
The biggest external problem I have ever had to personally deal with
was that the UCX stack still had an SMTP open relay with no way of restricting it, when the rest of the world had moved on and this was
very, very, no longer acceptable.
Most likely, every public node on the Internet is behind a firewall,
which severely limits what packets can reach a given node and, depending
on the quality of the firewall, the nature of those packets (i.e. good firewalls can detect and reject malformed packets).
Sadly, when an IP-based attack makes it through the firewall and into a
host, the host typically does worse than "fall over". It lets the
attacker in where the attacker can then do all kinds of nefarious
things. This is often not detected until long after the fact. If there has ever been a successful attack from an external source on a VMS
system that allowed the attacker to muck around on that system, I am not aware of it. Are you?
The purpose of a firewall is to protect the IP stack of the hosts behind it. I merely suggested a couple of ways one can firewall one's DECnet traffic, and thereby protect that stack.
I ran a VMS host fully exposed to the Internet with DECnet phase V on it
for years without issue. It was a honeypot so it wanted to see as many attack attempts as possible. It was running WASD instead of Apache so
none of the attacks on the web port succeeded and none of the attacks on
the ports used by DECnet ever caused an issue.
On 1/22/2024 2:40 PM, Mark Berryman wrote:
I ran a VMS host fully exposed to the Internet with DECnet phase V on it
for years without issue. It was a honeypot so it wanted to see as many
attack attempts as possible. It was running WASD instead of Apache so
none of the attacks on the web port succeeded and none of the attacks on
the ports used by DECnet ever caused an issue.
I was not even aware that DECnet used ports.
And how did DECnet traffic come in via the internet?
On 1/22/2024 2:40 PM, Mark Berryman wrote:Mark mentioned DECnet phase V which often/mostly uses DECnet over IP
Most likely, every public node on the Internet is behind a firewall,
which severely limits what packets can reach a given node and,
depending on the quality of the firewall, the nature of those packets
(i.e. good firewalls can detect and reject malformed packets).
Sadly, when an IP-based attack makes it through the firewall and into
a host, the host typically does worse than "fall over". It lets the
attacker in where the attacker can then do all kinds of nefarious
things. This is often not detected until long after the fact. If
there has ever been a successful attack from an external source on a
VMS system that allowed the attacker to muck around on that system, I
am not aware of it. Are you?
Long time ago: yes.
The purpose of a firewall is to protect the IP stack of the hosts
behind it. I merely suggested a couple of ways one can firewall one's
DECnet traffic, and thereby protect that stack.
Internet is IP only and firewalls does never pass DECnet traffic, so
no DECnet attacks that way.
DECnet attacks has to either be local or get in via IP and propagate
via DECnet.
I ran a VMS host fully exposed to the Internet with DECnet phase V on
it for years without issue. It was a honeypot so it wanted to see as
many attack attempts as possible. It was running WASD instead of
Apache so none of the attacks on the web port succeeded and none of
the attacks on the ports used by DECnet ever caused an issue.
I was not even aware that DECnet used ports.
And how did DECnet traffic come in via the internet?
On 2024-01-23 13:29:56 +0000, Simon Clubley said:
The biggest external problem I have ever had to personally deal with
was that the UCX stack still had an SMTP open relay with no way of
restricting it, when the rest of the world had moved on and this was
very, very, no longer acceptable.
Last I checked, the 💩 default for TCP/IP Services SMTP mail server was
a 💩 open relay. With no diagnostics. Reproducer was trivially simple: delete (or mis-locate) the SMTP configuration file.
With no TLS and no STARTTLS support to be found anywhere in the TCP/IP
mail server, last I checked.
On 2024-01-23, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/22/2024 2:40 PM, Mark Berryman wrote:
I ran a VMS host fully exposed to the Internet with DECnet phase V on it >>> for years without issue. It was a honeypot so it wanted to see as many >>> attack attempts as possible. It was running WASD instead of Apache so
none of the attacks on the web port succeeded and none of the attacks on >>> the ports used by DECnet ever caused an issue.
I was not even aware that DECnet used ports.
They are called objects, but they are really numbered ports, just like TCP/IP. However, I suspect Mark is talking about the TCP/IP ports used
as a transport for DECnet packets, in the same way as SSH can be used
to transport X11 traffic.
And how did DECnet traffic come in via the internet?
I suspect the implementation Mark is using encapsulates the DECnet
traffic in a little custom TCP/IP-based protocol, which is then routed
over one or more TCP/IP ports to its destination before the encapsulation
is reversed and the DECnet packets delivered to the target DECnet stack.
That means the attacks would be limited to malformed TCP/IP packets
unless the attacker was also running a DECnet stack and the same TCP/IP DECnet encapsulation protocol.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 434 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 115:03:18 |
| Calls: | 9,109 |
| Calls today: | 3 |
| Files: | 13,419 |
| Messages: | 6,030,395 |