Arbitrary Sandbox

Arbitrary Sandbox

[Rob Shea]

I've been handed a project, but I'm not a programmer, much less an Ada
programmer. The idea is a Windows test station sandbox where arbitrary
applications can be executed, but cannot make system changes or
transmit data.

I have two primary voice on my team, one is calling for J# as the .NET
framework will allow for "faster development and provides important
security features" and the other is calling for Ada because "safety is
the primary concern and it's cheaper to build it right the first
time."

Obviously these two choices are dramatically and I am leaning toward
J#, because, to be perfectly honest I've never been involved in an Ada
project before that wasn't hardware execution, embedded system, etc.
and that leaves my a little prejudice about it's place.

All things being equal, is it silly to utilize Ada in this manner? If
I could trouble any of you for arguments for and against would be
appreciated. I don't want to go too deep or heated or anything like
that, I'll need to decide, really by Monday.

Thank you!

Rob

Re: Arbitrary Sandbox

[Rob Shea]

Oops! I meant C#, not J#. (Also, there is apparently A#?)

cheers,

Rob

Re: Arbitrary Sandbox

[Tez]

On Feb 9, 6:10 pm, Rob Shea <zzyca...@gmail.com> wrote:
> Oops! I meant C#, not J#. (Also, there is apparently A#?)
>
> cheers,
>
> Rob

If you are much less a programmer, truthfully you are going to have
problems with both C# and Ada.  Ada and C# are both general purpose
enough that they will both do what you like for them to do.  Ada
types, kinda like Haskell types can throw you off if you have
programmed for a while.  They force you to think in a different way.
Some people say that Ada and Haskell can be easier to learn if you
don't have any experience -- as you don't have and
preconceptions.  .NET and Java EE can be their own nightmare.

If I were you, I would honestly start with Python.  It is a great
language to start with, you could probably read some well written
python and mostly understand what is going on.  There is an abundance
of free material to get you going.  Python can give you instant
satisfaction, as it wouldn't take long for you to be productive.
Mostly any idea you may have, you can probably do it in Python, and
probably have it off the ground or at least prototyped in a lot less
time than with a lot of other languages.

If you are set on learning Ada or C#, have at it.  Both are
sufficiently powerful.  Useful to learn both.  Neither Ada or C# are
the best fit for every problem you come across.

Re: Arbitrary Sandbox

[Rob Shea]

>
> If you are much less a programmer, truthfully you are going to have
> problems with both C# and Ada.  Ada and C# are both general purpose
> enough that they will both do what you like for them to do.  Ada
> types, kinda like Haskell types can throw you off if you have
> programmed for a while.  They force you to think in a different way.
> Some people say that Ada and Haskell can be easier to learn if you
> don't have any experience -- as you don't have and
> preconceptions.  .NET and Java EE can be their own nightmare.
>

My bad... I will not be doing any coding on this project. I have been
dropped in to get the client's/investor's/internal technical teams all
on the same page as there has been much bickering. So far good
progress has been made on a number of points, but this one has thrown
me as it flies in the face of my experiences with Ada development and
I just wanted a to hear a few more voices on the subject before the
next meeting and subsequent decision.

So, how would you sell an executive on or against Ada (or C#) for this
particular use?

Thanks,

Rob

Re: Arbitrary Sandbox

[Tez]

Gotcha.  I honestly misread your initial post.  I now see your problem
a little more clearly.  C# has the benefit of being much more of a
gorilla than Ada.  You will have a better time finding maintainers
with C# versus Ada.  That may not mean a lot to you if you are not
using the .NET stack very much.  Don't sell Ada short either though,
it is incredibly powerful.  Without knowing much about what you are
trying to accomplish, it is difficult to give you a hard
recommendation either way.

For a business in the US.  Without knowing anything else about the
project, C# probably makes more sense.  Hurts a bit, because I
definitely want to say Ada.

Re: Arbitrary Sandbox

[Shark8]

On Feb 9, 8:47 pm, Tez <mont...@gmail.com> wrote:
>
>>> So, how would you sell an executive on or against Ada (or C#) [for this
>> particular use]*?
>
> I definitely want to say Ada.

Then say Ada; give him your sale's-pitch!

* -- I'm omitting this; because I can.

But, seriously, there's several things I'd say to try to sell it,
although
I'm not by any means an Ada expert.

1 -- Maintainability
  Ada is extremely maintainable, its syntax lends itself more to
"self-
  documenting" code than anything I've seen from the curly-brace
languages.
  ('Self-documenting' is a myth, BTW; comments still rule in that
regard.)

  I've heard people say that they've plopped 20-year-old Ada code into
a
  compiler from a completely different vendor, had clean-compiles and
were
  up-and-running with no changes (note, this changes when compiler-
specific
  features, like GNAT's 'IMG attribute, are used). This indicates, to
me,
  that the well-defined nature, and the rejection of the non-
conforming
  implementations, give the source-code more stability** precisely
because
  the language is standardized. (**Stability in that the source does
not
  change meaning dependent upon which compiler is being used.)

2 -- Compile- (and run-) Time Error-Checking
  I've been using PHP for about the past year; and I _REALLY_ miss
this.
  I can't count the number of times that I've had to go back and fix
some
  code that someone broke because they changed the return-type format;
yes,
  this particular problem won't crop up in C# as it has return-types
attached
  to its functions, but consider: the earlier a bug is caught the
cheaper it
  is to fix.

  And then there's array indexing; given that Anders Hejlsberg (of
Turbo
  Pascal and Delphi) was recruited by Microsoft and given the lead
position
  I would be VERY surprised if the index-checking wasn't addressed in
C#,
  but C# *STILL* forces you to use zero-based indexing, which is a
stupid
  limitation that only gets in one's way. {In order to, say, match a
column
  number from a spreadsheet with it's associated array-index,
especially
  when the spreadsheet's column-numbers are one-based and someone's
talking
  about "column 3" after it's been read-in it becomes easy for the off-
by-1
  error to creep in.}

  Subtyping is another feature that is, quite frankly, AMAZING that
other
  languages haven't adopted. Being able to exclude values from a
problem-
  set means that you can write your code in such a way as to cater to
the
  "general case" and rely on the subtype-exclusion to weed-out the
  problematic values; case-in-point, Null-exclusion if you have a
procedure
  whose inner-processes are checking for Null all the time you can
simply
  re-write it as though you know that the pointers aren't Null and
then
  ensure that the subtype excludes null -- an attempt to assign the
bad
  value will be caught by the compiler, if it's static, or raise the
  CONSTRAINT_ERROR exception if it is dynamic.
    E.G Function X( Input : SOME_ACCESS ) Return SOME_TYPE is
     [...] checks that Input is not null [...] end X;
    would become
      Subtype NN_SOME_ACCESS is Not Null SOME_ACCESS;
      Function X( Input : NN_SOME_ACCESS ) Return SOME_TYPE is
     [...] just use Input as if it weren't null [...] end X;

3 -- Structuring & Reliability (Packages)
  This goes hand-in-hand with maintainability; but the ability to have
a
  single well-defined specification and implementation separation is
  something else that I miss greatly when I'm forced to do PHP; the
reason
  one can't "just program" in PHP is because you have to go to the
function
  itself and determine things like what type/format the parameters are
  expected to be in, and the return type (or even if there is one), or
if
  any of those change due to a parameter or some magic global
variable. Now
  I don't expect C# to be that bad, but in my experience C & C++ are
  _HORRID_ when it comes to maintaining an separation of spec and
body.

  Just like the big boon of being able to concern yourself with "just
the
  parameters and the procedure" was a big leap forward in making
provable
  and reliable code in the industry, packages allow you to do the same
but
  in a scalable manner. Furthermore, the specification/implementation
  divide means that you can sit down and *design* the system rather
than
  the current (far more bug-prone) "just grow the system" attitude
that
  seems more prevalent where I work. (Yes, it's website-design, and
yes
  that attitude is *why* we use PHP... but as someone once said, it
doesn't
  matter if you have a method for multiplying that is a hundred times
  faster but gives the wrong answer [sometimes], it's not a hundred
times
  faster, it's wrong.)

As for the other interesting things in Ada, like concurrency, I'm not
an
expert nor do I know if they would be applicable to your project. Yes,
you
can argue that all of my points are moot "with best practices" or
"correct
software engineering" and that "careful programming" can avoid them;
but
let me counter with this analogy: a "careful driver" who is "correct
in
all aspects regarding traffic statutes" and knows his car intimately
is
the most dangerous driver to be around when he's tired (sleep
deprived)
and under pressure.

Re: Arbitrary Sandbox

[BrianG]

On 02/09/2012 09:47 PM, Tez wrote:
> Gotcha.  I honestly misread your initial post.  I now see your problem
> a little more clearly.  C# has the benefit of being much more of a
> gorilla than Ada.
Is that a good thing or a bad thing? :-)
 >                    You will have a better time finding maintainers
> with C# versus Ada.
If your only requirement is to find people with "experience" in your 
chosen language, that's a good thing.  If you want people who can 
actually do what you need, it may or may not be - it may only increase 
the 'chaff' you need to sort thru to find the 'wheat' you're looking for.

It can also be a good thing if you want to entice people who's primary 
motivation is to add "good" things to their resume (I'm not sure if this 
is good or bad, they're just as likely to leave when something even 
better comes up).
 >                      That may not mean a lot to you if you are not
> using the .NET stack very much.  Don't sell Ada short either though,
> it is incredibly powerful.  Without knowing much about what you are
> trying to accomplish, it is difficult to give you a hard
> recommendation either way.
>
> For a business in the US.  Without knowing anything else about the
> project, C# probably makes more sense.  Hurts a bit, because I
> definitely want to say Ada.


