Re: [patch] Assigning syscall numbers for testing

Doug Ledford
2001-12-24T18:13:52Z

David Lang wrote:

> you miss the point, the syscall numbers will not nessasarily be consistant
> from boot to boot so if your code does not check for them it's seriously
> broken (and remember this is only for stuff in experimental status). The
> hope is that most if not all of the real checking can end up being done in
> glibc

No, I'm not missing the point. Try to follow with me here, this isn't
rocket science. *NOT* *ALL* *SOFTWARE* *IS* *OR* *WILL* *BE* *USING*
*DYNAMIC* *SYSCALLS*. Your scenario is fine if you want to convert all
existing software to dynamic syscalls. However, my scenario specifically
dealt with software that *DOES* *NOT* use dynamic syscalls (and which
doesn't need to because the syscalls it *does* use have been allocated).

Since people are having such a hard time with this, let me spell it out in
more detail. Assume the following scenario:

Linux 2.4.17 + dynamic syscall patch. Dynamic syscalls start at 240.

Linux 2.4.18 comes out, and now there are two *new* *official* *statically*
*allocated* syscalls at 240 and 241 (they are SYSGETAMIBLKHEAD and
SYSSETAMIBLKHEAD).

A new piece of software (or an existing one, doesn't matter) is written to
take advantage of the new syscalls. It uses the *predefined* syscall
numbers and is compiled against 2.4.18. It relies upon -ENOSYS (as is
typical for non-dynamic syscalls) to indicate if the kernel doesn't support
the intended syscalls.

Now, someone without realizing the implications of what's going on, runs
this new program on a machine running the 2.4.17 + dynamic syscall patch.

BOOM!

So, to reiterate my points. This *IS* *NOT* *SAFE* unless either A) the
dynamic syscall number range is officially allocated *before* the patch goes
into use to avoid these collisions later or B) you switch *all* software to
using dynamic syscalls (which does have a performance impact on the software
and which would also require lots of work).

> David Lang
>
>
>
> On Mon, 24 Dec 2001, Doug Ledford wrote:
>
>
>>Date: Mon, 24 Dec 2001 12:06:19 -0500
>>From: Doug Ledford <dledford@redhat.com>
>>To: Alan Cox <alan@lxorguk.ukuu.org.uk>
>>Cc: Keith Owens <kaos@ocs.com.au>, Benjamin LaHaise <bcrl@redhat.com>,
>> linux-kernel@vger.kernel.org
>>Subject: Re: [patch] Assigning syscall numbers for testing
>>
>>Alan Cox wrote:
>>
>>
>>>>Well, I'm not going to mess with code, but here's the example. Say you
>>>>start at syscall 240 for dynamic registration. Someone then submits a patch
>>>>
>>>>
>>>The number you start at depends on the kernel you run.
>>>
>>>
>>>
>>>>modify the base of your patch, but if it has been accepted into any real
>>>>kernels anywhere, then someone could inadvertently end up running a user
>>>>space app compiled against Linus' new kernel and that uses the newly
>>>>allocated syscalls 240 and 241. If that's run on an older kernel with your
>>>>
>>>>
>>>The code on execution will read the syscall numbers from procfs. It will
>>>find new numbers and call those. Its a very simple implementation of lazy
>>>binding. It only breaks if you actually run out of syscalls, and then it
>>>fails safe.
>>>
>>>Alan
>>>
>>>
>>>
>>No it doesn't. You are *assuming* that *all* code will check the lazy
>>syscall bindings. My example was about code using the predefined syscall
>>number for new functions on an older kernel where those functions don't
>>exist, but where they overlap with the older dynamic syscall numbers. In
>>short, the patch is safe for code that uses the lazy binding, but it can
>>still overlap with future syscall numbers and code that doesn't use the lazy
>>binding but instead uses predefined numbers.
>>
>>--
>>
>> Doug Ledford <dledford@redhat.com> http://people.redhat.com/dledford
>> Please check my web site for aic7xxx updates/answers before
>> e-mailing me about problems
>>
>>-
>>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>the body of a message to majordomo@vger.kernel.org
>>More majordomo info at http://vger.kernel.org/majordomo-info.html
>>Please read the FAQ at http://www.tux.org/lkml/
>>
>>
>

--

Doug Ledford <dledford@redhat.com> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems