On Wed, May 04 2022 at 15:56, Marcelo Tosatti wrote:
> On Wed, May 04, 2022 at 03:20:03PM +0200, Thomas Gleixner wrote:
>> Can we please focus on the initial problem of
>> providing a sensible isolation mechanism with well defined semantics?
>
> Case 2, however, was implicitly suggested by you (or at least i
> understood that):
>
> "Summary: The problem to be solved cannot be restricted to
>
> self_defined_important_task(OWN_WORLD);
>
> Policy is not a binary on/off problem. It's manifold across all levels
> of the stack and only a kernel problem when it comes down to the last
> line of defence.
>
> Up to the point where the kernel puts the line of last defence, policy
> is defined by the user/admin via mechanims provided by the kernel.
>
> Emphasis on "mechanims provided by the kernel", aka. user API.
>
> Just in case, I hope that I don't have to explain what level of scrunity
> and thought this requires."
Correct. This reasoning is still valid and I haven't changed my opinion
on that since then.
My main objections against the proposed solution back then were the all
or nothing approach and the implicit hard coded policies.
> The idea, as i understood was that certain task isolation features (or
> they parameters) might have to be changed at runtime (which depends on
> the task isolation features themselves, and the plan is to create
> an extensible interface).
Again. I'm not against useful controls to select the isolation an
application requires. I'm neither against extensible interfaces.
But I'm against overengineered implementations which lack any form of
sensible design and have ill defined semantics at the user ABI.
Designing user space ABI is _hard_ and needs a lot of thoughts. It's not
done with throwing something 'extensible' at the kernel and hope it
sticks. As I showed you in the review, the ABI is inconsistent in
itself, it has ill defined semantics and lacks any form of justification
of the approach taken.
Can we please take a step back and:
1) Define what is trying to be solved and what are the pieces known
today which need to be controlled in order to achieve the desired
isolation properties.
2) Describe the usage scenarios and the resulting constraints.
3) Describe the requirements for features on top, e.g. inheritance
or external control.
Once we have that, we can have a discussion about the desired control
granularity and how to support the extra features in a consistent and
well defined way.
A good and extensible UABI design comes with well defined functionality
for the start and an obvious and maintainable extension path. The most
important part is the well defined functionality.
There have been enough examples in the past how well received approaches
are, which lack the well defined part. Linus really loves to get a pull
request for something which cannot be described what it does, but could
be used for cool things in the future.
> So for case 2, all you'd have to do is to modify the application only
> once and allow the admin to configure the features.
That's still an orthogonal problem, which can be solved once a sensible
mechanism to control the isolation and handle it at the transition
points is in place. You surely want to consider it when designing the
UABI, but it's not required to create the real isolation mechanism in
the first place.
Problem decomposition is not an entirely new concept, really.
Thanks,
tglx
