16 Nov
2003
16 Nov
'03
9:45 a.m.
Paul Davis:
I couldn't wait til you found it, so I wrote one from scratch instead. :)
The url below point to a hackish patch againt 2.4.23-rc1, and yes, it is
very simple. Works by setting /proc/sys/kernel/setschedandmlock to 1.
http://www.notam02.no/arkiv/src/schedmlockpatch-2.4.23-rc1
--
Since
mainstream capabilities support seems always to be somewhere
over the horizon, I am interested in the patch Paul and Steve
mentioned. IIUC, it defines a control file in /proc which, if
enabled, allows any process access to scheduling and memory locking
privileges. No other capabilities are provided. I would love to see
a copy of this patch to study exactly what it does.
its a very simple patch, IIRC. it just short-circuits the checks on
uid==0 and/or capabilities when assigning SCHED_FIFO and/or locking
memory.
i'm looking for it in my archives. i'm a bit worried i may have 
17 Nov
17 Nov
12:44 a.m.
New subject: [linux-audio-dev] Re: [Jackit-devel] Re: POSIX caps/realtime/root processes
Paul Davis:
I couldn't wait til you found it, so I wrote one from scratch instead. :)
The url below point to a hackish patch againt 2.4.23-rc1, and yes, it is
very simple. Works by setting /proc/sys/kernel/setschedandmlock to 1.
http://www.notam02.no/arkiv/src/schedmlockpatch-2.4.23-rc1
Hey! Good! I'm very tempted to add it to the Planet CCRMA kernels right
away :-)
Has it seen much testing? Not that something so simple would require a
lot of testing, of course. I'm trying to think of potential problems
(over the use of capabilities) and can't think of anything. The only
that would occur to me is that access to SCHED_FIFO would be more
universal whereas with capabilities, programs like givertcap or
jackstart are required.
-- Fernando
Since
mainstream capabilities support seems always to be somewhere
over the horizon, I am interested in the patch Paul and Steve
mentioned. IIUC, it defines a control file in /proc which, if
enabled, allows any process access to scheduling and memory locking
privileges. No other capabilities are provided. I would love to see
a copy of this patch to study exactly what it does.
its a very simple patch, IIRC. it just short-circuits the checks on
uid==0 and/or capabilities when assigning SCHED_FIFO and/or locking
memory.
i'm looking for it in my archives. i'm a bit worried i may have
8:09 a.m.
New subject: [linux-audio-dev] Re: [Jackit-devel] Re: POSIX caps/realtime/root processes
On Mon, 16 Nov 2003, Fernando Pablo Lopez-Lezcano wrote:
Its not been much tested. :) But I have run it for a day now, and havent
noticed any problems. Its very very simple, shouldn't cause any trouble
(except for the security) I guess.
There is one thing though, the 60 in the "KERN_GAKK=60," addition to
sysctl.h might be the same as other enums applied in later patches.
Perhaps change it to something like 9999. I dont know what the KERN_
enums are for though... Or perhaps it can just be removed.
--
I couldn't wait til you found it, so I wrote one from scratch instead. :)
The url below point to a hackish patch againt 2.4.23-rc1, and yes, it is
very simple. Works by setting /proc/sys/kernel/setschedandmlock to 1.
http://www.notam02.no/arkiv/src/schedmlockpatch-2.4.23-rc1
Hey! Good! I'm very tempted to add it to the Planet CCRMA kernels right
away :-)
Has it seen much testing? Not that something so simple would require a
lot of testing, of course. I'm trying to think of potential problems
(over the use of capabilities) and can't think of anything. The only
that would occur to me is that access to SCHED_FIFO would be more
universal whereas with capabilities, programs like givertcap or
jackstart are required.
24 Nov
24 Nov
11:50 p.m.
Kjetil Svalastog Matheussen <k.s.matheussen(a)notam02.no> writes:
> I couldn't wait til you found it, so I wrote
one from scratch instead. :)
> The url below point to a hackish patch againt 2.4.23-rc1, and yes, it is
> very simple. Works by setting /proc/sys/kernel/setschedandmlock to 1.
> http://www.notam02.no/arkiv/src/schedmlockpatch-2.4.23-rc1
Fernando Pablo Lopez-Lezcano <nando(a)ccrma.stanford.edu> writes:
Hey! Good! I'm very tempted to add it to the
Planet CCRMA kernels right
away :-)
Has it seen much testing? Not that something so simple would require a
lot of testing, of course. I'm trying to think of potential problems
(over the use of capabilities) and can't think of anything. The only
that would occur to me is that access to SCHED_FIFO would be more
universal whereas with capabilities, programs like givertcap or
jackstart are required.
I finally got around to testing Kjetil's patch (backported to 2.4.19).
It basically works, but I found a couple of problems...
(1) The patch allows SCHED_FIFO but not SCHED_RR. This makes
PortAudio V18 fail. That looks trivial to fix. Is there any reason
to allow one realtime scheduling policy and not the other?
(2) I can start `jackd -R' as a normal user, but its clients fail to
connect. This looks like a problem in the capabilities_workaround
logic of jack_start_thread(). The test fails because the engine has
the `realtime' flag set, but not `has_capabilities'. I hacked a
patch for that test and now it works. I need to figure out if that
is the correct fix before committing it to CVS, though.
I did this as a baseline before adding the `realtimegroup' logic we
discussed last week. I think I'll attempt that next, after fixing the
SCHED_RR omission.
--
joq
25 Nov
25 Nov
8:36 a.m.
On Tue, 24 Nov 2003, Jack O'Quin wrote:
Kjetil Svalastog Matheussen <k.s.matheussen(a)notam02.no> writes:
Cant think of any.
> I couldn't wait til you found it, so I
wrote one from scratch instead. :)
> The url below point to a hackish patch againt 2.4.23-rc1, and yes, it is
> very simple. Works by setting /proc/sys/kernel/setschedandmlock to 1.
> http://www.notam02.no/arkiv/src/schedmlockpatch-2.4.23-rc1
Fernando Pablo Lopez-Lezcano <nando(a)ccrma.stanford.edu> writes:
Hey! Good! I'm very tempted to add it to the
Planet CCRMA kernels right
away :-)
Has it seen much testing? Not that something so simple would require a
lot of testing, of course. I'm trying to think of potential problems
(over the use of capabilities) and can't think of anything. The only
that would occur to me is that access to SCHED_FIFO would be more
universal whereas with capabilities, programs like givertcap or
jackstart are required.
I finally got around to testing Kjetil's patch (backported to 2.4.19).
It basically works, but I found a couple of problems...
(1) The patch allows SCHED_FIFO but not SCHED_RR. This makes
PortAudio V18 fail. That looks trivial to fix. Is there any reason
to allow one realtime scheduling policy and not the other?
(2) I can start `jackd -R' as a normal user, but
its clients fail to
connect. This looks like a problem in the capabilities_workaround
logic of jack_start_thread(). The test fails because the engine has
the `realtime' flag set, but not `has_capabilities'. I hacked a
patch for that test and now it works. I need to figure out if that
is the correct fix before committing it to CVS, though.
Yes, I noticed that problem as well.
I did this as a baseline before adding the
`realtimegroup' logic we
discussed last week. I think I'll attempt that next, after fixing the
SCHED_RR omission.
I thought about hacking together those additions after it was posted,
but soon after Robert posted a module that seemed to solve the problem
in a much better way.
Whats the status of that patch, and does it only work with 2.6.
And in case it only works with 2.6, can't a similar module be made for
2.4? I know it can, because we can just copy the code in the sys_setched
and sys_mlockall functions into the module.
--
11:52 a.m.
Kjetil Svalastog Matheussen <k.s.matheussen(a)notam02.no> writes:
The Linux Security Module (LSM) interface is a standard part of 2.6.
There actually is a backport of the security modules patch to 2.4 on
the NSA site for SELinux. But, it is quite large and I doubt many
people would want to apply it for running realtime audio. Your small
patch is probably safer and more secure.
So, my feeling is that the best approach is...
(1) LSM for 2.6.
This is something we might ask multimedia distributions to
distribute, enabling an optional turn-key solution for realtime
audio.
(2) An interface-compatible variant of your patch for 2.4.
This would probably only be available for do-it-yourself kernel
builders and via special-purpose distributions like Planet CCRMA.
Basically, this is for people who are currently using capabilities
and need to continue using 2.4 for a while. I don't see it as a
long-term solution. Most of those people will probably migrate to
2.6 fairly quickly.
Some applications may want to test whether the `kernel/realtime*'
variables exist. At least they would work the same, when present.
Generally, the best way for an application to test their privileges is
by directly trying the desired system call to see if it works or
returns EPERM. In the face of capabilities patches, your patch,
optional LSM features, and users running as `root', this is the only
reasonable thing to do. Some programs test for (geteuid() == 0),
which was already a mistake.
I intend to continue experimenting along these lines until I prove to
myself that all this really works and is useful. So, far it looks
encouraging.
Regards,
--
joq
I did this as
a baseline before adding the `realtimegroup' logic we
discussed last week. I think I'll attempt that next, after fixing
the SCHED_RR omission.
I thought about hacking together those additions after it was posted,
but soon after Robert posted a module that seemed to solve the problem
in a much better way. Whats the status of that patch, and does it
only work with 2.6.
And in case it only works with 2.6, can't a similar module be made for
2.4? I know it can, because we can just copy the code in the
sys_setched and sys_mlockall functions into the module.
2:06 p.m.
The Linux Security Module (LSM) interface is a
standard part of 2.6.
There actually is a backport of the security modules patch to 2.4 on
the NSA site for SELinux. But, it is quite large and I doubt many
people would want to apply it for running realtime audio.
It depends on whether it interacts with other patches... But yes, I
would prefer not to have to add YAP (yet another patch? :-)
Your small patch is probably safer and more secure.
So, my feeling is that the best approach is...
(1) LSM for 2.6.
(2) An interface-compatible variant of your patch for 2.4.
I agree, looks good to me.
I intend to continue experimenting along these lines
until I prove to
myself that all this really works and is useful. So, far it looks
encouraging.
Indeed... thanks for working on this! A LOT!
-- Fernando
26 Nov
26 Nov
9:52 a.m.
On Tue, 25 Nov 2003, Jack O'Quin wrote:
So, my feeling is that the best approach is...
(1) LSM for 2.6.
This is something we might ask multimedia distributions to
distribute, enabling an optional turn-key solution for realtime
audio.
(2) An interface-compatible variant of your patch for 2.4.
This would probably only be available for do-it-yourself kernel
builders and via special-purpose distributions like Planet CCRMA.
Basically, this is for people who are currently using capabilities
and need to continue using 2.4 for a while. I don't see it as a
long-term solution. Most of those people will probably migrate to
2.6 fairly quickly.
I still like a module idea though. I dont see the point of
patching the kernel with the security module interface, except for the
security. What I would like, though, is:
-A module that does not require any patches to the kernel.
-A module that provides some sort of give_me_realtime(int pri) function,
which can be called without being root or have capabilities.
-This give_me_realtime_or_something function sets SCHED_FIFO priority and
calls mlockall() and sets up a watchdog of some kind (shouldn't be to
hard when you are inside the kernel).
Why?
-No patching of the kernel.
-Same interface for 2.4 and 2.6, and possible other OS'es.
-Simple interface for the programmer.
-The module should be easy to make.
Unfortunately, I dont have the time to make this module right now.
--
noon
Kjetil Svalastog Matheussen <k.s.matheussen(a)notam02.no> writes:
I still like a module idea though. I dont see the
point of
patching the kernel with the security module interface, except for the
security. What I would like, though, is:
This idea makes sense. If there is a requirement for clean, on-going
support on 2.4, the advantages you mention are significant.
Right now, I anticipate all new multimedia distributions using 2.6 as
soon as it is officially released. To my mind that makes the whole
module discussion moot. The LSM approach is clearly the preferred
method of doing these things in the 2.6 world.
I don't see much chance of new distributions supporting these
interfaces under 2.4. The existing ones are already released. I
don't expect anyone to go back and re-release with a new
give_me_realtime_or_something() module, except Nando, of course. :-)
So, to me that means basically "roll your own" 2.4 kernel usage, for
which the simple kernel patch is sufficient.
But, maybe there's something I'm forgetting?
--
joq
27 Nov
27 Nov
7:35 a.m.
On Wed, 26 Nov 2003, Jack O'Quin wrote:
Kjetil Svalastog Matheussen
<k.s.matheussen(a)notam02.no> writes:
So how is the low-latency situation for 2.6? I did install 2.6 on
my private machine, but was not able to get better performance
than 2.4 with ll+pre (kicked out of jack-graph pretty soon with 128
frames period). Is there a trick to get better lowlatency performance with
2.6 I don't know about?
--
I still like a module idea though. I dont see the
point of
patching the kernel with the security module interface, except for the
security. What I would like, though, is:
This idea makes sense. If there is a requirement for clean, on-going
support on 2.4, the advantages you mention are significant.
Right now, I anticipate all new multimedia distributions using 2.6 as
soon as it is officially released. To my mind that makes the whole
module discussion moot. The LSM approach is clearly the preferred
method of doing these things in the 2.6 world.
7720
days inactive
7731
days old
linux-audio-dev@lists.linuxaudio.org
9 comments
3 participants
participants (3)
-
Fernando Pablo Lopez-Lezcano -
Jack O'Quin -
Kjetil Svalastog Matheussen