Comments on VMS TUD tour of Europe

[Dave Gudewicz]

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

[Hein van den Heuvel · Accepted solution]

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]

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]

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

[Uwe Zessin]

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.]

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 :-)

[Willem Grooters]

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....

[Uwe Zessin]

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.]

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

[John Gillings]

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 :-)