| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20190805115309.GJ2349@hirez.programming.kicks-ass.net>
Date: Mon, 5 Aug 2019 13:53:09 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Alessio Balsini <balsini@...roid.com>
Cc: mingo@...nel.org, juri.lelli@...hat.com,
linux-kernel@...r.kernel.org, dietmar.eggemann@....com,
luca.abeni@...tannapisa.it, bristot@...hat.com, dvyukov@...gle.com,
tglx@...utronix.de, vpillai@...italocean.com, rostedt@...dmis.org
Subject: Re: [RFC][PATCH 01/13] sched/deadline: Impose global limits on
sched_attr::sched_period
On Fri, Aug 02, 2019 at 06:21:04PM +0100, Alessio Balsini wrote:
> Hi Peter,
>
> This is indeed an important missing piece.
>
> I think it would be worth having some simple checks, e.g.:
> - period_min <= period_max;
> - period_min >= (1ULL << DL_SCALE).
>
> To be even more picky, I'm wondering if it would be a good practice to
> fail the write operation if there are already dl-tasks in the system
> that violate the new constraint. I'm afraid there is no cheap way of
> achieving such check, so, I think we can skip this last tricky thing for
> now.
Like so?
---
Subject: sched/deadline: Impose global limits on sched_attr::sched_period
From: Peter Zijlstra <peterz@...radead.org>
Date: Tue Jul 23 16:01:29 CEST 2019
There are two DoS scenarios with SCHED_DEADLINE related to
sched_attr::sched_period:
- since access-control only looks at utilization and density, a very
large period can allow a very large runtime, which in turn can
incur a very large latency to lower priority tasks.
- for very short periods we can end up spending more time programming
the hardware timer than actually running the task.
Mitigate these by imposing limits on the period.
Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
Cc: Daniel Bristot de Oliveira <bristot@...hat.com>
Cc: Luca Abeni <luca.abeni@...tannapisa.it>
Cc: Juri Lelli <juri.lelli@...hat.com>
Cc: Dmitry Vyukov <dvyukov@...gle.com>
---
include/linux/sched/sysctl.h | 7 ++++
kernel/sched/deadline.c | 61 +++++++++++++++++++++++++++++++++++++++++--
kernel/sysctl.c | 14 +++++++++
3 files changed, 80 insertions(+), 2 deletions(-)
--- a/include/linux/sched/sysctl.h
+++ b/include/linux/sched/sysctl.h
@@ -56,6 +56,13 @@ int sched_proc_update_handler(struct ctl
extern unsigned int sysctl_sched_rt_period;
extern int sysctl_sched_rt_runtime;
+extern unsigned int sysctl_sched_dl_period_max;
+extern unsigned int sysctl_sched_dl_period_min;
+
+extern int sched_dl_period_handler(struct ctl_table *table, int write,
+ void __user *buffer, size_t *lenp,
+ loff_t *ppos);
+
#ifdef CONFIG_UCLAMP_TASK
extern unsigned int sysctl_sched_uclamp_util_min;
extern unsigned int sysctl_sched_uclamp_util_max;
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -2660,6 +2660,52 @@ void __getparam_dl(struct task_struct *p
}
/*
+ * Default limits for DL period; on the top end we guard against small util
+ * tasks still getting ridiculous long effective runtimes, on the bottom end we
+ * guard against timer DoS.
+ */
+unsigned int sysctl_sched_dl_period_max = 1 << 22; /* ~4 seconds */
+unsigned int sysctl_sched_dl_period_min = 100; /* 100 us */
+
+int sched_dl_period_handler(struct ctl_table *table, int write,
+ void __user *buffer, size_t *lenp,
+ loff_t *ppos)
+{
+ unsigned int old_min, old_max;
+ static DEFINE_MUTEX(mutex);
+ int ret;
+
+ mutex_lock(&mutex);
+ old_min = sysctl_sched_dl_period_min;
+ old_max = sysctl_sched_dl_period_max;
+
+ ret = proc_dointvec(table, write, buffer, lenp, ppos);
+
+ if (!ret && write) {
+ u64 min = (u64)sysctl_sched_dl_period_min * NSEC_PER_USEC;
+ u64 max = (u64)sysctl_sched_dl_period_man * NSEC_PER_USEC;
+
+ ret = -EINVAL;
+ if (min < 1ULL << DL_SCALE)
+ goto undo;
+
+ if (max < min)
+ goto undo;
+
+ ret = 0;
+ }
+
+ if (0) {
+undo:
+ sysctl_sched_rt_period = old_period;
+ sysctl_sched_rt_runtime = old_runtime;
+ }
+ mutex_unlock(&mutex);
+
+ return ret;
+}
+
+/*
* This function validates the new parameters of a -deadline task.
* We ask for the deadline not being zero, and greater or equal
* than the runtime, as well as the period of being zero or
@@ -2671,6 +2717,8 @@ void __getparam_dl(struct task_struct *p
*/
bool __checkparam_dl(const struct sched_attr *attr)
{
+ u64 period, max, min;
+
/* special dl tasks don't actually use any parameter */
if (attr->sched_flags & SCHED_FLAG_SUGOV)
return true;
@@ -2694,12 +2742,21 @@ bool __checkparam_dl(const struct sched_
attr->sched_period & (1ULL << 63))
return false;
+ period = attr->sched_period;
+ if (!period)
+ period = attr->sched_deadline;
+
/* runtime <= deadline <= period (if period != 0) */
- if ((attr->sched_period != 0 &&
- attr->sched_period < attr->sched_deadline) ||
+ if (period < attr->sched_deadline ||
attr->sched_deadline < attr->sched_runtime)
return false;
+ max = (u64)READ_ONCE(sysctl_sched_dl_period_max) * NSEC_PER_USEC;
+ min = (u64)READ_ONCE(sysctl_sched_dl_period_min) * NSEC_PER_USEC;
+
+ if (period < min || period > max)
+ return false;
+
return true;
}
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -443,6 +443,20 @@ static struct ctl_table kern_table[] = {
.proc_handler = sched_rt_handler,
},
{
+ .procname = "sched_deadline_period_max_us",
+ .data = &sysctl_sched_dl_period_max,
+ .maxlen = sizeof(unsigned int),
+ .mode = 0644,
+ .proc_handler = sched_dl_period_handler,
+ },
+ {
+ .procname = "sched_deadline_period_min_us",
+ .data = &sysctl_sched_dl_period_min,
+ .maxlen = sizeof(unsigned int),
+ .mode = 0644,
+ .proc_handler = sched_dl_period_handler,
+ },
+ {
.procname = "sched_rr_timeslice_ms",
.data = &sysctl_sched_rr_timeslice,
.maxlen = sizeof(int),
Powered by blists - more mailing lists