-- 
---
BrianG
000
@[Google's email domain]
.com

Re: Arbitrary Sandbox

[tmoran]

> So, how would you sell an executive on or against Ada (or C#) for this
> particular use?
   The use of the term "Sandbox" suggests security is a primary goal.  Ada
was invented for the military.

> The idea is a Windows test station sandbox where arbitrary
> applications can be executed, but cannot make system changes or
> transmit data.
   Could you be more specific?  That sounds like a computer running
Windows, alone in a dedicated room, with no connections to the outside.

Re: Arbitrary Sandbox

[Rob Shea]

Thank you for all the feedback Shark8


>    The use of the term "Sandbox" suggests security is a primary goal.  Ada
> was invented for the military.
>
True, and that is a bit point in favour.

> > The idea is a Windows test station sandbox where arbitrary
> > applications can be executed, but cannot make system changes or
> > transmit data.
>
>    Could you be more specific?  That sounds like a computer running
> Windows, alone in a dedicated room, with no connections to the outside.

Well, virtually speaking, that is exactly what I want... literally
speaking it's a Windows system, networked, with removable disks, that
needs to run untrusted code processing untrusted data. This untrusted
data and the system, network, printer, usb, etc must be immutable. A
read-only compartment that can run arbitrary, dangerous, code, safely.

In other words, a very simple and restrictive, operating system level
virtualization tool for Windows, that can be initiated by unprivileged
users.

cheers,

rob

Re: Arbitrary Sandbox

[Jeffrey Carter]

On 02/09/2012 09:41 PM, Rob Shea wrote:
>
>>     The use of the term "Sandbox" suggests security is a primary goal.  Ada
>> was invented for the military.
>>
> True, and that is a bit point in favour.

More along those lines: Ada is the language of choice for software that must 
behave correctly. It's the language of choice for SW that flies jetliners, 
controls passenger trains, controls nuclear reactors, and the like.

Why is that? The answer is lives and money. If the SW fails, lives may be lost, 
and the company could be out billions of dollars. Ada has demonstrated that it 
is the least expensive way to get SW that won't do that.

So if correct behavior of your SW is important, Ada is the way to go. You'll 
have to pay for decent SW engineers, and they're not cheap. If you don't care 
how the SW behaves, then you might be able to save some development money by 
using a popular language and the cheap people who use it. But if you've got 
decent SW engineers, a small group of them using Ada can usually produce better 
SW faster and cheaper than a large group of coders using a popular language.

-- 
Jeff Carter
"IMHO, Interfaces are worthless."
Randy Brukardt
117

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Re: Arbitrary Sandbox

[Rob Shea]

I understand the benefits of Ada in embedded systems and the like, but
are these benefits lost when used on top of all the abstraction that
is Windows?

Cheers,

Rob

On Feb 10, 5:15 pm, Jeffrey Carter
<spam.jrcarter....@spam.not.acm.org> wrote:
> On 02/09/2012 09:41 PM, Rob Shea wrote:
>
>
>
> >>     The use of the term "Sandbox" suggests security is a primary goal.  Ada
> >> was invented for the military.
>
> > True, and that is a bit point in favour.
>
> More along those lines: Ada is the language of choice for software that must
> behave correctly. It's the language of choice for SW that flies jetliners,
> controls passenger trains, controls nuclear reactors, and the like.
>
> Why is that? The answer is lives and money. If the SW fails, lives may be lost,
> and the company could be out billions of dollars. Ada has demonstrated that it
> is the least expensive way to get SW that won't do that.
>
> So if correct behavior of your SW is important, Ada is the way to go. You'll
> have to pay for decent SW engineers, and they're not cheap. If you don't care
> how the SW behaves, then you might be able to save some development money by
> using a popular language and the cheap people who use it. But if you've got
> decent SW engineers, a small group of them using Ada can usually produce better
> SW faster and cheaper than a large group of coders using a popular language.
>
> --
> Jeff Carter
> "IMHO, Interfaces are worthless."
> Randy Brukardt
> 117
>
> --- Posted via news://freenews.netfront.net/ - Complaints to n...@netfront.net ---

Re: Arbitrary Sandbox

[Jeffrey Carter]

On 02/09/2012 11:18 PM, Rob Shea wrote:
>
> I understand the benefits of Ada in embedded systems and the like, but
> are these benefits lost when used on top of all the abstraction that
> is Windows?

Anything that runs on top of Windows is going to be subject to any weakness in 
Windows. That's true no matter what language you use.

-- 
Jeff Carter
"Your mother was a hamster and your father smelt of elderberries."
Monty Python & the Holy Grail
06

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Re: Arbitrary Sandbox

[Thomas Løcke]

On 02/10/2012 05:41 AM, Rob Shea wrote:
> In other words, a very simple and restrictive, operating system level
> virtualization tool for Windows, that can be initiated by unprivileged
> users.


I have to ask: Why not just virtualize these Windows boxes? Run them
read-only using something like QEMU/KVM or VirtualBox? They both have
a feature where all changes made to the guest OS is written to an image
of your own choice, or simply take a snapshot when starting the OS, do
your stuff and rollback when shutting the guest down.

This is a standard feature in most virtualization solutions.

Or do you have some special needs where the Windows machine _must_
run on bare metal?

-- 
Thomas L�cke | thomas@12boo.net | http://12boo.net

Re: Arbitrary Sandbox

[Rob Shea]

Only some applications need to be handled in this way, as they are
developed (hence the arbitrary requirement) while other applications
require all the normal abilities, like network access and file system
writing.

Thank you for the suggestion though, it would make life a bit easier,
but alas not appropriate here.

Cheers,

Rob

On Feb 10, 5:19 pm, Thomas Løcke <t...@ada-dk.org> wrote:
> On 02/10/2012 05:41 AM, Rob Shea wrote:
>
> I have to ask: Why not just virtualize these Windows boxes? Run them
> read-only using something like QEMU/KVM or VirtualBox? They both have
> a feature where all changes made to the guest OS is written to an image
> of your own choice, or simply take a snapshot when starting the OS, do
> your stuff and rollback when shutting the guest down.
>
> This is a standard feature in most virtualization solutions.
>
> Or do you have some special needs where the Windows machine _must_
> run on bare metal?
>
> --
> Thomas Løcke | tho...@12boo.net |http://12boo.net

Re: Arbitrary Sandbox

[Thomas Løcke]

On 02/10/2012 10:32 AM, Rob Shea wrote:
>
> Only some applications need to be handled in this way, as they are
> developed (hence the arbitrary requirement) while other applications
> require all the normal abilities, like network access and file system
> writing.



Then simply run more guests, with differing setups and permissions.

Honestly, it sounds like you guys are trying to reinvent the wheel.

Virtualization today is cheap and easy, so unless you specifically need
to run on bare metal, I fail to see why you would ever want to invent
your own sandbox environment. This has already been done to death by a
bunch of very skilled and knowledgable people.

By using some of the existing technologies you get the added benefit of
snapshots, cloning and a very fine grained control over what hardware
the guest sees.



>
> Thank you for the suggestion though, it would make life a bit easier,
> but alas not appropriate here.



Obviously I've no idea what you're actually trying to accomplish or what
your final goals are, but as soon as I read this:

"The idea is a Windows test station sandbox where arbitrary
applications can be executed, but cannot make system changes or
transmit data"

Then I'm instantly thinking: Already solved, by every single
virtualization product out there.

Unless there's more to your product than what you've described, I
honestly think you'd be doing yourself a disservice by trying to come
up with a homegrown solution.

If you're trying to build walls around unsafe programs inside Windows,
I believe you're setting yourself up for failure.

But if this is what you want to do, then you should obviously go with
Ada, simply because it was created with safety and security in mind. I
don't know of any other language where this is the case.

Good luck!  :o)

-- 
Thomas L�cke | thomas@12boo.net | http://12boo.net

Re: Arbitrary Sandbox

[Ludovic Brenta]

Rob,

I second Thomas' suggestion that you first look into existing
virtualization solutions.

If you decide that no existing virtualization solution works for you,
then fall back on Ada and perhaps even SPARK, a subset of Ada
sugmented with annotations suitable for static analysis and formal
proof of correctness.  There is a detailed case study of how SPARK has
been used to achieve military-grade security here:

http://www.adacore.com/home/products/sparkpro/tokeneer/

I believe that if you implement a virtual machine in C# you will
probably fail because C# already runs on the .NET virtual machine; it
makes no sense to create a virtual machine on top of another.  If you
use Ada and program to the bare Win32 API, you stand only a small
chance of success because the weakest link in your solution will be
Windows itself.  If you target the bare metal, then you can
reimplement a hypervisor on top of which the untrusted, obscure and un-
audited Windows code base can run; this is your only reasonable option
IMHO.  Since several hypervisors already exist, your only chance to
make a difference and prove the superiority of your implementation is
to use SPARK and formal proof.

Good luck.

--
Ludovic Brenta.

Re: Arbitrary Sandbox

[Brian Drummond]

On Thu, 09 Feb 2012 20:41:05 -0800, Rob Shea wrote:

>>    Could you be more specific?  That sounds like a computer running
>> Windows, alone in a dedicated room, with no connections to the outside.
> 
> Well, virtually speaking, that is exactly what I want... literally
> speaking it's a Windows system, networked, with removable disks, that
> needs to run untrusted code processing untrusted data. This untrusted
> data and the system, network, printer, usb, etc must be immutable. A
> read-only compartment that can run arbitrary, dangerous, code, safely.

It's not clear to me how "arbitrary" this code is...
do you mean, arbitrary code that is part of this project, written in 
(your choice of) Ada or C#, to establish the trustworthiness of your 
team's app?

or do you mean that Ada or C# is to be used to help sandbox the machine 
against unknown executables, maybe downloaded from dodgy Iranian websites 
or lottery emails via those removable disks?

The former case, it seems to me, Ada would be the better choice.
In the latter, there may be more tools and better integration between C# 
and Windows, that make C# easier and faster to develop, if not 
necessarily ultimately better.

- Brian

Re: Arbitrary Sandbox

[Maciej Sobczak]

On 10 Lut, 05:41, Rob Shea <zzyca...@gmail.com> wrote:

> >    Could you be more specific?  That sounds like a computer running
> > Windows, alone in a dedicated room, with no connections to the outside.
>
> Well, virtually speaking, that is exactly what I want... literally
> speaking it's a Windows system, networked, with removable disks, that
> needs to run untrusted code processing untrusted data.

> In other words, a very simple and restrictive, operating system level
> virtualization tool for Windows, that can be initiated by unprivileged
> users.

Then I don't understand why you got stuck at the level of language
choices. Neither .NET nor Ada will provide you this level of isolation
- both can initiate malicious network connections and both can read
and write files, for example.

I think that you should take a look at virtualization solutions like
VMWare. This allows to create an operating system within an operating
system, which is great for experimentation as well as for creating
security sandboxes. In essence, such a sandbox is like a separate
machine, but does not require separate hardware.
What is most important, you can really run *arbitrary applications* on
such a sandboxed system (just as you have described in your initial
post), no matter what language they are written in. Note that if you
choose .NET as your "virtualization solution", then you will *not* be
able to run any application that is not .NET-based. Similarly, if you
pick Python, you will only be able to run Python applications on it.
Same for Java [*].
That does not count as "I can run arbitrary applications on it" for
me.

[*] Yes, I know that there are many .NET-based languages, and there
are many languages based on the JVM. Still, that does not count as "I
can run arbitrary applications on it".

The advantage of real virtual machines (of the VMWare or Parallels,
etc. kind) is that you can do with them things that you would never
find a courage to do with your physical machine. This is really a
great tool for creating experimental, testing or security sandboxes
and I'd recommend that you take a look at them.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Arbitrary Sandbox

[Dmitry A. Kazakov]

On Sat, 11 Feb 2012 02:32:45 -0800 (PST), Maciej Sobczak wrote:

> This allows to create an operating system within an operating
> system, which is great for experimentation as well as for creating
> security sandboxes. In essence, such a sandbox is like a separate
> machine, but does not require separate hardware.

I wonder when (maybe already) the malware will start to target specifically
virtualization software.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Arbitrary Sandbox

[Maciej Sobczak]

On 11 Lut, 12:39, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> I wonder when (maybe already) the malware will start to target specifically
> virtualization software.

That would not be any different from a malware that targets separate
physical machines. This of course exists already, but the advantage of
a virtual machine is that it can be protected by means that are
outside of it. For example, a virtual machine can be put behind a
firewall that is outside of the virtual machine (and is therefore
unreachable from inside of it) instead of relying on a firewall that
is part of the sandboxed system. I count it as an added security.

Of course, a virtual machine is a software and can have its own bugs.
Whether they can be exploited by a contained (sandboxed) software is
another story - but such speculations are true about any software
tools, including compilers themselves. We have to trust something and
I think that VM-based sandbox is safer than no sandbox at all.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Arbitrary Sandbox

[Dmitry A. Kazakov]

On Sat, 11 Feb 2012 13:15:12 -0800 (PST), Maciej Sobczak wrote:

> On 11 Lut, 12:39, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> I wonder when (maybe already) the malware will start to target specifically
>> virtualization software.
> 
> That would not be any different from a malware that targets separate
> physical machines. This of course exists already, but the advantage of
> a virtual machine is that it can be protected by means that are
> outside of it. For example, a virtual machine can be put behind a
> firewall that is outside of the virtual machine (and is therefore
> unreachable from inside of it) instead of relying on a firewall that
> is part of the sandboxed system. I count it as an added security.

A firewall running on the same hardware is not outside. There is no
difference sp long the insulation is software-based. The only difference
could be if the host OS is more secure than the guest one.

Evidently, a guest OS is as secure as the host OS is, or less.

> I think that VM-based sandbox is safer than no sandbox at all.

I think that VM is yet another distraction (like firewalls, anti-virus
software are) rather that a solution of safety problems of existing OSes
and protocols.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Arbitrary Sandbox

[Rob Shea]

I agree.

However, this is all getting off point now and I think I have enough
information to properly moderate the debate.

Thank you all for the help!

On Feb 12, 8:38 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Sat, 11 Feb 2012 13:15:12 -0800 (PST), Maciej Sobczak wrote:
> > On 11 Lut, 12:39, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> I think that VM is yet another distraction (like firewalls, anti-virus
> software are) rather that a solution of safety problems of existing OSes
> and protocols.
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

Re: Arbitrary Sandbox

[Tez]

On Feb 11, 5:39 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Sat, 11 Feb 2012 02:32:45 -0800 (PST), Maciej Sobczak wrote:
> > This allows to create an operating system within an operating
> > system, which is great for experimentation as well as for creating
> > security sandboxes. In essence, such a sandbox is like a separate
> > machine, but does not require separate hardware.
>
> I wonder when (maybe already) the malware will start to target specifically
> virtualization software.
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

On a separate note.  There is already malware that target the virtual
machine.  Some will bypass the SEH if it detects if it is in a virtual
machine.  Some will also rely on timing anomalies to determine if they
are in a virtual machine as well.

Re: Arbitrary Sandbox

[Yannick Duchêne (Hibou57)]

Le Mon, 13 Feb 2012 03:10:52 +0100, Tez <montezf@gmail.com> a écrit:
> On a separate note.  There is already malware that target the virtual
> machine.  Some will bypass the SEH if it detects if it is in a virtual
> machine.
What is "SEH"?


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Arbitrary Sandbox

[Pascal Obry]

Le 13/02/2012 10:08, Yannick Duchêne (Hibou57) a écrit :

> What is "SEH"?

Structured Exception Handling.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Arbitrary Sandbox

[Georg Bauhaus]

On 10.02.12 03:21, Rob Shea wrote:

> My bad... I will not be doing any coding on this project. I have been
> dropped in to get the client's/investor's/internal technical teams all
> on the same page as there has been much bickering.

That sounds like there is an opportunity to force either
camp to respond to some questions that do not allow much
bickering. The answers should influence the language choice
(if any). As a bonus, answers based on facts should help
everyone saving face.

The starting point is whether the two options Ada vs C# will
"provide important security features", or whether they
are sold with a promise of providing important security
features. Is this enough?

The necessary follow-up question addresses whether the project
would need

- a secured system, or
- a secure system, or
- something that (how exactly, given the context?)
  provides security features?

Can members of either party claim anything of the above
at some level of expertise, and at a sufficient level of detail?
Can they name meaningful definitions of the above terms?
Can they exemplify how these things mentioned will interact,
specifically, with the choice of language?


Some subjects:

Security experts have explained that the shift from
Windows Vista to Windows 7 has meant more user satisfaction
with UAC at the price of UAC defaulting to insecure.
Does access control, in general, matter? In which ways?
Should it be part of testing applications?

(I imagine that some will answer in the style of "you just
have to change the defaults..." which seems technically
correct to some extent. Should help to put the requirements
in focus, in any case. The more often someone says the words
"your just have to...", the less the built-in security seems
to be, and the more diligence is needed.)

By which technique do the C# compiler and then the .NET
JIT compiler produce safer executables than a compiler
that produces executables directly?
This question should test actual knowledge.

Is the goal to produce applications that mainly add
MVC glue to existing .NET classes?

Catch question: Is VB.NET more or less secure than C#?
Why not VB.NET, then?

Re: Arbitrary Sandbox

[Erich]

On Feb 9, 11:47 pm, Rob Shea <zzyca...@gmail.com> wrote:
> I've been handed a project, but I'm not a programmer, much less an Ada
> programmer. The idea is a Windows test station sandbox where arbitrary
> applications can be executed, but cannot make system changes or
> transmit data.

From your requirements I'd say you should care more about the host
operating system than the language. Try NetBSD or a hardened Linux
variant as a host OS and perhaps some virtualization technology on top
of that. Notice that you can use Wine on a Linux system to run most
Windows programs. Even then it will be hard to make this really
secure. You might want to consider some way to automatically reinstall
the complete system on each reboot from a read-only device. There is
already plenty of software for that, because it's used in every public
computer lab and kiosk mode application.

Or do you want to write your own software PC emulator (without
virtualization)? That would be secure and Ada could be appropriate for
it (certainly more than C#) although most existing emulators are
written in C/C++. In any case expect a lot of work.

Third, if it's about running programs written in a particular perhaps
domain-specific language at an acceptable speed, then you could
implement this in a possibly JIT-compiled language that already allows
for secure sandboxing. For example, implementations of Java,
Javascript, and Racket have such modes. However, in that case the
security of the overall solution depends on the security of the 3rd-
party application, of course, and these implementations are written in
C/C++ and likely contain exploitable bugs.

In all three cases I'm afraid I'd have to agree with the other poster
that it seems you're trying to reinvent the wheel.

Re: Arbitrary Sandbox

[Ludovic Brenta]

Rob Shea wrote on comp.lang.ada:
> I've been handed a project, but I'm not a programmer, much less an Ada
> programmer. The idea is a Windows test station sandbox where arbitrary
> applications can be executed, but cannot make system changes or
> transmit data.
>
> I have two primary voice on my team, one is calling for J# as the .NET
> framework will allow for "faster development and provides important
> security features" and the other is calling for Ada because "safety is
> the primary concern and it's cheaper to build it right the first
> time."

IIUC, your sandbox cannot be a .NET application, or it will not be
able to run "arbitrary code" because it will be restricted to running
only .NET bytecode inside the .NET virtual machine.  If that is
correct and if C# can only be compiled to .NET and can only run in
the .NET virtual machine, then C# is ruled out.  If you want to run
"arbitrary code", you must run outside the .NET virtual machine
(possibly running a .NET virtual machine _inside_ your sandbox).

--
Ludovic Brenta.

Re: Arbitrary Sandbox

[Rob Shea]

Is this true? I've seen it mentioned one other place but it was just
from another individual... most places imply otherwise.

As for the other posts about virtualization, unfortunately I am only
able to discuss a small portion of the project, I appreciate the
efforts to solve my problem, but at this point I am just looking to be
better intellectually armed for a big meeting about this and as I
said, I feel I'm under educated on the choices and the proponents of
each have political motives so I may be getting less than absolute
honest from my team.

If anyone is able to address my concerns about Ada on embedded systems
is awesome, but Ada on the abstraction of Windows, relying on the
APIs, etc... is this still awesome?

Thank you.

On Feb 10, 10:48 pm, Ludovic Brenta <ludo...@ludovic-brenta.org>
wrote:
>
> IIUC, your sandbox cannot be a .NET application, or it will not be
> able to run "arbitrary code" because it will be restricted to running
> only .NET bytecode inside the .NET virtual machine.  If that is
> correct and if C# can only be compiled to .NET and can only run in
> the .NET virtual machine, then C# is ruled out.  If you want to run
> "arbitrary code", you must run outside the .NET virtual machine
> (possibly running a .NET virtual machine _inside_ your sandbox).
>
> --
> Ludovic Brenta.

Re: Arbitrary Sandbox

[Randy Brukardt]

"Rob Shea" <zzycatch@gmail.com> wrote in message 
news:4da4bf75-e6c9-4c17-9072-ab6f533ed93f@vd8g2000pbc.googlegroups.com...
...
>If anyone is able to address my concerns about Ada on embedded systems
>is awesome, but Ada on the abstraction of Windows, relying on the
>APIs, etc... is this still awesome?

Of course. Ada is awesome everywhere! :-)

I may be biased of course, but we've developed a number of programs using 
Claw (along with Claw itself), which are solely targeted to Windows. The 
"good things" about Ada don't depend on the target platform. If there is an 
issue (and it exists on any target) is that there sometimes is a need to 
write interfaces to other code (APIs sometimes, but also ROMs and hardware 
as well). Taking the time to do this right is almost always a win - but it 
does take some time.

Please note that I don't have any experience with .NET beyond the 
occassional annoying message that it needs to be patched. :-) So I don't 
know much about running in that environment (it's hard for me to imagine 
precisely why such an environment would be an improvement over a properly 
designed compiler / runtime environment -- the only problem being that both 
Windows and Unix-based systems do not have a properly designed (native) 
runtime environment -- stuff we did to make Janus/Ada more secure on DOS 
extenders in the 1980s never made it to OS environments).

                                               Randy.

Re: Arbitrary Sandbox

[björn lundin]

On 12 Feb, 03:10, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Rob Shea" <zzyca...@gmail.com> wrote in message
>
> news:4da4bf75-e6c9-4c17-9072-ab6f533ed93f@vd8g2000pbc.googlegroups.com...
> ...
>
> >If anyone is able to address my concerns about Ada on embedded systems
> >is awesome, but Ada on the abstraction of Windows, relying on the
> >APIs, etc... is this still awesome?

I work on a system were the servercode is in ada
And the clients are c#.
We do have More problems with the clients.
This is a warehouse control system. We also have
A warehouse management system with ada in server
And something completely different as clients.
But the ada part handles orders, inventory,
Talks to erp systems like sap, jde, axapta
Very well. Most of our customers are impressed
How often we get most thing right the first
Time.

Ada is not just for embedded.
It has its place where you want to model
The real world in software correctly - fast
--
Björn

Re: Arbitrary Sandbox

[Shark8]

On Feb 11, 8:10 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>
> Windows and Unix-based systems do not have a properly designed (native)
> runtime environment -- stuff we did to make Janus/Ada more secure on DOS
> extenders in the 1980s never made it to OS environments).

Could you elaborate on that? (Both what's needed to make such an
environment and what was done on Janus/Ada.)

Re: Arbitrary Sandbox

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:203d63cf-42a9-49ef-82cd-943d77b5e438@c21g2000yqi.googlegroups.com...
On Feb 11, 8:10 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>>
>> Windows and Unix-based systems do not have a properly designed (native)
>> runtime environment -- stuff we did to make Janus/Ada more secure on DOS
>> extenders in the 1980s never made it to OS environments).
>
>Could you elaborate on that? (Both what's needed to make such an
>environment and what was done on Janus/Ada.)

