* Re: Re: [PATCH v3 05/20] selftests/ftrace: add install target to enable test install
From: Masami Hiramatsu @ 2015-01-04 5:29 UTC (permalink / raw)
To: Steven Rostedt
Cc: Shuah Khan, mmarek, gregkh, akpm, mingo, davem, keescook,
tranmanphong, mpe, cov, dh.herrmann, hughd, bobby.prani,
serge.hallyn, ebiederm, tim.bird, josh, koct9i, linux-kbuild,
linux-kernel, linux-api, netdev, yrl.pp-manager.tt@hitachi.com
In-Reply-To: <20150102104526.29df5641@gandalf.local.home>
(2015/01/03 0:45), Steven Rostedt wrote:
> On Wed, 24 Dec 2014 09:27:41 -0700
> Shuah Khan <shuahkh@osg.samsung.com> wrote:
>
>> Add a new make target to enable installing test. This target
>> installs test in the kselftest install location and add to the
>> kselftest script to run the test. Install target can be run
>> only from top level kernel source directory.
>>
>> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
>> ---
>> tools/testing/selftests/ftrace/Makefile | 11 ++++++++++-
>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/testing/selftests/ftrace/Makefile b/tools/testing/selftests/ftrace/Makefile
>> index 76cc9f1..7c7cf42 100644
>> --- a/tools/testing/selftests/ftrace/Makefile
>> +++ b/tools/testing/selftests/ftrace/Makefile
>> @@ -1,7 +1,16 @@
>> +TEST_STR = /bin/sh ./ftracetest || echo ftrace selftests: [FAIL]
>
> Is it ok that this removes the quotes around the echo string? I don't
> see anything wrong about it, but I don't know if there's a shell out
> there that will fail due to it.
Agreed, if possible, we'd better add quotes around the echo string
as you did in 2/20 in this series.
Anyway, you can also add my ack to this patch.
Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Thank you!
>
> Other than than,
>
> Acked-by: Steven Rostedt <rostedt@goodmis.org>
>
> -- Steve
>
>
>> +
>> all:
>>
>> +install:
>> +ifdef INSTALL_KSFT_PATH
>> + install ./ftracetest $(INSTALL_KSFT_PATH)
>> + @cp -r test.d $(INSTALL_KSFT_PATH)
>> + echo "$(TEST_STR)" >> $(KSELFTEST)
>> +endif
>> +
>> run_tests:
>> - @/bin/sh ./ftracetest || echo "ftrace selftests: [FAIL]"
>> + @$(TEST_STR)
>>
>> clean:
>> rm -rf logs/*
>
> --
> 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/
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
^ permalink raw reply
* Re: Re: [PATCH v3 05/20] selftests/ftrace: add install target to enable test install
From: Masami Hiramatsu @ 2015-01-04 5:18 UTC (permalink / raw)
To: Steven Rostedt
Cc: Shuah Khan, mmarek-AlSwsSmVLrQ,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
mingo-H+wXaHxf7aLQT0dZR+AlfA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
keescook-F7+t8E8rja9g9hUCZPvPmw,
tranmanphong-Re5JQEeQqe8AvxtiuMwx3w, mpe-Gsx/Oe8HsFggBc27wqDAHg,
cov-sgV2jX0FEOL9JmXXK+q4OQ, dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w,
hughd-hpIqsD4AKlfQT0dZR+AlfA, bobby.prani-Re5JQEeQqe8AvxtiuMwx3w,
serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, tim.bird-/MT0OVThwyLZJqsBc5GL+g,
josh-iaAMLnmF4UmaiuxdJuQwMA, koct9i-Re5JQEeQqe8AvxtiuMwx3w,
linux-kbuild-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150102104526.29df5641-f9ZlEuEWxVcJvu8Pb33WZ0EMvNT87kid@public.gmane.org>
(2015/01/03 0:45), Steven Rostedt wrote:
> On Wed, 24 Dec 2014 09:27:41 -0700
> Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
>
>> Add a new make target to enable installing test. This target
>> installs test in the kselftest install location and add to the
>> kselftest script to run the test. Install target can be run
>> only from top level kernel source directory.
>>
>> Signed-off-by: Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
>> ---
>> tools/testing/selftests/ftrace/Makefile | 11 ++++++++++-
>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/testing/selftests/ftrace/Makefile b/tools/testing/selftests/ftrace/Makefile
>> index 76cc9f1..7c7cf42 100644
>> --- a/tools/testing/selftests/ftrace/Makefile
>> +++ b/tools/testing/selftests/ftrace/Makefile
>> @@ -1,7 +1,16 @@
>> +TEST_STR = /bin/sh ./ftracetest || echo ftrace selftests: [FAIL]
>
> Is it ok that this removes the quotes around the echo string? I don't
> see anything wrong about it, but I don't know if there's a shell out
> there that will fail due to it.
Agreed, if possible, we'd better add quotes around the echo string
as you did in 2/20 in this series.
Anyway, you can also add my ack to this patch.
Acked-by: Masami Hiramatsu <masami.hiramatsu.pt-FCd8Q96Dh0JBDgjK7y7TUQ@public.gmane.org>
Thank you!
>
> Other than than,
>
> Acked-by: Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>
>
> -- Steve
>
>
>> +
>> all:
>>
>> +install:
>> +ifdef INSTALL_KSFT_PATH
>> + install ./ftracetest $(INSTALL_KSFT_PATH)
>> + @cp -r test.d $(INSTALL_KSFT_PATH)
>> + echo "$(TEST_STR)" >> $(KSELFTEST)
>> +endif
>> +
>> run_tests:
>> - @/bin/sh ./ftracetest || echo "ftrace selftests: [FAIL]"
>> + @$(TEST_STR)
>>
>> clean:
>> rm -rf logs/*
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt-FCd8Q96Dh0JBDgjK7y7TUQ@public.gmane.org
^ permalink raw reply
* Re: [PATCH 1/7] tuner-core: properly initialize media controller subdev
From: Sakari Ailus @ 2015-01-04 0:39 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Laurent Pinchart
Cc: Linux Media Mailing List, Mauro Carvalho Chehab, Hans Verkuil,
Prabhakar Lad, linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4ff2de5fce002a6f6f87993440f45e0f198c57cb.1420315245.git.mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
Hi Mauro,
Mauro Carvalho Chehab wrote:
> Properly initialize tuner core subdev at the media controller.
>
> That requires a new subtype at the media controller API.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
>
> diff --git a/drivers/media/v4l2-core/tuner-core.c b/drivers/media/v4l2-core/tuner-core.c
> index 559f8372e2eb..114715ed0110 100644
> --- a/drivers/media/v4l2-core/tuner-core.c
> +++ b/drivers/media/v4l2-core/tuner-core.c
> @@ -134,6 +134,9 @@ struct tuner {
> unsigned int type; /* chip type id */
> void *config;
> const char *name;
> +#if defined(CONFIG_MEDIA_CONTROLLER)
> + struct media_pad pad;
> +#endif
> };
>
> /*
> @@ -434,6 +437,8 @@ static void set_type(struct i2c_client *c, unsigned int type,
> t->name = analog_ops->info.name;
> }
>
> + t->sd.entity.name = t->name;
> +
> tuner_dbg("type set to %s\n", t->name);
>
> t->mode_mask = new_mode_mask;
> @@ -592,6 +597,7 @@ static int tuner_probe(struct i2c_client *client,
> struct tuner *t;
> struct tuner *radio;
> struct tuner *tv;
> + int ret;
This will emit a compiler warning if CONFIG_MEDIA_CONTROLLER isn't defined.
> t = kzalloc(sizeof(struct tuner), GFP_KERNEL);
> if (NULL == t)
> @@ -696,6 +702,15 @@ register_client:
> t->type,
> t->mode_mask & T_RADIO ? " Radio" : "",
> t->mode_mask & T_ANALOG_TV ? " TV" : "");
> +#if defined(CONFIG_MEDIA_CONTROLLER)
> + t->pad.flags = MEDIA_PAD_FL_SOURCE;
> + t->sd.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_TUNER;
> + t->sd.entity.name = t->name;
> +
> + ret = media_entity_init(&t->sd.entity, 1, &t->pad, 0);
> + if (ret < 0)
> + tuner_err("failed to initialize media entity!\n");
I might return the error back to the caller. The failing initialisation
of a media entity itself might not be a fatal problem, but someone later
assuming it has been initialised might be.
> +#endif
> return 0;
> }
>
> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> index 707db275f92b..5ffde035789b 100644
> --- a/include/uapi/linux/media.h
> +++ b/include/uapi/linux/media.h
> @@ -66,6 +66,8 @@ struct media_device_info {
> /* A converter of analogue video to its digital representation. */
> #define MEDIA_ENT_T_V4L2_SUBDEV_DECODER (MEDIA_ENT_T_V4L2_SUBDEV + 4)
>
> +#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER (MEDIA_ENT_T_V4L2_SUBDEV + 5)
> +
> #define MEDIA_ENT_FL_DEFAULT (1 << 0)
>
> struct media_entity_desc {
>
--
Kind regards,
Sakari Ailus
sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org
^ permalink raw reply
* [PATCH 1/7] tuner-core: properly initialize media controller subdev
From: Mauro Carvalho Chehab @ 2015-01-03 20:09 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Hans Verkuil, Prabhakar Lad, Sakari Ailus,
linux-api
In-Reply-To: <cover.1420315245.git.mchehab@osg.samsung.com>
Properly initialize tuner core subdev at the media controller.
That requires a new subtype at the media controller API.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
diff --git a/drivers/media/v4l2-core/tuner-core.c b/drivers/media/v4l2-core/tuner-core.c
index 559f8372e2eb..114715ed0110 100644
--- a/drivers/media/v4l2-core/tuner-core.c
+++ b/drivers/media/v4l2-core/tuner-core.c
@@ -134,6 +134,9 @@ struct tuner {
unsigned int type; /* chip type id */
void *config;
const char *name;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ struct media_pad pad;
+#endif
};
/*
@@ -434,6 +437,8 @@ static void set_type(struct i2c_client *c, unsigned int type,
t->name = analog_ops->info.name;
}
+ t->sd.entity.name = t->name;
+
tuner_dbg("type set to %s\n", t->name);
t->mode_mask = new_mode_mask;
@@ -592,6 +597,7 @@ static int tuner_probe(struct i2c_client *client,
struct tuner *t;
struct tuner *radio;
struct tuner *tv;
+ int ret;
t = kzalloc(sizeof(struct tuner), GFP_KERNEL);
if (NULL == t)
@@ -696,6 +702,15 @@ register_client:
t->type,
t->mode_mask & T_RADIO ? " Radio" : "",
t->mode_mask & T_ANALOG_TV ? " TV" : "");
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ t->pad.flags = MEDIA_PAD_FL_SOURCE;
+ t->sd.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_TUNER;
+ t->sd.entity.name = t->name;
+
+ ret = media_entity_init(&t->sd.entity, 1, &t->pad, 0);
+ if (ret < 0)
+ tuner_err("failed to initialize media entity!\n");
+#endif
return 0;
}
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 707db275f92b..5ffde035789b 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -66,6 +66,8 @@ struct media_device_info {
/* A converter of analogue video to its digital representation. */
#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER (MEDIA_ENT_T_V4L2_SUBDEV + 4)
+#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER (MEDIA_ENT_T_V4L2_SUBDEV + 5)
+
#define MEDIA_ENT_FL_DEFAULT (1 << 0)
struct media_entity_desc {
--
2.1.0
^ permalink raw reply related
* [PATCHv2 2/9] media: add new types for DVB devnodes
From: Mauro Carvalho Chehab @ 2015-01-03 14:49 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cover.1420294938.git.mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
Most of the DVB subdevs have already their own devnode.
Add support for them at the media controller API.
Signed-off-by: Mauro Carvalho Chehab <mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 7902e800f019..707db275f92b 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -50,7 +50,14 @@ struct media_device_info {
#define MEDIA_ENT_T_DEVNODE_V4L (MEDIA_ENT_T_DEVNODE + 1)
#define MEDIA_ENT_T_DEVNODE_FB (MEDIA_ENT_T_DEVNODE + 2)
#define MEDIA_ENT_T_DEVNODE_ALSA (MEDIA_ENT_T_DEVNODE + 3)
-#define MEDIA_ENT_T_DEVNODE_DVB (MEDIA_ENT_T_DEVNODE + 4)
+#define MEDIA_ENT_T_DEVNODE_DVB_FE (MEDIA_ENT_T_DEVNODE + 4)
+#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX (MEDIA_ENT_T_DEVNODE + 5)
+#define MEDIA_ENT_T_DEVNODE_DVB_DVR (MEDIA_ENT_T_DEVNODE + 6)
+#define MEDIA_ENT_T_DEVNODE_DVB_CA (MEDIA_ENT_T_DEVNODE + 7)
+#define MEDIA_ENT_T_DEVNODE_DVB_NET (MEDIA_ENT_T_DEVNODE + 8)
+
+/* Legacy symbol. Use it to avoid userspace compilation breakages */
+#define MEDIA_ENT_T_DEVNODE_DVB MEDIA_ENT_T_DEVNODE_DVB_FE
#define MEDIA_ENT_T_V4L2_SUBDEV (2 << MEDIA_ENT_TYPE_SHIFT)
#define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR (MEDIA_ENT_T_V4L2_SUBDEV + 1)
--
2.1.0
^ permalink raw reply related
* [PATCHv2 1/9] media: Fix DVB representation at media controller API
From: Mauro Carvalho Chehab @ 2015-01-03 14:49 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, linux-api
In-Reply-To: <cover.1420294938.git.mchehab@osg.samsung.com>
The DVB devices are identified via a (major, minor) tuple,
and not by a random id. Fix it, before we start using it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index e00459185d20..de333cc8261b 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -97,7 +97,10 @@ struct media_entity {
u32 device;
u32 subdevice;
} alsa;
- int dvb;
+ struct {
+ u32 major;
+ u32 minor;
+ } dvb;
/* Sub-device specifications */
/* Nothing needed yet */
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index d847c760e8f0..7902e800f019 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -27,7 +27,7 @@
#include <linux/types.h>
#include <linux/version.h>
-#define MEDIA_API_VERSION KERNEL_VERSION(0, 1, 0)
+#define MEDIA_API_VERSION KERNEL_VERSION(0, 1, 1)
struct media_device_info {
char driver[16];
@@ -88,7 +88,10 @@ struct media_entity_desc {
__u32 device;
__u32 subdevice;
} alsa;
- int dvb;
+ struct {
+ __u32 major;
+ __u32 minor;
+ } dvb;
/* Sub-device specifications */
/* Nothing needed yet */
--
2.1.0
^ permalink raw reply related
* [PATCH 2/7] dvb core: add support for media controller at dvbdev
From: Mauro Carvalho Chehab @ 2015-01-03 2:04 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cover.1420250453.git.mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
Provide a way to register media controller device nodes
at the DVB core.
Please notice that the dvbdev callers also require changes
for the devices to be registered via the media controller.
Signed-off-by: Mauro Carvalho Chehab <mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c
index 983db75de350..464a457e7527 100644
--- a/drivers/media/dvb-core/dvbdev.c
+++ b/drivers/media/dvb-core/dvbdev.c
@@ -180,6 +180,59 @@ skip:
return -ENFILE;
}
+static void dvb_register_media_device(struct dvb_device *dvbdev,
+ int type, int minor)
+{
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ int ret;
+
+ if (!dvbdev->mdev)
+ return;
+
+ dvbdev->entity = kzalloc(sizeof(*dvbdev->entity), GFP_KERNEL);
+ if (!dvbdev->entity)
+ return;
+
+ dvbdev->entity->type = MEDIA_ENT_T_DEVNODE_DVB;
+ dvbdev->entity->info.dvb.major = DVB_MAJOR;
+ dvbdev->entity->info.dvb.minor = minor;
+ dvbdev->entity->name = dvbdev->name;
+ switch(type) {
+ case DVB_DEVICE_FRONTEND:
+ dvbdev->entity->flags = MEDIA_ENT_T_DVB_FE;
+ break;
+ case DVB_DEVICE_DEMUX:
+ dvbdev->entity->flags = MEDIA_ENT_T_DVB_DEMUX;
+ break;
+ case DVB_DEVICE_DVR:
+ dvbdev->entity->flags = MEDIA_ENT_T_DVB_DVR;
+ break;
+ case DVB_DEVICE_CA:
+ dvbdev->entity->flags = MEDIA_ENT_T_DVB_CA;
+ break;
+ case DVB_DEVICE_NET:
+ dvbdev->entity->flags = MEDIA_ENT_T_DVB_NET;
+ break;
+ default:
+ kfree(dvbdev->entity);
+ dvbdev->entity = NULL;
+ return;
+ }
+
+ ret = media_device_register_entity(dvbdev->mdev, dvbdev->entity);
+ if (ret < 0) {
+ printk(KERN_ERR
+ "%s: media_device_register_entity failed for %s\n",
+ __func__, dvbdev->entity->name);
+ kfree(dvbdev->entity);
+ dvbdev->entity = NULL;
+ return;
+ }
+
+ printk(KERN_DEBUG "%s: media device '%s' registered.\n",
+ __func__, dvbdev->entity->name);
+#endif
+}
int dvb_register_device(struct dvb_adapter *adap, struct dvb_device **pdvbdev,
const struct dvb_device *template, void *priv, int type)
@@ -258,10 +311,11 @@ int dvb_register_device(struct dvb_adapter *adap, struct dvb_device **pdvbdev,
__func__, adap->num, dnames[type], id, PTR_ERR(clsdev));
return PTR_ERR(clsdev);
}
-
dprintk(KERN_DEBUG "DVB: register adapter%d/%s%d @ minor: %i (0x%02x)\n",
adap->num, dnames[type], id, minor, minor);
+ dvb_register_media_device(dvbdev, type, minor);
+
return 0;
}
EXPORT_SYMBOL(dvb_register_device);
@@ -278,6 +332,13 @@ void dvb_unregister_device(struct dvb_device *dvbdev)
device_destroy(dvb_class, MKDEV(DVB_MAJOR, dvbdev->minor));
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ if (dvbdev->entity) {
+ media_device_unregister_entity(dvbdev->entity);
+ kfree(dvbdev->entity);
+ }
+#endif
+
list_del (&dvbdev->list_head);
kfree (dvbdev->fops);
kfree (dvbdev);
diff --git a/drivers/media/dvb-core/dvbdev.h b/drivers/media/dvb-core/dvbdev.h
index f96b28e7fc95..f58dfef46984 100644
--- a/drivers/media/dvb-core/dvbdev.h
+++ b/drivers/media/dvb-core/dvbdev.h
@@ -27,6 +27,7 @@
#include <linux/poll.h>
#include <linux/fs.h>
#include <linux/list.h>
+#include <media/media-device.h>
#define DVB_MAJOR 212
@@ -92,6 +93,15 @@ struct dvb_device {
/* don't really need those !? -- FIXME: use video_usercopy */
int (*kernel_ioctl)(struct file *file, unsigned int cmd, void *arg);
+ /* Needed for media controller register/unregister */
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ struct media_device *mdev;
+ const char *name;
+
+ /* Filled inside dvbdev.c */
+ struct media_entity *entity;
+#endif
+
void *priv;
};
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 7902e800f019..cdb6946d315e 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -59,6 +59,12 @@ struct media_device_info {
/* A converter of analogue video to its digital representation. */
#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER (MEDIA_ENT_T_V4L2_SUBDEV + 4)
+#define MEDIA_ENT_T_DVB_FE (MEDIA_ENT_T_V4L2_SUBDEV + 5)
+#define MEDIA_ENT_T_DVB_DEMUX (MEDIA_ENT_T_V4L2_SUBDEV + 6)
+#define MEDIA_ENT_T_DVB_DVR (MEDIA_ENT_T_V4L2_SUBDEV + 7)
+#define MEDIA_ENT_T_DVB_CA (MEDIA_ENT_T_V4L2_SUBDEV + 8)
+#define MEDIA_ENT_T_DVB_NET (MEDIA_ENT_T_V4L2_SUBDEV + 9)
+
#define MEDIA_ENT_FL_DEFAULT (1 << 0)
struct media_entity_desc {
--
2.1.0
^ permalink raw reply related
* [PATCH 1/7] media: Fix DVB representation at media controller API
From: Mauro Carvalho Chehab @ 2015-01-03 2:04 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, linux-api
In-Reply-To: <cover.1420250453.git.mchehab@osg.samsung.com>
The DVB devices are identified via a (major, minor) tuple,
and not by a random id. Fix it, before we start using it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index e00459185d20..de333cc8261b 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -97,7 +97,10 @@ struct media_entity {
u32 device;
u32 subdevice;
} alsa;
- int dvb;
+ struct {
+ u32 major;
+ u32 minor;
+ } dvb;
/* Sub-device specifications */
/* Nothing needed yet */
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index d847c760e8f0..7902e800f019 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -27,7 +27,7 @@
#include <linux/types.h>
#include <linux/version.h>
-#define MEDIA_API_VERSION KERNEL_VERSION(0, 1, 0)
+#define MEDIA_API_VERSION KERNEL_VERSION(0, 1, 1)
struct media_device_info {
char driver[16];
@@ -88,7 +88,10 @@ struct media_entity_desc {
__u32 device;
__u32 subdevice;
} alsa;
- int dvb;
+ struct {
+ __u32 major;
+ __u32 minor;
+ } dvb;
/* Sub-device specifications */
/* Nothing needed yet */
--
2.1.0
^ permalink raw reply related
* Re: [PATCH v3 05/20] selftests/ftrace: add install target to enable test install
From: Steven Rostedt @ 2015-01-02 15:45 UTC (permalink / raw)
To: Shuah Khan
Cc: mmarek, gregkh, akpm, mingo, davem, keescook, tranmanphong, mpe,
cov, dh.herrmann, hughd, bobby.prani, serge.hallyn, ebiederm,
tim.bird, josh, koct9i, linux-kbuild, linux-kernel, linux-api,
netdev
In-Reply-To: <e84eeeecde70ecb3ab82c5f825fec359f9e967ff.1419387513.git.shuahkh@osg.samsung.com>
On Wed, 24 Dec 2014 09:27:41 -0700
Shuah Khan <shuahkh@osg.samsung.com> wrote:
> Add a new make target to enable installing test. This target
> installs test in the kselftest install location and add to the
> kselftest script to run the test. Install target can be run
> only from top level kernel source directory.
>
> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
> ---
> tools/testing/selftests/ftrace/Makefile | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/ftrace/Makefile b/tools/testing/selftests/ftrace/Makefile
> index 76cc9f1..7c7cf42 100644
> --- a/tools/testing/selftests/ftrace/Makefile
> +++ b/tools/testing/selftests/ftrace/Makefile
> @@ -1,7 +1,16 @@
> +TEST_STR = /bin/sh ./ftracetest || echo ftrace selftests: [FAIL]
Is it ok that this removes the quotes around the echo string? I don't
see anything wrong about it, but I don't know if there's a shell out
there that will fail due to it.
Other than than,
Acked-by: Steven Rostedt <rostedt@goodmis.org>
-- Steve
> +
> all:
>
> +install:
> +ifdef INSTALL_KSFT_PATH
> + install ./ftracetest $(INSTALL_KSFT_PATH)
> + @cp -r test.d $(INSTALL_KSFT_PATH)
> + echo "$(TEST_STR)" >> $(KSELFTEST)
> +endif
> +
> run_tests:
> - @/bin/sh ./ftracetest || echo "ftrace selftests: [FAIL]"
> + @$(TEST_STR)
>
> clean:
> rm -rf logs/*
^ permalink raw reply
* [PATCH v7 2/2] crypto: AF_ALG: enable AEAD interface compilation
From: Stephan Mueller @ 2015-01-02 14:42 UTC (permalink / raw)
To: 'Herbert Xu'
Cc: Daniel Borkmann, 'Quentin Gouchet', linux-kernel,
linux-crypto, ABI/API
In-Reply-To: <6964260.mNa1jtPz7Z@tachyon.chronox.de>
Enable compilation of the AEAD AF_ALG support and provide a Kconfig
option to compile the AEAD AF_ALG support.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
crypto/Kconfig | 9 +++++++++
crypto/Makefile | 1 +
2 files changed, 10 insertions(+)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 50f4da4..41a3fc5 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1523,6 +1523,15 @@ config CRYPTO_USER_API_RNG
This option enables the user-spaces interface for random
number generator algorithms.
+config CRYPTO_USER_API_AEAD
+ tristate "User-space interface for AEAD cipher algorithms"
+ depends on NET
+ select CRYPTO_AEAD
+ select CRYPTO_USER_API
+ help
+ This option enables the user-spaces interface for AEAD
+ cipher algorithms.
+
config CRYPTO_HASH_INFO
bool
diff --git a/crypto/Makefile b/crypto/Makefile
index ba19465..97b7d3a 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -100,6 +100,7 @@ obj-$(CONFIG_CRYPTO_USER_API) += af_alg.o
obj-$(CONFIG_CRYPTO_USER_API_HASH) += algif_hash.o
obj-$(CONFIG_CRYPTO_USER_API_SKCIPHER) += algif_skcipher.o
obj-$(CONFIG_CRYPTO_USER_API_RNG) += algif_rng.o
+obj-$(CONFIG_CRYPTO_USER_API_AEAD) += algif_aead.o
#
# generic algorithms and the async_tx api
--
2.1.0
^ permalink raw reply related
* [PATCH v7 1/2] crypto: AF_ALG: add AEAD support
From: Stephan Mueller @ 2015-01-02 14:41 UTC (permalink / raw)
To: 'Herbert Xu'
Cc: Daniel Borkmann, 'Quentin Gouchet', linux-kernel,
linux-crypto, ABI/API
In-Reply-To: <6964260.mNa1jtPz7Z@tachyon.chronox.de>
This patch adds the AEAD support for AF_ALG.
The implementation is based on algif_skcipher, but contains heavy
modifications to streamline the interface for AEAD uses.
To use AEAD, the user space consumer has to use the salg_type named
"aead".
The AEAD implementation includes some overhead to calculate the size of
the ciphertext, because the AEAD implementation of the kernel crypto API
makes implied assumption on the location of the authentication tag. When
performing an encryption, the tag will be added to the created
ciphertext (note, the tag is placed adjacent to the ciphertext). For
decryption, the caller must hand in the ciphertext with the tag appended
to the ciphertext. Therefore, the selection of the used memory
needs to add/subtract the tag size from the source/destination buffers
depending on the encryption type. The code is provided with comments
explaining when and how that operation is performed.
A fully working example using all aspects of AEAD is provided at
http://www.chronox.de/libkcapi.html
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
crypto/algif_aead.c | 631 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 631 insertions(+)
create mode 100644 crypto/algif_aead.c
diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
new file mode 100644
index 0000000..c461266
--- /dev/null
+++ b/crypto/algif_aead.c
@@ -0,0 +1,631 @@
+/*
+ * algif_aeadr: User-space interface for AEAD algorithms
+ *
+ * Copyright (C) 2014, Stephan Mueller <smueller@chronox.de>
+ *
+ * This file provides the user-space API for AEAD ciphers.
+ *
+ * This file is derived from algif_skcipher.c.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ */
+
+#include <crypto/scatterwalk.h>
+#include <crypto/if_alg.h>
+#include <linux/init.h>
+#include <linux/list.h>
+#include <linux/kernel.h>
+#include <linux/mm.h>
+#include <linux/module.h>
+#include <linux/net.h>
+#include <net/sock.h>
+
+struct aead_sg_list {
+ unsigned int cur;
+ struct scatterlist sg[ALG_MAX_PAGES];
+};
+
+struct aead_ctx {
+ struct aead_sg_list tsgl;
+ struct af_alg_sgl rsgl;
+
+ void *iv;
+
+ struct af_alg_completion completion;
+
+ unsigned long used;
+
+ unsigned int len;
+ bool more;
+ bool merge;
+ bool enc;
+
+ size_t aead_assoclen;
+ struct aead_request aead_req;
+};
+
+static inline int aead_sndbuf(struct sock *sk)
+{
+ struct alg_sock *ask = alg_sk(sk);
+ struct aead_ctx *ctx = ask->private;
+
+ return max_t(int, max_t(int, sk->sk_sndbuf & PAGE_MASK, PAGE_SIZE) -
+ ctx->used, 0);
+}
+
+static inline bool aead_writable(struct sock *sk)
+{
+ return PAGE_SIZE <= aead_sndbuf(sk);
+}
+
+static void aead_put_sgl(struct sock *sk)
+{
+ struct alg_sock *ask = alg_sk(sk);
+ struct aead_ctx *ctx = ask->private;
+ struct aead_sg_list *sgl = &ctx->tsgl;
+ struct scatterlist *sg = sgl->sg;
+ unsigned int i;
+
+ for (i = 0; i < sgl->cur; i++) {
+ if (!sg_page(sg + i))
+ continue;
+
+ put_page(sg_page(sg + i));
+ sg_assign_page(sg + i, NULL);
+ }
+ sgl->cur = 0;
+ ctx->used = 0;
+ ctx->more = 0;
+ ctx->merge = 0;
+}
+
+static int aead_wait_for_wmem(struct sock *sk, unsigned flags)
+{
+ long timeout;
+ DEFINE_WAIT(wait);
+ int err = -ERESTARTSYS;
+
+ if (flags & MSG_DONTWAIT)
+ return -EAGAIN;
+
+ set_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags);
+
+ for (;;) {
+ if (signal_pending(current))
+ break;
+ prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
+ timeout = MAX_SCHEDULE_TIMEOUT;
+ if (sk_wait_event(sk, &timeout, aead_writable(sk))) {
+ err = 0;
+ break;
+ }
+ }
+ finish_wait(sk_sleep(sk), &wait);
+
+ return err;
+}
+
+static void aead_wmem_wakeup(struct sock *sk)
+{
+ struct socket_wq *wq;
+
+ if (!aead_writable(sk))
+ return;
+
+ rcu_read_lock();
+ wq = rcu_dereference(sk->sk_wq);
+ if (wq_has_sleeper(wq))
+ wake_up_interruptible_sync_poll(&wq->wait, POLLIN |
+ POLLRDNORM |
+ POLLRDBAND);
+ sk_wake_async(sk, SOCK_WAKE_WAITD, POLL_IN);
+ rcu_read_unlock();
+}
+
+static int aead_wait_for_data(struct sock *sk, unsigned flags)
+{
+ struct alg_sock *ask = alg_sk(sk);
+ struct aead_ctx *ctx = ask->private;
+ long timeout;
+ DEFINE_WAIT(wait);
+ int err = -ERESTARTSYS;
+
+ if (flags & MSG_DONTWAIT) {
+ return -EAGAIN;
+ }
+
+ set_bit(SOCK_ASYNC_WAITDATA, &sk->sk_socket->flags);
+
+ for (;;) {
+ if (signal_pending(current))
+ break;
+ prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
+ timeout = MAX_SCHEDULE_TIMEOUT;
+ if (sk_wait_event(sk, &timeout, !ctx->more)) {
+ err = 0;
+ break;
+ }
+ }
+ finish_wait(sk_sleep(sk), &wait);
+
+ clear_bit(SOCK_ASYNC_WAITDATA, &sk->sk_socket->flags);
+
+ return err;
+}
+
+static void aead_data_wakeup(struct sock *sk)
+{
+ struct alg_sock *ask = alg_sk(sk);
+ struct aead_ctx *ctx = ask->private;
+ struct socket_wq *wq;
+
+ if (ctx->more)
+ return;
+
+ rcu_read_lock();
+ wq = rcu_dereference(sk->sk_wq);
+ if (wq_has_sleeper(wq))
+ wake_up_interruptible_sync_poll(&wq->wait, POLLOUT |
+ POLLRDNORM |
+ POLLRDBAND);
+ sk_wake_async(sk, SOCK_WAKE_SPACE, POLL_OUT);
+ rcu_read_unlock();
+}
+
+static int aead_sendmsg(struct kiocb *unused, struct socket *sock,
+ struct msghdr *msg, size_t size)
+{
+ struct sock *sk = sock->sk;
+ struct alg_sock *ask = alg_sk(sk);
+ struct aead_ctx *ctx = ask->private;
+ unsigned ivsize =
+ crypto_aead_ivsize(crypto_aead_reqtfm(&ctx->aead_req));
+ struct aead_sg_list *sgl = &ctx->tsgl;
+ struct af_alg_control con = {};
+ long copied = 0;
+ bool enc = 0;
+ bool init = 0;
+ int err = -EINVAL;
+
+ if (msg->msg_controllen) {
+ err = af_alg_cmsg_send(msg, &con);
+ if (err)
+ return err;
+
+ init = 1;
+ switch (con.op) {
+ case ALG_OP_ENCRYPT:
+ enc = 1;
+ break;
+ case ALG_OP_DECRYPT:
+ enc = 0;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (con.iv && con.iv->ivlen != ivsize)
+ return -EINVAL;
+
+ if (!con.aead_assoclen)
+ return -EINVAL;
+
+ /* aead_recvmsg limits the maximum AD size to one page */
+ if (con.aead_assoclen > PAGE_SIZE)
+ return -E2BIG;
+ }
+
+ lock_sock(sk);
+ if (!ctx->more && ctx->used)
+ goto unlock;
+
+ if (init) {
+ ctx->enc = enc;
+ if (con.iv)
+ memcpy(ctx->iv, con.iv->iv, ivsize);
+
+ ctx->aead_assoclen = con.aead_assoclen;
+ }
+
+ while (size) {
+ unsigned long len = size;
+ struct scatterlist *sg = NULL;
+
+ if (ctx->merge) {
+ sg = sgl->sg + sgl->cur - 1;
+ len = min_t(unsigned long, len,
+ PAGE_SIZE - sg->offset - sg->length);
+ err = memcpy_from_msg(page_address(sg_page(sg)) +
+ sg->offset + sg->length,
+ msg, len);
+ if (err)
+ goto unlock;
+
+ sg->length += len;
+ ctx->merge = (sg->offset + sg->length) &
+ (PAGE_SIZE - 1);
+
+ ctx->used += len;
+ copied += len;
+ size -= len;
+ }
+
+ if (!aead_writable(sk)) {
+ /*
+ * If there is more data to be expected, but we cannot
+ * write more data, forcefully define that we do not
+ * expect more data to invoke the AEAD operation. This
+ * prevents a deadlock in user space.
+ */
+ ctx->more = 0;
+ err = aead_wait_for_wmem(sk, msg->msg_flags);
+ if (err)
+ goto unlock;
+ }
+
+ len = min_t(unsigned long, size, aead_sndbuf(sk));
+ while (len && sgl->cur < ALG_MAX_PAGES) {
+ int plen = 0;
+
+ sg = sgl->sg + sgl->cur;
+ plen = min_t(int, len, PAGE_SIZE);
+
+ if (sgl->cur >= ALG_MAX_PAGES) {
+ err = -E2BIG;
+ goto unlock;
+ }
+
+ sg_assign_page(sg, alloc_page(GFP_KERNEL));
+ err = -ENOMEM;
+ if (!sg_page(sg))
+ goto unlock;
+
+ err = memcpy_from_msg(page_address(sg_page(sg)),
+ msg, plen);
+ if (err) {
+ __free_page(sg_page(sg));
+ sg_assign_page(sg, NULL);
+ goto unlock;
+ }
+
+ sg->length = plen;
+ len -= plen;
+ ctx->used += plen;
+ copied += plen;
+ sgl->cur++;
+ size -= plen;
+ ctx->merge = plen & (PAGE_SIZE - 1);
+ }
+ }
+
+ err = 0;
+
+ ctx->more = msg->msg_flags & MSG_MORE;
+
+unlock:
+ aead_data_wakeup(sk);
+ release_sock(sk);
+
+ return copied ?: err;
+}
+
+static ssize_t aead_sendpage(struct socket *sock, struct page *page,
+ int offset, size_t size, int flags)
+{
+ struct sock *sk = sock->sk;
+ struct alg_sock *ask = alg_sk(sk);
+ struct aead_ctx *ctx = ask->private;
+ struct aead_sg_list *sgl = &ctx->tsgl;
+ int err = -EINVAL;
+
+ if (flags & MSG_SENDPAGE_NOTLAST)
+ flags |= MSG_MORE;
+
+ if (sgl->cur >= ALG_MAX_PAGES)
+ return -E2BIG;
+
+ lock_sock(sk);
+ if (!ctx->more && ctx->used)
+ goto unlock;
+
+ if (!size)
+ goto done;
+
+ if (!aead_writable(sk)) {
+ /* see aead_sendmsg why more is set to 0 */
+ ctx->more = 0;
+ err = aead_wait_for_wmem(sk, flags);
+ if (err)
+ goto unlock;
+ }
+
+ ctx->merge = 0;
+
+ get_page(page);
+ sg_set_page(sgl->sg + sgl->cur, page, size, offset);
+ sgl->cur++;
+ ctx->used += size;
+
+ err = 0;
+
+done:
+ ctx->more = flags & MSG_MORE;
+
+unlock:
+ aead_data_wakeup(sk);
+ release_sock(sk);
+
+ return err ?: size;
+}
+
+static int aead_recvmsg(struct kiocb *unused, struct socket *sock,
+ struct msghdr *msg, size_t ignored, int flags)
+{
+ struct sock *sk = sock->sk;
+ struct alg_sock *ask = alg_sk(sk);
+ struct aead_ctx *ctx = ask->private;
+ unsigned bs = crypto_aead_blocksize(crypto_aead_reqtfm(&ctx->aead_req));
+ unsigned as = crypto_aead_authsize(crypto_aead_reqtfm(&ctx->aead_req));
+ struct aead_sg_list *sgl = &ctx->tsgl;
+ struct scatterlist *sg = sgl->sg;
+ struct scatterlist assoc;
+ size_t assoclen = 0;
+ unsigned int i = 0;
+ int err = -EAGAIN;
+ unsigned long used = 0;
+ unsigned long outlen = 0;
+
+ /*
+ * Require exactly one IOV block as the AEAD operation is a one shot
+ * due to the authentication tag.
+ */
+ if (msg->msg_iter.nr_segs != 1)
+ return -ENOMSG;
+
+ lock_sock(sk);
+ /*
+ * AEAD memory structure: For encryption, the tag is appended to the
+ * ciphertext which implies that the memory allocated for the ciphertext
+ * must be increased by the tag length. For decryption, the tag
+ * is expected to be concatenated to the ciphertext. The plaintext
+ * therefore has a memory size of the ciphertext minus the tag length.
+ *
+ * The memory structure for cipher operation has the following
+ * structure:
+ * AEAD encryption input: assoc data || plaintext
+ * AEAD encryption output: cipherntext || auth tag
+ * AEAD decryption input: assoc data || ciphertext || auth tag
+ * AEAD decryption output: plaintext
+ */
+
+ if (ctx->more) {
+ err = aead_wait_for_data(sk, flags);
+ if (err)
+ goto unlock;
+ }
+
+ used = ctx->used;
+
+ err = -EINVAL;
+ /*
+ * The cipher operation input data is reduced by the associated data
+ * length as this data is processed separately later on.
+ */
+ used -= ctx->aead_assoclen;
+
+ if (ctx->enc) {
+ /* round up output buffer to multiple of block size */
+ outlen = ((used + bs - 1) / bs * bs);
+ /* add the size needed for the auth tag to be created */
+ outlen += as;
+ } else {
+ /* output data size is input without the authentication tag */
+ outlen = used - as;
+ /* round up output buffer to multiple of block size */
+ outlen = ((outlen + bs - 1) / bs * bs);
+ }
+
+ /* ensure output buffer is sufficiently large */
+ if (msg->msg_iter.iov->iov_len < outlen)
+ goto unlock;
+
+ outlen = af_alg_make_sg(&ctx->rsgl, msg->msg_iter.iov->iov_base,
+ outlen, 1);
+ err = outlen;
+ if (err < 0)
+ goto unlock;
+
+ err = -EINVAL;
+ /*
+ * first chunk of input is AD -- one scatterlist entry is one page,
+ * and we process only one scatterlist, the maximum size of AD is
+ * one page
+ */
+ sg_init_table(&assoc, 1);
+ sg_set_page(&assoc, sg_page(sg), ctx->aead_assoclen, sg->offset);
+ aead_request_set_assoc(&ctx->aead_req, &assoc, ctx->aead_assoclen);
+
+ /* point sg to cipher/plaintext start */
+ assoclen = ctx->aead_assoclen;
+ for(i = 0; i < ctx->tsgl.cur; i++) {
+ sg = sgl->sg + i;
+ if (sg->length <= assoclen) {
+ assoclen -= sg->length;
+ if (i >= ctx->tsgl.cur)
+ goto unlock;
+ } else {
+ sg->length -= assoclen;
+ sg->offset += assoclen;
+ break;
+ }
+ }
+
+ aead_request_set_crypt(&ctx->aead_req, sg, ctx->rsgl.sg, used, ctx->iv);
+
+ err = af_alg_wait_for_completion(ctx->enc ?
+ crypto_aead_encrypt(&ctx->aead_req) :
+ crypto_aead_decrypt(&ctx->aead_req),
+ &ctx->completion);
+
+ af_alg_free_sg(&ctx->rsgl);
+
+ if (err)
+ goto unlock;
+
+ aead_put_sgl(sk);
+
+ err = 0;
+
+unlock:
+ aead_wmem_wakeup(sk);
+ release_sock(sk);
+
+ return err ? err : outlen;
+}
+
+static unsigned int aead_poll(struct file *file, struct socket *sock,
+ poll_table *wait)
+{
+ struct sock *sk = sock->sk;
+ struct alg_sock *ask = alg_sk(sk);
+ struct aead_ctx *ctx = ask->private;
+ unsigned int mask;
+
+ sock_poll_wait(file, sk_sleep(sk), wait);
+ mask = 0;
+
+ if (!ctx->more)
+ mask |= POLLIN | POLLRDNORM;
+
+ if (aead_writable(sk))
+ mask |= POLLOUT | POLLWRNORM | POLLWRBAND;
+
+ return mask;
+}
+
+static struct proto_ops algif_aead_ops = {
+ .family = PF_ALG,
+
+ .connect = sock_no_connect,
+ .socketpair = sock_no_socketpair,
+ .getname = sock_no_getname,
+ .ioctl = sock_no_ioctl,
+ .listen = sock_no_listen,
+ .shutdown = sock_no_shutdown,
+ .getsockopt = sock_no_getsockopt,
+ .mmap = sock_no_mmap,
+ .bind = sock_no_bind,
+ .accept = sock_no_accept,
+ .setsockopt = sock_no_setsockopt,
+
+ .release = af_alg_release,
+ .sendmsg = aead_sendmsg,
+ .sendpage = aead_sendpage,
+ .recvmsg = aead_recvmsg,
+ .poll = aead_poll,
+};
+
+static void *aead_bind(const char *name, u32 type, u32 mask)
+{
+ return crypto_alloc_aead(name, type, mask);
+}
+
+static void aead_release(void *private)
+{
+ crypto_free_aead(private);
+}
+
+static int aead_setauthsize(void *private, unsigned int authsize)
+{
+ return crypto_aead_setauthsize(private, authsize);
+}
+
+static int aead_setkey(void *private, const u8 *key, unsigned int keylen)
+{
+ return crypto_aead_setkey(private, key, keylen);
+}
+
+static void aead_sock_destruct(struct sock *sk)
+{
+ struct alg_sock *ask = alg_sk(sk);
+ struct aead_ctx *ctx = ask->private;
+ unsigned int ivlen = crypto_aead_ivsize(
+ crypto_aead_reqtfm(&ctx->aead_req));
+
+ aead_put_sgl(sk);
+ sock_kzfree_s(sk, ctx->iv, ivlen);
+ sock_kfree_s(sk, ctx, ctx->len);
+ af_alg_release_parent(sk);
+}
+
+static int aead_accept_parent(void *private, struct sock *sk)
+{
+ struct aead_ctx *ctx;
+ struct alg_sock *ask = alg_sk(sk);
+ unsigned int len = sizeof(*ctx) + crypto_aead_reqsize(private);
+ unsigned int ivlen = crypto_aead_ivsize(private);
+
+ ctx = sock_kmalloc(sk, len, GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
+ memset(ctx, 0, len);
+
+ ctx->iv = sock_kmalloc(sk, ivlen, GFP_KERNEL);
+ if (!ctx->iv) {
+ sock_kfree_s(sk, ctx, len);
+ return -ENOMEM;
+ }
+ memset(ctx->iv, 0, ivlen);
+
+ ctx->len = len;
+ ctx->used = 0;
+ ctx->more = 0;
+ ctx->merge = 0;
+ ctx->enc = 0;
+ ctx->tsgl.cur = 0;
+ ctx->aead_assoclen = 0;
+ af_alg_init_completion(&ctx->completion);
+ sg_init_table(ctx->tsgl.sg, ALG_MAX_PAGES);
+
+ ask->private = ctx;
+
+ aead_request_set_tfm(&ctx->aead_req, private);
+ aead_request_set_callback(&ctx->aead_req, CRYPTO_TFM_REQ_MAY_BACKLOG,
+ af_alg_complete, &ctx->completion);
+
+ sk->sk_destruct = aead_sock_destruct;
+
+ return 0;
+}
+
+static const struct af_alg_type algif_type_aead = {
+ .bind = aead_bind,
+ .release = aead_release,
+ .setkey = aead_setkey,
+ .setauthsize = aead_setauthsize,
+ .accept = aead_accept_parent,
+ .ops = &algif_aead_ops,
+ .name = "aead",
+ .owner = THIS_MODULE
+};
+
+static int __init algif_aead_init(void)
+{
+ return af_alg_register_type(&algif_type_aead);
+}
+
+static void __exit algif_aead_exit(void)
+{
+ int err = af_alg_unregister_type(&algif_type_aead);
+ BUG_ON(err);
+}
+
+module_init(algif_aead_init);
+module_exit(algif_aead_exit);
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Stephan Mueller <smueller@chronox.de>");
+MODULE_DESCRIPTION("AEAD kernel crypto API user space interface");
--
2.1.0
^ permalink raw reply related
* [PATCH v7 0/2] crypto: AF_ALG: add AEAD and RNG support
From: Stephan Mueller @ 2015-01-02 14:40 UTC (permalink / raw)
To: 'Herbert Xu'
Cc: Daniel Borkmann, 'Quentin Gouchet',
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, ABI/API
Hi,
This patch set adds AEAD and RNG support to the AF_ALG interface
exported by the kernel crypto API. By extending AF_ALG with AEAD and RNG
support, all cipher types the kernel crypto API allows access to are
now accessible from userspace.
Both, AEAD and RNG implementations are stand-alone and do not depend
other AF_ALG interfaces (like hash or skcipher).
The AEAD implementation uses the same approach as provided with
skcipher by offering the following interfaces:
* sendmsg and recvmsg interfaces allowing multiple
invocations supporting a threaded user space. To support
multi-threaded user space, kernel-side buffering
is implemented similarly to skcipher.
* splice / vmsplice interfaces allowing a zero-copy
invocation
The RNG interface only implements the recvmsg interface as
zero-copy is not applicable.
The new AEAD and RNG interfaces are fully tested with the test application
provided at [1]. That test application exercises all newly added user space
interfaces. The testing covers:
* use of the sendmsg/recvmsg interface
* use of the splice / vmsplice interface
* invocation of all AF_ALG types (aead, rng, skcipher, hash)
* using all types of operation (encryption, decryption, keyed MD,
MD, random numbers, AEAD decryption with positive and negative
authentication verification)
* stress testing by running all tests for 30 minutes in an
endless loop
* test execution on 64 bit and 32 bit
[1] http://www.chronox.de/libkcapi.html
Changes v2:
* rebase to current cryptodev-2.6 tree
* use memzero_explicit to zeroize AEAD associated data
* use sizeof for determining length of AEAD associated data
* update algif_rng.c covering all suggestions from Daniel Borkmann
<dborkman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
* addition of patch 9: add digestsize interface for hashes
* addition of patch to update documentation covering the userspace interface
* change numbers of getsockopt options: separate them from sendmsg interface
definitions
Changes v3:
* remove getsockopt interface
* AEAD: associated data is set prepended to the plain/ciphertext
* AEAD: allowing arbitrary associated data lengths
* remove setkey patch as protection was already in the existing code
Changes v4:
* stand-alone implementation of AEAD
* testing of all interfaces offered by AEAD
* stress testing of AEAD and RNG
Changes v5:
* AEAD: add outer while(size) loop in aead_sendmsg to ensure all data is
copied into the kernel (reporter Herbert Xu)
* AEAD: aead_sendmsg bug fix: change size -= len; to size -= plen;
* AF_ALG / AEAD: add aead_setauthsize and associated extension to
struct af_alg_type as well as alg_setsockopt (reporter Herbert Xu)
* RNG: rng_recvmsg: use 128 byte stack variable for output of RNG instead
of ctx->result (reporter Herbert Xu)
* RNG / AF_ALG: allow user space to seed RNG via setsockopt
* RNG: rng_recvmsg bug fix: use genlen as result variable for
crypto_rng_get_bytes as previously no negative errors were obtained
* AF_ALG: alg_setop: zeroize buffer before free
Changes v6:
* AEAD/RNG: port to 3.19-rc1 with the iov_iter handling
* RNG: use the setkey interface to obtain the seed and drop the patch adding
a separate reseeding interface
* extract the zeroization patch for alg_setkey into a stand-alone patch
submission
* fix bug in aead_sufficient_data (reporter Herbert Xu)
* testing of all interfaces with test application provided with libkcapi version
0.6.2
Changes v7:
* AEAD: aead_recvmsg: change error code from ENOMEM to EINVAL
* AEAD: drop aead_readable/aead_sufficient_data and only use ctx->more to decide
whether the read side shall become active. This change requires that the
patch for crypto_aead_decrypt ensuring that the ciphertext contains the
authentication tag was added -- see https://lkml.org/lkml/2014/12/30/200.
Otherwise, user space can trigger a kernel crash.
* RNG: patch dropped as it was applied
* AEAD: port Kconfig/Makefile patch forward to current code base
Stephan Mueller (2):
crypto: AF_ALG: add AEAD support
crypto: AF_ALG: enable AEAD interface compilation
crypto/Kconfig | 9 +
crypto/Makefile | 1 +
crypto/algif_aead.c | 631 ++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 641 insertions(+)
create mode 100644 crypto/algif_aead.c
--
2.1.0
^ permalink raw reply
* Re: [PATCH] selftests/exec: Use %zu to format size_t
From: David Drysdale @ 2015-01-02 13:46 UTC (permalink / raw)
To: Shuah Khan
Cc: Geert Uytterhoeven, Andrew Morton, Linux API,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <54985F6E.2010205-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On Mon, Dec 22, 2014 at 6:14 PM, Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
>
> On 12/21/2014 03:58 AM, Geert Uytterhoeven wrote:
> > On 32-bit:
> >
> > execveat.c: In function 'check_execveat_pathmax':
> > execveat.c:183: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'size_t'
> > execveat.c:187: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'size_t'
> >
> > Signed-off-by: Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
> > ---
> > tools/testing/selftests/exec/execveat.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/testing/selftests/exec/execveat.c b/tools/testing/selftests/exec/execveat.c
> > index 33a5c06d95caa038..d273624c93a64254 100644
> > --- a/tools/testing/selftests/exec/execveat.c
> > +++ b/tools/testing/selftests/exec/execveat.c
> > @@ -179,11 +179,11 @@ static int check_execveat_pathmax(int dot_dfd, const char *src, int is_script)
> > */
> > fd = open(longpath, O_RDONLY);
> > if (fd > 0) {
> > - printf("Invoke copy of '%s' via filename of length %lu:\n",
> > + printf("Invoke copy of '%s' via filename of length %zu:\n",
> > src, strlen(longpath));
> > fail += check_execveat(fd, "", AT_EMPTY_PATH);
> > } else {
> > - printf("Failed to open length %lu filename, errno=%d (%s)\n",
> > + printf("Failed to open length %zu filename, errno=%d (%s)\n",
> > strlen(longpath), errno, strerror(errno));
> > fail++;
> > }
> >
>
>
> Applied to kernel/git/shuah/linux-kselftest.git fixes
> for 3.19-rc2
>
> thanks,
> -- Shuah
Thanks for fixing, and apologies for the delay in responding.
Acked-by: David Drysdale <drysdale-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> --
> Shuah Khan
> Sr. Linux Kernel Developer
> Open Source Innovation Group
> Samsung Research America (Silicon Valley)
> shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org | (970) 217-8978
^ permalink raw reply
* [PATCH] Documentation: dell-laptop: correct als_setting description
From: Gabriele Mazzotta @ 2015-01-02 11:06 UTC (permalink / raw)
Cc: dvhart-VuQAYsv1563Yd54FQh9/CA, pali.rohar-Re5JQEeQqe8AvxtiuMwx3w,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
A.Sloman-dxBOTFGcEFw2EctHIo1CcQ, Gabriele Mazzotta
It was incorrectly stated that als_setting is to enable and disable
the ambient light sensor on supported system rather than setting a
threshold value. Correct the description and add a note to make more
clear what could be the effect of changing als_setting.
Reported-by: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Gabriele Mazzotta <gabriele.mzt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Documentation/ABI/testing/sysfs-platform-dell-laptop | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-platform-dell-laptop b/Documentation/ABI/testing/sysfs-platform-dell-laptop
index 7969443..a40c217 100644
--- a/Documentation/ABI/testing/sysfs-platform-dell-laptop
+++ b/Documentation/ABI/testing/sysfs-platform-dell-laptop
@@ -4,10 +4,12 @@ KernelVersion: 3.19
Contact: Gabriele Mazzotta <gabriele.mzt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Description:
- This file allows to control the automatic keyboard
- illumination mode on some systems that have an ambient
- light sensor. Write 1 to this file to enable the auto
- mode, 0 to disable it.
+ This file allows to set at which value reported by the
+ ambient light sensor the keyboard backlight has to be
+ turned on or off.
+
+ Note that the 'als' trigger must be supported and enabled
+ for this setting to have any effect.
What: /sys/class/leds/dell::kbd_backlight/start_triggers
Date: December 2014
@@ -32,6 +34,13 @@ Description:
Note that not all the available triggers can be configured.
+ Note also that enabling the 'als' trigger could simply
+ alter the behavior of the other triggers and not allow
+ the ambient light sensor control the keyboard illumination
+ independently. It could prevent other triggers from turning
+ the keyboard backlight on or force them to turn it off
+ depending on the current ambient light and als_setting.
+
What: /sys/class/leds/dell::kbd_backlight/stop_timeout
Date: December 2014
KernelVersion: 3.19
--
2.1.4
^ permalink raw reply related
* Re: [PATCH] Documentation: Add entry for dell-laptop sysfs interface
From: Darren Hart @ 2015-01-02 4:25 UTC (permalink / raw)
To: Gabriele Mazzotta
Cc: Brian Norris, mjg59-1xO5oi07KQx4cg9Nei1l7Q,
linux-api-u79uwXL29TY76Z2rM5mHXA,
platform-driver-x86-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
libsmbios-devel-XtjxT7Vmt5ZskZv2Y/7f+AC/G2K4zDHf,
Srinivas_G_Gowda-8PEkshWhKlo, Michael_E_Brown-8PEkshWhKlo,
pali.rohar-Re5JQEeQqe8AvxtiuMwx3w,
A.Sloman-dxBOTFGcEFw2EctHIo1CcQ
In-Reply-To: <1636595.UbTko9mUNA@xps13>
On Wed, Dec 31, 2014 at 12:20:59PM +0100, Gabriele Mazzotta wrote:
> On Tuesday 30 December 2014 21:31:49 Brian Norris wrote:
> > Hi,
> >
> > On Wed, Dec 03, 2014 at 06:41:33PM +0100, Gabriele Mazzotta wrote:
> > > Add the documentation for the new sysfs interface of dell-laptop
> > > that allows to configure the keyboard illumination on Dell systems.
> > >
> > > Signed-off-by: Gabriele Mazzotta <gabriele.mzt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > Signed-off-by: Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > ---
> > > .../ABI/testing/sysfs-platform-dell-laptop | 60 ++++++++++++++++++++++
> > > 1 file changed, 60 insertions(+)
> > > create mode 100644 Documentation/ABI/testing/sysfs-platform-dell-laptop
> > >
> > > diff --git a/Documentation/ABI/testing/sysfs-platform-dell-laptop b/Documentation/ABI/testing/sysfs-platform-dell-laptop
> > > new file mode 100644
> > > index 0000000..7969443
> > > --- /dev/null
> > > +++ b/Documentation/ABI/testing/sysfs-platform-dell-laptop
> > > @@ -0,0 +1,60 @@
> > > +What: /sys/class/leds/dell::kbd_backlight/als_setting
> > > +Date: December 2014
> > > +KernelVersion: 3.19
> > > +Contact: Gabriele Mazzotta <gabriele.mzt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
> > > + Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > +Description:
> > > + This file allows to control the automatic keyboard
> > > + illumination mode on some systems that have an ambient
> > > + light sensor. Write 1 to this file to enable the auto
> > > + mode, 0 to disable it.
> > [...]
> >
> > This entry appears wrong, or at least incomplete. My system boots with a
> > default value of 18, and the 'set' implementation accepts any value from
> > 0 to 255.
> >
> > According to the comments in dell-laptop.c, the value actually means
> > something different than on/off:
> >
> > cbArg3, byte0 Desired setting of ALS value that turns the light on or off.
> >
> > Admittedly, I'm not clear on what the intended interface is, as I've
> > never had the ALS / keyboard backlight controls all working properly on
> > my laptop in the first place, but I thought this would be the right
> > place to ask about getting the documentation and driver in sync.
>
> Hi,
>
> You are perfectly right, the documentation is wrong and I'm sorry for
> that. als_setting should allow you to define when the keyboard
> backlight has to be turned on or off depending on the value reported
> by the ambient light sensor.
>
> Please note that not everything that is in libsmbios [1] is implemented
> in the kernel driver. Take a look at it, recently there have been few
> changes related to the ALS settings. Probably they are not needed given
> that you are able to set the threshold with the current kernel driver,
> but you might find something interesting.
>
> I'll submit a patch to correct the documentation, thanks for reporting.
Thanks Gabriele, let's make sure to get this into this rc cycle, sooner the
better.
Thanks,
--
Darren Hart
Intel Open Source Technology Center
^ permalink raw reply
* [PATCH 4/5] dvb core: add media controller support for the demod
From: Mauro Carvalho Chehab @ 2015-01-01 15:51 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Shuah Khan, Akihiro Tsukada, Olli Salonen,
Antti Palosaari, Hans Verkuil, Nibble Max, James Harper,
Matthias Schwarzott, linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cover.1420127255.git.mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
Now that we have an I2C function to attach DVB sub-devices, add
support for media controller on it.
Signed-off-by: Mauro Carvalho Chehab <mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
diff --git a/drivers/media/dvb-core/dvb_frontend.h b/drivers/media/dvb-core/dvb_frontend.h
index 41aae1bf0103..65d002f19cc3 100644
--- a/drivers/media/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb-core/dvb_frontend.h
@@ -40,6 +40,8 @@
#include <linux/dvb/frontend.h>
+#include <media/media-device.h>
+
#include "dvbdev.h"
/*
@@ -416,6 +418,11 @@ struct dvb_frontend {
struct dvb_frontend_ops ops;
struct dvb_adapter *dvb;
struct i2c_client *fe_cl;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ struct media_device *mdev;
+ struct media_entity demod_entity;
+#endif
+
void *demodulator_priv;
void *tuner_priv;
void *frontend_priv;
diff --git a/drivers/media/dvb-core/dvb_i2c.c b/drivers/media/dvb-core/dvb_i2c.c
index 4ea4e5e59f14..df8b7718ca8a 100644
--- a/drivers/media/dvb-core/dvb_i2c.c
+++ b/drivers/media/dvb-core/dvb_i2c.c
@@ -39,11 +39,12 @@ dvb_i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info *info,
struct dvb_frontend *
dvb_i2c_attach_fe(struct i2c_adapter *adap, const struct i2c_board_info *info,
- const void *cfg, void **out)
+ const void *cfg, void **out, struct media_device *mdev)
{
struct i2c_client *cl;
struct i2c_board_info bi;
struct dvb_i2c_dev_config dcfg;
+ struct dvb_frontend *fe;
dcfg.priv_cfg = cfg;
dcfg.out = out;
@@ -53,7 +54,28 @@ dvb_i2c_attach_fe(struct i2c_adapter *adap, const struct i2c_board_info *info,
cl = dvb_i2c_new_device(adap, &bi, NULL);
if (!cl)
return NULL;
- return i2c_get_clientdata(cl);
+ fe = i2c_get_clientdata(cl);
+
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ /* Register the media controller entity. */
+ if (mdev) {
+ int ret;
+
+ if (!fe->mdev)
+ fe->mdev = mdev;
+
+ fe->demod_entity.type = MEDIA_ENT_T_DEVNODE_DVB;
+ fe->demod_entity.name = info->type;
+ fe->demod_entity.info.dvb = fe->id;
+ fe->demod_entity.flags = MEDIA_ENT_T_DVB_DEMOD;
+ ret = media_device_register_entity(fe->mdev, &fe->demod_entity);
+ if (ret < 0)
+ printk(KERN_WARNING
+ "%s: media_device_register_entity failed\n",
+ __func__);
+ }
+#endif
+ return fe;
}
EXPORT_SYMBOL(dvb_i2c_attach_fe);
@@ -193,6 +215,10 @@ static int remove_fe(struct i2c_client *client,
if (param->priv_remove)
param->priv_remove(client);
fe = i2c_get_clientdata(client);
+
+ if (fe->mdev)
+ media_device_unregister_entity(&fe->demod_entity);
+
kfree(fe->demodulator_priv);
kfree(fe);
module_put(this_module);
diff --git a/drivers/media/dvb-core/dvb_i2c.h b/drivers/media/dvb-core/dvb_i2c.h
index 2bf409d4bcaf..c2efed9c997e 100644
--- a/drivers/media/dvb-core/dvb_i2c.h
+++ b/drivers/media/dvb-core/dvb_i2c.h
@@ -33,7 +33,8 @@
struct dvb_frontend *dvb_i2c_attach_fe(struct i2c_adapter *adap,
const struct i2c_board_info *info,
- const void *cfg, void **out);
+ const void *cfg, void **out,
+ struct media_device *mdev);
struct i2c_client *dvb_i2c_attach_tuner(struct i2c_adapter *adap,
const struct i2c_board_info *info,
diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c b/drivers/media/pci/cx23885/cx23885-dvb.c
index fc23b7ad194f..084526a29414 100644
--- a/drivers/media/pci/cx23885/cx23885-dvb.c
+++ b/drivers/media/pci/cx23885/cx23885-dvb.c
@@ -1510,7 +1510,7 @@ static int dvb_register(struct cx23885_tsport *port)
fe0->dvb.frontend = dvb_i2c_attach_fe(&i2c_bus->i2c_adap,
&mb86a20s_board_info,
&mygica_x8507_mb86a20s_config,
- NULL);
+ NULL, NULL);
if (fe0->dvb.frontend == NULL)
break;
diff --git a/drivers/media/pci/saa7134/saa7134-dvb.c b/drivers/media/pci/saa7134/saa7134-dvb.c
index 74b5ce0de488..a47630be4583 100644
--- a/drivers/media/pci/saa7134/saa7134-dvb.c
+++ b/drivers/media/pci/saa7134/saa7134-dvb.c
@@ -1814,7 +1814,7 @@ static int dvb_init(struct saa7134_dev *dev)
fe0->dvb.frontend = dvb_i2c_attach_fe(&dev->i2c_adap,
&mb86a20s_board_info,
&kworld_mb86a20s_config,
- NULL);
+ NULL, NULL);
if (fe0->dvb.frontend != NULL) {
dvb_attach(tda829x_attach, fe0->dvb.frontend,
&dev->i2c_adap, 0x4b,
diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c b/drivers/media/usb/cx231xx/cx231xx-dvb.c
index 27803a8cf5a4..e6b6da44b1e5 100644
--- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
+++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
@@ -822,7 +822,7 @@ static int dvb_init(struct cx231xx *dev)
dev->dvb->frontend = dvb_i2c_attach_fe(demod_i2c,
&mb86a20s_board_info,
&pv_mb86a20s_config,
- NULL);
+ NULL, NULL);
if (dev->dvb->frontend == NULL) {
dev_err(dev->dev,
"Failed to attach mb86a20s demod\n");
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c b/drivers/media/usb/em28xx/em28xx-dvb.c
index 6fa4eeed9f50..c9bbc251c7c7 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1330,7 +1330,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
dvb->fe[0] = dvb_i2c_attach_fe(&dev->i2c_adap[dev->def_i2c_bus],
&mb86a20s_board_info,
&c3tech_duo_mb86a20s_config,
- NULL);
+ NULL, NULL);
if (dvb->fe[0] != NULL)
dvb_attach(tda18271_attach, dvb->fe[0], 0x60,
&dev->i2c_adap[dev->def_i2c_bus],
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index d847c760e8f0..c002aed74e6b 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -27,7 +27,7 @@
#include <linux/types.h>
#include <linux/version.h>
-#define MEDIA_API_VERSION KERNEL_VERSION(0, 1, 0)
+#define MEDIA_API_VERSION KERNEL_VERSION(0, 1, 1)
struct media_device_info {
char driver[16];
@@ -59,6 +59,8 @@ struct media_device_info {
/* A converter of analogue video to its digital representation. */
#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER (MEDIA_ENT_T_V4L2_SUBDEV + 4)
+#define MEDIA_ENT_T_DVB_DEMOD (MEDIA_ENT_T_V4L2_SUBDEV + 5)
+
#define MEDIA_ENT_FL_DEFAULT (1 << 0)
struct media_entity_desc {
--
2.1.0
^ permalink raw reply related
* WIP alternative - was Re: [PATCH v3 14/20] selftests/size: add install target to enable test install
From: Tim Bird @ 2015-01-01 2:31 UTC (permalink / raw)
To: Shuah Khan, mmarek@suse.cz, gregkh@linuxfoundation.org,
akpm@linux-foundation.org, rostedt@goodmis.org, mingo@redhat.com,
davem@davemloft.net, keescook@chromium.org,
tranmanphong@gmail.com, mpe@ellerman.id.au, cov@codeaurora.org,
dh.herrmann@gmail.com, hughd@google.com, bobby.prani@gmail.com,
serge.hallyn@ubuntu.com, ebiederm@xmission.com,
josh@joshtriplett.org, koct9i@gmail.com
Cc: linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-api@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <c961f80614b02a2f3c6455518d1f6fabdaf6c7f3.1419387513.git.shuahkh@osg.samsung.com>
On 12/24/2014 08:27 AM, Shuah Khan wrote:
> Add a new make target to enable installing test. This target
> installs test in the kselftest install location and add to the
> kselftest script to run the test. Install target can be run
> only from top level kernel source directory.
>
> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
> ---
> tools/testing/selftests/size/Makefile | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/size/Makefile b/tools/testing/selftests/size/Makefile
> index 04dc25e..bb7113b 100644
> --- a/tools/testing/selftests/size/Makefile
> +++ b/tools/testing/selftests/size/Makefile
> @@ -1,12 +1,22 @@
> CC = $(CROSS_COMPILE)gcc
>
> +TEST_STR = ./get_size || echo get_size selftests: [FAIL]
> +
> all: get_size
>
> get_size: get_size.c
> $(CC) -static -ffreestanding -nostartfiles -s $< -o $@
>
> +install:
> +ifdef INSTALL_KSFT_PATH
> + install ./get_size $(INSTALL_KSFT_PATH)
> + @echo "$(TEST_STR)" >> $(KSELFTEST)
> +else
> + @echo Run make kselftest_install in top level source directory
> +endif
> +
> run_tests: all
> - ./get_size
> + @$(TEST_STR)
>
> clean:
> $(RM) get_size
>
The install phase is desperately needed for usage of kselftest in
cross-target situations (applicable to almost all embedded). So this
is great stuff.
I worked a bit on isolating the install stuff to a makefile include file.
This allows simplifying some of the sub-level Makefiles a bit, and allowing
control of some of the install and run logic in less places.
This is still a work in progress, but before I got too far along, I wanted
to post it for people to provide feedback. A couple of problems cropped
up that are worth discussing, IMHO.
1) I think it should be a requirement that each test has a single
"main" program to execute to run the tests. If multiple tests are supported
or more flexibility is desired for additional arguments, or that sort of
thing, then that's fine, but the automated script builder should be able
to run just a single program or script to have things work. This also
makes things more consistent. In the case of the firmware test, I created
a single fw_both.sh script to do this, instead of having two separate
blocks in the kselftest.sh script.
2) I've added a CROSS_INSTALL variable, which can call an arbitrary program
to place files on the target system (rather than just calling 'install').
In my case, I'd use my own 'ttc cp' command, which I can extend as necessary
to put things on a remote machine. This works for a single directory,
but things get dicier with sub-directory trees full of files (like
the ftrace test uses.)
If additional items need to be installed to the target, then maybe a setup
program should be used, rather than just copying files.
3) Some of the scripts were using /bin/bash to execute them, rather
than rely on the interpreter line in the script itself (and having
the script have executable privileges). Is there a reason for this?
I modified a few scripts to be executable, and got rid of the
explicit execution with /bin/bash.
The following is just a start... Let me know if this direction looks
OK, and I'll finish this up. The main item to look at is
kselftest.include file. Note that these patches are based on Shuah's
series - but if you want to use these ideas I can rebase them onto
mainline, and break them out per test sub-level like Shuah did.
Let me know what you think.
>From 14164fd3117c97799a050f8cf791dedc93aa5e82 Mon Sep 17 00:00:00 2001
From: Tim Bird <tim.bird@sonymobile.com>
Date: Wed, 31 Dec 2014 18:04:08 -0800
Subject: [PATCH] Switch to using an include file for common kselftest_install
actions
---
tools/testing/selftests/cpu-hotplug/Makefile | 15 +++-------
.../selftests/cpu-hotplug/cpu-on-off-test.sh | 0
tools/testing/selftests/efivarfs/Makefile | 21 ++++----------
tools/testing/selftests/efivarfs/efivarfs.sh | 0
tools/testing/selftests/firmware/Makefile | 32 ++++------------------
tools/testing/selftests/firmware/fw_both.sh | 13 +++++++++
tools/testing/selftests/kselftest.include | 26 ++++++++++++++++++
tools/testing/selftests/size/Makefile | 19 +++----------
9 files changed, 60 insertions(+), 69 deletions(-)
mode change 100644 => 100755 tools/testing/selftests/cpu-hotplug/cpu-on-off-test.sh
mode change 100644 => 100755 tools/testing/selftests/efivarfs/efivarfs.sh
create mode 100755 tools/testing/selftests/firmware/fw_both.sh
create mode 100644 tools/testing/selftests/kselftest.include
diff --git a/tools/testing/selftests/cpu-hotplug/Makefile b/tools/testing/selftests/cpu-hotplug/Makefile
index c9e15ee..d2e540d 100644
--- a/tools/testing/selftests/cpu-hotplug/Makefile
+++ b/tools/testing/selftests/cpu-hotplug/Makefile
@@ -1,18 +1,11 @@
-TEST_STR=/bin/bash ./cpu-on-off-test.sh || echo cpu-hotplug selftests: [FAIL]
+TEST_TITLE = cpu-hotplug
+TEST_MAIN_PROG = cpu-on-off-test.sh
all:
-install:
-ifdef INSTALL_KSFT_PATH
- install ./cpu-on-off-test.sh $(INSTALL_KSFT_PATH)/cpu-on-off-test.sh
- @echo "$(TEST_STR)" >> $(KSELFTEST)
-else
- @echo Run make kselftest_install in top level source directory
-endif
-
-run_tests:
- @$(TEST_STR)
+include ../kselftest.include
+# use -a to get all tests
run_full_test:
@/bin/bash ./cpu-on-off-test.sh -a || echo "cpu-hotplug selftests: [FAIL]"
diff --git a/tools/testing/selftests/cpu-hotplug/cpu-on-off-test.sh b/tools/testing/selftests/cpu-hotplug/cpu-on-off-test.sh
old mode 100644
new mode 100755
diff --git a/tools/testing/selftests/efivarfs/Makefile b/tools/testing/selftests/efivarfs/Makefile
index aaf404b..8d48e9c 100644
--- a/tools/testing/selftests/efivarfs/Makefile
+++ b/tools/testing/selftests/efivarfs/Makefile
@@ -1,24 +1,15 @@
-CC = $(CROSS_COMPILE)gcc
-CFLAGS = -Wall
+TEST_TITLE = efivarfs
+TEST_MAIN_PROG = efivarfs.sh
-test_objs = open-unlink create-read
+CFLAGS = -Wall
-TEST_STR = /bin/bash ./efivarfs.sh || echo efivarfs selftests: [FAIL]
+TEST_PROGS = open-unlink create-read
all:
gcc open-unlink.c -o open-unlink
gcc create-read.c -o create-read
-install:
-ifdef INSTALL_KSFT_PATH
- install ./efivarfs.sh $(test_objs) $(INSTALL_KSFT_PATH)
- @echo "$(TEST_STR)" >> $(KSELFTEST)
-else
- @echo Run make kselftest_install in top level source directory
-endif
-
-run_tests: all
- @$(TEST_STR)
+include ../kselftest.include
clean:
- rm -f $(test_objs)
+ rm -f $(TEST_PROGS)
diff --git a/tools/testing/selftests/efivarfs/efivarfs.sh b/tools/testing/selftests/efivarfs/efivarfs.sh
old mode 100644
new mode 100755
diff --git a/tools/testing/selftests/firmware/Makefile b/tools/testing/selftests/firmware/Makefile
index 7ac1cf3..b576308 100644
--- a/tools/testing/selftests/firmware/Makefile
+++ b/tools/testing/selftests/firmware/Makefile
@@ -1,36 +1,14 @@
# Makefile for firmware loading selftests
+TEST_MAIN_PROG = fw_both.sh
+TEST_TITLE = firmware
+TEST_FILES = ./fw_filesystem.sh ./fw_userhelper.sh
# No binaries, but make sure arg-less "make" doesn't trigger "run_tests"
-
-__fw_filesystem:
-fw_filesystem = if /bin/sh ./fw_filesystem.sh ; then
-fw_filesystem += echo fw_filesystem: ok;
-fw_filesystem += else echo fw_filesystem: [FAIL];
-fw_filesystem += fi
-
-__fw_userhelper:
-fw_userhelper = if /bin/sh ./fw_userhelper.sh ; then
-fw_userhelper += echo fw_userhelper: ok;
-fw_userhelper += else
-fw_userhelper += echo fw_userhelper: [FAIL];
-fw_userhelper += fi
-
all:
-install:
-ifdef INSTALL_KSFT_PATH
- install ./fw_filesystem.sh ./fw_userhelper.sh $(INSTALL_KSFT_PATH)
- @echo "$(fw_filesystem)" >> $(KSELFTEST)
- @echo "$(fw_userhelper)" >> $(KSELFTEST)
-else
- @echo Run make kselftest_install in top level source directory
-endif
-
-run_tests:
- @$(fw_filesystem)
- @$(fw_userhelper)
+include ../kselftest.include
# Nothing to clean up.
clean:
-.PHONY: all clean run_tests fw_filesystem fw_userhelper
+.PHONY: all clean run_tests
diff --git a/tools/testing/selftests/firmware/fw_both.sh b/tools/testing/selftests/firmware/fw_both.sh
new file mode 100755
index 0000000..fb7fa8d
--- /dev/null
+++ b/tools/testing/selftests/firmware/fw_both.sh
@@ -0,0 +1,13 @@
+#!/bin/sh
+
+if /bin/sh ./fw_filesystem.sh ; then
+ echo "fw_filesystem: ok";
+else
+ echo "fw_filesystem: [FAIL]";
+fi
+
+if /bin/sh ./fw_userhelper.sh ; then
+ echo "fw_userhelper: ok";
+else
+ echo "fw_userhelper: [FAIL]";
+fi
diff --git a/tools/testing/selftests/kselftest.include b/tools/testing/selftests/kselftest.include
new file mode 100644
index 0000000..7020a82
--- /dev/null
+++ b/tools/testing/selftests/kselftest.include
@@ -0,0 +1,26 @@
+# this make include script expects the following variables to be set:
+# TEST_MAIN_PROG - a single program to invoke to run the test
+# TEST_TITLE - the title of the test
+# TEST_FILES - other files that should be copied to the testing directory
+# INSTALL_KSFT_PATH - where to put test programs
+# KSELFTEST - the name of the generated script (which calls the sub-tests)
+# the 'all' target, which makes sure everything is built
+
+# this file defines the 'install' and 'run_tests' targets
+
+CC = $(CROSS_COMPILE)gcc
+INSTALL = $(CROSS_INSTALL)install
+export INSTALL
+
+TEST_STR = ./$(TEST_MAIN_PROG) || echo $(TEST_TITLE) selftests: [FAIL]
+
+install:
+ifdef INSTALL_KSFT_PATH
+ $(INSTALL) ./$(TEST_MAIN_PROG) $(TEST_FILES) $(INSTALL_KSFT_PATH)
+ @echo "$(TEST_STR)" >> $(KSELFTEST)
+else
+ @echo Run make kselftest_install in the top level source directory
+endif
+
+run_tests: all
+ @$(TEST_STR)
diff --git a/tools/testing/selftests/size/Makefile b/tools/testing/selftests/size/Makefile
index bb7113b..c88819a 100644
--- a/tools/testing/selftests/size/Makefile
+++ b/tools/testing/selftests/size/Makefile
@@ -1,22 +1,11 @@
-CC = $(CROSS_COMPILE)gcc
+TEST_MAIN_PROG = get_size
-TEST_STR = ./get_size || echo get_size selftests: [FAIL]
+all: $(TEST_MAIN_PROG)
-all: get_size
+include ../kselftest.include
get_size: get_size.c
$(CC) -static -ffreestanding -nostartfiles -s $< -o $@
-install:
-ifdef INSTALL_KSFT_PATH
- install ./get_size $(INSTALL_KSFT_PATH)
- @echo "$(TEST_STR)" >> $(KSELFTEST)
-else
- @echo Run make kselftest_install in top level source directory
-endif
-
-run_tests: all
- @$(TEST_STR)
-
clean:
- $(RM) get_size
+ $(RM) $(TEST_MAIN_PROG)
--
1.8.2.2
^ permalink raw reply related
* Re: [PATCH net-next] l2tp : multicast notification to the registered listeners
From: David Miller @ 2014-12-31 19:17 UTC (permalink / raw)
To: stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ
Cc: therbert-hpIqsD4AKlfQT0dZR+AlfA, g.nault-pHk1y4uTXVDytLWWfqlThQ,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20141227101239.3ea24d70@urahara>
From: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
Date: Sat, 27 Dec 2014 10:12:39 -0800
> From: Bill Hong <bhong-43mecJUBy8ZBDgjK7y7TUQ@public.gmane.org>
>
> Previously l2tp module did not provide any means for the user space to
> get notified when tunnels/sessions are added/modified/deleted.
> This change contains the following
> - create a multicast group for the listeners to register.
> - notify the registered listeners when the tunnels/sessions are
> created/modified/deleted.
>
> Signed-off-by: Bill Hong <bhong-43mecJUBy8ZBDgjK7y7TUQ@public.gmane.org>
> Reviewed-by: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
> Reviewed-by: Sven-Thorsten Dietrich <sven-43mecJUBy8ZBDgjK7y7TUQ@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH] Documentation: Add entry for dell-laptop sysfs interface
From: Gabriele Mazzotta @ 2014-12-31 11:20 UTC (permalink / raw)
To: Brian Norris
Cc: dvhart, mjg59, linux-api, platform-driver-x86, linux-kernel,
libsmbios-devel, Srinivas_G_Gowda, Michael_E_Brown, pali.rohar,
A.Sloman
In-Reply-To: <20141231053149.GA3764@norris-Latitude-E6410>
On Tuesday 30 December 2014 21:31:49 Brian Norris wrote:
> Hi,
>
> On Wed, Dec 03, 2014 at 06:41:33PM +0100, Gabriele Mazzotta wrote:
> > Add the documentation for the new sysfs interface of dell-laptop
> > that allows to configure the keyboard illumination on Dell systems.
> >
> > Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > ---
> > .../ABI/testing/sysfs-platform-dell-laptop | 60 ++++++++++++++++++++++
> > 1 file changed, 60 insertions(+)
> > create mode 100644 Documentation/ABI/testing/sysfs-platform-dell-laptop
> >
> > diff --git a/Documentation/ABI/testing/sysfs-platform-dell-laptop b/Documentation/ABI/testing/sysfs-platform-dell-laptop
> > new file mode 100644
> > index 0000000..7969443
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-platform-dell-laptop
> > @@ -0,0 +1,60 @@
> > +What: /sys/class/leds/dell::kbd_backlight/als_setting
> > +Date: December 2014
> > +KernelVersion: 3.19
> > +Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
> > + Pali Rohár <pali.rohar@gmail.com>
> > +Description:
> > + This file allows to control the automatic keyboard
> > + illumination mode on some systems that have an ambient
> > + light sensor. Write 1 to this file to enable the auto
> > + mode, 0 to disable it.
> [...]
>
> This entry appears wrong, or at least incomplete. My system boots with a
> default value of 18, and the 'set' implementation accepts any value from
> 0 to 255.
>
> According to the comments in dell-laptop.c, the value actually means
> something different than on/off:
>
> cbArg3, byte0 Desired setting of ALS value that turns the light on or off.
>
> Admittedly, I'm not clear on what the intended interface is, as I've
> never had the ALS / keyboard backlight controls all working properly on
> my laptop in the first place, but I thought this would be the right
> place to ask about getting the documentation and driver in sync.
Hi,
You are perfectly right, the documentation is wrong and I'm sorry for
that. als_setting should allow you to define when the keyboard
backlight has to be turned on or off depending on the value reported
by the ambient light sensor.
Please note that not everything that is in libsmbios [1] is implemented
in the kernel driver. Take a look at it, recently there have been few
changes related to the ALS settings. Probably they are not needed given
that you are able to set the threshold with the current kernel driver,
but you might find something interesting.
I'll submit a patch to correct the documentation, thanks for reporting.
[1] http://linux.dell.com/git/libsmbios.git
> NB: I came across this because
>
> (1) I'd really like to be able to turn the keyboard backlight on, the
> timeout off, and the ALS off; and
>
> (2) I noticed there was a new driver patch in 3.19 (nice! thanks!),
> where previously there must have been some kind of half-functional
> working driver -- I could get backlight control, but it always timed
> out too quickly.
>
> It seems like /sys/.../als_setting is documented to handle the latter
> part of (1), but its implementation does not match.
>
> Thanks,
> Brian
>
> P.S. The author of this page [1] might be interested in these new driver
> additions.
>
> [1] http://www.cs.bham.ac.uk/~axs/laptop/dell-e6410-fn-keys.html
^ permalink raw reply
* Re: [PATCH v6 4/4] crypto: AF_ALG: enable RNG interface compilation
From: Stephan Mueller @ 2014-12-31 7:57 UTC (permalink / raw)
To: Herbert Xu
Cc: Daniel Borkmann, 'Quentin Gouchet', 'LKML',
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20141229104158.GB13699-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Am Montag, 29. Dezember 2014, 21:41:58 schrieb Herbert Xu:
Hi Herbert,
> On Thu, Dec 25, 2014 at 11:00:39PM +0100, Stephan Mueller wrote:
> > Enable compilation of the RNG AF_ALG support and provide a Kconfig
> > option to compile the RNG AF_ALG support.
> >
> > Signed-off-by: Stephan Mueller <smueller-T9tCv8IpfcWELgA04lAiVw@public.gmane.org>
>
> Patch applied.
May I ask you to push the change so that I can create an AEAD Makefile/Kconfig
patch that applies cleanly?
--
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH] Documentation: Add entry for dell-laptop sysfs interface
From: Brian Norris @ 2014-12-31 5:31 UTC (permalink / raw)
To: Gabriele Mazzotta
Cc: dvhart, mjg59, linux-api, platform-driver-x86, linux-kernel,
libsmbios-devel, Srinivas_G_Gowda, Michael_E_Brown, pali.rohar,
A.Sloman
In-Reply-To: <1417628493-29323-1-git-send-email-gabriele.mzt@gmail.com>
Hi,
On Wed, Dec 03, 2014 at 06:41:33PM +0100, Gabriele Mazzotta wrote:
> Add the documentation for the new sysfs interface of dell-laptop
> that allows to configure the keyboard illumination on Dell systems.
>
> Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> ---
> .../ABI/testing/sysfs-platform-dell-laptop | 60 ++++++++++++++++++++++
> 1 file changed, 60 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-platform-dell-laptop
>
> diff --git a/Documentation/ABI/testing/sysfs-platform-dell-laptop b/Documentation/ABI/testing/sysfs-platform-dell-laptop
> new file mode 100644
> index 0000000..7969443
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-platform-dell-laptop
> @@ -0,0 +1,60 @@
> +What: /sys/class/leds/dell::kbd_backlight/als_setting
> +Date: December 2014
> +KernelVersion: 3.19
> +Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
> + Pali Rohár <pali.rohar@gmail.com>
> +Description:
> + This file allows to control the automatic keyboard
> + illumination mode on some systems that have an ambient
> + light sensor. Write 1 to this file to enable the auto
> + mode, 0 to disable it.
[...]
This entry appears wrong, or at least incomplete. My system boots with a
default value of 18, and the 'set' implementation accepts any value from
0 to 255.
According to the comments in dell-laptop.c, the value actually means
something different than on/off:
cbArg3, byte0 Desired setting of ALS value that turns the light on or off.
Admittedly, I'm not clear on what the intended interface is, as I've
never had the ALS / keyboard backlight controls all working properly on
my laptop in the first place, but I thought this would be the right
place to ask about getting the documentation and driver in sync.
NB: I came across this because
(1) I'd really like to be able to turn the keyboard backlight on, the
timeout off, and the ALS off; and
(2) I noticed there was a new driver patch in 3.19 (nice! thanks!),
where previously there must have been some kind of half-functional
working driver -- I could get backlight control, but it always timed
out too quickly.
It seems like /sys/.../als_setting is documented to handle the latter
part of (1), but its implementation does not match.
Thanks,
Brian
P.S. The author of this page [1] might be interested in these new driver
additions.
[1] http://www.cs.bham.ac.uk/~axs/laptop/dell-e6410-fn-keys.html
^ permalink raw reply
* Re: [PATCH v6 1/4] crypto: AF_ALG: add AEAD support
From: Stephan Mueller @ 2014-12-30 21:30 UTC (permalink / raw)
To: Herbert Xu
Cc: Daniel Borkmann, 'Quentin Gouchet', 'LKML',
linux-crypto, linux-api
In-Reply-To: <20141229173340.GA15790@gondor.apana.org.au>
Am Dienstag, 30. Dezember 2014, 04:33:41 schrieb Herbert Xu:
Hi Herbert,
> On Mon, Dec 29, 2014 at 04:05:40PM +0100, Stephan Mueller wrote:
> > This would mean that the check must stay in recvmsg as only here we know
> > that the caller wants data to be processed.
>
> On the send side you would do the check when MSG_MORE is unset.
> On the receive side you should stop waiting only when ctx->more
> is false and the send-side check succeeded.
>
> Perhaps rename ctx->more to ctx->done and then you can use it
> to indicate to the receive side that we're ready and have valid
> data for it. The receive side can then simply wait for ctx->done
> to become true.
I followed your advise and changed the sleep to wait for !ctx->more. Together
with the patch suggested below that was just released, I removed aead_readable
and aead_sufficient_data.
Though, I did not rename ctx->more to ctx->done due to the following:
- other AF_ALG implementations use ctx->more -- to aid code reviewers, I want
to keep the logic as close together as possible
- I do not want to negate the check for MSG_MORE -- at least for me, negating
flags always twists my mind when reading code.
The patch will come shortly after I tested all thoroughly.
>
> > > PS we should add a length check for missing/partial auth tags
> > > to crypto_aead_decrypt. We can then remove such checks from
> > > individual implementations.
> >
> > I agree in full here. Shall I create such a patch together with the AEAD
> > AF_ALG interface, or can we merge the AEAD without that patch now and
> > create a separate patch later?
>
> We should at least add a check in crypto_aead_decrypt first so as
> to guarantee nothing slips through.
>
> Thanks,
--
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH v6 1/4] crypto: AF_ALG: add AEAD support
From: Stephan Mueller @ 2014-12-30 21:03 UTC (permalink / raw)
To: Herbert Xu
Cc: Daniel Borkmann, 'Quentin Gouchet', 'LKML',
linux-crypto, linux-api
In-Reply-To: <20141229173340.GA15790@gondor.apana.org.au>
Am Dienstag, 30. Dezember 2014, 04:33:41 schrieb Herbert Xu:
Hi Herbert,
>
> > > PS we should add a length check for missing/partial auth tags
> > > to crypto_aead_decrypt. We can then remove such checks from
> > > individual implementations.
> >
> > I agree in full here. Shall I create such a patch together with the AEAD
> > AF_ALG interface, or can we merge the AEAD without that patch now and
> > create a separate patch later?
>
> We should at least add a check in crypto_aead_decrypt first so as
> to guarantee nothing slips through.
I have prepared a patch for this which I will release shortly. IMHO that patch
should not have any significant performance penalty. I will also remove the
respective check from the algif_aead implementation.
In addition, I would suggest to add a similar check for the encryption
operation to verify that the ciphertext buffer is at least as large as the
blocks needed for plaintext plus the memory needed for the auth tag (note, my
first attempts working with AEAD lead to days of debugging of kernel crashers
as I did not understand I had too little memory allocated for the ciphertext
buffer). However, such check needs to traverse all plaintext scatterlist
entries which may have a noticeable performance hit.
Do you see the need for such check? If yes, do you see a way to avoid
traversing all plaintext scatterlist entries?
Thanks
--
Ciao
Stephan
^ permalink raw reply
* Re: Edited seccomp.2 man page for review [v2]
From: Michael Kerrisk (man-pages) @ 2014-12-30 19:45 UTC (permalink / raw)
To: Kees Cook
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, Daniel Borkmann, Linux API,
linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, lkml,
Will Drewry
In-Reply-To: <CAGXu5j+C0SWQ+CeOb2ADXdsLWorUHahX4UhUg+UGbT6UuWiQFQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[CC += Will Drewry; Will, maybe you have input on a point below
(search for your name in the message text)]
Kees,
Thanks for the quick response.
On 12/30/2014 06:16 PM, Kees Cook wrote:
> On Tue, Dec 30, 2014 at 4:14 AM, Michael Kerrisk (man-pages)
> <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Hi Kees, (and all),
>>
>> Thanks for your comments on the previous draft of the seccomp(2)
>> man page and (once again) my apologies for the slow follow-up.
>>
>> I have done some further editing of the page. Could you check
>> the revised version below. I have added a number of FIXMEs
>> for points where I'd either like you to check new text that I
>> added (in case it contains errors) or where I hope you can
>> provide answers to questions relating to details that may need
>> clarifying in the page.
>>
>> I've appended the revised page at the foot of this mail. You can also
>> find the branch holding this page in Git at:
>> http://git.kernel.org/cgit/docs/man-pages/man-pages.git/log/?h=draft_seccomp
>>
>> Notable changes from the previous draft:
>> * Several new error cases added under ERRORS
>> * New subsection on Seccomp-specific BPF details
>> * Add some detail in discussion of 'siginfo_t' fields
>> * Tweaked comments on BPF program in EXAMPLE section
>> * Added various FIXMEs
>>
>> I also have one API quibble, regarding the name of the
>> SYS_SECCOMP constant; see below.
>>
>> Feedback as inline comments to the below would be great!
>>
>> Cheers,
>>
>> Michael
>>
>> .\" Copyright (C) 2014 Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>> .\" and Copyright (C) 2012 Will Drewry <wad-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>> .\" and Copyright (C) 2008, 2014 Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> .\"
>> .\" %%%LICENSE_START(VERBATIM)
>> .\" Permission is granted to make and distribute verbatim copies of this
>> .\" manual provided the copyright notice and this permission notice are
>> .\" preserved on all copies.
>> .\"
>> .\" Permission is granted to copy and distribute modified versions of this
>> .\" manual under the conditions for verbatim copying, provided that the
>> .\" entire resulting derived work is distributed under the terms of a
>> .\" permission notice identical to this one.
>> .\"
>> .\" Since the Linux kernel and libraries are constantly changing, this
>> .\" manual page may be incorrect or out-of-date. The author(s) assume no
>> .\" responsibility for errors or omissions, or for damages resulting from
>> .\" the use of the information contained herein. The author(s) may not
>> .\" have taken the same level of care in the production of this manual,
>> .\" which is licensed free of charge, as they might when working
>> .\" professionally.
>> .\"
>> .\" Formatted or processed versions of this manual, if unaccompanied by
>> .\" the source, must acknowledge the copyright and authors of this work.
>> .\" %%%LICENSE_END
>> .\"
>> .TH SECCOMP 2 2014-06-23 "Linux" "Linux Programmer's Manual"
>> .SH NAME
>> seccomp \- operate on Secure Computing state of the process
>> .SH SYNOPSIS
>> .nf
>> .B #include <linux/seccomp.h>
>> .B #include <linux/filter.h>
>> .B #include <linux/audit.h>
>> .B #include <linux/signal.h>
>> .B #include <sys/ptrace.h>
>> .\" Kees Cook noted: Anything that uses SECCOMP_RET_TRACE returns will
>> .\" need <sys/ptrace.h>
>>
>> .BI "int seccomp(unsigned int " operation ", unsigned int " flags \
>> ", void *" args );
>> .fi
>> .SH DESCRIPTION
>> The
>> .BR seccomp ()
>> system call operates on the Secure Computing (seccomp) state of the
>> calling process.
>>
>> Currently, Linux supports the following
>> .IR operation
>> values:
>> .TP
>> .BR SECCOMP_SET_MODE_STRICT
>> The only system calls that the calling thread is permitted to make are
>> .BR read (2),
>> .BR write (2),
>> .BR _exit (2),
>> and
>> .BR sigreturn (2).
>> Other system calls result in the delivery of a
>> .BR SIGKILL
>> signal.
>> Strict secure computing mode is useful for number-crunching
>> applications that may need to execute untrusted byte code, perhaps
>> obtained by reading from a pipe or socket.
>>
>> This operation is available only if the kernel is configured with
>> .BR CONFIG_SECCOMP
>> enabled.
>>
>> The value of
>> .IR flags
>> must be 0, and
>> .IR args
>> must be NULL.
>>
>> This operation is functionally identical to the call:
>>
>> prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT);
>> .TP
>> .BR SECCOMP_SET_MODE_FILTER
>> The system calls allowed are defined by a pointer to a Berkeley Packet
>> Filter (BPF) passed via
>> .IR args .
>> This argument is a pointer to a
>> .IR "struct\ sock_fprog" ;
>> it can be designed to filter arbitrary system calls and system call
>> arguments.
>> If the filter is invalid,
>> .BR seccomp ()
>> fails, returning
>> .BR EINVAL
>> in
>> .IR errno .
>>
>> If
>> .BR fork (2)
>> or
>> .BR clone (2)
>> is allowed by the filter, any child processes will be constrained to
>> the same system call filters as the parent.
>> If
>> .BR execve (2)
>> is allowed,
>> the existing filters will be preserved across a call to
>> .BR execve (2).
>>
>> In order to use the
>> .BR SECCOMP_SET_MODE_FILTER
>> operation, either the caller must have the
>> .BR CAP_SYS_ADMIN
>> capability, or the thread must already have the
>> .I no_new_privs
>> bit set.
>> If that bit was not already set by an ancestor of this thread,
>> the thread must make the following call:
>>
>> prctl(PR_SET_NO_NEW_PRIVS, 1);
>>
>> Otherwise, the
>> .BR SECCOMP_SET_MODE_FILTER
>> operation will fail and return
>> .BR EACCES
>> in
>> .IR errno .
>> This requirement ensures that an unprivileged process cannot apply
>> a malicious filter and then invoke a set-user-ID or
>> other privileged program using
>> .BR execve (2),
>> thus potentially compromising that program.
>> (Such a malicious filter might, for example, cause an attempt to use
>> .BR setuid (2)
>> to set the caller's user IDs to non-zero values to instead
>> return 0 without actually making the system call.
>> Thus, the program might be tricked into retaining superuser privileges
>> in circumstances where it is possible to influence it to do
>> dangerous things because it did not actually drop privileges.)
>>
>> If
>> .BR prctl (2)
>> or
>> .BR seccomp (2)
>> is allowed by the attached filter, further filters may be added.
>> This will increase evaluation time, but allows for further reduction of
>> the attack surface during execution of a thread.
>>
>> The
>> .BR SECCOMP_SET_MODE_FILTER
>> operation is available only if the kernel is configured with
>> .BR CONFIG_SECCOMP_FILTER
>> enabled.
>>
>> When
>> .IR flags
>> is 0, this operation is functionally identical to the call:
>>
>> prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, args);
>>
>> The recognized
>> .IR flags
>> are:
>> .RS
>> .TP
>> .BR SECCOMP_FILTER_FLAG_TSYNC
>> When adding a new filter, synchronize all other threads of the calling
>> process to the same seccomp filter tree.
>> A "filter tree" is the ordered list of filters attached to a thread.
>> (Attaching identical filters in separate
>> .BR seccomp ()
>> calls results in different filters from this perspective.)
>>
>> If any thread cannot synchronize to the same filter tree,
>> the call will not attach the new seccomp filter,
>> and will fail, returning the first thread ID found that cannot synchronize.
>> Synchronization will fail if another thread in the same process is in
>> .BR SECCOMP_MODE_STRICT
>> or if it has attached new seccomp filters to itself,
>> diverging from the calling thread's filter tree.
>> .RE
>> .SS Filters
>> When adding filters via
>> .BR SECCOMP_SET_MODE_FILTER ,
>> .IR args
>> points to a filter program:
>>
>> .in +4n
>> .nf
>> struct sock_fprog {
>> unsigned short len; /* Number of BPF instructions */
>> struct sock_filter *filter; /* Pointer to array of
>> BPF instructions */
>> };
>> .fi
>> .in
>>
>> Each program must contain one or more BPF instructions:
>>
>> .in +4n
>> .nf
>> struct sock_filter { /* Filter block */
>> __u16 code; /* Actual filter code */
>> __u8 jt; /* Jump true */
>> __u8 jf; /* Jump false */
>> __u32 k; /* Generic multiuse field */
>> };
>> .fi
>> .in
>>
>> .\" FIXME I reworded/enhanced the following sentence. Is it okay?
>> When executing the instructions, the BPF program operates on the
>> system call information made available (i.e., use the
>> .BR BPF_ABS
>> addressing mode) as a buffer of the following form:
>
> That looks correct to me, yes.
Okay. Thanks.
>> .in +4n
>> .nf
>> struct seccomp_data {
>> int nr; /* System call number */
>> __u32 arch; /* AUDIT_ARCH_* value
>> (see <linux/audit.h>) */
>> __u64 instruction_pointer; /* CPU instruction pointer */
>> __u64 args[6]; /* Up to 6 system call arguments */
>> };
>> .fi
>> .in
>>
>> A seccomp filter returns a 32-bit value consisting of two parts:
>> the most significant 16 bits
>> (corresponding to the mask defined by the constant
>> .BR SECCOMP_RET_ACTION )
>> contain one of the "action" values listed below;
>> the least significant 16-bits (defined by the constant
>> .BR SECCOMP_RET_DATA )
>> are "data" to be associated with this return value.
>>
>> If multiple filters exist, they are all executed,
>> in reverse order of their addition to the filter tree
>> (i.e., the most recently installed filter is executed first).
>> The return value for the evaluation of a given system call is the first-seen
>> .BR SECCOMP_RET_ACTION
>> value of highest precedence (along with its accompanying data)
>> returned by execution of all of the filters.
>>
>> In decreasing order of precedence,
>> the values that may be returned by a seccomp filter are:
>> .TP
>> .BR SECCOMP_RET_KILL
>> This value results in the process exiting immediately
>> without executing the system call.
>> The process terminates as though killed by a
>> .B SIGSYS
>> signal
>> .RI ( not
>> .BR SIGKILL ).
>> .TP
>> .BR SECCOMP_RET_TRAP
>> This value results in the kernel sending a
>> .BR SIGSYS
>> signal to the triggering process without executing the system call.
>> Various fields will be set in the
>> .I siginfo_t
>> structure (see
>> .BR sigaction (2))
>> associated with signal:
>> .RS
>> .IP * 3
>> .I si_signo
>> will contain
>> .BR SIGSYS .
>> .IP *
>> .IR si_call_addr
>> will show the address of the system call instruction.
>> .IP *
>> .IR si_syscall
>> and
>> .IR si_arch
>> will indicate which system call was attempted.
>> .IP *
>> .I si_code
>> .\" FIXME Why is the constant thus named? All of the other 'si_code'
>> .\" constants are prefixed 'SI_'. Why the inconsistency?
>> will contain
>> .BR SYS_SECCOMP .
>
> Only certain reserved values have the SI_ prefix. All the
> signal-specific values have their signal name as the prefix. See ILL_*
> FPE_* SEGV_* BUS_* TRAP_* CLD_* POLL_* and SYS_*. I see these in
> /usr/include/asm-generic/siginfo.h
Ahh -- yes, of course. Thanks.
>> .IP *
>> .I si_errno
>> will contain the
>> .BR SECCOMP_RET_DATA
>> portion of the filter return value.
>> .RE
>> .IP
>> The program counter will be as though the system call happened
>> (i.e., it will not point to the system call instruction).
>> The return value register will contain an architecture\-dependent value;
>> if resuming execution, set it to something sensible.
>> .\" FIXME Regarding the preceding line, can you give an example(s)
>> .\" of "something sensible"? (Depending on the answer, maybe it
>> .\" might be useful to add some text on this point.)
>
> This means sensible in the context of the syscall made, or the desired
> behavior. For example, setting the return value to ELOOP for something
> like a "bind" syscall isn't very sensible.
Okay -- I did s/sensible/appropriate for the system call/
>> .\"
>> .\" FIXME Please check:
>> .\" In an attempt to make the text clearer, I changed
>> .\" "replacing it with" to "setting the return value register to"
>> .\" Okay?
>> (The architecture dependency is because setting the return value register to
>> .BR ENOSYS
>> could overwrite some useful information.)
>
> Well, the arch dependency is really because _how_ to change the
> register, and the register itself, is different between architectures.
> (i.e. which ptrace call is needed, and which register is being
> changed.) The overwriting of useful information is certainly true too,
> though.
So, revert to the previous wording? Or do you have a suggested
better wording?
>> .TP
>> .BR SECCOMP_RET_ERRNO
>> This value results in the
>> .B SECCOMP_RET_DATA
>> portion of the filter's return value being passed to user space as the
>> .IR errno
>> value without executing the system call.
>> .TP
>> .BR SECCOMP_RET_TRACE
>> When returned, this value will cause the kernel to attempt to notify a
>> .BR ptrace (2)-based
>> tracer prior to executing the system call.
>> If there is no tracer present,
>> the system call is not executed and returns a failure status with
>> .I errno
>> set to
>> .BR ENOSYS .
>>
>> A tracer will be notified if it requests
>> .BR PTRACE_O_TRACESECCOMP
>> using
>> .IR ptrace(PTRACE_SETOPTIONS) .
>> The tracer will be notified of a
>> .BR PTRACE_EVENT_SECCOMP
>> and the
>> .BR SECCOMP_RET_DATA
>> portion of the filter's return value will be available to the tracer via
>> .BR PTRACE_GETEVENTMSG .
>>
>> The tracer can skip the system call by changing the system call number
>> to \-1.
>> Alternatively, the tracer can change the system call
>> requested by changing the system call to a valid system call number.
>> If the tracer asks to skip the system call, then the system call will
>> appear to return the value that the tracer puts in the return value register.
>>
>> The seccomp check will not be run again after the tracer is notified.
>> (This means that seccomp-based sandboxes
>> .B "must not"
>> allow use of
>> .BR ptrace (2)\(emeven
>> of other
>> sandboxed processes\(emwithout extreme care;
>> .\" FIXME Below, I think it would be helpful to add some words after
>> .\" "to escape", as in "to escape [what?]" I suppose the wording
>> .\" would be something like "to escape the seccomp sandbox mechanism"
>> .\" but perhaps you have a better wording.
>> ptracers can use this mechanism to escape.)
>
> Yeah, that could be further clarified to "... use this mechanism to
> escape from the seccomp sandbox." How does that sound?
Good. Changed.
>> .TP
>> .BR SECCOMP_RET_ALLOW
>> This value results in the system call being executed.
>> .SH RETURN VALUE
>> On success,
>> .BR seccomp ()
>> returns 0.
>> On error, if
>> .BR SECCOMP_FILTER_FLAG_TSYNC
>> was used,
>> the return value is the ID of the thread
>> that caused the synchronization failure.
>> (This ID is a kernel thread ID of the type returned by
>> .BR clone (2)
>> and
>> .BR gettid (2).)
>> On other errors, \-1 is returned, and
>> .IR errno
>> is set to indicate the cause of the error.
>> .SH ERRORS
>> .BR seccomp ()
>> can fail for the following reasons:
>> .TP
>> .BR EACCESS
>> The caller did not have the
>> .BR CAP_SYS_ADMIN
>> capability, or had not set
>> .IR no_new_privs
>> before using
>> .BR SECCOMP_SET_MODE_FILTER .
>> .TP
>> .BR EFAULT
>> .IR args
>> was not a valid address.
>> .TP
>> .BR EINVAL
>> .IR operation
>> is unknown; or
>> .IR flags
>> are invalid for the given
>> .IR operation .
>> .\" FIXME Please review the following
>> .TP
>> .BR EINVAL
>> .I operation
>> included
>> .BR BPF_ABS ,
>> but the specified offset was not aligned to a 32-bit boundary or exceeded
>> .IR "sizeof(struct\ seccomp_data)" .
>> .\" FIXME Please review the following
>> .TP
>> .BR EINVAL
>> .\" See kernel/seccomp.c::seccomp_may_assign_mode() in 3.18 sources
>> A secure computing mode has already been set, and
>> .I operation
>> differs from the existing setting.
>> .\" FIXME Please review the following
>> .TP
>> .BR EINVAL
>> .\" See stub kernel/seccomp.c::seccomp_set_mode_filter() in 3.18 sources
>> .I operation
>> specified
>> .BR SECCOMP_SET_MODE_FILTER ,
>> but the kernel was not built with
>> .B CONFIG_SECCOMP_FILTER
>> enabled.
>> .\" FIXME Please review the following
>> .TP
>> .BR EINVAL
>> .I operation
>> specified
>> .BR SECCOMP_SET_MODE_FILTER ,
>> but the filter program pointed to by
>> .I args
>> was not valid or the length of the filter program was zero or exceeded
>> .B BPF_MAXINSNS
>> (4096) instructions.
>> .BR EINVAL
>> .TP
>> .BR ENOMEM
>> Out of memory.
>> .\" FIXME Please review the following
>> .TP
>> .BR ENOMEM
>> .\" ENOMEM in kernel/seccomp.c::seccomp_attach_filter() in 3.18 sources
>> The total length of all filter programs attached
>> to the calling thread would exceed
>> .B MAX_INSNS_PER_PATH
>> (32768) instructions.
>> Note that for the purposes of calculating this limit,
>> each already existing filter program incurs an
>> overhead penalty of 4 instructions.
>> .TP
>> .BR ESRCH
>> Another thread caused a failure during thread sync, but its ID could not
>> be determined.
>> .SH VERSIONS
>> The
>> .BR seccomp()
>> system call first appeared in Linux 3.17.
>> .\" FIXME . Add glibc version
>> .SH CONFORMING TO
>> The
>> .BR seccomp()
>> system call is a nonstandard Linux extension.
>> .SH NOTES
>> .BR seccomp ()
>> provides a superset of the functionality provided by the
>> .BR prctl (2)
>> .BR PR_SET_SECCOMP
>> operation (which does not support
>> .IR flags ).
>> .\" FIXME Please review the following new subsection {{{
>> .SS Seccomp-specific BPF details
>> Note the following BPF details specific to seccomp filters:
>> .IP * 3
>> The
>> .B BPF_H
>> and
>> .B BPF_B
>> size modifiers are not supported: all operations must load and store
>> (4-byte) words
>> .RB ( BPF_W ).
>> .IP *
>> To access the contents of the
>> .I seccomp_data
>> buffer, use the
>> .B BPF_ABS
>> addressing mode modifier.
>> .\" FIXME What is the significance of the line
>> .\" ftest->code = BPF_LDX | BPF_W | BPF_ABS;
>> .\" in kernel/seccomp.c::seccomp_check_filter()?
>
> This is converting an accumulator load (BPF_LD) into a index load
> (BPF_LDX). I think this is to avoid addressing modes 1 and 2, but Will
> may remember more here. The LD|W|ABS structure is very common, so I
> think this was a way to accept that in the filter, but change it into
> a more limited command.
Will, could you comment?
>> .IP *
>> The
>> .B BPF_LEN
>> addressing mode modifier yields an immediate mode operand
>> whose value is the size of the
>> .IR seccomp_data
>> buffer.
>> .\" FIXME Any other seccomp-specific BPF details that should be added here?
>> .\"
>> .\" FIXME End of new subsection for review }}}
>
> All the rest of the FIXMEs above (excepting the standing glibc one)
> looks correct to me.
Okay. Thanks.
>> .SH EXAMPLE
>> The program below accepts four or more arguments.
>> The first three arguments are a system call number,
>> a numeric architecture identifier, and an error number.
>> The program uses these values to construct a BPF filter
>> that is used at run time to perform the following checks:
>> .IP [1] 4
>> If the program is not running on the specified architecture,
>> the BPF filter causes system calls to fail with the error
>> .BR ENOSYS .
>> .IP [2]
>> If the program attempts to execute the system call with the specified number,
>> the BPF filter causes the system call to fail, with
>> .I errno
>> being set to the specified error number.
>> .PP
>> The remaining command-line arguments specify
>> the pathname and additional arguments of a program
>> that the example program should attempt to execute using
>> .BR execve (3)
>> (a library function that employs the
>> .BR execve (2)
>> system call).
>> Some example runs of the program are shown below.
>>
>> First, we display the architecture that we are running on (x86-64)
>> and then construct a shell function that looks up system call
>> numbers on this architecture:
>>
>> .nf
>> .in +4n
>> $ \fBuname -m\fP
>> x86_64
>> $ \fBsyscall_nr() {
>> cat /usr/src/linux/arch/x86/syscalls/syscall_64.tbl | \\
>> awk '$2 != "x32" && $3 == "'$1'" { print $1 }'
>> }\fP
>> .in
>> .fi
>>
>> When the BPF filter rejects a system call (case [2] above),
>> it causes the system call to fail with the error number
>> specified on the command line.
>> In the experiments shown here, we'll use error number 99:
>>
>> .nf
>> .in +4n
>> $ \fBerrno 99\fP
>> EADDRNOTAVAIL 99 Cannot assign requested address
>> .in
>> .fi
>>
>> In the following example, we attempt to run the command
>> .BR whoami (1),
>> but the BPF filter rejects the
>> .BR execve (2)
>> system call, so that the command is not even executed:
>>
>> .nf
>> .in +4n
>> $ \fBsyscall_nr execve\fP
>> 59
>> $ \fB./a.out\fP
>> Usage: ./a.out <syscall_nr> <arch> <errno> <prog> [<args>]
>> Hint for <arch>: AUDIT_ARCH_I386: 0x40000003
>> AUDIT_ARCH_X86_64: 0xC000003E
>> $ \fB./a.out 59 0xC000003E 99 /bin/whoami\fP
>> execv: Cannot assign requested address
>> .in
>> .fi
>>
>> In the next example, the BPF filter rejects the
>> .BR write (2)
>> system call, so that, although it is successfully started, the
>> .BR whoami (1)
>> command is not able to write output:
>>
>> .nf
>> .in +4n
>> $ \fBsyscall_nr write\fP
>> 1
>> $ \fB./a.out 1 0xC000003E 99 /bin/whoami\fP
>> .in
>> .fi
>>
>> In the final example,
>> the BPF filter rejects a system call that is not used by the
>> .BR whoami (1)
>> command, so it is able to successfully execute and produce output:
>>
>> .nf
>> .in +4n
>> $ \fBsyscall_nr preadv\fP
>> 295
>> $ \fB./a.out 295 0xC000003E 99 /bin/whoami\fP
>> cecilia
>> .in
>> .fi
>> .SS Program source
>> .fi
>> .nf
>> #include <errno.h>
>> #include <stddef.h>
>> #include <stdio.h>
>> #include <stdlib.h>
>> #include <unistd.h>
>> #include <linux/audit.h>
>> #include <linux/filter.h>
>> #include <linux/seccomp.h>
>> #include <sys/prctl.h>
>>
>> static int
>> install_filter(int syscall_nr, int t_arch, int f_errno)
>> {
>> .\" FIXME In the BPF program below, you use '+' to build the instructions.
>> .\" However, most other BPF example code I see uses '|'. While I
>> .\" assume it's equivalent (i.e., the bit fields are nonoverlapping),
>> .\" was there a reason to use '+' rather than '|'? (To me, the
>> .\" latter is a little clearer in its intent.)
>
> Ah, no, "|" should be used, good catch.
Okay -- all instances of '+' changed to '|'
>> .\"
>> .\" FIXME I expanded comments [0], [1], [2], [3], [4] a little.
>> .\" Are they okay? */
>
> Yup, these look good to me.
Okay. Thanks.
>
>> .\"
>> struct sock_filter filter[] = {
>> /* [0] Load architecture from 'seccomp_data' buffer into
>> accumulator */
>> BPF_STMT(BPF_LD + BPF_W + BPF_ABS,
>> (offsetof(struct seccomp_data, arch))),
>>
>> /* [1] Jump forward 4 instructions if architecture does not
>> match 't_arch' */
>> BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, t_arch, 0, 4),
>>
>> /* [2] Load system call number from 'seccomp_data' buffer into
>> accumulator */
>> BPF_STMT(BPF_LD + BPF_W + BPF_ABS,
>> (offsetof(struct seccomp_data, nr))),
>>
>> /* [3] Jump forward 1 instruction if system call number
>> does not match 'syscall_nr' */
>> BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, syscall_nr, 0, 1),
>>
>> /* [4] Matching architecture and system call: don't execute
>> the system call, and return 'f_errno' in 'errno' */
>> BPF_STMT(BPF_RET + BPF_K,
>> SECCOMP_RET_ERRNO | (f_errno & SECCOMP_RET_DATA)),
>>
>> /* [5] Destination of system call number mismatch: allow other
>> system calls */
>> BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_ALLOW),
>>
>> /* [6] Destination of architecture mismatch: kill process */
>> BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_KILL),
>> };
>>
>> struct sock_fprog prog = {
>> .len = (unsigned short) (sizeof(filter) / sizeof(filter[0])),
>> .filter = filter,
>> };
>>
>> if (seccomp(SECCOMP_SET_MODE_FILTER, 0, &prog)) {
>> perror("seccomp");
>> return 1;
>> }
>>
>> return 0;
>> }
>>
>> int
>> main(int argc, char **argv)
>> {
>> if (argc < 5) {
>> fprintf(stderr, "Usage: "
>> "%s <syscall_nr> <arch> <errno> <prog> [<args>]\\n"
>> "Hint for <arch>: AUDIT_ARCH_I386: 0x%X\\n"
>> " AUDIT_ARCH_X86_64: 0x%X\\n"
>> "\\n", argv[0], AUDIT_ARCH_I386, AUDIT_ARCH_X86_64);
>> exit(EXIT_FAILURE);
>> }
>>
>> if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) {
>> perror("prctl");
>> exit(EXIT_FAILURE);
>> }
>>
>> if (install_filter(strtol(argv[1], NULL, 0),
>> strtol(argv[2], NULL, 0),
>> strtol(argv[3], NULL, 0)))
>> exit(EXIT_FAILURE);
>>
>> execv(argv[4], &argv[4]);
>> perror("execv");
>> exit(EXIT_FAILURE);
>> }
>> .fi
>> .SH SEE ALSO
>> .BR prctl (2),
>> .BR ptrace (2),
>> .BR signal (7),
>> .BR socket (7)
>> .sp
>> The kernel source files
>> .IR Documentation/networking/filter.txt
>> and
>> .IR Documentation/prctl/seccomp_filter.txt .
>> .sp
>> McCanne, S. and Jacobson, V. (1992)
>> .IR "The BSD Packet Filter: A New Architecture for User-level Packet Capture" ,
>> Proceedings of the USENIX Winter 1993 Conference
>> .UR http://www.tcpdump.org/papers/bpf-usenix93.pdf
>> .UE
>
> Thanks for the additional details and clarifications!
Thanks. We're getting close now.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Edited seccomp.2 man page for review [v2]
From: Kees Cook @ 2014-12-30 17:16 UTC (permalink / raw)
To: Michael Kerrisk (man-pages)
Cc: Daniel Borkmann, Linux API,
linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, lkml
In-Reply-To: <54A29722.1010901-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Dec 30, 2014 at 4:14 AM, Michael Kerrisk (man-pages)
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi Kees, (and all),
>
> Thanks for your comments on the previous draft of the seccomp(2)
> man page and (once again) my apologies for the slow follow-up.
>
> I have done some further editing of the page. Could you check
> the revised version below. I have added a number of FIXMEs
> for points where I'd either like you to check new text that I
> added (in case it contains errors) or where I hope you can
> provide answers to questions relating to details that may need
> clarifying in the page.
>
> I've appended the revised page at the foot of this mail. You can also
> find the branch holding this page in Git at:
> http://git.kernel.org/cgit/docs/man-pages/man-pages.git/log/?h=draft_seccomp
>
> Notable changes from the previous draft:
> * Several new error cases added under ERRORS
> * New subsection on Seccomp-specific BPF details
> * Add some detail in discussion of 'siginfo_t' fields
> * Tweaked comments on BPF program in EXAMPLE section
> * Added various FIXMEs
>
> I also have one API quibble, regarding the name of the
> SYS_SECCOMP constant; see below.
>
> Feedback as inline comments to the below would be great!
>
> Cheers,
>
> Michael
>
> .\" Copyright (C) 2014 Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> .\" and Copyright (C) 2012 Will Drewry <wad-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> .\" and Copyright (C) 2008, 2014 Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> .\"
> .\" %%%LICENSE_START(VERBATIM)
> .\" Permission is granted to make and distribute verbatim copies of this
> .\" manual provided the copyright notice and this permission notice are
> .\" preserved on all copies.
> .\"
> .\" Permission is granted to copy and distribute modified versions of this
> .\" manual under the conditions for verbatim copying, provided that the
> .\" entire resulting derived work is distributed under the terms of a
> .\" permission notice identical to this one.
> .\"
> .\" Since the Linux kernel and libraries are constantly changing, this
> .\" manual page may be incorrect or out-of-date. The author(s) assume no
> .\" responsibility for errors or omissions, or for damages resulting from
> .\" the use of the information contained herein. The author(s) may not
> .\" have taken the same level of care in the production of this manual,
> .\" which is licensed free of charge, as they might when working
> .\" professionally.
> .\"
> .\" Formatted or processed versions of this manual, if unaccompanied by
> .\" the source, must acknowledge the copyright and authors of this work.
> .\" %%%LICENSE_END
> .\"
> .TH SECCOMP 2 2014-06-23 "Linux" "Linux Programmer's Manual"
> .SH NAME
> seccomp \- operate on Secure Computing state of the process
> .SH SYNOPSIS
> .nf
> .B #include <linux/seccomp.h>
> .B #include <linux/filter.h>
> .B #include <linux/audit.h>
> .B #include <linux/signal.h>
> .B #include <sys/ptrace.h>
> .\" Kees Cook noted: Anything that uses SECCOMP_RET_TRACE returns will
> .\" need <sys/ptrace.h>
>
> .BI "int seccomp(unsigned int " operation ", unsigned int " flags \
> ", void *" args );
> .fi
> .SH DESCRIPTION
> The
> .BR seccomp ()
> system call operates on the Secure Computing (seccomp) state of the
> calling process.
>
> Currently, Linux supports the following
> .IR operation
> values:
> .TP
> .BR SECCOMP_SET_MODE_STRICT
> The only system calls that the calling thread is permitted to make are
> .BR read (2),
> .BR write (2),
> .BR _exit (2),
> and
> .BR sigreturn (2).
> Other system calls result in the delivery of a
> .BR SIGKILL
> signal.
> Strict secure computing mode is useful for number-crunching
> applications that may need to execute untrusted byte code, perhaps
> obtained by reading from a pipe or socket.
>
> This operation is available only if the kernel is configured with
> .BR CONFIG_SECCOMP
> enabled.
>
> The value of
> .IR flags
> must be 0, and
> .IR args
> must be NULL.
>
> This operation is functionally identical to the call:
>
> prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT);
> .TP
> .BR SECCOMP_SET_MODE_FILTER
> The system calls allowed are defined by a pointer to a Berkeley Packet
> Filter (BPF) passed via
> .IR args .
> This argument is a pointer to a
> .IR "struct\ sock_fprog" ;
> it can be designed to filter arbitrary system calls and system call
> arguments.
> If the filter is invalid,
> .BR seccomp ()
> fails, returning
> .BR EINVAL
> in
> .IR errno .
>
> If
> .BR fork (2)
> or
> .BR clone (2)
> is allowed by the filter, any child processes will be constrained to
> the same system call filters as the parent.
> If
> .BR execve (2)
> is allowed,
> the existing filters will be preserved across a call to
> .BR execve (2).
>
> In order to use the
> .BR SECCOMP_SET_MODE_FILTER
> operation, either the caller must have the
> .BR CAP_SYS_ADMIN
> capability, or the thread must already have the
> .I no_new_privs
> bit set.
> If that bit was not already set by an ancestor of this thread,
> the thread must make the following call:
>
> prctl(PR_SET_NO_NEW_PRIVS, 1);
>
> Otherwise, the
> .BR SECCOMP_SET_MODE_FILTER
> operation will fail and return
> .BR EACCES
> in
> .IR errno .
> This requirement ensures that an unprivileged process cannot apply
> a malicious filter and then invoke a set-user-ID or
> other privileged program using
> .BR execve (2),
> thus potentially compromising that program.
> (Such a malicious filter might, for example, cause an attempt to use
> .BR setuid (2)
> to set the caller's user IDs to non-zero values to instead
> return 0 without actually making the system call.
> Thus, the program might be tricked into retaining superuser privileges
> in circumstances where it is possible to influence it to do
> dangerous things because it did not actually drop privileges.)
>
> If
> .BR prctl (2)
> or
> .BR seccomp (2)
> is allowed by the attached filter, further filters may be added.
> This will increase evaluation time, but allows for further reduction of
> the attack surface during execution of a thread.
>
> The
> .BR SECCOMP_SET_MODE_FILTER
> operation is available only if the kernel is configured with
> .BR CONFIG_SECCOMP_FILTER
> enabled.
>
> When
> .IR flags
> is 0, this operation is functionally identical to the call:
>
> prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, args);
>
> The recognized
> .IR flags
> are:
> .RS
> .TP
> .BR SECCOMP_FILTER_FLAG_TSYNC
> When adding a new filter, synchronize all other threads of the calling
> process to the same seccomp filter tree.
> A "filter tree" is the ordered list of filters attached to a thread.
> (Attaching identical filters in separate
> .BR seccomp ()
> calls results in different filters from this perspective.)
>
> If any thread cannot synchronize to the same filter tree,
> the call will not attach the new seccomp filter,
> and will fail, returning the first thread ID found that cannot synchronize.
> Synchronization will fail if another thread in the same process is in
> .BR SECCOMP_MODE_STRICT
> or if it has attached new seccomp filters to itself,
> diverging from the calling thread's filter tree.
> .RE
> .SS Filters
> When adding filters via
> .BR SECCOMP_SET_MODE_FILTER ,
> .IR args
> points to a filter program:
>
> .in +4n
> .nf
> struct sock_fprog {
> unsigned short len; /* Number of BPF instructions */
> struct sock_filter *filter; /* Pointer to array of
> BPF instructions */
> };
> .fi
> .in
>
> Each program must contain one or more BPF instructions:
>
> .in +4n
> .nf
> struct sock_filter { /* Filter block */
> __u16 code; /* Actual filter code */
> __u8 jt; /* Jump true */
> __u8 jf; /* Jump false */
> __u32 k; /* Generic multiuse field */
> };
> .fi
> .in
>
> .\" FIXME I reworded/enhanced the following sentence. Is it okay?
> When executing the instructions, the BPF program operates on the
> system call information made available (i.e., use the
> .BR BPF_ABS
> addressing mode) as a buffer of the following form:
That looks correct to me, yes.
>
> .in +4n
> .nf
> struct seccomp_data {
> int nr; /* System call number */
> __u32 arch; /* AUDIT_ARCH_* value
> (see <linux/audit.h>) */
> __u64 instruction_pointer; /* CPU instruction pointer */
> __u64 args[6]; /* Up to 6 system call arguments */
> };
> .fi
> .in
>
> A seccomp filter returns a 32-bit value consisting of two parts:
> the most significant 16 bits
> (corresponding to the mask defined by the constant
> .BR SECCOMP_RET_ACTION )
> contain one of the "action" values listed below;
> the least significant 16-bits (defined by the constant
> .BR SECCOMP_RET_DATA )
> are "data" to be associated with this return value.
>
> If multiple filters exist, they are all executed,
> in reverse order of their addition to the filter tree
> (i.e., the most recently installed filter is executed first).
> The return value for the evaluation of a given system call is the first-seen
> .BR SECCOMP_RET_ACTION
> value of highest precedence (along with its accompanying data)
> returned by execution of all of the filters.
>
> In decreasing order of precedence,
> the values that may be returned by a seccomp filter are:
> .TP
> .BR SECCOMP_RET_KILL
> This value results in the process exiting immediately
> without executing the system call.
> The process terminates as though killed by a
> .B SIGSYS
> signal
> .RI ( not
> .BR SIGKILL ).
> .TP
> .BR SECCOMP_RET_TRAP
> This value results in the kernel sending a
> .BR SIGSYS
> signal to the triggering process without executing the system call.
> Various fields will be set in the
> .I siginfo_t
> structure (see
> .BR sigaction (2))
> associated with signal:
> .RS
> .IP * 3
> .I si_signo
> will contain
> .BR SIGSYS .
> .IP *
> .IR si_call_addr
> will show the address of the system call instruction.
> .IP *
> .IR si_syscall
> and
> .IR si_arch
> will indicate which system call was attempted.
> .IP *
> .I si_code
> .\" FIXME Why is the constant thus named? All of the other 'si_code'
> .\" constants are prefixed 'SI_'. Why the inconsistency?
> will contain
> .BR SYS_SECCOMP .
Only certain reserved values have the SI_ prefix. All the
signal-specific values have their signal name as the prefix. See ILL_*
FPE_* SEGV_* BUS_* TRAP_* CLD_* POLL_* and SYS_*. I see these in
/usr/include/asm-generic/siginfo.h
> .IP *
> .I si_errno
> will contain the
> .BR SECCOMP_RET_DATA
> portion of the filter return value.
> .RE
> .IP
> The program counter will be as though the system call happened
> (i.e., it will not point to the system call instruction).
> The return value register will contain an architecture\-dependent value;
> if resuming execution, set it to something sensible.
> .\" FIXME Regarding the preceding line, can you give an example(s)
> .\" of "something sensible"? (Depending on the answer, maybe it
> .\" might be useful to add some text on this point.)
This means sensible in the context of the syscall made, or the desired
behavior. For example, setting the return value to ELOOP for something
like a "bind" syscall isn't very sensible.
> .\"
> .\" FIXME Please check:
> .\" In an attempt to make the text clearer, I changed
> .\" "replacing it with" to "setting the return value register to"
> .\" Okay?
> (The architecture dependency is because setting the return value register to
> .BR ENOSYS
> could overwrite some useful information.)
Well, the arch dependency is really because _how_ to change the
register, and the register itself, is different between architectures.
(i.e. which ptrace call is needed, and which register is being
changed.) The overwriting of useful information is certainly true too,
though.
> .TP
> .BR SECCOMP_RET_ERRNO
> This value results in the
> .B SECCOMP_RET_DATA
> portion of the filter's return value being passed to user space as the
> .IR errno
> value without executing the system call.
> .TP
> .BR SECCOMP_RET_TRACE
> When returned, this value will cause the kernel to attempt to notify a
> .BR ptrace (2)-based
> tracer prior to executing the system call.
> If there is no tracer present,
> the system call is not executed and returns a failure status with
> .I errno
> set to
> .BR ENOSYS .
>
> A tracer will be notified if it requests
> .BR PTRACE_O_TRACESECCOMP
> using
> .IR ptrace(PTRACE_SETOPTIONS) .
> The tracer will be notified of a
> .BR PTRACE_EVENT_SECCOMP
> and the
> .BR SECCOMP_RET_DATA
> portion of the filter's return value will be available to the tracer via
> .BR PTRACE_GETEVENTMSG .
>
> The tracer can skip the system call by changing the system call number
> to \-1.
> Alternatively, the tracer can change the system call
> requested by changing the system call to a valid system call number.
> If the tracer asks to skip the system call, then the system call will
> appear to return the value that the tracer puts in the return value register.
>
> The seccomp check will not be run again after the tracer is notified.
> (This means that seccomp-based sandboxes
> .B "must not"
> allow use of
> .BR ptrace (2)\(emeven
> of other
> sandboxed processes\(emwithout extreme care;
> .\" FIXME Below, I think it would be helpful to add some words after
> .\" "to escape", as in "to escape [what?]" I suppose the wording
> .\" would be something like "to escape the seccomp sandbox mechanism"
> .\" but perhaps you have a better wording.
> ptracers can use this mechanism to escape.)
Yeah, that could be further clarified to "... use this mechanism to
escape from the seccomp sandbox." How does that sound?
> .TP
> .BR SECCOMP_RET_ALLOW
> This value results in the system call being executed.
> .SH RETURN VALUE
> On success,
> .BR seccomp ()
> returns 0.
> On error, if
> .BR SECCOMP_FILTER_FLAG_TSYNC
> was used,
> the return value is the ID of the thread
> that caused the synchronization failure.
> (This ID is a kernel thread ID of the type returned by
> .BR clone (2)
> and
> .BR gettid (2).)
> On other errors, \-1 is returned, and
> .IR errno
> is set to indicate the cause of the error.
> .SH ERRORS
> .BR seccomp ()
> can fail for the following reasons:
> .TP
> .BR EACCESS
> The caller did not have the
> .BR CAP_SYS_ADMIN
> capability, or had not set
> .IR no_new_privs
> before using
> .BR SECCOMP_SET_MODE_FILTER .
> .TP
> .BR EFAULT
> .IR args
> was not a valid address.
> .TP
> .BR EINVAL
> .IR operation
> is unknown; or
> .IR flags
> are invalid for the given
> .IR operation .
> .\" FIXME Please review the following
> .TP
> .BR EINVAL
> .I operation
> included
> .BR BPF_ABS ,
> but the specified offset was not aligned to a 32-bit boundary or exceeded
> .IR "sizeof(struct\ seccomp_data)" .
> .\" FIXME Please review the following
> .TP
> .BR EINVAL
> .\" See kernel/seccomp.c::seccomp_may_assign_mode() in 3.18 sources
> A secure computing mode has already been set, and
> .I operation
> differs from the existing setting.
> .\" FIXME Please review the following
> .TP
> .BR EINVAL
> .\" See stub kernel/seccomp.c::seccomp_set_mode_filter() in 3.18 sources
> .I operation
> specified
> .BR SECCOMP_SET_MODE_FILTER ,
> but the kernel was not built with
> .B CONFIG_SECCOMP_FILTER
> enabled.
> .\" FIXME Please review the following
> .TP
> .BR EINVAL
> .I operation
> specified
> .BR SECCOMP_SET_MODE_FILTER ,
> but the filter program pointed to by
> .I args
> was not valid or the length of the filter program was zero or exceeded
> .B BPF_MAXINSNS
> (4096) instructions.
> .BR EINVAL
> .TP
> .BR ENOMEM
> Out of memory.
> .\" FIXME Please review the following
> .TP
> .BR ENOMEM
> .\" ENOMEM in kernel/seccomp.c::seccomp_attach_filter() in 3.18 sources
> The total length of all filter programs attached
> to the calling thread would exceed
> .B MAX_INSNS_PER_PATH
> (32768) instructions.
> Note that for the purposes of calculating this limit,
> each already existing filter program incurs an
> overhead penalty of 4 instructions.
> .TP
> .BR ESRCH
> Another thread caused a failure during thread sync, but its ID could not
> be determined.
> .SH VERSIONS
> The
> .BR seccomp()
> system call first appeared in Linux 3.17.
> .\" FIXME . Add glibc version
> .SH CONFORMING TO
> The
> .BR seccomp()
> system call is a nonstandard Linux extension.
> .SH NOTES
> .BR seccomp ()
> provides a superset of the functionality provided by the
> .BR prctl (2)
> .BR PR_SET_SECCOMP
> operation (which does not support
> .IR flags ).
> .\" FIXME Please review the following new subsection {{{
> .SS Seccomp-specific BPF details
> Note the following BPF details specific to seccomp filters:
> .IP * 3
> The
> .B BPF_H
> and
> .B BPF_B
> size modifiers are not supported: all operations must load and store
> (4-byte) words
> .RB ( BPF_W ).
> .IP *
> To access the contents of the
> .I seccomp_data
> buffer, use the
> .B BPF_ABS
> addressing mode modifier.
> .\" FIXME What is the significance of the line
> .\" ftest->code = BPF_LDX | BPF_W | BPF_ABS;
> .\" in kernel/seccomp.c::seccomp_check_filter()?
This is converting an accumulator load (BPF_LD) into a index load
(BPF_LDX). I think this is to avoid addressing modes 1 and 2, but Will
may remember more here. The LD|W|ABS structure is very common, so I
think this was a way to accept that in the filter, but change it into
a more limited command.
> .IP *
> The
> .B BPF_LEN
> addressing mode modifier yields an immediate mode operand
> whose value is the size of the
> .IR seccomp_data
> buffer.
> .\" FIXME Any other seccomp-specific BPF details that should be added here?
> .\"
> .\" FIXME End of new subsection for review }}}
All the rest of the FIXMEs above (excepting the standing glibc one)
looks correct to me.
> .SH EXAMPLE
> The program below accepts four or more arguments.
> The first three arguments are a system call number,
> a numeric architecture identifier, and an error number.
> The program uses these values to construct a BPF filter
> that is used at run time to perform the following checks:
> .IP [1] 4
> If the program is not running on the specified architecture,
> the BPF filter causes system calls to fail with the error
> .BR ENOSYS .
> .IP [2]
> If the program attempts to execute the system call with the specified number,
> the BPF filter causes the system call to fail, with
> .I errno
> being set to the specified error number.
> .PP
> The remaining command-line arguments specify
> the pathname and additional arguments of a program
> that the example program should attempt to execute using
> .BR execve (3)
> (a library function that employs the
> .BR execve (2)
> system call).
> Some example runs of the program are shown below.
>
> First, we display the architecture that we are running on (x86-64)
> and then construct a shell function that looks up system call
> numbers on this architecture:
>
> .nf
> .in +4n
> $ \fBuname -m\fP
> x86_64
> $ \fBsyscall_nr() {
> cat /usr/src/linux/arch/x86/syscalls/syscall_64.tbl | \\
> awk '$2 != "x32" && $3 == "'$1'" { print $1 }'
> }\fP
> .in
> .fi
>
> When the BPF filter rejects a system call (case [2] above),
> it causes the system call to fail with the error number
> specified on the command line.
> In the experiments shown here, we'll use error number 99:
>
> .nf
> .in +4n
> $ \fBerrno 99\fP
> EADDRNOTAVAIL 99 Cannot assign requested address
> .in
> .fi
>
> In the following example, we attempt to run the command
> .BR whoami (1),
> but the BPF filter rejects the
> .BR execve (2)
> system call, so that the command is not even executed:
>
> .nf
> .in +4n
> $ \fBsyscall_nr execve\fP
> 59
> $ \fB./a.out\fP
> Usage: ./a.out <syscall_nr> <arch> <errno> <prog> [<args>]
> Hint for <arch>: AUDIT_ARCH_I386: 0x40000003
> AUDIT_ARCH_X86_64: 0xC000003E
> $ \fB./a.out 59 0xC000003E 99 /bin/whoami\fP
> execv: Cannot assign requested address
> .in
> .fi
>
> In the next example, the BPF filter rejects the
> .BR write (2)
> system call, so that, although it is successfully started, the
> .BR whoami (1)
> command is not able to write output:
>
> .nf
> .in +4n
> $ \fBsyscall_nr write\fP
> 1
> $ \fB./a.out 1 0xC000003E 99 /bin/whoami\fP
> .in
> .fi
>
> In the final example,
> the BPF filter rejects a system call that is not used by the
> .BR whoami (1)
> command, so it is able to successfully execute and produce output:
>
> .nf
> .in +4n
> $ \fBsyscall_nr preadv\fP
> 295
> $ \fB./a.out 295 0xC000003E 99 /bin/whoami\fP
> cecilia
> .in
> .fi
> .SS Program source
> .fi
> .nf
> #include <errno.h>
> #include <stddef.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
> #include <linux/audit.h>
> #include <linux/filter.h>
> #include <linux/seccomp.h>
> #include <sys/prctl.h>
>
> static int
> install_filter(int syscall_nr, int t_arch, int f_errno)
> {
> .\" FIXME In the BPF program below, you use '+' to build the instructions.
> .\" However, most other BPF example code I see uses '|'. While I
> .\" assume it's equivalent (i.e., the bit fields are nonoverlapping),
> .\" was there a reason to use '+' rather than '|'? (To me, the
> .\" latter is a little clearer in its intent.)
Ah, no, "|" should be used, good catch.
> .\"
> .\" FIXME I expanded comments [0], [1], [2], [3], [4] a little.
> .\" Are they okay? */
Yup, these look good to me.
> .\"
> struct sock_filter filter[] = {
> /* [0] Load architecture from 'seccomp_data' buffer into
> accumulator */
> BPF_STMT(BPF_LD + BPF_W + BPF_ABS,
> (offsetof(struct seccomp_data, arch))),
>
> /* [1] Jump forward 4 instructions if architecture does not
> match 't_arch' */
> BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, t_arch, 0, 4),
>
> /* [2] Load system call number from 'seccomp_data' buffer into
> accumulator */
> BPF_STMT(BPF_LD + BPF_W + BPF_ABS,
> (offsetof(struct seccomp_data, nr))),
>
> /* [3] Jump forward 1 instruction if system call number
> does not match 'syscall_nr' */
> BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, syscall_nr, 0, 1),
>
> /* [4] Matching architecture and system call: don't execute
> the system call, and return 'f_errno' in 'errno' */
> BPF_STMT(BPF_RET + BPF_K,
> SECCOMP_RET_ERRNO | (f_errno & SECCOMP_RET_DATA)),
>
> /* [5] Destination of system call number mismatch: allow other
> system calls */
> BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_ALLOW),
>
> /* [6] Destination of architecture mismatch: kill process */
> BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_KILL),
> };
>
> struct sock_fprog prog = {
> .len = (unsigned short) (sizeof(filter) / sizeof(filter[0])),
> .filter = filter,
> };
>
> if (seccomp(SECCOMP_SET_MODE_FILTER, 0, &prog)) {
> perror("seccomp");
> return 1;
> }
>
> return 0;
> }
>
> int
> main(int argc, char **argv)
> {
> if (argc < 5) {
> fprintf(stderr, "Usage: "
> "%s <syscall_nr> <arch> <errno> <prog> [<args>]\\n"
> "Hint for <arch>: AUDIT_ARCH_I386: 0x%X\\n"
> " AUDIT_ARCH_X86_64: 0x%X\\n"
> "\\n", argv[0], AUDIT_ARCH_I386, AUDIT_ARCH_X86_64);
> exit(EXIT_FAILURE);
> }
>
> if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) {
> perror("prctl");
> exit(EXIT_FAILURE);
> }
>
> if (install_filter(strtol(argv[1], NULL, 0),
> strtol(argv[2], NULL, 0),
> strtol(argv[3], NULL, 0)))
> exit(EXIT_FAILURE);
>
> execv(argv[4], &argv[4]);
> perror("execv");
> exit(EXIT_FAILURE);
> }
> .fi
> .SH SEE ALSO
> .BR prctl (2),
> .BR ptrace (2),
> .BR signal (7),
> .BR socket (7)
> .sp
> The kernel source files
> .IR Documentation/networking/filter.txt
> and
> .IR Documentation/prctl/seccomp_filter.txt .
> .sp
> McCanne, S. and Jacobson, V. (1992)
> .IR "The BSD Packet Filter: A New Architecture for User-level Packet Capture" ,
> Proceedings of the USENIX Winter 1993 Conference
> .UR http://www.tcpdump.org/papers/bpf-usenix93.pdf
> .UE
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/
Thanks for the additional details and clarifications!
-Kees
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox