Message-ID: <CAFf+5zj4Tg-uNqPaSzqmryC7kPDY5bfUe2iu0EeSJE+k_nwUrA@mail.gmail.com>
Date: Wed, 1 Oct 2025 13:40:11 +0530
From: Amit <amitchoudhary0523@...il.com>
To: linux-kernel@...r.kernel.org
Subject: Code performance vs Code security.

People are against input validation because they think that:

1. Input validation will lead to ""significant"" performance degradation.

2. They don't want to put "arbitrary limits" on the user.

---------------
Point no. 1:
---------------

There has been no research / study / tests done on whether input
validation leads to ""significant"" performance degradation. So, this
claim is not backed up by any proof.

I did some experiments with glibc's qsort() function and I found out
that the performance degradation is only 0.6% - 0.8% per function
argument. So, let's say that there are 7 arguments to a function, then
the maximum performance degradation will be 5.6%.

So, now the question is - do you want to give your users insecure code
(without input validation) just for 5.6% performance improvement?

Another question is what do users actually want - no one has done this
study also. So, we can't say for sure that users want 5.6% performance
improvement even if the code is insecure.

These days, I think that most of the people want secure code and
probably they will disregard 5.6% performance degradation.

And so the code/specification should also change with changing times.

Some people (exceptions) may not want 5.6% performance degradation but
then we are satisfying the minority at the expense of the majority.

---------------
Point no. 2:
---------------

I am not saying to put "arbitrary limits" on the user. But reasonable
limits should be placed to save the user from getting hacked.

As an example, what should be a reasonable limit on qsort() function
as to how much data it will allow to be sorted - My opinion is that it
should be 5% of RAM (size_of_ram()/20). If the user wants more then
the user can change the code or write his/her own implementation. I
myself don't like how few functions of glibc are implemented, etc. so
I have implemented my own versions. I don't use those glibc functions,
I use my own implementations in all my projects.

Now, we can't give more than 5%. If we give more - like 10%, then
chances are there that other processes may not get desired memory.

And 5% is probably what most of the users would need.

This is a reasonable limit, in my opinion. If I write code, I will
give 5%, if the user is not happy, then the user can change/implement
on his/her own. """"But, in any case, I will not give the user any
insecure code.""""

But the point is that to satisfy a minority (who wants 10% of RAM or
more), why are we giving out insecure code to a majority of people?

Also, in my opinion, whether the code is ""low level or high level"",
the provider of the code should give secure code.

Also, the user of the code should also write secure code.

So, in my opinion, secure code is not the responsibility of only the
user, it is the responsibility of both the parties (provider of the
code and the user of the code).

Another point is that if some specification is not taking care of
security, then in my opinion, that specification is wrong.

As an aside, insecure code has led to loss of millions of dollars
(ransomware attacks, exposing users private data (SSNs), etc.).

Secure but slightly slower code (around 5% slower) will save millions
of dollars and also save lots of people/governments from lots of
trouble, etc.

Let's say that some hospital software got hacked because the code
provider didn't validate the inputs because he/she didn't want 5%
performance degradation. Now what will happen to the patients? What
will happen to those patients who were using medical machines and
these machines got hacked because 5% performance degradation was not
acceptable even if that resulted in insecure code (which ultimately
got hacked)?

----------------------------------------------------------

Powered by blists - more mailing lists