The vast majority of programs do not have self-modifying code, and it 
shouldn't be possible for them to run such code in any way. If that's the 
case, most code-injection attacks cannot happen.

We used the native segmentation of the Intel hardware to completely separate 
code and data in Janus/Ada programs. It was impossible to accidentally 
execute data simply because the data wasn't even in the same address space.

Of course, some programs do need self-modifying code, and an OS would have 
provided an API for that purpose. But it should have been rarely used.

Now, I recognize that DEP was added to Intel hardware to provide some of 
this protection, but the problem is that a lot of programs can't use it 
because of the basic architectual mistake (including GNAT programs until 
recently, which is why I had to leave it off on my computer - boo). Plus 
requiring a new feature to get this protection is annoying as it was always 
available in Intel hardware (back to 80286); people just had to use it and 
they didn't. (I think that was a consequence of Windows NT copying the bad 
Unix memory model more than an intentional decision - and of course the 
security issues hadn't popped up so much then). [Aside: Intel has 
de-emphasized segments in modern hardware to the point that you probably 
couldn't do this today, as you would pay a nasty performance price. Boo 
again (understandable, though).]

                                                Randy.

Re: Arbitrary Sandbox

[Yannick Duchêne (Hibou57)]

Le Wed, 15 Feb 2012 22:07:37 +0100, Randy Brukardt <randy@rrsoftware.com>  
a écrit:
> Now, I recognize that DEP was added to Intel hardware to provide some of
> this protection, but the problem is that a lot of programs can't use it
> because of the basic architectual mistake (including GNAT programs until
> recently, which is why I had to leave it off on my computer - boo). Plus
> requiring a new feature to get this protection is annoying as it was  
> always available in Intel hardware (back to 80286); people just had to  
> use it and they didn't. (I think that was a consequence of Windows NT  
> copying the bad Unix memory model more than an intentional decision
I use to wonder if there a so much clever reason so that I could not  
understand it. But you are competent enough, and feel the same too about  
the flat memory model. So you confirm something was sadly wasted here (and  
yes, since the very old 80286).

Well, beyond segment protection, there is page protection (since 80486 (*)  
). May be this one was precisely added by Intel to afford something to the  
flat memory model to which segment by segment attributes was not  
accessible. Otherwise, I don't see why, as this is probably cleaner to  
apply the same attributes to a whole segment.

(*) And something else again added again later, with a Pentium generation,  
but I can't recall the details.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Arbitrary Sandbox

[Shark8]

On Feb 15, 3:07 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Shark8" <onewingedsh...@gmail.com> wrote in message
>
> news:203d63cf-42a9-49ef-82cd-943d77b5e438@c21g2000yqi.googlegroups.com...
> On Feb 11, 8:10 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>
>
>
> >> Windows and Unix-based systems do not have a properly designed (native)
> >> runtime environment -- stuff we did to make Janus/Ada more secure on DOS
> >> extenders in the 1980s never made it to OS environments).
>
> >Could you elaborate on that? (Both what's needed to make such an
> >environment and what was done on Janus/Ada.)
>
> The vast majority of programs do not have self-modifying code, and it
> shouldn't be possible for them to run such code in any way. If that's the
> case, most code-injection attacks cannot happen.
>
> We used the native segmentation of the Intel hardware to completely separate
> code and data in Janus/Ada programs. It was impossible to accidentally
> execute data simply because the data wasn't even in the same address space.
>
> Of course, some programs do need self-modifying code, and an OS would have
> provided an API for that purpose. But it should have been rarely used.
>
> Now, I recognize that DEP was added to Intel hardware to provide some of
> this protection, but the problem is that a lot of programs can't use it
> because of the basic architectual mistake (including GNAT programs until
> recently, which is why I had to leave it off on my computer - boo). Plus
> requiring a new feature to get this protection is annoying as it was always
> available in Intel hardware (back to 80286); people just had to use it and
> they didn't. (I think that was a consequence of Windows NT copying the bad
> Unix memory model more than an intentional decision - and of course the
> security issues hadn't popped up so much then). [Aside: Intel has
> de-emphasized segments in modern hardware to the point that you probably
> couldn't do this today, as you would pay a nasty performance price. Boo
> again (understandable, though).]
>
>                                                 Randy.

You know; I always wondered why they (developers, and OS designers)
didn't take advantage of segments. It seems to be a very nice way to
enforce security. (As you said, going all the way to the 286.)

I realize that the flat memory model is simpler, in concept, and
likely the programming community wanted to be able to "just take the
integer value of the location"... and likely was a "cheap-and-dirty"
way of handling inter-process communication. But isn't such a layout/
usage is almost asking for abuse (as you can then just fiddle around
in memory), and asking for both uncontrolled memory usage (leaks) and
unauthorized access (like you mentioned about self-modifying code)?

Though, that does bring to mind a design question: what is/are the
best way(s) to handle inter-process communication in a general-purpose
OS?

Re: Arbitrary Sandbox

[Dmitry A. Kazakov]

On Fri, 17 Feb 2012 20:47:36 -0800 (PST), Shark8 wrote:

> You know; I always wondered why they (developers, and OS designers)
> didn't take advantage of segments.

Ineffective, complicated, generally useless?

> I realize that the flat memory model is simpler, in concept, and
> likely the programming community wanted to be able to "just take the
> integer value of the location"... and likely was a "cheap-and-dirty"
> way of handling inter-process communication. But isn't such a layout/
> usage is almost asking for abuse (as you can then just fiddle around
> in memory), and asking for both uncontrolled memory usage (leaks) and
> unauthorized access (like you mentioned about self-modifying code)?

Flat /= von Neumann's. If the question is whether the memory access rights
should be reflected in the structure of the address, then, most likely, the
answer is no.

> Though, that does bring to mind a design question: what is/are the
> best way(s) to handle inter-process communication in a general-purpose
> OS?

That depends on the requirements imposed on such a communication and the
machine architecture, if you have shared memory in mind.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Arbitrary Sandbox

[Yannick Duchêne (Hibou57)]

Le Sat, 18 Feb 2012 09:26:42 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Fri, 17 Feb 2012 20:47:36 -0800 (PST), Shark8 wrote:
>
>> You know; I always wondered why they (developers, and OS designers)
>> didn't take advantage of segments.
>
> Ineffective, complicated, generally useless?
Why?

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Arbitrary Sandbox

[Dmitry A. Kazakov]

On Sat, 18 Feb 2012 11:45:58 +0100, Yannick Duch�ne (Hibou57) wrote:

> Le Sat, 18 Feb 2012 09:26:42 +0100, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
> 
>> On Fri, 17 Feb 2012 20:47:36 -0800 (PST), Shark8 wrote:
>>
>>> You know; I always wondered why they (developers, and OS designers)
>>> didn't take advantage of segments.
>>
>> Ineffective, complicated, generally useless?
> Why?

Presumably because of lack of address order. Comparing driver developing
for PDP-11/RSX-11 vs. 80286/Windows/DOS. The former was immensely simpler,
safer and also more effective (you could pass a buffer from the process
space to the driver). The latter was a pure horror.

I wonder what kind of architecture could require a safe implementation of
Ada, e.g. when private parts of packages and protected objects would be
mapped onto the memory physically inaccessible from public contexts.

Or, considering an implementation of an object-based OS without any I/O
when everything is just memory mapped. Maybe some sort of segments on top
of pages could be used for that...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Arbitrary Sandbox

[Niklas Holsti]

On 12-02-18 13:31 , Dmitry A. Kazakov wrote:
> On Sat, 18 Feb 2012 11:45:58 +0100, Yannick Duch�ne (Hibou57) wrote:
>
>> Le Sat, 18 Feb 2012 09:26:42 +0100, Dmitry A. Kazakov
>> <mailbox@dmitry-kazakov.de>  a �crit:
>>
>>> On Fri, 17 Feb 2012 20:47:36 -0800 (PST), Shark8 wrote:
>>>
>>>> You know; I always wondered why they (developers, and OS designers)
>>>> didn't take advantage of segments.
>>>
>>> Ineffective, complicated, generally useless?
>> Why?
>
> Presumably because of lack of address order. Comparing driver developing
> for PDP-11/RSX-11 vs. 80286/Windows/DOS. The former was immensely simpler,
> safer and also more effective (you could pass a buffer from the process
> space to the driver). The latter was a pure horror.
>
> I wonder what kind of architecture could require a safe implementation of
> Ada, e.g. when private parts of packages and protected objects would be
> mapped onto the memory physically inaccessible from public contexts.
>
> Or, considering an implementation of an object-based OS without any I/O
> when everything is just memory mapped. Maybe some sort of segments on top
> of pages could be used for that...

The Nokia Data MPS 10 minicomputer (1983) was something like that. See:

Pekka Lahtinen. 1982. A machine architecture for Ada. Ada Lett. II, 2 
(September 1982), 28-33. DOI=10.1145/989798.989799 
http://doi.acm.org/10.1145/989798.989799

 From that description, its seems that each static (= library-level) 
package had its own data segment, which contained both the public and 
private data of that package. So hardware was not used to check or 
enforce Ada visibility rules, at least not for the package level, but I 
suppose it could have been done by simply making two different segments 
for the package. Perhaps a change in the Ada compiler would have been 
enough.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Arbitrary Sandbox

[Yannick Duchêne (Hibou57)]

Le Sat, 18 Feb 2012 12:31:42 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>>>> You know; I always wondered why they (developers, and OS designers)
>>>> didn't take advantage of segments.
>>>
>>> Ineffective, complicated, generally useless?
>> Why?
>
> Presumably because of lack of address order. Comparing driver developing
> for PDP-11/RSX-11 vs. 80286/Windows/DOS. The former was immensely  
> simpler,
> safer and also more effective (you could pass a buffer from the process
> space to the driver). The latter was a pure horror.

Segments can share physical addresses (since the i286), and there is  
memory mapped IO ports (at least since the i386).

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Arbitrary Sandbox

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> I wonder what kind of architecture could require a safe implementation of
> Ada, e.g. when private parts of packages and protected objects would be
> mapped onto the memory physically inaccessible from public contexts.

The kind of architecture that is overly complicated
and grossly inefficient.  Imagine a private type with
discriminants.  The discriminant of each object is visible
to clients; other components are not.  Or imagine a private
extension of a (visible) record extension.  What about the
fact that some portion (not all) of a child package has
visibility on the private part (but not the body) of the
parent package?

Why do work at run time that can be done at compile time?
Implementing things in hardware doesn't magically make
them free.

Putting high-level support for higher-level languages in hardware
has been tried a number of times, and it's always been a bad idea.

- Bob

Re: Arbitrary Sandbox

[Niklas Holsti]

On 12-02-18 20:55 , Robert A Duff wrote:
> "Dmitry A. Kazakov"<mailbox@dmitry-kazakov.de>  writes:
>
>> I wonder what kind of architecture could require a safe implementation of
>> Ada, e.g. when private parts of packages and protected objects would be
>> mapped onto the memory physically inaccessible from public contexts.

  ...

