HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Comments on VMS TUD tour of Europe

 
SOLVED
Go to solution
Dave Gudewicz
Valued Contributor

Comments on VMS TUD tour of Europe

Now that the European TUD for VMS is coming to a close, can we get some comments from those who attended?

13 REPLIES
Hein van den Heuvel
Honored Contributor
Solution

Re: Comments on VMS TUD tour of Europe

Sue Skonetski posted a comment in comp.os.vms from HP/organizer perspective earlier today. See below.

fwiw, There is a similar thread here from Ian in:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=705846

It would indeed be interesting to her more attendee feedback.

Regards,
Hein.
----- sue's message from comp.os.vms -----

Dear Newsgroup,

Hello, from Vienna Austria. This is our fourth stop on the Technical
update tour. We have had an excellent time. We started in Stockholm
Sweden. We were in the HP office in Kista. The event sold out there
and a few people ended up sitting on the floor, we then moved to
Holland, Utrect (sp?)we had one spare seat on the first day. Then off
to London and now Austria. Its funny no matter where I go I am always
touched at how kind the VMS people are. The audience is always very
open to what we have to say about where are going and what we are
doing now. Hopefully people will post their own thoughts.

We are off to the last technical update day in Germany on Friday.

Warm Regards,
Sue
Dave Gudewicz
Valued Contributor

Re: Comments on VMS TUD tour of Europe

Thanks for the comments Hein.

I did see the other thread here, but it didn't contain much in the way of user comments on the event itself, more like "are you going" , etc.

It was Sue's note on cov (hope to see user comments) that got me to start this thread.
Jan van den Ende
Honored Contributor

Re: Comments on VMS TUD tour of Europe

Dave (and others interested),

of the many, many things passing by, the one that comes to my mind immediately is one point by Hoff.
In the IA64 version of VMS, the Stacks will be protected against execution.
Rationale: more and more U*X progs are ported, and A LOT (all?) of that is C-stuff. And with C, the programmer will have to specifically code to guard against buffer-overflows, which is often omitted or forgotten (from laziness or ignorance...).
As a result, there have been an un-VMS-sy amount of CERT warnings, yes, all for exploits of ported stuff. Since most exploits abuse stack manipulation & execution, making the stack non-executable prevents this.
In a private discussion afterward with Hoff I wondered why it was not also introduced on Alpha. "Because that MIGHT break existing code. Bad code, but running code".
I wondered if the feature might be turned on/off under control of Logical, or, if needing to be done very early, a SYSGEN param so as to give it to "the" community, while allowing the oddball, if at all existant. He liked the idea, and if no dragons turn up on thorough investigation, it would only synchronise Alpha and IA64 better.
Defenitely NOT for 8.2 though!!

And maybe you can have a look at
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=716858
as well.


Cheers.

Have one on me.

Jan
Don't rust yours pelled jacker to fine doll missed aches.
Uwe Zessin
Honored Contributor

Re: Comments on VMS TUD tour of Europe

I have a dim memory that early versions of Tru64 Unix (DEC OSF/1) had a protected stack, but that had to be given up for Java support.

Can't comment on the TUD, yet. It'll begin the day after tomorrow here in Germany.
.
Ian Miller.
Honored Contributor

Re: Comments on VMS TUD tour of Europe

A excellent event as always. The interaction with the engineers in the breaks as valuable as the presentations.

I think the secure email server is potentially a great idea.

I'm slightly concerned that the rules for licence transfer have changed. hp want to know if you move a licence from one i64 system to another. (previously if they where the same class DEC did not worry). As long as it is a simple thing to do and costs no money it will be fine.

Guy Peleg and Norm L. from RDB did a presentation that they had just written which was excellent and I would like to see more if it.

The marketing guy Martin Riley was interesting without too much fluff. You can be sure plenty of people wanted to talk to him about VMS marketing :-)
____________________
Purely Personal Opinion
Willem Grooters
Honored Contributor

Re: Comments on VMS TUD tour of Europe

Sue did a good job - as usual.
Given Jan's remark, there has been quit some concern on the CERN recommendations - all 5 in the last few years did have to do with ported OpenSource (=U*x) programs. Hopefully, the attitude and dicipline towards security and stability, that IMHO is lacking (in whatever degree) in that community, is NOT ported to VMS.

The way stack overflow is now prevented has it's drawbacks. In stead of silently taking over the system and comprimising data consistency, the system will crash. Hoff agreed it's not the best solution....
Willem Grooters
OpenVMS Developer & System Manager
Uwe Zessin
Honored Contributor

Re: Comments on VMS TUD tour of Europe

Excuse me, but I don't get it. What has a stack overflow (which one are you talking about, by the way?) have to do with disallowing code execution within the stack's memory area?

I think it has always been possible to catch a stack over/underflow by putting guard pages around it, but I don't see a way to limit the damage in kernel mode, either.
.
Ian Miller.
Honored Contributor

Re: Comments on VMS TUD tour of Europe

Regarding buffer overflow attacks you may wish to review the wise words of Keith Parris
http://www.google.com/groups?selm=6ec1251e.0204030914.7143730f%40posting.google.com&output=gplain

____________________
Purely Personal Opinion
John Gillings
Honored Contributor

Re: Comments on VMS TUD tour of Europe

Uwe,
>Excuse me, but I don't get it. What has a stack overflow (which one are you talking about, by the way?) have to do with disallowing code execution within the stack's memory area?

Without wanting to give away too much... if a program has a buffer allocated to the stack which is vulnerable to overflow, then you can send it a string which will overwrite the call frame, including the return address. If you arrange for the return address to point to a stack location, the same string can contain the code to be executed. So, by returning from the routine, you're transferring control to the bad guy's code. From there, the sky's the limit.

By marking the stack "no execute" you prevent this entire class of exploit. And since no normal programmer in their right mind would ever want to execute anything on the stack, you don't break anything either :-)
A crucible of informative mistakes
Uwe Zessin
Honored Contributor

Re: Comments on VMS TUD tour of Europe

A stack overflow (what Willem was talking about) and a buffer overflow (be it within the bounds of a stack or not) is two different things to me. Perhaps Willem meant the second.
.
Karl Rohwedder
Honored Contributor

Re: Comments on VMS TUD tour of Europe

The last event was here in germany.
It was crowded, around 130 customer attended the event. It was excellent, especially the already mentioned presentation from Guy and Norm.
Willem Grooters
Honored Contributor

Re: Comments on VMS TUD tour of Europe

Uwe,

You're right - I meant the BUFFER overflow, but in context of stack. John explained the method of exploit. This is the exploit that caused the last 5 CERT reports on VMS - or, to be more precise, on OpenSource software ported to VMS.
Using this exploit requires execute acecss on the stack pages. By removing this, it won't be possible to execute pushed code, so it won't compromise security. Drawback, as stated, is that not just the offending process will crash (that is for sure), but quit possible, the whole system as well.

Willem
Willem Grooters
OpenVMS Developer & System Manager
Uwe Zessin
Honored Contributor

Re: Comments on VMS TUD tour of Europe

Well, VMS has always tried to minimize the impact when something went wrong. It first tries to rundown the currently executing image - I remember an incident in the old days when we had an access problem to a Massbus disk where a secondary pagefile was located. Lots of users were dropped to DCL, but the system was continuing.

The next step is trying to delete the process.

And finally, yes, the system will crash. But this is to protect the data - the system restarts with a new, fresh copy of OpenVMS instead of trying to continue from a possible compromised memory configuration.
.