On Fri, Nov 08, 2002 at 12:55:31AM +0100, Ulrich Weigand was heard to remark:
> Linas Vepstas wrote:
>
> >I didn't say it wasn't enormous. Its not tiny, but I'm not sure
> >its that big either.
>
> Well, for a start, you can't really do program calls in home space
> mode (which is where Linux user mode runs), so you'd need to
I want to set storage keys differently on different chunks of memory.
And then I want be able to change storage keys at some subroutine
call boundaries, but not others. If a program call is not the ticket,
then, hmm. maybe some other, kernel assisted stunt. Last time I looked
at this, a few years ago, it seemed possible, but I'm pretty new
to the 390 arch so I dunno.
> Indeed. However, if you need to significantly change your apps
> to make use of these hypothetical security features, then you
> could just as well change the apps to use existing mechanisms,
> like just using multiple processes ...
Yes, except as stated, I beleive that creating apps that use multiple
proccesses is hard. (Off-topic: I know a guy who teaches C++, and he insists
that 25% of his students don't know how to handle C pointers correctly,
even if they've been coding in C for a decade. Do you think this 25%
would be capable of writing a multiple-process app? My extrapolation
from this datapoint is grim.)
> So System V IPC is crap, that's no big news ;-) Use pipes and/or
> shared mmap instead, and you'll see lots of applications that do
> that. (See e.g. the recently introduced 'privilege separation'
> feature of OpenSSH.)
Sorry I used the word semaphore. Using pipes & shmem is hard. Well,
using them is easy, using them and creating something that's extenisble,
maintainble, lacks race conditions and other bugs ... that's a lot
harder. If it's so easy, why didn't ssh do it years ago?
> - significantly easier to use than multiple processes / IPC
Some storage-key based mechanism.
> - worth while for application programmers to implement even
> though they restrict themselves to a single platform
I was proposing experimentation. I'm thinking that, after some
experiments, one discovers either that its a good idea, at which
point other future CPU's arch's should also get such mechanisms,
say 2 or 5 or 8 years out. Or one finds that a slightly different
implemention would be better. Or maybe the idea of putting a
fine-grained control over read/write/execute permissions on different
portions of a flat memory space is a bad idea. Right now, it seems
like a neat idea, but without significant work, I won't know.
Maybe it can't be done easily/cleanly/well on the s390. I'm not
adverse to going into a lab and working with someone to create a
new cpu which would be a testbed for such a feature. Maybe alter
some secret 390 insn microcode, you know.
> One main point why just function calls are so much easier
> to use than IPC is that you can pass pointers to complex
> data structures back and forth. If you really implement
> some sort of strict memory protection, that won't work
> any more.
Huh? why not?
> and why is this then still significantly
> easier than IPC?
To define a library interface, traditionally, one defines some functin
prototypes, and then writes the code to make them "do something".
To pass data on a socket, you need to define the structure
of the data passing through the socket. And you need to define
at least two subroutines, one to pack the data into the pipe, one
to pull it out. And a third routine to do the "actual work"
that your app is supposed to do.
OK, so there are tools that can automate a lot of this, such as RPC's
and stub generators and IDL's, or you can code in Java or scheme or
C# or some language that provides native support for this
("introspection", or ability to marshall/unmarshall itself). Or use
.net so that you can be a stupid programmer creating incredibly complex
systems. But these are all very complex mechanisms if your goal
is merely to be a lowly library trying to prevent someone from meddling
with your innards.
> Furthermore, if the protection is supposed to be enforced
> against adversary efforts (and not just some feature to
> catch bugs, like e.g. mprotect), then there needs to be
> a protection barrier set up by some agent outside of the
> process itself. E.g. you don't just switch the PSW key
> (the callee could just switch it back), but you need to
> actually change the PSW key *mask*, i.e. perform a
> program call or the like. This needs kernel help to
> set up program call numbers, entry tables etc.
yes.
> How is that kernel help to be triggered?
Dunno
> What authentication
> mechanism protects access to these features?
Dunno.
> I don't think the S/390 hardware features are a 'magic
> bullet' that solves all these security problems. The
Maybe not :-(
> real problem is to come up with an interface that
> actually provides these features in a sane way; the
Yes.
> hardware might then be used to implement them in a
> more efficent way, maybe.
If the feature is sane & usable, then yes. I am reminded that
the 390 executes a significant amount of microcode to emulate
certain instructions. If one had access to these (proprietary)
guts, I suspect one could design/create a new program-call
instruction that would set the storage keys appropriately.
One the 390, just because the needed instruction doesn't yet
exist doesn't mean you can't create it tommorrow, (if you
had access to these highly restricted, highly secret innards).
> E.g. one could imagine
Yep, that's the stage I'm currently at.
--linas
--
pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