> Why do work at run time that can be done at compile time?
> Implementing things in hardware doesn't magically make
> them free.
>
> Putting high-level support for higher-level languages in hardware
> has been tried a number of times, and it's always been a bad idea.

For some critical systems, having checks at more than one level is good.

I seem to remember that the Burroughs mainframe computers had rather 
poor hardware-level protections. A buggy or malicious compiler could 
generate code that had harmful effects that were not restricted to the 
user running the code, if I remember correctly. A consequence was that 
an ordinary user was not allowed to create a compiler; special 
privileges were required to label a program as a "compiler" and thus let 
it generate executable code.

I agree with Bob that high-level things like visibility do not benefit 
from hardware support. But I wish hardware could detect erroneous 
executions of Ada programs.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Arbitrary Sandbox

[tmoran]

> I seem to remember that the Burroughs mainframe computers had rather
> poor hardware-level protections. A buggy or malicious compiler could
> generate code that had harmful effects that were not restricted to the
> user running the code, if I remember correctly. A consequence was that
> an ordinary user was not allowed to create a compiler; special
> privileges were required to label a program as a "compiler" and thus let
> it generate executable code.

  The Burroughs philosophy was to design hardware and software together,
which included doing different kinds of checks in different, appropriate,
places.  Bad code could be prevented by a correct compiler, so an
arbitrary generator of bit streams couldn't call its output "executable
code".  Indexing out of range couldn't be prevented by a compiler, so it
was checked at run time by hardware.  And so forth.
  In five years supporting a B5500 at U of Wisconsin, I never saw a core
dump caused by a compiler generating bad code.  (Unfortunately, Burroughs
added to their Algol "stream procedures" which were unchecked string
operations - those were the source of most problems.)

Re: Arbitrary Sandbox

[Niklas Holsti]

On 12-02-18 22:06 , tmoran@acm.org wrote:
>> I seem to remember that the Burroughs mainframe computers had rather
>> poor hardware-level protections. A buggy or malicious compiler could
>> generate code that had harmful effects that were not restricted to the
>> user running the code, if I remember correctly. A consequence was that
>> an ordinary user was not allowed to create a compiler; special
>> privileges were required to label a program as a "compiler" and thus let
>> it generate executable code.
>
>    The Burroughs philosophy was to design hardware and software together,
> which included doing different kinds of checks in different, appropriate,
> places.

Right. I did not mean to be critical of Burroughs; it is one example of 
dividing checks between SW and HW. Current systems have a different 
division, which is better in some respects -- illegal code has limited 
effects, so anyone can develop and experiment with compilers -- but 
worse in other respects, such as less checks on pointer arithmetic.

> Bad code could be prevented by a correct compiler, so an
> arbitrary generator of bit streams couldn't call its output "executable
> code".  Indexing out of range couldn't be prevented by a compiler, so it
> was checked at run time by hardware.  And so forth.

Yes. The ideal is that all illegalities are detected at some level. But 
today, in Ada and other languages, we have cases of erroneous execution, 
undefined behaviour, and so on, that are not detected at all, and simply 
lead to wrong results or weird crashes. I wish that hardware could 
detect more of them.

> In five years supporting a B5500 at U of Wisconsin, I never saw a core
> dump caused by a compiler generating bad code.  (Unfortunately, Burroughs
> added to their Algol "stream procedures" which were unchecked string
> operations - those were the source of most problems.)

No disagreement from me. I liked the Burroughs systems at the U of 
Helsinki, and I don't remember hearing of any problems. (I was an 
ordinary and minor user, not a sysadmin.)

But perhaps there would have been more problems if I and other students 
in the compiler-implementation course had been allowed to run our 
experimental compilers as real compilers, not just as MIXAL generators :-)

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Arbitrary Sandbox

[Robert A Duff]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> Right. I did not mean to be critical of Burroughs; it is one example of
> dividing checks between SW and HW.

I've never used a Burroughs machine, but it seems to me that a design
that requires compilers to run in a privileged mode is just wrong.
A goal is to avoid having too much code in privileged mode, and
compilers are complicated beasts.

I talked to some folks who wrote a compiler (I don't remember which
language, might have been Ada) for one of those machines, and they said
it was a nightmare, because when there's a bug, instead of the compiler
crashing, or the compiler-generated program crashing, the entire system
would crash.  This was a multi-user system, so one minor mistake by one
member of the compiler team disrupts the work of the whole team.

> Yes. The ideal is that all illegalities are detected at some level. But
> today, in Ada and other languages, we have cases of erroneous execution,
> undefined behaviour, and so on, that are not detected at all, and simply
> lead to wrong results or weird crashes. I wish that hardware could
> detect more of them.

I wish software would detect more of them.  ;-)

- Bob

Re: Arbitrary Sandbox

[tmoran]

> I've never used a Burroughs machine, but it seems to me that a design
> that requires compilers to run in a privileged mode is just wrong.
> A goal is to avoid having too much code in privileged mode, and
> compilers are complicated beasts.

  There was no "privileged mode" or "user mode".  Files on disk had
various security privileges, and one possibility was "this is a code
file" while another possibility was "this is a compiler and it's
allowed to create a file with 'code file' security".

> I talked to some folks who wrote a compiler (I don't remember which
> language, might have been Ada) for one of those machines, and they said
> it was a nightmare, because when there's a bug, instead of the compiler
> crashing, or the compiler-generated program crashing, the entire system
> would crash.  This was a multi-user system, so one minor mistake by one
> member of the compiler team disrupts the work of the whole team.

  The B5500 came out in the early sixties.  It was one of the first
designed for multiprogramming and time sharing.  It still was capable of
"batch" operation, in which crashing the machine meant crashing your job,
which was the only one on the machine.  When we tested new OS changes at
UW, we did it at night, after all the batch jobs were done and the
time-sharing users were gone.  If an OS change caused a crash, we
rebooted.  I imagine the Burroughs compiler writers lived under the
same situation, except that they could work in the daytime on their
own "development" machine.  I suspect that's the way compiler writers
work today, each with his own (rebootable) development machine

  Most OS changes did not causes crashes, just undesirable behavior.
Most compiler bugs don't cause machine crashes, just program errors.
Since the B5500 had segments with descriptors and hardware checked
indexing, a bad program would more likely generate a fault ("exception")
than crash the whole system.

  BTW, the only real problem we had with bad user programs was one grad
student who had heard about "virtual memory" and wrote his program to use
large arrays.  Unfortunately he accessed them column-wise, while they were
stored row-wise, so his program swapped horribly.  In 1970 it would have
taken a very smart compiler indeed to prevent that problem.

  We've spent the last half-century making computers faster, with modest,
or sometimes negative, progress on preventing or catching software bugs,
so the number of executed bugs/second must be orders of magnitude larger.

Re: Arbitrary Sandbox

[Robert A Duff]

tmoran@acm.org writes:

>> I've never used a Burroughs machine, but it seems to me that a design
>> that requires compilers to run in a privileged mode is just wrong.
>> A goal is to avoid having too much code in privileged mode, and
>> compilers are complicated beasts.
>
>   There was no "privileged mode" or "user mode".  Files on disk had
> various security privileges, and one possibility was "this is a code
> file" while another possibility was "this is a compiler and it's
> allowed to create a file with 'code file' security".

OK, thanks for the clarification -- as I said, I never used one of
those machines.  But I think it amounts to more-or-less the same thing
-- a design that requires compilers to have special privileges
is a bad idea, whether you call that a "mode" or a "per-file privilege
attribute" or whatever.

>...  I imagine the Burroughs compiler writers lived under the
> same situation, except that they could work in the daytime on their
> own "development" machine.

The ones I was talking about _shared_ a machine.  So rebooting it
disrupted the entire project, not just one programmer.

>...I suspect that's the way compiler writers
> work today, each with his own (rebootable) development machine

I'm a compiler writer, and yes, I have my own rebootable development
machine.  But compiler bugs don't require rebooting.  Operating system
kernel bugs do, but that's inevitable, and it's a good reason to
keep the kernel small.

>   Most OS changes did not causes crashes, just undesirable behavior.
> Most compiler bugs don't cause machine crashes, just program errors.
> Since the B5500 had segments with descriptors and hardware checked
> indexing, a bad program would more likely generate a fault ("exception")
> than crash the whole system.

OK.

>   BTW, the only real problem we had with bad user programs was one grad
> student who had heard about "virtual memory" and wrote his program to use
> large arrays.  Unfortunately he accessed them column-wise, while they were
> stored row-wise, so his program swapped horribly.  In 1970 it would have
> taken a very smart compiler indeed to prevent that problem.

That problem still exists.  I've seen cases recently, on both windows
and linux, where a rogue program swapped horribly, and put the system
in a state where it won't listen to the keyboard or mouse, so I can't
kill the program.  It seems to me it's possible to design an OS that
wouldn't do that.

>   We've spent the last half-century making computers faster, with modest,
> or sometimes negative, progress on preventing or catching software bugs,
> so the number of executed bugs/second must be orders of magnitude larger.

Certainly true.  There are also a lot more car wrecks nowadays than
there were 100 years ago.  ;-)

- Bob

Re: Arbitrary Sandbox

[tmoran]

> -- a design that requires compilers to have special privileges
> is a bad idea, whether you call that a "mode" or a "per-file privilege
> attribute" or whatever.

  Catching/preventing bugs earlier rather than later is a good idea.  If
the regular compiler doesn't generate I/O instructions or bad instruction
sequences, then the hardware doesn't need a "user" mode to detect those at
run-time.  You've pushed back the detection so it's done essentially at
the time you give a particular programmer the security status of being
able to use the fancy, I/O Op generating, systems programmer compiler.
Modern computers are designed to run as executable code any sequence of
bits that anyone, including fools and knaves, gives them.  That means you
have to delay protection till run time, with things like user/kernel mode.

> >...  I imagine the Burroughs compiler writers lived under the
> > same situation, except that they could work in the daytime on their
> > own "development" machine.
> The ones I was talking about _shared_ a machine.  So rebooting it
> disrupted the entire project, not just one programmer.

  I think we're talking different eras of computing here.  In the mid '60s
very few people had their own development machines - they were million
dollar mainframes (with only a few hundred kilobytes of core) and were
shared.  At that time very few machines ran multiprogramming - they were
in effect rebooted between each batch job.  Things like memory protection
(eg, Burroughs' "descriptor") were new and rare so there was no
alternative to rebooting when a program crashed hard.  OTOH, a reboot took
seconds, not minutes.

Re: Arbitrary Sandbox

[tmoran]

> >   We've spent the last half-century making computers faster, with modest,
> > or sometimes negative, progress on preventing or catching software bugs,
> > so the number of executed bugs/second must be orders of magnitude larger.
>
> Certainly true.  There are also a lot more car wrecks nowadays than
> there were 100 years ago.  ;-)

The fatalities/vehicle mile have decreased by roughly one order of
magnitude.  Have the number of bugs/line of code done a lot better?

Re: Arbitrary Sandbox

[Robert A Duff]

tmoran@acm.org writes:

>> >   We've spent the last half-century making computers faster, with modest,
>> > or sometimes negative, progress on preventing or catching software bugs,
>> > so the number of executed bugs/second must be orders of magnitude larger.
>>
>> Certainly true.  There are also a lot more car wrecks nowadays than
>> there were 100 years ago.  ;-)
>
> The fatalities/vehicle mile have decreased by roughly one order of
> magnitude.

