headers
Jon Masters | 6 Oct 02:25
Favicon

pulse-rt by default?

Hi,

Can I suggest that we consider adding new desktop users on a fresh
install to pulse-rt by default? Or, put another way, does anyone think
this is a particularly bad idea to be doing?

Jon.

--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Permalink | Reply |
headers
Lennart Poettering | 6 Oct 02:48

Re: pulse-rt by default?

On Sun, 05.10.08 20:29, Jon Masters (jonathan <at> jonmasters.org) wrote:

> Hi,
> 
> Can I suggest that we consider adding new desktop users on a fresh
> install to pulse-rt by default? Or, put another way, does anyone think
> this is a particularly bad idea to be doing?

It's a security issue.

If you add a user to pulse-rt he basically got the power to block the
CPU indefinitely and thus freeze the machine.

Unfortunately on Linux we don't have anything in place that would
allow "safe" usage of realtime features. There have been steps in the
right direction (like real-time group scheduling, RLIMIT_RTTIME), but
that is still a royal PITA to use or trivial to circumvent.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
(Continue reading)

Permalink | Reply |
headers
Arjan van de Ven | 6 Oct 02:56
Favicon

Re: pulse-rt by default?

On Mon, 6 Oct 2008 02:48:46 +0200
Lennart Poettering <mzerqung <at> 0pointer.de> wrote:

> On Sun, 05.10.08 20:29, Jon Masters (jonathan <at> jonmasters.org) wrote:
> 
> > Hi,
> > 
> > Can I suggest that we consider adding new desktop users on a fresh
> > install to pulse-rt by default? Or, put another way, does anyone
> > think this is a particularly bad idea to be doing?
> 
> It's a security issue.
> 
> If you add a user to pulse-rt he basically got the power to block the
> CPU indefinitely and thus freeze the machine.
> 
> Unfortunately on Linux we don't have anything in place that would
> allow "safe" usage of realtime features. There have been steps in the
> right direction (like real-time group scheduling, RLIMIT_RTTIME), but
> that is still a royal PITA to use or trivial to circumvent.
> 

yeah it's better to not need realtime, and just have a good enough
scheduler instead ;-)

--

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
(Continue reading)

Permalink | Reply |
headers
Lennart Poettering | 6 Oct 03:42

Re: pulse-rt by default?

On Sun, 05.10.08 17:56, Arjan van de Ven (arjan <at> infradead.org) wrote:

> > If you add a user to pulse-rt he basically got the power to block the
> > CPU indefinitely and thus freeze the machine.
> > 
> > Unfortunately on Linux we don't have anything in place that would
> > allow "safe" usage of realtime features. There have been steps in the
> > right direction (like real-time group scheduling, RLIMIT_RTTIME), but
> > that is still a royal PITA to use or trivial to circumvent.
>
> yeah it's better to not need realtime, and just have a good enough
> scheduler instead ;-)

I'd love to see something like SCHED_ISO implemented: i.e. where a
process could specify how much CPU time it needs and how often. Would
be ideal for everything that requires a fixed amount of CPU but not
the entire CPU all the time. Would be perfect for video playback,
audio stuff, animations, and everything else.

And that same information would be useful as a replacement for all the
different latency APIs we have on Linux -- if a process says it needs
a bit of CPU every 30th of a second to bring a new movie frame to the
screen then this same information can be used to let the CPU sleep in
some deep sleep state for the rest of the time.

SCHED_ISO wuldn't just solve the security issue. It would also be
immensly useful and a nice API on top.

Lennart
(Continue reading)

Permalink | Reply |
headers
Jon Masters | 6 Oct 04:20
Favicon

Re: pulse-rt by default?

On Sun, 2008-10-05 at 17:56 -0700, Arjan van de Ven wrote:
> On Mon, 6 Oct 2008 02:48:46 +0200
> Lennart Poettering <mzerqung <at> 0pointer.de> wrote:
> 
> > On Sun, 05.10.08 20:29, Jon Masters (jonathan <at> jonmasters.org) wrote:
> > 
> > > Hi,
> > > 
> > > Can I suggest that we consider adding new desktop users on a fresh
> > > install to pulse-rt by default? Or, put another way, does anyone
> > > think this is a particularly bad idea to be doing?
> > 
> > It's a security issue.

It's not a security issue if you're on a single user desktop/laptop, and
therefore something that could be configured up during installation. One
idea I had was to suggest having install "profiles" available - I'd love
to have an anaconda option I can click that will:

* Add me to sudoers automatically (first thing I do on every Fedora/RHEL
system, and the most annoying thing missing from a standard install)
* Add me to various groups useful to desktop self-admin, etc.
* (Disable SELinux policy with a vengeance :P)

> > Unfortunately on Linux we don't have anything in place that would
> > allow "safe" usage of realtime features.

