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