I can believe it.  I know driving has gotten safer in the U.S.
since I learned to drive (more recently than 100 years ago).

Sorry, I didn't mean for my silly joke to cause an off-topic discussion
about cars.

>...Have the number of bugs/line of code done a lot better?

Probably not.  But note that the move almost entirely away
from assembly language reduced the number of lines of code
needed for a given functionality.  So we had to increase the
amount of useless functionality to make up for that.  ;-)

- Bob

Re: Arbitrary Sandbox

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccr4xpnkh6.fsf@shell01.TheWorld.com...
> tmoran@acm.org writes:
...
>>   BTW, the only real problem we had with bad user programs was one grad
>> student who had heard about "virtual memory" and wrote his program to use
>> large arrays.  Unfortunately he accessed them column-wise, while they 
>> were
>> stored row-wise, so his program swapped horribly.  In 1970 it would have
>> taken a very smart compiler indeed to prevent that problem.
>
> That problem still exists.  I've seen cases recently, on both windows
> and linux, where a rogue program swapped horribly, and put the system
> in a state where it won't listen to the keyboard or mouse, so I can't
> kill the program.  It seems to me it's possible to design an OS that
> wouldn't do that.

Indeed, until I got rid of them, there used to be a bunch of ACATS tests 
that *tried* to exhaust memory, and thus often had that effect. I remember 
that we had to put an artificial memory limit into our early Windows NT 
compilers to keep those tests from crashing our solitary Windows NT machine 
(which also doubled as our domain controller, so that was not good.).

One of the first things I did when I took over the ACATS was to get approval 
to remove those tests from the test suite. (I think I actually ended up 
allocating a large data structure, but bounded the size to 32MB, rather than 
just running until Storage_Error was raised.)

                                  Randy.

Re: Arbitrary Sandbox

[Adam Beneschan]

On Feb 18, 12:06 pm, tmo...@acm.org wrote:

>   The Burroughs philosophy was to design hardware and software together,
> which included doing different kinds of checks in different, appropriate,
> places.  Bad code could be prevented by a correct compiler, so an
> arbitrary generator of bit streams couldn't call its output "executable
> code".  Indexing out of range couldn't be prevented by a compiler, so it
> was checked at run time by hardware.  And so forth.
>   In five years supporting a B5500 at U of Wisconsin, I never saw a core
> dump caused by a compiler generating bad code.

You were lucky.  I seem to remember plenty of them when I worked as a
COBOL programmer on a 3500.

                        -- Adam

Re: Arbitrary Sandbox

[BrianG]

On 02/18/2012 02:24 PM, Niklas Holsti wrote:
> But I wish hardware could detect erroneous executions of Ada programs.
>
That depends on what meaning you give to "erroneous execution".
Use the LRM definition, that would probably be impossible - unless you 
had LRM hardware.
Use the 'common' meaning (which I think you mean), it might be more 
possible (but not likely to happen).

-- 
---
BrianG
000
@[Google's email domain]
.com

Re: Arbitrary Sandbox

[Dmitry A. Kazakov]

On Sat, 18 Feb 2012 13:55:48 -0500, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> I wonder what kind of architecture could require a safe implementation of
>> Ada, e.g. when private parts of packages and protected objects would be
>> mapped onto the memory physically inaccessible from public contexts.
> 
> The kind of architecture that is overly complicated
> and grossly inefficient.  Imagine a private type with
> discriminants.  The discriminant of each object is visible
> to clients; other components are not.  Or imagine a private
> extension of a (visible) record extension.  What about the
> fact that some portion (not all) of a child package has
> visibility on the private part (but not the body) of the
> parent package?
> 
> Why do work at run time that can be done at compile time?

Because it cannot (in presence of Unchecked_Conversion and similar stuff). 

> Implementing things in hardware doesn't magically make
> them free.

It makes them incomputable. In a secure environment you wanted certain 
things to become incomputable for non-trusted clients, e.g. reading user 
passwords.

> Putting high-level support for higher-level languages in hardware
> has been tried a number of times, and it's always been a bad idea.

Maybe so. But this is a different case, because memory protection and 
segmentation support is already there. Why no high-level language uses it?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Arbitrary Sandbox

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sat, 18 Feb 2012 13:55:48 -0500, Robert A Duff wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> I wonder what kind of architecture could require a safe implementation of
>>> Ada, e.g. when private parts of packages and protected objects would be
>>> mapped onto the memory physically inaccessible from public contexts.
>> 
>> The kind of architecture that is overly complicated
>> and grossly inefficient.  Imagine a private type with
>> discriminants.  The discriminant of each object is visible
>> to clients; other components are not.  Or imagine a private
>> extension of a (visible) record extension.  What about the
>> fact that some portion (not all) of a child package has
>> visibility on the private part (but not the body) of the
>> parent package?
>> 
>> Why do work at run time that can be done at compile time?
>
> Because it cannot (in presence of Unchecked_Conversion and similar stuff). 

If U_C etc. causes trouble, use Java.  Or use a subset of Ada that
doesn't allow such features.  I really can't imagine a sensible way to
use such features and check them at run time.

It would be good to have an easy way to check whether a given
Ada program uses such dangerous features, and if so, where.

>> Implementing things in hardware doesn't magically make
>> them free.
>
> It makes them incomputable. In a secure environment you wanted certain 
> things to become incomputable for non-trusted clients, e.g. reading user 
> passwords.

Sure, but Ada's visibility features (private types and the like)
are not designed for security.  Use other means for that (like
protection based on paging).

>> Putting high-level support for higher-level languages in hardware
>> has been tried a number of times, and it's always been a bad idea.
>
> Maybe so. But this is a different case, because memory protection and 
> segmentation support is already there. Why no high-level language uses it?

You mean "already there" in 386/pentium?  Languages don't use it because
it's inefficient, and because whatever segmentation can do can be done
better by some combination of software and paging.

- Bob

Re: Arbitrary Sandbox

[Dmitry A. Kazakov]

On Mon, 20 Feb 2012 18:27:10 -0500, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sat, 18 Feb 2012 13:55:48 -0500, Robert A Duff wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> 
>>>> I wonder what kind of architecture could require a safe implementation of
>>>> Ada, e.g. when private parts of packages and protected objects would be
>>>> mapped onto the memory physically inaccessible from public contexts.
>>> 
>>> The kind of architecture that is overly complicated
>>> and grossly inefficient.  Imagine a private type with
>>> discriminants.  The discriminant of each object is visible
>>> to clients; other components are not.  Or imagine a private
>>> extension of a (visible) record extension.  What about the
>>> fact that some portion (not all) of a child package has
>>> visibility on the private part (but not the body) of the
>>> parent package?
>>> 
>>> Why do work at run time that can be done at compile time?
>>
>> Because it cannot (in presence of Unchecked_Conversion and similar stuff). 
> 
> If U_C etc. causes trouble, use Java.  Or use a subset of Ada that
> doesn't allow such features.  I really can't imagine a sensible way to
> use such features and check them at run time.

Of course there is. Do you remember the last time U_C crashed Windows or
Linux?

>>> Implementing things in hardware doesn't magically make
>>> them free.
>>
>> It makes them incomputable. In a secure environment you wanted certain 
>> things to become incomputable for non-trusted clients, e.g. reading user 
>> passwords.
> 
> Sure, but Ada's visibility features (private types and the like)
> are not designed for security.

Yes, but they could be a good start. (If there were any interest. No need
to tell that there is none)

> Use other means for that (like protection based on paging).

That is low-level and inherently based on pointers.

>>> Putting high-level support for higher-level languages in hardware
>>> has been tried a number of times, and it's always been a bad idea.
>>
>> Maybe so. But this is a different case, because memory protection and 
>> segmentation support is already there. Why no high-level language uses it?
> 
> You mean "already there" in 386/pentium?  Languages don't use it because
> it's inefficient, and because whatever segmentation can do can be done
> better by some combination of software and paging.

That was my point. There is a disconnect in the designs of the hardware and
higher level languages. You said it must be so. I disagree. There is no
other reason for that than the dark ages we are living at. Nobody invests
anything in serious language, OS, hardware design.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Arbitrary Sandbox

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Mon, 20 Feb 2012 18:27:10 -0500, Robert A Duff wrote:

>> If U_C etc. causes trouble, use Java.  Or use a subset of Ada that
>> doesn't allow such features.  I really can't imagine a sensible way
>> to use such features and check them at run time.
>
> Of course there is. Do you remember the last time U_C crashed Windows
> or Linux?

An application can easily trash my data without crashing the OS.

Re: Arbitrary Sandbox

[Dmitry A. Kazakov]

On Tue, 21 Feb 2012 09:59:19 +0000, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Mon, 20 Feb 2012 18:27:10 -0500, Robert A Duff wrote:
> 
>>> If U_C etc. causes trouble, use Java.  Or use a subset of Ada that
>>> doesn't allow such features.  I really can't imagine a sensible way
>>> to use such features and check them at run time.
>>
>> Of course there is. Do you remember the last time U_C crashed Windows
>> or Linux?
> 
> An application can easily trash my data without crashing the OS.

Is this a reason why it should better crash the OS as well?

Anyway, Ada (and all other languages) have a null-safety model of software
decomposition. It is frequently repeated that you can always shoot yourself
in the foot in Ada. So anticipating this argument: shooting yourself is not
same as being shot by someone else. We are increasingly using components
while there is no way to secure them keeping the interfaces at high level.
At present level of complexity and growing, the software is too fragile.
The effects of bugs and faults are unbounded. Static checks and enforced
insulation are means to address this unimportant problem...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Arbitrary Sandbox

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Of course there is. Do you remember the last time U_C crashed Windows or
> Linux?

No.

But I've lost track of whether we're talking about security
or bug prevention/detection.

> That was my point. There is a disconnect in the designs of the hardware and
> higher level languages. You said it must be so. I disagree. There is no
> other reason for that than the dark ages we are living at. Nobody invests
> anything in serious language, OS, hardware design.

I agree with "dark ages" with respect to languages and OS,
but not hardware.  x86 is a mess, but it's popularity is
an accident of history.  People know how to design pretty-good
hardware architectures -- several exist.

- Bob

Re: Arbitrary Sandbox

[Dmitry A. Kazakov]

On Tue, 21 Feb 2012 12:25:09 -0500, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Of course there is. Do you remember the last time U_C crashed Windows or
>> Linux?
> 
> No.
> 
> But I've lost track of whether we're talking about security
> or bug prevention/detection.

The former and the latter when it comes to bounding the effects of
execution of buggy code.

Consider design of a container library in Ada, which cannot broken whatever
the client does. I think it is possible to achieve with the corresponding
modifications of the language and appropriate hardware support. Consider
all software designed in such manner... (Yes, nobody of us will ever see
this)

> x86 is a mess, but it's popularity is
> an accident of history.

I don't believe in accidents, negative selection is a real thing at work.
Otherwise, there would be no dark ages.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Arbitrary Sandbox

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Consider design of a container library in Ada, which cannot broken whatever
> the client does. I think it is possible to achieve with the corresponding
> modifications of the language and appropriate hardware support.

We have appropriate hardware support.  You can isolate that container in
its own process, and allow communication with it via (say) the
Distributed Systems Annex.  In the (unlikely) absence of compiler bugs,
OS bugs, hardware bugs, and bugs in the container itself, you can
ensure that client bugs (or malicious clients) don't break your
container.

That's inefficient, which was part of my claim:  If you allow things
like U_C of pointers, and rely on hardware to prevent problems,
that hardware (and related software support) is going to be
inefficient.

Or you can go the pure-Java route (no JNI).  Then in the absence
of compiler (etc.) bugs, you can ensure that client bugs won't
break your container.  But that's not a complete solution, because
you can't write (for example) the garbage collector in Java -- you
*need* to do unsafe things in a GC.  And implementing the GC in
hardware won't magically make it bug-free, nor efficient.

- Bob

Re: Arbitrary Sandbox

[Dmitry A. Kazakov]

On Tue, 21 Feb 2012 16:19:02 -0500, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Consider design of a container library in Ada, which cannot broken whatever
>> the client does. I think it is possible to achieve with the corresponding
>> modifications of the language and appropriate hardware support.
> 
> We have appropriate hardware support.  You can isolate that container in
> its own process, and allow communication with it via (say) the
> Distributed Systems Annex.

No. It is a mess to "communicate" with an array.

The point is to have a platform where you could protect software components
without drawing process borders around them.

> Or you can go the pure-Java route (no JNI).

I doubt it can. Virtualization is not an answer to the problem.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Arbitrary Sandbox

[Yannick Duchêne (Hibou57)]

Le Tue, 21 Feb 2012 19:53:04 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>> x86 is a mess, but it's popularity is
>> an accident of history.
>
> I don't believe in accidents, negative selection is a real thing at work.
> Otherwise, there would be no dark ages.
Depends on the expectations. I don't like a lot the Intel series, neither,  
especially since the Pentium and its big step further in monolithic and  
complex instruction set design, and would have preferred smaller pieces  
organized in network. But on the other hand, if you note multimedia and  
game, and specialized instructions for this target, was a wish from many  
ones, to these ones, Intel is just fine and is the opposite of a mess.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Arbitrary Sandbox

[Dmitry A. Kazakov]

On Tue, 21 Feb 2012 22:25:12 +0100, Yannick Duch�ne (Hibou57) wrote:

> Le Tue, 21 Feb 2012 19:53:04 +0100, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
>>> x86 is a mess, but it's popularity is
>>> an accident of history.
>>
>> I don't believe in accidents, negative selection is a real thing at work.
>> Otherwise, there would be no dark ages.
> Depends on the expectations. I don't like a lot the Intel series, neither,  
> especially since the Pentium and its big step further in monolithic and  
> complex instruction set design, and would have preferred smaller pieces  
> organized in network. But on the other hand, if you note multimedia and  
> game, and specialized instructions for this target, was a wish from many  
> ones, to these ones, Intel is just fine and is the opposite of a mess.

It is not RISC vs. CISC. The negative selection is at work in both
categories.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Arbitrary Sandbox

[Georg Bauhaus]

On 21.02.12 00:27, Robert A Duff wrote:
> "Dmitry A. Kazakov"<mailbox@dmitry-kazakov.de>  writes:

>>> The kind of architecture that is overly complicated
>>> and grossly inefficient.  Imagine a private type with
>>> discriminants.  The discriminant of each object is visible
>>> to clients; other components are not.  Or imagine a private
>>> extension of a (visible) record extension.  What about the
>>> fact that some portion (not all) of a child package has
>>> visibility on the private part (but not the body) of the
>>> parent package?
>>>
>>> Why do work at run time that can be done at compile time?
>>
>> Because it cannot (in presence of Unchecked_Conversion and similar stuff).
>
> If U_C etc. causes trouble, use Java.

How does using Java prevent trouble in this case?
I mean, the notion of JNI checking (if that's a close relative of
Ada's unchecked constructs) shows that Java is no better in this case,
asking programmers to be careful.

>  Or use a subset of Ada that
> doesn't allow such features.  I really can't imagine a sensible way to
> use such features and check them at run time.

Re: Arbitrary Sandbox

[Robert A Duff]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> How does using Java prevent trouble in this case?
> I mean, the notion of JNI checking (if that's a close relative of
> Ada's unchecked constructs) shows that Java is no better in this case,
> asking programmers to be careful.

Good point.  But Java-without-JNI is a possibility.

- Bob

Re: Arbitrary Sandbox

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccvcn1nl0x.fsf@shell01.TheWorld.com...
...
>> Maybe so. But this is a different case, because memory protection and
>> segmentation support is already there. Why no high-level language uses 
>> it?
>
> You mean "already there" in 386/pentium?  Languages don't use it because
> it's inefficient, and because whatever segmentation can do can be done
> better by some combination of software and paging.

The only reason it is "inefficient" was because OSes didn't use it. That is, 
it was quite efficient on an 386 (the only big expense occurs when reloading 
segment registers, and that was something that occurred very rarely in the 
two-segment model we used). Nowdays, the segment prefixes themselves have 
become very expensive, and thus it's no longer practical to use the segments 
at all. Boo.

As far as "software" and "paging" being able to do anything, this makes no 
sense at all. Pages on the x86 architecture don't (or at least didn't until 
fairly recently) have any memory permissions associated with them, so it was 
impossible to use that to prevent executing data. Moreover, Unix-derived 
file formats had no practical way to tell the OS what was not executed (and 
the little information that exists was not used in any Unix or Windows 
system that I worked on prior to XPsp3).

As a practical matter, OSes made it completely impossible for a compiler to 
do anything in this area, even if it wanted to (as we strongly did -- we 
continued to use the DOS Extender compiler for development for a decade 
simply because it detected bugs a lot earlier than NT could - executing 
stack by mistake is extremely common). So sad. And nowdays they're 
reinventing the wheel such that it still is impossible for a compiler to do 
much in this area, except a handful of very weak technologies like DEP.

                                   Randy. 

Re: Arbitrary Sandbox

[Yannick Duchêne (Hibou57)]

Le Tue, 06 Mar 2012 02:06:06 +0100, Randy Brukardt <randy@rrsoftware.com>  
a écrit:
> As far as "software" and "paging" being able to do anything, this makes  
> no
> sense at all. Pages on the x86 architecture don't (or at least didn't  
> until
> fairly recently) have any memory permissions associated with them, so it  
> was
> impossible to use that to prevent executing data. Moreover, Unix-derived
> file formats had no practical way to tell the OS what was not executed  
> (and
> the little information that exists was not used in any Unix or Windows
> system that I worked on prior to XPsp3).
What changed with SP3?

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Arbitrary Sandbox

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

>> You mean "already there" in 386/pentium?  Languages don't use it because
>> it's inefficient, and because whatever segmentation can do can be done
>> better by some combination of software and paging.
>
> The only reason it is "inefficient" was because OSes didn't use it.

And OSes didn't use it because it for the reasons I stated.  It's a
cyclic thing -- I'm sure Intel could have made it faster if there
was demand.

But there's an inherent inefficiency in segmentation: the size of
all your pointers doubles.  Or to look at it the other way around,
for any given amount of address space, it's split inconveniently.
With the amount of memory I can afford today, a 32-bit segment
number plus a 32-bit offset wouldn't be enough (both too few
segments and segment size too small).  64-bit seg num plus
64-bit offset?  OK, big enough, but inefficient.  64-bit flat
address space: perfect!  ;-)

