Re: CVS commit: src/lib/librumpuser

[Alexander Nasonov <alnsn%yandex.ru@localhost>]

Antti Kantee wrote:
> Ok, one more try, this time with an example:
> 
> * fact: interface will be used to say "I have loaded code here, please
> arrange things so that it can be executed"
> * fact: you want to call the interface "sync icache" and possess those
> semantics
> 
> the example:
> Let's assume some fictional platform where you need to sign newly loaded
> code before it can execute.  Should the implementation of "sync icache" on
> that platform sign code?  If not, you can't execute the code, which was the
> original purpose.  If yes, you've failed to implement the interface
> correctly, because that might not be what the caller wants at all.  Will
> such a platform be supported?  Who knows.  Is it cause to leave known
> problems into the interface?  Definitely not!

You're over generalizing. You can't generate and sign your own code
without posing a security risk. This case deserves a special interface,
you can't just bring it under umbrella of a single hypercall that does
everything to turn memory into code.

I'm following a common practice of calling __clear_cache for JIT code
except that I wrap it as a hypercall. 

> If you don't want to solve anything except your immediate problem, that's
> more than fair enough (we've all been there),

We've seen many examples of over generalizing too.

My need is driven by existing sljit code which follows a common practice
of calling __clear_cache() gcc extension. If you want to generalize it,
we will need to work with sljit upstream to design a new interface.
Alternatively, we can disable jit code on arm and mips and give intel
a favor.

> but it needs to be done
> without breaking things for everyone else or knowingly introducing
> suboptimal interfaces that everyone else will suffer from.

"Everyone else" is a multi-dimentional term. Are you referring to users
of other operating systems or users of arches where sync_icache is noop
or a hypotetical arch where you need to sign code before running it?
(well, it's probably not hypotetical anymore, I vaguely remember reading
about a similar feature few months ago).

As I stated in the earlier email, I can build my rumpkern stuff
conditionally if you split librumpuser into NetBSD and non-NetBSD
versions. I'm going to check how it will work with a private component.

Alex