kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)

[Thiago Macieira]

On Saturday, 20 de August de 2011 14:11:32 Oswald Buddenhagen wrote:
> On Sat, Aug 20, 2011 at 12:20:55PM +0200, Thiago Macieira wrote:
> > On Saturday, 20 de August de 2011 10:02:31 Oswald Buddenhagen wrote:
> > > kded's module activation is redundant with systemd.
> > 
> > But not at all the same impact. Starting an application and negotiating
> > its
> > connection to D-Bus is hardly comparable to loading a plugin in a daemon
> > that is already connected.
> 
> yeah, at the cost of rather considerable instability.
> we should see whether regular service activation isn't the better
> option, now that we have it.

What instability? If kded crashes, what makes you think individual services 
won't crash, in addition to taking longer to load and use more memory?

But I agree we should investigate.

> fwiw, macosx has something similar - launchd. it is to be seen whether
> kde could make use of it.

Yup.

> > 2) Lennart is also very much opposed to the fork-no-exec solution that
> > kdeinit and booster use to pre-initialise.
> 
> yes, he made it pretty clear to me that he doesn't like it. but then,
> in retrospect, all his arguments seem pretty easy to refute, so if he
> is the reasonable person he appears to be, it should be possible to
> change his mind if we can make a strong technical case that it would
> also clearly benefit gnome.
> and in the worst case, the feature is optional and the patch to systemd
> wouldn't be extraordinarily big, so we could put it in the hands of
> distributors.

One problem with a no-exec scenario is the inability to switch security 
contexts and to control them on a per-binary case. Today, that is. There's 
nothing preventing additional code to be introduced to do that, if we start 
from an all-privileged daemon like systemd. It's privilege elevation that 
suffers.

The argument Lennart has against fork-no-exec are the COW that happen inside 
the original launcher due to shared pages. During the forking, all of the 
original launcher's private pages are marked COW and then get shared with the 
child process. Whenever the launcher makes a new write to those pages due to 
its normal operations, the kernel will fault and trigger a copy. The end 
result is that the launcher has a lot more COW operations that aren't its 
fault and its pages are duplicated everywhere.

If there's a privilege boundary in the process, then this might even be a 
security risk, as an unprivileged process gets read-only access to all of the 
launcher's memory and state, then it could mount a privilege escalation attack 
on the launcher itself.

I believe a solution to this would involve unmapping all of the original 
launcher's private pages, but this is extremely hard to do given copy relocs 
(libc variables ending up in the launcher pages, for example) and other 
things. Not only would this be very much OS-specific, it might be architecture-
specific.

It's far easier to introduce the feature we want into the prelinker and 
dynamic loader, such as having a "stasis" process: the dynamic loader could 
load everything as needed, then freeze the images just prior to running any 
code.

> ksecretservice is a new implementation. dunno how much code was reused.
> the arguments against two backends are easy:
> - two backends means almost twice the work, including security auditing
> - assuming the backends use different storage (it's not part of the
>   spec, after all), even after switching desktops you need to stick with
>   the now "alien" password manager.

Ok, but see below:

> > But just as before, I don't see why our code can't be cross-desktop. So no
> > argument in favour of dropping kglobalaccel.
> 
> i think it is pretty clear that our *code* is not going to be accepted
> as the cross-desktop solution. seeing the reluctance to anything with g*
> within our community, why do you think the gnomers would embrace
> anything with a q* or even k*, esp. given that it usually weights in at
> least twice as much as the typical g* solution?

I don't know where you got those numbers for weight, not to mention it's 
completely ambiguous (did you mean memory consumption?). But I don't care what 
they like or dislike: if the implementation is good, it should stay.

If they afterwards want to reimplement the code using their technologies, it's 
their right, but they're the ones that created duplication.

> > One remaining issue is to have an "alternate representation" for certain
> > types in the data, most importantly strings. As I provoked in the
> > Enlightenment talk in the Summit, when Gustavo was calling for shared,
> > binary formats, "strings are UTF-16, right?"
> 
> that's a tough one.
> one can't have the binary dbs in utf-16, as then the g* apps would be at
> disadvantage.

I don't care. As long as there's a UTF-16 representation, I'm fine. That's why 
I'm calling this "alternate representation". I didn't mean to say that it's 
UTF-16 exclusively. I just want UTF-16 to be there.

I could even accept the alternate representation to be optional, so an UTF-8-
to-UTF-16 coversion needs to happen when Qt-based code reads the config. What's 
unacceptable is to not optimise for Qt when the settings are read and written 
by Qt-based apps.

> one could have the string data in both formats at once, but that would
> be wasteful.

That's what I'm advocating: both formats.

> so an entirely different approach i've been thinking about for a while:
> make QString a hybrid, so it stores raw data and a codec. it would
> transcode only on demand, so in many (possibly even most) cases, it
> would do 8-bit pass-through. of course, many common "small" operations
> would become more expensive. i'm not convinced that there would be an
> overall improvement. or even that the exercise makes sense in the first
> place.

Agreed, changing QString like that would be a nightmare. I've thought of the 
same solution as you have: store the Latin-1 or UTF-8 strings and set a flag 
indicating that the conversion is incomplete. Leave it to lazy conversion when 
necessary, or optimise where we can to use the 8-bit data.

The problem I found is the same as QUrl today: implicit sharing of lazily 
constructed data. When you need to finish your lazy work, do you need to detach 
or not? If you detach, only one side will get the non-lazy output. If you 
don't detach, you need to somehow make the setting thread-safe -- which QUrl 
doesn't do.

This also carries the burden of checking the flags at many points in the code, 
probably adding overhead to timing-sensitive code which many already find slow.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110820/61005433/attachment.sig>