>... That is, 
> it was quite efficient on an 386 (the only big expense occurs when reloading 
> segment registers, and that was something that occurred very rarely in the 
> two-segment model we used).

OK, I have no idea what two-segment model you used.  I was picturing
some sort of one-heap-object-per-segment model, and that sort of
thing, which some folks have advocated as a "solution" to the
problem of indexing out of bounds in languages that don't
require detection of that.

> As far as "software" and "paging" being able to do anything, this makes no 
> sense at all. Pages on the x86 architecture don't (or at least didn't until 
> fairly recently) have any memory permissions associated with them, so it was 
> impossible to use that to prevent executing data.

They had read/write bits and user/supervisor bits (per page) as far
back as 80386.  You're right that execute permission was a glaring
omission.  And even that isn't such a big deal if you use languages
that have array bounds checking -- like Ada (to bring this slightly
back on topic!).  Note that a no-execute stack doesn't prevent
security problems if you can overwrite return addresses -- you
can make them point to snippets of legitimate (executable) code.

But if you allow me to forget about x86 misfeatures, I stand by my
statement, "whatever segmentation can do can be done better by some
combination of software and paging" -- assuming a well designed
paging system.  And assuming well designed programming languages!

- Bob

Re: Arbitrary Sandbox

[tmoran]

> But there's an inherent inefficiency in segmentation: the size of
> all your pointers doubles.  Or to look at it the other way around,
> for any given amount of address space, it's split inconveniently.
> With the amount of memory I can afford today, a 32-bit segment
> number plus a 32-bit offset wouldn't be enough (both too few
> segments and segment size too small).  64-bit seg num plus
> 64-bit offset?  OK, big enough, but inefficient.  64-bit flat
> address space: perfect!  ;-)

  How many programs have more than 2**16 different objects?  You could use
16 bit segment numbers and 48 bit offsets to give you 64 bit pointers.
That's 64K distinct segments, each of 256 terabytes.  A flat 64 bit
address is going to have the upper quarter (at least) of bits zero anyway
on most machines for some years to come.
  Big addresses take a lot of storage if you have large arrays of full
pointers (not just offsets).  But segments shrink *code* size by
occasionally loading segment registers, but usually using a small number
of bits to indicate which segment register to use in an operation.
  Segments are like using people's first names, or even pronouns, instead
of full names all the time.  You can't run a company-wide database on
first names, but in most discourse you would say something like
"Does Bob want coffee too?", not "Does Robert A Duff want coffee too?".

Re: Arbitrary Sandbox

[Dmitry A. Kazakov]

On Wed, 7 Mar 2012 19:32:52 +0000 (UTC), tmoran@acm.org wrote:

> How many programs have more than 2**16 different objects?

The project I am working on does not compile under 32-bit Windows. GNAT
wants more than 3GB RAM. I have no idea why. The resulting program is not
large, a couple of megabytes or so. I think it is the magic of generics, as
always...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Arbitrary Sandbox

[Robert A Duff]

tmoran@acm.org writes:

>   How many programs have more than 2**16 different objects?

Do you mean "object" as defined in Ada?  If so, lots of programs have
far more.  If not, then you'll have to explain how you want to map
Ada objects into segments, and what you expect to accomplish thereby.
I've seen lots of ideas in that area, and none of them make a whole
lot of sense to me.

An array of a million Booleans contains a million objects, in
the Ada sense.

>...You could use
> 16 bit segment numbers and 48 bit offsets to give you 64 bit pointers.
> That's 64K distinct segments, each of 256 terabytes.  A flat 64 bit
> address is going to have the upper quarter (at least) of bits zero anyway
> on most machines for some years to come.

I agree that a 48-bit offset is big enough.  I don't agree that a 16-bit
segment number is big enough.  OK, so maybe split 24/40 instead of
16/48?  Still not enough segments.  That's the problem -- however you
split those 64 bits, you have not enough segments or not big enough
segments, or both.