That's not true. You already have PolicyKit support and even look to see
if you have a policy. So that authorization could just be setup in
advance for pulseaudio if it's running on a desktop system.
(Continue reading)

Permalink | Reply |
headers
Brennan Ashton | 6 Oct 05:01

Re: pulse-rt by default?

On Sun, 2008-10-05 at 22:20 -0400, Jon Masters wrote:
> On Sun, 2008-10-05 at 17:56 -0700, Arjan van de Ven wrote:
> > On Mon, 6 Oct 2008 02:48:46 +0200
> > Lennart Poettering <mzerqung <at> 0pointer.de> wrote:
> > 
> > > On Sun, 05.10.08 20:29, Jon Masters (jonathan <at> jonmasters.org) wrote:
> > > 
> > > > Hi,
> > > > 
> > > > Can I suggest that we consider adding new desktop users on a fresh
> > > > install to pulse-rt by default? Or, put another way, does anyone
> > > > think this is a particularly bad idea to be doing?
> > > 
> > > It's a security issue.
> 
> It's not a security issue if you're on a single user desktop/laptop, and
> therefore something that could be configured up during installation. One
> idea I had was to suggest having install "profiles" available - I'd love
> to have an anaconda option I can click that will:
> 
> * Add me to sudoers automatically (first thing I do on every Fedora/RHEL
> system, and the most annoying thing missing from a standard install)
> * Add me to various groups useful to desktop self-admin, etc.
> * (Disable SELinux policy with a vengeance :P)
> 
> > > Unfortunately on Linux we don't have anything in place that would
> > > allow "safe" usage of realtime features.
> 
> That's not true. You already have PolicyKit support and even look to see
> if you have a policy. So that authorization could just be setup in
(Continue reading)

Permalink | Reply |
headers
Jesse Keating | 6 Oct 18:12
Favicon

Re: pulse-rt by default?

On Sun, 2008-10-05 at 22:20 -0400, Jon Masters wrote:
> It's not a security issue if you're on a single user desktop/laptop, and
> therefore something that could be configured up during installation. One
> idea I had was to suggest having install "profiles" available - I'd love
> to have an anaconda option I can click that will:
> 
> * Add me to sudoers automatically (first thing I do on every Fedora/RHEL
> system, and the most annoying thing missing from a standard install)
> * Add me to various groups useful to desktop self-admin, etc.
> * (Disable SELinux policy with a vengeance :P)

Most of these require a user already created, which would mean this
should go in Firstboot instead.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Permalink | Reply |
headers
Callum Lerwick | 6 Oct 03:46

Re: pulse-rt by default?

On Sun, 2008-10-05 at 20:29 -0400, Jon Masters wrote:
> Hi,
> 
> Can I suggest that we consider adding new desktop users on a fresh
> install to pulse-rt by default? Or, put another way, does anyone think
> this is a particularly bad idea to be doing?

Seems kind of pointless. If you're running low on CPU time, giving
pulseaudio priority will likely just result in client buffers running
dry anyway. Is there anything in place to take care of the priority
inversion problem? I know jackd/jacklib has some scheduling magic in
it...

--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Permalink | Reply |
headers
Lennart Poettering | 6 Oct 04:18

Re: pulse-rt by default?

On Sun, 05.10.08 20:46, Callum Lerwick (seg <at> haxxed.com) wrote:

> On Sun, 2008-10-05 at 20:29 -0400, Jon Masters wrote:
> > Hi,
> > 
> > Can I suggest that we consider adding new desktop users on a fresh
> > install to pulse-rt by default? Or, put another way, does anyone think
> > this is a particularly bad idea to be doing?
> 
> Seems kind of pointless. If you're running low on CPU time, giving
> pulseaudio priority will likely just result in client buffers running
> dry anyway. Is there anything in place to take care of the priority
> inversion problem? I know jackd/jacklib has some scheduling magic in
> it...

I am not sure you fully understand what real-time is about. It is not
about giving some process "priority". That's what nice levels are for.

Taking care of the "priority inversion problem"? There is no need for
anyone to work around that, since we have PTHREAD_PRIO_INHERIT which
PA has been using for quite a while (although we are mostly lock-less
now).

Lennart

--

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
(Continue reading)

Permalink | Reply |
headers
Alan Cox | 6 Oct 10:54
Favicon

Re: pulse-rt by default?

On Sun, Oct 05, 2008 at 08:46:18PM -0500, Callum Lerwick wrote:
> pulseaudio priority will likely just result in client buffers running
> dry anyway. Is there anything in place to take care of the priority
> inversion problem? I know jackd/jacklib has some scheduling magic in
> it...

And on a lot of hardware the problem in the X server locking the bus up
anyway not the kernel scheduler. The intel driver developed that bad habit
between FC8 and FC9. Nothing the kernel can do if the PCI bus is being
hogged by another device so much the buffers drain.

Alan

--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Permalink | Reply |

Gmane