Re: [Simh] Mark's mailbox full
I actually find it interesting how much it reveals about the target e-mail and account configuration We know he's running VMS We know he has a disk called $DISK3: We know his user space is under $DISK3:[MARK] And we know we've successfully filled his disk, thus denying some level of service and system functionality In this era of hackers that feed off this sort of exposed data, I doubt any modern mail server would be game to post back so much configuration-specific information that could be used to aid in a targeted hacking attack. Cheers Jason A -Original Message- From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Alan Frisbie Sent: Friday, 7 August 2015 7:33 PM To: SIMH@trailing-edge.com Subject: [Simh] Mark's mailbox full If anyone know how to get in touch with Mark Pizzolato outside of email, please let him know that he has a disk allocation failure: This is a report on the delivery status of your message. Message-ID: 15080716022951_...@slug.flying-disk.com Subject: Re: [Simh] Problem with default builds --Failed delivery to: Address: MARK+SIMH Status: error writing !AS Reporting-MTA: dns;infocomm.com Arrival-Date: Fri, 7 Aug 2015 15:25:38 -0700 Final-Recipient: x-local;MARK+SIMH Action: failed Status: 5.2.0 (Other or undefined mailbox status) Diagnostic-Code: x-local;error writing !AS %MAIL-W-WRITEERR, error writing $DISK3:[MARK.MAIL]MAIL.MAI -RMS-F-FUL, device full (insufficient space for allocation) Last-Attempt-Date: Fri, 7 Aug 2015 15:25:40 -0700 Thanks, Alan Frisbie ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Mark's mailbox full
It might be helpul to post this to comp.os.vms too, since new development on VMS is in the works and security is high on their list of things to work on. On Mon, 10 Aug 2015 15:06:06 + Armistead, Jason BIS jason.armist...@otis.com wrote: I actually find it interesting how much it reveals about the target e-mail and account configuration We know he's running VMS We know he has a disk called $DISK3: We know his user space is under $DISK3:[MARK] And we know we've successfully filled his disk, thus denying some level of service and system functionality In this era of hackers that feed off this sort of exposed data, I doubt any modern mail server would be game to post back so much configuration-specific information that could be used to aid in a targeted hacking attack. Cheers Jason A -Original Message- From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Alan Frisbie Sent: Friday, 7 August 2015 7:33 PM To: SIMH@trailing-edge.com Subject: [Simh] Mark's mailbox full If anyone know how to get in touch with Mark Pizzolato outside of email, please let him know that he has a disk allocation failure: This is a report on the delivery status of your message. Message-ID: 15080716022951_...@slug.flying-disk.com Subject: Re: [Simh] Problem with default builds --Failed delivery to: Address: MARK+SIMH Status: error writing !AS Reporting-MTA: dns;infocomm.com Arrival-Date: Fri, 7 Aug 2015 15:25:38 -0700 Final-Recipient: x-local;MARK+SIMH Action: failed Status: 5.2.0 (Other or undefined mailbox status) Diagnostic-Code: x-local;error writing !AS %MAIL-W-WRITEERR, error writing $DISK3:[MARK.MAIL]MAIL.MAI -RMS-F-FUL, device full (insufficient space for allocation) Last-Attempt-Date: Fri, 7 Aug 2015 15:25:40 -0700 Thanks, Alan Frisbie ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh -- Please DO NOT COPY ME on mailing list replies. I read the mailing list. RSA 4096 fingerprint 7940 3F02 16D3 AFEE F2F8 ACAA 557C 4B36 98E4 4D49 ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] Needed: RH750 specification
Mark Pizzolato sent me a note about a code sequence in the original VAX750 bootstrap that fails on the 750 simulator. The code is doing a BBC #7,address,10$ where the address is in the RH750 Massbus adapter. The sequence fails because the simulated RH750 throws an error - the operand access is not an aligned longword. BBC and the other bit branches use a byte access operand. The SRM says that VAX implementations must access the precise byte specified by the base address and the byte part of the bit offset. There's no leeway in the wording, and the VAX chips (and the 780) do precisely that. If the 750 microcode is correctly implemented, then the best explanation is that the RH750, unlike the RH780, does not in fact check the length (and possibly not the alignment) of register accesses. This is true of the respective Unibus adapters: the 780's does lots of checking, the 750's does none. The 750 simulator is not mine, but I'd like to track this problem down. The RH750 schematics don't help, because the critical logic is inside gate arrays. What's needed is an RH750 specification. Does anyone have it? Thanks, /Bob Supnik ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Needed: RH750 specification
On 10-Aug-15 14:13, Bob Supnik wrote:
Mark Pizzolato sent me a note about a code sequence in the original
VAX750 bootstrap that fails on the 750 simulator. The code is doing a
BBC #7,address,10$
where the address is in the RH750 Massbus adapter. The sequence fails
because the simulated RH750 throws an error - the operand access is
not an aligned longword.
BBC and the other bit branches use a byte access operand. The SRM says
that VAX implementations must access the precise byte specified by the
base address and the byte part of the bit offset. There's no leeway in
the wording, and the VAX chips (and the 780) do precisely that.
This is not exactly correct. BB uses a FIELD access, not a pure byte
access. SRM 3.5 (p. 3-56 BB) opcode pos.rl, base.vb, displ.bb,
{field.mv} Note the v.
Fields are 1-5 bytes, and access the minimum number of aligned
longwords necessary to to contain the field. (SRM 1.2.10) (Rev. J
added a reference to INSV in 3.4, but this postdates the 750 and isn't
relevant here.)
The SRM also says that BBC is not legal in I/O space. See 7.5.5 (3) --
BBC is a control instruction with a field operand. Operand types of
field are not legal in I/O space.
As a practical matter, BB is problematic in I/O space. For example,
Aquarius fetches a quadword around the base address, which can have side
effects reading the unwanted register... (And yes, the implementation
conforms to 1.2.10 from the programmer's perspective when the field is
in memory.) I remember finding and removing a number of OS/driver bugs
where I/O space was used...
That said, programmers do things that are unspecified when they seem
to work on the hardware they're using, move on.
Apparently the 750 hardware deals with whatever access the CPU generates
for BBC - which architecturally can be anything from a byte read to a
longword.
I don't have the RH750 specification - but this is unspecified
behavior. I would be mildly surprised if the spec bothered to mention it.
The spirit of SimH, of course, is to make the software work despite
implementation bugs. I'd say this is an unspecified behavior in the
RH750 simulator that SimH needs to fix there... Removing the check is
probably the right hack - with a suitable comment.
If the 750 microcode is correctly implemented, then the best
explanation is that the RH750, unlike the RH780, does not in fact
check the length (and possibly not the alignment) of register
accesses. This is true of the respective Unibus adapters: the 780's
does lots of checking, the 750's does none.
Either the 780 driver doesn't do this, or this particular case isn't
checked for in the 780 hardware. The hardware is not obliged to check
for UNSPECIFIED behavior (FIELD in I/O space). If the 780 ucode happens
to make a longword reference to fetch the byte for BB (which is valid
for memory, so long as it's aligned won't pagefault), things would
appear to work. Without looking at the hardware, that would be my guess.
The 750 simulator is not mine, but I'd like to track this problem
down. The RH750 schematics don't help, because the critical logic is
inside gate arrays. What's needed is an RH750 specification. Does
anyone have it?
Thanks,
/Bob Supnik
smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Mark's mailbox full
Consider that it possible that disk quotas have been applied and/or $DISK3 could be a logical disk with a small size to avoid impacting services. In fact, Mark may only use that username for email. On 8/10/2015 8:06 AM, Armistead, Jason BIS wrote: I actually find it interesting how much it reveals about the target e-mail and account configuration We know he's running VMS We know he has a disk called $DISK3: We know his user space is under $DISK3:[MARK] And we know we've successfully filled his disk, thus denying some level of service and system functionality In this era of hackers that feed off this sort of exposed data, I doubt any modern mail server would be game to post back so much configuration-specific information that could be used to aid in a targeted hacking attack. Cheers Jason A -Original Message- From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Alan Frisbie Sent: Friday, 7 August 2015 7:33 PM To: SIMH@trailing-edge.com Subject: [Simh] Mark's mailbox full If anyone know how to get in touch with Mark Pizzolato outside of email, please let him know that he has a disk allocation failure: This is a report on the delivery status of your message. Message-ID: 15080716022951_...@slug.flying-disk.com Subject: Re: [Simh] Problem with default builds --Failed delivery to: Address: MARK+SIMH Status: error writing !AS Reporting-MTA: dns;infocomm.com Arrival-Date: Fri, 7 Aug 2015 15:25:38 -0700 Final-Recipient: x-local;MARK+SIMH Action: failed Status: 5.2.0 (Other or undefined mailbox status) Diagnostic-Code: x-local;error writing !AS %MAIL-W-WRITEERR, error writing $DISK3:[MARK.MAIL]MAIL.MAI -RMS-F-FUL, device full (insufficient space for allocation) Last-Attempt-Date: Fri, 7 Aug 2015 15:25:40 -0700 Thanks, Alan Frisbie ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