A flat address space solves the problem -- the programmer gets to decide
whether to have a huge number of small objects, or a small number of
huge objects, or something in between.

>   Big addresses take a lot of storage if you have large arrays of full
> pointers (not just offsets).

Agreed.  So use array indices instead, when that's the problem.

>...But segments shrink *code* size by
> occasionally loading segment registers, but usually using a small number
> of bits to indicate which segment register to use in an operation.

If I understand what you mean, it seems to me you can use a small
number of bits to indicate which register points to the beginning
of an array in a flat address space, just as well.

- Bob

Re: Arbitrary Sandbox

[tmoran]

> An array of a million Booleans contains a million objects, in
> the Ada sense.
    In a segment based architecture that would be one segment. The
array is the object at that level, not the bit.  If you pass that
array as a procedure argument, you mention one name, not a million.

> >...But segments shrink *code* size by
> > occasionally loading segment registers, but usually using a small number
> > of bits to indicate which segment register to use in an operation.
>
> If I understand what you mean, it seems to me you can use a small
> number of bits to indicate which register points to the beginning
> of an array in a flat address space, just as well.
    Yes, you can partially simulate segmented addresses that way.  But
using general registers, rather than specific registers, means the
hardware can't help.  If they are hardware segment registers they can
have security/usage/paging bits and the OS can tell which segments are
in use when it wants to swap something, for instance.
  If you want to code at the bit level in asm or C, then certainly having
every bit equal, with the individual programmer deciding what every bit
means, is appropriate.  If you want to code at a higher level, with things
like "this is an array segment, it's currently located in RAM starting
here, its size is xxx, it's read-only, non-executable", then I prefer
segments.

Re: Arbitrary Sandbox

[Brian Drummond]

On Wed, 07 Mar 2012 19:50:03 -0500, Robert A Duff wrote:


> 
> I agree that a 48-bit offset is big enough.  I don't agree that a 16-bit
> segment number is big enough.  OK, so maybe split 24/40 instead of
> 16/48?  Still not enough segments.  That's the problem -- however you
> split those 64 bits, you have not enough segments or not big enough
> segments, or both.

OK, divide the object space further. Reserving one bit of the object 
number as a tag to distinguish between object types, 2^30 small objects 
(32-bit offset) and 2^15 large (48-bit offset) objects is probably 
enough. 

Using more bits in the tag can distinguish more object types : perhaps 
allocated from different storage pools either for common sizes or 
different lifetimes (or remote objects). Reserve one tag value for 
"compact objects" (well, the architect was an astronomer!) where the type 
and value are encoded into the object number.

Ancient history:
http://en.wikipedia.org/wiki/Rekursiv
Object numbers there were just 40 bits; 64 gives much more room.

(I had not realised someone re-engineered it in 1992!)
alexandria.tue.nl/extra1/afstversl/E/374655.pdf

- Brian

Re: Arbitrary Sandbox

[Shark8]

On Wednesday, March 7, 2012 1:32:52 PM UTC-6, tmo...@acm.org wrote:
> > But there's an inherent inefficiency in segmentation: the size of
> > all your pointers doubles.  Or to look at it the other way around,
> > for any given amount of address space, it's split inconveniently.
> > With the amount of memory I can afford today, a 32-bit segment
> > number plus a 32-bit offset wouldn't be enough (both too few
> > segments and segment size too small).  64-bit seg num plus
> > 64-bit offset?  OK, big enough, but inefficient.  64-bit flat
> > address space: perfect!  ;-)
> 
>   How many programs have more than 2**16 different objects?  You could use
> 16 bit segment numbers and 48 bit offsets to give you 64 bit pointers.
> That's 64K distinct segments, each of 256 terabytes.  A flat 64 bit
> address is going to have the upper quarter (at least) of bits zero anyway
> on most machines for some years to come.
>   Big addresses take a lot of storage if you have large arrays of full
> pointers (not just offsets).  But segments shrink *code* size by
> occasionally loading segment registers, but usually using a small number
> of bits to indicate which segment register to use in an operation.
>   Segments are like using people's first names, or even pronouns, instead
> of full names all the time.  You can't run a company-wide database on
> first names, but in most discourse you would say something like
> "Does Bob want coffee too?", not "Does Robert A Duff want coffee too?".

You know, I thought that the 16-bit segment / 48-bit offset sounded good several years ago... when 64-bit processes were coming into vogue/hype; given that each additional bit doubles the addressable memory.

Re: Arbitrary Sandbox

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcceht4o92a.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>>> You mean "already there" in 386/pentium?  Languages don't use it because
>>> it's inefficient, and because whatever segmentation can do can be done
>>> better by some combination of software and paging.
>>
>> The only reason it is "inefficient" was because OSes didn't use it.
>
> And OSes didn't use it because it for the reasons I stated.  It's a
> cyclic thing -- I'm sure Intel could have made it faster if there
> was demand.
>
> But there's an inherent inefficiency in segmentation: the size of
> all your pointers doubles.  Or to look at it the other way around,
> for any given amount of address space, it's split inconveniently.
> With the amount of memory I can afford today, a 32-bit segment
> number plus a 32-bit offset wouldn't be enough (both too few
> segments and segment size too small).  64-bit seg num plus
> 64-bit offset?  OK, big enough, but inefficient.  64-bit flat
> address space: perfect!  ;-)

I disagree. The 48-bit segment pointers of the x86 are big enough for some 
time to come, with the possible exception of a handful of extreme image 
processing programs. I do agree that there will come a point when 32-bits is 
not enough, but it's still a few years off. (About all the memory I can 
afford is 8GB, and that's going to be partitioned amongst several programs, 
so I don't see having any bigger than 4GB objects in the near future.)

And I would be perfectly happy with a 16:48 scheme for a foreseeable 
future -- I doubt there will be many machines with more than 2**48 bytes of 
memory any time soon.

In any case, you don't want to use a *lot* of segments. You just want 
separate segments for the major divisions in your code (executable code, 
constants, data, heap perhaps).

>>... That is,
>> it was quite efficient on an 386 (the only big expense occurs when 
>> reloading
>> segment registers, and that was something that occurred very rarely in 
>> the
>> two-segment model we used).
>
> OK, I have no idea what two-segment model you used.  I was picturing
> some sort of one-heap-object-per-segment model, and that sort of
> thing, which some folks have advocated as a "solution" to the
> problem of indexing out of bounds in languages that don't
> require detection of that.

As you note later, our source language is Ada and checking for out-of-bounds 
index values isn't a problem. The problem I was trying to prevent was 
executing random data, usually after some part of the stack got clobbered, 
as well as preventing the modification of code by screwed up pointers. So we 
just kept the code and data completely separate in separate segments, with 
no execute permission on the data segment and no write permission on the 
code segment. The x86 has separate registers for this anyway, so there's 
almost no overhead. In addition, since most code only uses the offsets, you 
can't accidentally read code when you meant to get data.

>> As far as "software" and "paging" being able to do anything, this makes 
>> no
>> sense at all. Pages on the x86 architecture don't (or at least didn't 
>> until
>> fairly recently) have any memory permissions associated with them, so it 
>> was
>> impossible to use that to prevent executing data.
>
> They had read/write bits and user/supervisor bits (per page) as far
> back as 80386.  You're right that execute permission was a glaring
> omission.  And even that isn't such a big deal if you use languages
> that have array bounds checking -- like Ada (to bring this slightly
> back on topic!).  Note that a no-execute stack doesn't prevent
> security problems if you can overwrite return addresses -- you
> can make them point to snippets of legitimate (executable) code.

Actually, it is a *very* glaring omission. Marking data as no execute is 
critical to improving code quality (our compiler got a lot better when we 
could do that, in large part because I didn't have to spend anywhere near as 
much time tracking impossible to pinpoint bugs). And it also was free, which 
was important for our small company that couldn't spend 10K on a fancy 
hardware ICE.

I agree that this scheme can't eliminate all security problems, but it does 
eliminate all code *injection* problems: because the segments prevent 
executing anything that can be modified. So it is impossible to execute any 
new code. It's still possible to leverage a bug to execute code that already 
exists somewhere in the program, but that's a lot harder to do. (And using 
static linking to ensure that no vestiage of unused APIs exists in your 
executable would help even more -- another place were Windows got this 
wrong). I realize there has to be an API to allow executing code created on 
the fly (for JIT compilers, for one use), but since the vast majority of 
programs don't use it, it can be protected (and not even present in the 
code).

BTW, I'm well aware that security people have finally caught up with this, 
and are finally doing most of these things (along with some others) in 
recent OSes like Windows 7. The annoying thing is that we used segments to 
do all of the above in our 1990-era DOS Extender compilers, so why it took 
nearly 20 years for the world to catch up is beyond me.

> But if you allow me to forget about x86 misfeatures, I stand by my
> statement, "whatever segmentation can do can be done better by some
> combination of software and paging" -- assuming a well designed
> paging system.  And assuming well designed programming languages!

You can't much forget about x86 misfeatures, because it was pretty much all 
there was until very recently. Until ARM started getting used a lot, every 
other architecture was down there in the noise.

In any case, the problem with paging is it requires wasting lots of address 
space. I suppose if you are willing to waste 64-bits for pointers (I still 
find 32-bit pointers wasteful!), it doesn't really matter. (I, after all, 
find the waste of space caused by alignment distasteful; Janus/Ada will pack 
everything to the nearest byte if you let it.)

                                        Randy.

Re: Arbitrary Sandbox

[Tero Koskinen]

On Fri, 17 Feb 2012 20:47:36 -0800 (PST)
Shark8 <onewingedshark@gmail.com> wrote:

> On Feb 15, 3:07 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> > "Shark8" <onewingedsh...@gmail.com> wrote in message
> >
> > news:203d63cf-42a9-49ef-82cd-943d77b5e438@c21g2000yqi.googlegroups.com...
> > On Feb 11, 8:10 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> >
> > >> Windows and Unix-based systems do not have a properly designed (native)
> > >> runtime environment -- stuff we did to make Janus/Ada more secure on DOS
> > >> extenders in the 1980s never made it to OS environments).
> >
> > The vast majority of programs do not have self-modifying code, and it
> > shouldn't be possible for them to run such code in any way. If that's the
> > case, most code-injection attacks cannot happen.
> >
> > We used the native segmentation of the Intel hardware to completely separate
> > code and data in Janus/Ada programs. It was impossible to accidentally
> > execute data simply because the data wasn't even in the same address space.
> >
> >                                                 Randy.
> 
> You know; I always wondered why they (developers, and OS designers)
> didn't take advantage of segments. It seems to be a very nice way to
> enforce security. (As you said, going all the way to the 286.)

OpenBSD uses somewhat similar tactic on i386 for its W^X
(write-or-execute) feature:  https://en.wikipedia.org/wiki/W%5EX

You can set the execute or write flags using mprotect system call, so
Just-In-Time compilers and other programs with fancy memory usage work
more of less out of the box.

Theo de Raadt's presentation from 2005 has some implementation info
and also descriptions of other security features of OpenBSD:
http://www.openbsd.org/papers/ven05-deraadt/index.html

-- 
Tero Koskinen - http://iki.fi/tero.koskinen/