• Something is happening at VSI

    From John H. Reinhardt@21:1/5 to All on Sun Mar 31 22:33:22 2024
    I've been checking the VSI Service Platform to see if the x86 Community PAK got renewed over the weekend just in case they decided to put out something to keep my x86 systems from expiring Monday (or will things stop working at midnight? I've ever been
    around when a PAK expired). All weekend there was no change - until tonight. It's 10:20 CDT and not even midnight Eastern time but my package listing is blank. It looks like all access to x86 packages there has been revoked. At least to me.

    Both letters I got from VSI mentioned continuing x86 Community Licensing and I thought I saw someplace that said if you already had an x86 CLP then they would automatically send an email with the new credentials/setup but re-reading both I don't see that
    so I'm not sure if I imagined it or it was someplace else or that my reading comprehension failed.

    It will be interesting to see what April Fool's Day brings.

    --
    John H. Reinhardt

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Single Stage to Orbit@21:1/5 to John H. Reinhardt on Mon Apr 1 10:29:17 2024
    On Sun, 2024-03-31 at 22:33 -0500, John H. Reinhardt wrote:

    I've been checking the VSI Service Platform to see if the x86
    Community PAK got renewed over the weekend just in case they decided
    to put out something to keep my x86 systems from expiring Monday (or
    will things stop working at midnight? I've ever been around when a
    PAK expired). All weekend there was no change - until tonight.  It's
    10:20 CDT and not even midnight Eastern time but my package listing
    is blank.  It looks like all access to x86 packages there has been revoked.  At least to me.

    Both letters I got from VSI mentioned continuing x86 Community
    Licensing and I thought I saw someplace that said if you already had
    an x86 CLP then they would automatically send an email with the new credentials/setup but re-reading both I don't see that so I'm not
    sure if I imagined it or it was someplace else or that my reading comprehension failed.

    It will be interesting to see what April Fool's Day brings.

    Same here. Waiting to see what happens next.
    --
    Tactical Nuclear Kittens

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John H. Reinhardt@21:1/5 to Single Stage to Orbit on Mon Apr 1 04:49:46 2024
    On 4/1/2024 4:29 AM, Single Stage to Orbit wrote:
    On Sun, 2024-03-31 at 22:33 -0500, John H. Reinhardt wrote:

    I've been checking the VSI Service Platform to see if the x86
    Community PAK got renewed over the weekend just in case they decided
    to put out something to keep my x86 systems from expiring Monday (or
    will things stop working at midnight? I've ever been around when a
    PAK expired). All weekend there was no change - until tonight.  It's
    10:20 CDT and not even midnight Eastern time but my package listing
    is blank.  It looks like all access to x86 packages there has been
    revoked.  At least to me.

    Both letters I got from VSI mentioned continuing x86 Community
    Licensing and I thought I saw someplace that said if you already had
    an x86 CLP then they would automatically send an email with the new
    credentials/setup but re-reading both I don't see that so I'm not
    sure if I imagined it or it was someplace else or that my reading
    comprehension failed.

    It will be interesting to see what April Fool's Day brings.

    Same here. Waiting to see what happens next.

    PAK wise I guess we still have today (1-APR-2024) and things will stop when the date rolls over to 2-APR-2024. I couldn't remember if the termination date took effect ON the date or if that was the last day.

    --
    John H. Reinhardt

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Craig A. Berry@21:1/5 to John H. Reinhardt on Mon Apr 1 06:58:46 2024
    On 3/31/24 10:33 PM, John H. Reinhardt wrote:

    Both letters I got from VSI mentioned continuing x86 Community Licensing
    and I thought I saw someplace that said if you already had an x86 CLP
    then they would automatically send an email with the new
    credentials/setup but re-reading both I don't see that so I'm not sure
    if I imagined it or it was someplace else or that my reading
    comprehension failed.

    What they said was they will send anyone who has previously applied for
    an x86 license is a link to the new vmdk that already has software and
    licenses on it. My understanding is that the service portal is going
    away for CL users and what you get on the vmdk is what you'll have until
    the next one comes out the following year.

    Regarding Alpha and Integrity, the announcement on the web page says, "Effective immediately, we will discontinue offering new community
    licenses for non-commercial use for Alpha and Integrity. Existing
    holders of community licenses for these architectures will get updates
    for those licenses and retain their access to the Service Portal until
    March 2025 for Alpha and December 2025 for Integrity."[1] Which is odd
    since my community membership never got me access to anything related to
    Alpha and Integrity on the portal.

    [1] https://vmssoftware.com/about/news/2024-03-25-community-license-update/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Single Stage to Orbit@21:1/5 to Craig A. Berry on Mon Apr 1 13:46:23 2024
    On Mon, 2024-04-01 at 06:58 -0500, Craig A. Berry wrote:
    Existing holders of community licenses for these architectures will
    get updates for those licenses and retain their access to the Service
    Portal until March 2025 for Alpha and December 2025 for
    Integrity."[1]  Which is odd since my community membership never got
    me access to anything related to Alpha and Integrity on the portal.

    I have access to the x86 portal but there is nothing there, no updates
    or packages.
    --
    Tactical Nuclear Kittens

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dave Froble@21:1/5 to John H. Reinhardt on Mon Apr 1 10:04:04 2024
    On 4/1/2024 5:49 AM, John H. Reinhardt wrote:
    On 4/1/2024 4:29 AM, Single Stage to Orbit wrote:
    On Sun, 2024-03-31 at 22:33 -0500, John H. Reinhardt wrote:

    I've been checking the VSI Service Platform to see if the x86
    Community PAK got renewed over the weekend just in case they decided
    to put out something to keep my x86 systems from expiring Monday (or
    will things stop working at midnight? I've ever been around when a
    PAK expired). All weekend there was no change - until tonight. It's
    10:20 CDT and not even midnight Eastern time but my package listing
    is blank. It looks like all access to x86 packages there has been
    revoked. At least to me.

    Both letters I got from VSI mentioned continuing x86 Community
    Licensing and I thought I saw someplace that said if you already had
    an x86 CLP then they would automatically send an email with the new
    credentials/setup but re-reading both I don't see that so I'm not
    sure if I imagined it or it was someplace else or that my reading
    comprehension failed.

    It will be interesting to see what April Fool's Day brings.

    Same here. Waiting to see what happens next.

    PAK wise I guess we still have today (1-APR-2024) and things will stop when the
    date rolls over to 2-APR-2024. I couldn't remember if the termination date took
    effect ON the date or if that was the last day.


    One of our customers had a problem. Their PAKs expired in December, but the system wasn't re-booted until a recent power outage. It appears that perhaps the licenses continued to work, but, would not re-load upon re-boot.

    Now, never re-booting isn't a solution. But perhaps the expired PAKs will work until a re-boot, and failure to load, occurs. Then again there have been claims
    of long uptimes on VMS.

    --
    David Froble Tel: 724-529-0450
    Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
    DFE Ultralights, Inc.
    170 Grimplin Road
    Vanderbilt, PA 15486

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John H. Reinhardt@21:1/5 to Craig A. Berry on Mon Apr 1 09:05:58 2024
    On 4/1/2024 6:58 AM, Craig A. Berry wrote:

    On 3/31/24 10:33 PM, John H. Reinhardt wrote:

    Both letters I got from VSI mentioned continuing x86 Community Licensing and I thought I saw someplace that said if you already had an x86 CLP then they would automatically send an email with the new credentials/setup but re-reading both I don't see
    that so I'm not sure if I imagined it or it was someplace else or that my reading comprehension failed.

    What they said was they will send anyone who has previously applied for
    an x86 license is a link to the new vmdk that already has software and licenses on it. My understanding is that the service portal is going
    away for CL users and what you get on the vmdk is what you'll have until
    the next one comes out the following year.

    Regarding Alpha and Integrity, the announcement on the web page says, "Effective immediately, we will discontinue offering new community
    licenses for non-commercial use for Alpha and Integrity. Existing
    holders of community licenses for these architectures will get updates
    for those licenses and retain their access to the Service Portal until
    March 2025 for Alpha and December 2025 for Integrity."[1]  Which is odd since my community membership never got me access to anything related to Alpha and Integrity on the portal.

    [1] https://vmssoftware.com/about/news/2024-03-25-community-license-update/

    Yes, that's where it was, on the web site. Thanks Craig!

    At 8:34am CDT I received the email with the information and the download link for the vmdk. It's a zip file with a 5GB virtual disk. I'm in the process of uploading it to my ESXi host and creating a system with it. Also in the email is a link to a page
    describing how to set up a VM using VirtualBox. I'm just cloning one of the two VMS VM's I already have.

    --
    John H. Reinhardt

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jouk Jansen@21:1/5 to Craig A. Berry on Tue Apr 2 08:10:51 2024
    Craig A. Berry wrote on 1-APR-2024 13:05:15.61

    What they said was they will send anyone who has previously applied for
    an x86 license is a link to the new vmdk that already has software and >licenses on it. My understanding is that the service portal is going
    away for CL users and what you get on the vmdk is what you'll have until
    the next one comes out the following year.

    I did not get that E-mail (should have got it because I got CLP licenses). Seems no vmdk for me.

    Jouk



    Pax, vel iniusta, utilior est quam iustissimum bellum.
    (free after Marcus Tullius Cicero (106 b.Chr.-46 b.Chr.)
    Epistularum ad Atticum 7.1.4.3)


    Touch not the cat bot a glove

    ------------------------------------------------------------------------------<

    Jouk Jansen

    joukj@hrem.nano.tudelft.nl

    Technische Universiteit Delft tttttttttt uu uu ddddddd
    Kavli Institute of Nanoscience tttttttttt uu uu dd dd
    Nationaal centrum voor HREM tt uu uu dd dd
    Lorentzweg 1 tt uu uu dd dd
    2628 CJ Delft tt uu uu dd dd
    Nederland tt uu uu dd dd
    tel. +31-15-2782272 tt uuuuuuu ddddddd

    ------------------------------------------------------------------------------<

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Craig A. Berry@21:1/5 to Jouk Jansen on Tue Apr 2 07:57:48 2024
    On 4/2/24 1:10 AM, Jouk Jansen wrote:
    Craig A. Berry wrote on 1-APR-2024 13:05:15.61

    What they said was they will send anyone who has previously applied for
    an x86 license is a link to the new vmdk that already has software and
    licenses on it. My understanding is that the service portal is going
    away for CL users and what you get on the vmdk is what you'll have until
    the next one comes out the following year.

    I did not get that E-mail (should have got it because I got CLP licenses). Seems no vmdk for me.

    I have not gotten such an e-mail either.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tony Nicholson@21:1/5 to Jouk Jansen on Wed Apr 3 03:40:15 2024
    On 2/04/2024 5:10 pm, Jouk Jansen wrote:

    I did not get that E-mail (should have got it because I got CLP licenses). Seems no vmdk for me.

    Go to https://vmssoftware.com/products/licenses/ where you'll need to
    reapply for the Community license for VSI OpenVMS x86_64.

    I did this last Sunday and received an e-mail with download details for
    the vdmk disk image on Tuesday.

    Tony

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From motk@21:1/5 to All on Wed Apr 3 09:10:35 2024
    On 3/04/2024 12:22 am, mjos_examine wrote:
    On 2024-04-02 8:57 a.m., Craig A. Berry wrote:
    I did not get that E-mail (should have got it because I got CLP
    licenses).
    Seems no vmdk for me.

    I have not gotten such an e-mail either.

    It sounds like there may be many of us that have not received that email
    as of yet, so we're kind of stuck.

    Whether our emails are queued up, or we've been overlooked, we have no
    way of knowing at this point.

    I didn't receive an email for seven months; when I mentioned this on the
    forum I was chided for impatience and then was told I had been sent an
    email. Checked entire email server logs, nothing there. I asked if it
    could be resent and have had no reply.

    Friends, it's not looking good.


    --
    motk

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From motk@21:1/5 to motk on Wed Apr 3 10:10:20 2024
    On 3/04/2024 9:10 am, motk wrote:

    I didn't receive an email for seven months; when I mentioned this on the forum I was chided for impatience and then was told I had been sent an
    email. Checked entire email server logs, nothing there. I asked if it
    could be resent and have had no reply.

    And ... it just appeared! Well, there's a thing.


    --
    motk

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From motk@21:1/5 to motk on Wed Apr 3 10:20:47 2024
    On 3/04/2024 10:10 am, motk wrote:
    On 3/04/2024 9:10 am, motk wrote:

    I didn't receive an email for seven months; when I mentioned this on
    the forum I was chided for impatience and then was told I had been
    sent an email. Checked entire email server logs, nothing there. I
    asked if it could be resent and have had no reply.

    And ... it just appeared! Well, there's a thing.

    Doing a qm import into proxmox now. I've been a bit intemperant, and I'm
    not convinced in any way that this is the right thing to do with the CL,
    but I'll give it a go.

    --
    motk

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John H. Reinhardt@21:1/5 to Tony Nicholson on Wed Apr 3 09:16:09 2024
    On 4/2/2024 11:40 AM, Tony Nicholson wrote:
    On 2/04/2024 5:10 pm, Jouk Jansen wrote:

    I did not get that E-mail (should have got it because I got CLP licenses). >> Seems no vmdk for me.

    Go to https://vmssoftware.com/products/licenses/ where you'll need to reapply for the Community license for VSI OpenVMS x86_64.

    I did this last Sunday and received an e-mail with download details for
    the vdmk disk image on Tuesday.

    Tony


    From Mister Moderator on the VSI Forum:

    "This week already we have processed over 1000 applications to get access to the community instance of x86 OpenVMS for the VMDK. This included some old applications as well so please check your inboxes and spam folders. If you have not received one yet
    and have only just applied then please be patient as we will get to you and thankfully the process is a lot faster than it once was."

    Hopefully everyone is getting their email.

    --
    John H. Reinhardt

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From motk@21:1/5 to motk on Thu Apr 4 17:52:48 2024
    On 4/3/24 10:20, motk wrote:
    On 3/04/2024 10:10 am, motk wrote:
    On 3/04/2024 9:10 am, motk wrote:

    I didn't receive an email for seven months; when I mentioned this on
    the forum I was chided for impatience and then was told I had been
    sent an email. Checked entire email server logs, nothing there. I
    asked if it could be resent and have had no reply.

    And ... it just appeared! Well, there's a thing.

    Doing a qm import into proxmox now. I've been a bit intemperant, and I'm
    not convinced in any way that this is the right thing to do with the CL,
    but I'll give it a go.

    After working out I needed to add "args: -no-hpet" to the server conf in /etc/pve/qemu-server/xxx.conf, it's been working well enough.

    I did apparently accidentally fuzz things:

    $ product list *

    Improperly handled condition, bad stack or no handler specified.
    Signal arguments: Number = 0000000000000005
    Name = 000000000000000C
    0000000000000007
    0000000000006000
    FFFF830007C0236B
    0000000000000012
    Register dump:
    RAX = 0000000000000000 RDI = 000000007FF9DC80 RSI = 0000000000006000
    RDX = 5344524F5759454B RCX = 0000000000006000 R8 = 00000000FFFF8F86
    R9 = 000000000808080D RBX = 000000007FFABE00 RBP = 000000007FF9FF60
    R10 = 000000007FFABDB0 R11 = 000000007FFA4D18 R12 = 000000007FF9C0F8
    R13 = 0000000000000018 R14 = 000000007FF9C2B0 R15 = 0000000000008301
    RIP = FFFF830007C0236B RSP = 000000007FF9FF00 SS = 000000000000001B %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000000C, PC=0000000000000002, PS=7AD5D8EE

    Improperly handled condition, bad stack or no handler specified.
    Signal arguments: Number = 0000000000000005
    Name = 000000000000000C
    0000000000000014
    0000000000000018
    000000007FF9CE98
    0000000000000012
    Register dump:
    RAX = 0000000000000001 RDI = 000000007FF7BC20 RSI = 0000000000000001
    RDX = 0000000000000000 RCX = FFFFFFFF8AC09B5E R8 = 000000007ACBD11F
    R9 = 0000000000000106 RBX = 000000007FFABE00 RBP = 000000007FF9F0A8
    R10 = 000000007FFA4D18 R11 = 000000007FFA4D18 R12 = 000000007FF9F060
    R13 = 000000007FFCDCAC R14 = 0000000000000002 R15 = 000000003DA78301 Connection closed by foreign host.000000007FF9CA30 SS = 000000000000001B

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Volker Halle@21:1/5 to All on Thu Apr 4 10:49:15 2024
    Am 04.04.2024 um 09:52 schrieb motk:
    On 4/3/24 10:20, motk wrote:
    ...
    I did apparently accidentally fuzz things:

    $ product list  *

      Improperly handled condition, bad stack or no handler specified.
        Signal arguments:   Number = 0000000000000005
                            Name   = 000000000000000C
                                     0000000000000007
                                     0000000000006000
                                     FFFF830007C0236B
                                     0000000000000012
        Register dump:
        RAX = 0000000000000000  RDI = 000000007FF9DC80  RSI = 0000000000006000
        RDX = 5344524F5759454B  RCX = 0000000000006000  R8  = 00000000FFFF8F86
        R9  = 000000000808080D  RBX = 000000007FFABE00  RBP = 000000007FF9FF60
        R10 = 000000007FFABDB0  R11 = 000000007FFA4D18  R12 = 000000007FF9C0F8
        R13 = 0000000000000018  R14 = 000000007FF9C2B0  R15 = 0000000000008301
        RIP = FFFF830007C0236B  RSP = 000000007FF9FF00  SS  = 000000000000001B
    %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000000C, PC=0000000000000002, PS=7AD5D8EE

    motk,

    can you reproduce this ? Over and over again ?

    If so, please consider to report this in the VSI Forum together with a detailled description of your underlying software/hardware and the steps
    to reproduce this access violation.

    https://forum.vmssoftware.com/search.php?search_id=active_topics

    Volker.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From motk@21:1/5 to Volker Halle on Thu Apr 4 19:59:55 2024
    On 4/4/24 18:49, Volker Halle wrote:

    can you reproduce this ? Over and over again ?

    If so, please consider to report this in the VSI Forum together with a detailled description of your underlying software/hardware and the steps
    to reproduce this access violation.

    https://forum.vmssoftware.com/search.php?search_id=active_topics

    If I can reproduce it, I will. No luck so far.

    --
    motk

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Clubley@21:1/5 to Volker Halle on Thu Apr 4 12:43:09 2024
    On 2024-04-04, Volker Halle <volker_halle@hotmail.com> wrote:
    Am 04.04.2024 um 09:52 schrieb motk:
    On 4/3/24 10:20, motk wrote:
    ...
    I did apparently accidentally fuzz things:

    $ product list *

    Improperly handled condition, bad stack or no handler specified.
    Signal arguments: Number = 0000000000000005
    Name = 000000000000000C
    0000000000000007
    0000000000006000
    FFFF830007C0236B
    0000000000000012
    Register dump:
    RAX = 0000000000000000 RDI = 000000007FF9DC80 RSI = 0000000000006000 >> RDX = 5344524F5759454B RCX = 0000000000006000 R8 = 00000000FFFF8F86 >> R9 = 000000000808080D RBX = 000000007FFABE00 RBP = 000000007FF9FF60 >> R10 = 000000007FFABDB0 R11 = 000000007FFA4D18 R12 = 000000007FF9C0F8 >> R13 = 0000000000000018 R14 = 000000007FF9C2B0 R15 = 0000000000008301 >> RIP = FFFF830007C0236B RSP = 000000007FF9FF00 SS = 000000000000001B >> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
    address=000000000000000C, PC=0000000000000002, PS=7AD5D8EE

    motk,

    can you reproduce this ? Over and over again ?

    If so, please consider to report this in the VSI Forum together with a detailled description of your underlying software/hardware and the steps
    to reproduce this access violation.

    https://forum.vmssoftware.com/search.php?search_id=active_topics


    Well that's a seriously "interesting" thing to suggest Volker. :-(

    Assuming the posted output has not been edited, running a user-mode program resulted in the process being killed. That means it failed in either
    supervisor mode or executive mode. That means VSI need to be told _privately_ about the sequence to reproduce (if it can be discovered) so that they can
    see if the sequence can be modified to actually exploit the system.

    If that sequence is published in a public forum before VSI have analyzed
    and fixed the problem, it means anyone else will be able to perform the
    same analysis to see if the problem can be exploited. :-(

    Of course, the OP will have to report this to VSI via insecure email
    (if they can discover the sequence) because VSI clearly think it is
    below them to actually make available a public security reporting
    mechanism. :-(

    Simon.

    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Walking destinations on a map are further away than they appear.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From motk@21:1/5 to Simon Clubley on Fri Apr 5 19:49:04 2024
    On 4/04/2024 10:43 pm, Simon Clubley wrote:
    On 2024-04-04, Volker Halle <volker_halle@hotmail.com> wrote:
    Am 04.04.2024 um 09:52 schrieb motk:
    On 4/3/24 10:20, motk wrote:
    ...
    I did apparently accidentally fuzz things:

    $ product list  *

      Improperly handled condition, bad stack or no handler specified.
        Signal arguments:   Number = 0000000000000005
                            Name   = 000000000000000C
                                     0000000000000007
                                     0000000000006000
                                     FFFF830007C0236B
                                     0000000000000012
        Register dump:
        RAX = 0000000000000000  RDI = 000000007FF9DC80  RSI = 0000000000006000
        RDX = 5344524F5759454B  RCX = 0000000000006000  R8  = 00000000FFFF8F86
        R9  = 000000000808080D  RBX = 000000007FFABE00  RBP = 000000007FF9FF60
        R10 = 000000007FFABDB0  R11 = 000000007FFA4D18  R12 = 000000007FF9C0F8
        R13 = 0000000000000018  R14 = 000000007FF9C2B0  R15 = 0000000000008301
        RIP = FFFF830007C0236B  RSP = 000000007FF9FF00  SS  = 000000000000001B
    %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
    address=000000000000000C, PC=0000000000000002, PS=7AD5D8EE

    motk,

    can you reproduce this ? Over and over again ?

    If so, please consider to report this in the VSI Forum together with a
    detailled description of your underlying software/hardware and the steps
    to reproduce this access violation.

    https://forum.vmssoftware.com/search.php?search_id=active_topics


    Well that's a seriously "interesting" thing to suggest Volker. :-(

    Assuming the posted output has not been edited, running a user-mode program resulted in the process being killed. That means it failed in either supervisor mode or executive mode. That means VSI need to be told _privately_ about the sequence to reproduce (if it can be discovered) so that they can see if the sequence can be modified to actually exploit the system.

    I can guarantee that output wasn't mangled in any way. I've been trying
    to reproduce it with no success so far. It was an extremely surprising
    result though; would it have hit a log somewhere?


    If that sequence is published in a public forum before VSI have analyzed
    and fixed the problem, it means anyone else will be able to perform the
    same analysis to see if the problem can be exploited. :-(

    Fuzzing tools are free and plentiful.


    Simon.


    --
    motk

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Clubley@21:1/5 to motk on Fri Apr 5 12:27:31 2024
    On 2024-04-05, motk <meh@meh.meh> wrote:
    On 4/04/2024 10:43 pm, Simon Clubley wrote:
    Am 04.04.2024 um 09:52 schrieb motk:
    On 4/3/24 10:20, motk wrote:
    %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
    address=000000000000000C, PC=0000000000000002, PS=7AD5D8EE

    Assuming the posted output has not been edited, running a user-mode program >> resulted in the process being killed. That means it failed in either
    supervisor mode or executive mode. That means VSI need to be told _privately_
    about the sequence to reproduce (if it can be discovered) so that they can >> see if the sequence can be modified to actually exploit the system.

    I can guarantee that output wasn't mangled in any way. I've been trying
    to reproduce it with no success so far. It was an extremely surprising
    result though; would it have hit a log somewhere?


    The exit status on the accounting log may be interesting.

    Try a "$ acc/since=<whatever>/full" and once you have found the correct session, have a look at the exit status.

    Assuming the current mode bits on x86-64 in the PS register match those
    on Alpha, then, assuming I am decoding the bitfield correctly, it looks
    like an executive mode failure (ie: a failure in RMS itself). :-(

    Can someone confirm I am decoding the current mode bits in the above
    PS register correctly ?

    Simon.


    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Walking destinations on a map are further away than they appear.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Clubley@21:1/5 to Simon Clubley on Fri Apr 5 13:20:16 2024
    On 2024-04-05, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
    On 2024-04-05, motk <meh@meh.meh> wrote:
    On 4/04/2024 10:43 pm, Simon Clubley wrote:
    Am 04.04.2024 um 09:52 schrieb motk:
    On 4/3/24 10:20, motk wrote:
    %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
    address=000000000000000C, PC=0000000000000002, PS=7AD5D8EE

    Assuming the posted output has not been edited, running a user-mode program >>> resulted in the process being killed. That means it failed in either
    supervisor mode or executive mode. That means VSI need to be told _privately_
    about the sequence to reproduce (if it can be discovered) so that they can >>> see if the sequence can be modified to actually exploit the system.

    I can guarantee that output wasn't mangled in any way. I've been trying
    to reproduce it with no success so far. It was an extremely surprising
    result though; would it have hit a log somewhere?


    The exit status on the accounting log may be interesting.

    Try a "$ acc/since=<whatever>/full" and once you have found the correct session, have a look at the exit status.

    Assuming the current mode bits on x86-64 in the PS register match those
    on Alpha, then, assuming I am decoding the bitfield correctly, it looks
    like an executive mode failure (ie: a failure in RMS itself). :-(

    Can someone confirm I am decoding the current mode bits in the above
    PS register correctly ?


    Another idea: If this really is an executive mode failure, I wonder if
    setting BUGCHECKFATAL to 1 would be useful here ?

    Alex: What this would do is to turn the failure into a failure that
    crashes the system (and writes a dumpfile, assuming the VSI virtual
    image is setup correctly) instead of just deleting the current process.

    It would also mean anything in memory (including command history, etc)
    would be written to the dumpfile, so make sure there's nothing private
    in the memory of your system before performing more tests.

    What you could do then is to compress the dumpfile and send it to VSI
    privately via some means they give you.

    BTW, another idea: does x86-64 VMS currently write an entry into the
    errorlog on an executive mode bugcheck ? I wonder if it would be useful
    to check the errorlog to see if there is anything useful there from the previous failure ?

    Simon.

    PS: pointed message to VSI management: A hobbyist has just appeared to
    find a process-deleting bug within VMS that your testing has missed so far. _This_ is an example of why the hobbyist program is important, and of
    benefit, to you.

    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Walking destinations on a map are further away than they appear.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Clubley@21:1/5 to Simon Clubley on Fri Apr 5 13:22:22 2024
    On 2024-04-05, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

    Alex: What this would do is to turn the failure into a failure that
    crashes the system (and writes a dumpfile, assuming the VSI virtual
    image is setup correctly) instead of just deleting the current process.


    Oops. motk, not Alex. Sorry. :-)

    Simon.

    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Walking destinations on a map are further away than they appear.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Single Stage to Orbit@21:1/5 to Simon Clubley on Fri Apr 5 16:48:10 2024
    On Fri, 2024-04-05 at 13:20 +0000, Simon Clubley wrote:
    Alex: What this would do is to turn the failure into a failure that
    crashes the system (and writes a dumpfile, assuming the VSI virtual
    image is setup correctly) instead of just deleting the current
    process.

    Who, me? I think it's actually motk with the issue, is it not?
    --
    Tactical Nuclear Kittens

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Clubley@21:1/5 to Single Stage to Orbit on Fri Apr 5 17:15:06 2024
    On 2024-04-05, Single Stage to Orbit <alex.buell@munted.eu> wrote:
    On Fri, 2024-04-05 at 13:20 +0000, Simon Clubley wrote:
    Alex: What this would do is to turn the failure into a failure that
    crashes the system (and writes a dumpfile, assuming the VSI virtual
    image is setup correctly) instead of just deleting the current
    process.

    Who, me? I think it's actually motk with the issue, is it not?

    Yes, you. :-) As I posted in a followup, I got the name wrong. Sorry. :-)

    Simon.

    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Walking destinations on a map are further away than they appear.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From motk@21:1/5 to Simon Clubley on Sat Apr 6 10:36:42 2024
    On 5/04/2024 10:27 pm, Simon Clubley wrote:

    The exit status on the accounting log may be interesting.

    Try a "$ acc/since=<whatever>/full" and once you have found the correct session, have a look at the exit status.

    This seems relevant:

    Queue entry: Final status code: 1000000C
    Queue name:
    Job name:
    Final status text: %SYSTEM-F-ACCVIO, access violation, reason mask=!XB,
    virtual address=!XH, PC=!XH

    I remembered vaguely how to drive sysgen, and have enabled SYSTEM_CHECK
    now.

    Simon.

    --
    motk

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Clubley@21:1/5 to motk on Mon Apr 8 12:11:12 2024
    On 2024-04-05, motk <meh@meh.meh> wrote:
    On 5/04/2024 10:27 pm, Simon Clubley wrote:

    The exit status on the accounting log may be interesting.

    Try a "$ acc/since=<whatever>/full" and once you have found the correct
    session, have a look at the exit status.

    This seems relevant:

    Queue entry: Final status code: 1000000C
    Queue name:
    Job name:
    Final status text: %SYSTEM-F-ACCVIO, access violation, reason mask=!XB, virtual address=!XH, PC=!XH

    I remembered vaguely how to drive sysgen, and have enabled SYSTEM_CHECK
    now.


    Is there anything in the error log ?

    Simon.

    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Walking destinations on a map are further away than they appear.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From motk@21:1/5 to Simon Clubley on Tue Apr 9 10:32:54 2024
    On 4/8/24 22:11, Simon Clubley wrote:
    On 2024-04-05, motk <meh@meh.meh> wrote:

    I remembered vaguely how to drive sysgen, and have enabled SYSTEM_CHECK
    now.


    Is there anything in the error log ?

    I was trying to check that when it carked it last time :)

    --
    motk

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)