On Fri, Jun 27, 2014 at 12:55 PM, Oleg Nesterov wrote:
> On 06/27, Andy Lutomirski wrote:
>>
>> On Fri, Jun 27, 2014 at 12:27 PM, Oleg Nesterov wrote:
>> > On 06/27, Kees Cook wrote:
>> >>
>> >> It looks like SMP ARM issues dsb for rmb, which seems a bit expensive.
>> >>
On Fri, Jun 27, 2014 at 12:55 PM, Oleg Nesterov wrote:
> On 06/27, Andy Lutomirski wrote:
>>
>> On Fri, Jun 27, 2014 at 12:27 PM, Oleg Nesterov wrote:
>> > On 06/27, Kees Cook wrote:
>> >>
>> >> It looks like SMP ARM issues dsb for rmb, which seems a bit expensive.
>> >>
On 06/27, Andy Lutomirski wrote:
>
> On Fri, Jun 27, 2014 at 12:27 PM, Oleg Nesterov wrote:
> > On 06/27, Kees Cook wrote:
> >>
> >> It looks like SMP ARM issues dsb for rmb, which seems a bit expensive.
> >> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204g/CIHJFGFE.htm
> >>
>
On Fri, Jun 27, 2014 at 12:27 PM, Oleg Nesterov wrote:
> On 06/27, Kees Cook wrote:
>>
>> It looks like SMP ARM issues dsb for rmb, which seems a bit expensive.
>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204g/CIHJFGFE.htm
>>
>> ...
>>
>> I really want to avoid adding
On 06/27, Kees Cook wrote:
>
> It looks like SMP ARM issues dsb for rmb, which seems a bit expensive.
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204g/CIHJFGFE.htm
>
> ...
>
> I really want to avoid adding anything to the secure_computing()
> execution path. :(
I must have
On Fri, Jun 27, 2014 at 12:04 PM, Kees Cook wrote:
> On Fri, Jun 27, 2014 at 11:56 AM, Andy Lutomirski wrote:
>> On Fri, Jun 27, 2014 at 11:52 AM, Kees Cook wrote:
>>> On Fri, Jun 27, 2014 at 11:39 AM, Andy Lutomirski
>>> wrote:
On Fri, Jun 27, 2014 at 11:33 AM, Kees Cook wrote:
>
On Fri, Jun 27, 2014 at 11:56 AM, Andy Lutomirski wrote:
> On Fri, Jun 27, 2014 at 11:52 AM, Kees Cook wrote:
>> On Fri, Jun 27, 2014 at 11:39 AM, Andy Lutomirski
>> wrote:
>>> On Fri, Jun 27, 2014 at 11:33 AM, Kees Cook wrote:
On Wed, Jun 25, 2014 at 11:07 AM, Andy Lutomirski
On Fri, Jun 27, 2014 at 11:52 AM, Kees Cook wrote:
> On Fri, Jun 27, 2014 at 11:39 AM, Andy Lutomirski wrote:
>> On Fri, Jun 27, 2014 at 11:33 AM, Kees Cook wrote:
>>> On Wed, Jun 25, 2014 at 11:07 AM, Andy Lutomirski
>>> wrote:
On Wed, Jun 25, 2014 at 11:00 AM, Kees Cook wrote:
>
On Fri, Jun 27, 2014 at 11:39 AM, Andy Lutomirski wrote:
> On Fri, Jun 27, 2014 at 11:33 AM, Kees Cook wrote:
>> On Wed, Jun 25, 2014 at 11:07 AM, Andy Lutomirski
>> wrote:
>>> On Wed, Jun 25, 2014 at 11:00 AM, Kees Cook wrote:
On Wed, Jun 25, 2014 at 10:51 AM, Oleg Nesterov wrote:
On Fri, Jun 27, 2014 at 11:33 AM, Kees Cook wrote:
> On Wed, Jun 25, 2014 at 11:07 AM, Andy Lutomirski wrote:
>> On Wed, Jun 25, 2014 at 11:00 AM, Kees Cook wrote:
>>> On Wed, Jun 25, 2014 at 10:51 AM, Oleg Nesterov wrote:
On 06/25, Andy Lutomirski wrote:
>
> On Wed, Jun 25, 2014
On Wed, Jun 25, 2014 at 11:07 AM, Andy Lutomirski wrote:
> On Wed, Jun 25, 2014 at 11:00 AM, Kees Cook wrote:
>> On Wed, Jun 25, 2014 at 10:51 AM, Oleg Nesterov wrote:
>>> On 06/25, Andy Lutomirski wrote:
On Wed, Jun 25, 2014 at 10:32 AM, Oleg Nesterov wrote:
> On 06/25, Andy
On Wed, Jun 25, 2014 at 11:07 AM, Andy Lutomirski l...@amacapital.net wrote:
On Wed, Jun 25, 2014 at 11:00 AM, Kees Cook keesc...@chromium.org wrote:
On Wed, Jun 25, 2014 at 10:51 AM, Oleg Nesterov o...@redhat.com wrote:
On 06/25, Andy Lutomirski wrote:
On Wed, Jun 25, 2014 at 10:32 AM, Oleg
On Fri, Jun 27, 2014 at 11:33 AM, Kees Cook keesc...@chromium.org wrote:
On Wed, Jun 25, 2014 at 11:07 AM, Andy Lutomirski l...@amacapital.net wrote:
On Wed, Jun 25, 2014 at 11:00 AM, Kees Cook keesc...@chromium.org wrote:
On Wed, Jun 25, 2014 at 10:51 AM, Oleg Nesterov o...@redhat.com wrote:
On Fri, Jun 27, 2014 at 11:39 AM, Andy Lutomirski l...@amacapital.net wrote:
On Fri, Jun 27, 2014 at 11:33 AM, Kees Cook keesc...@chromium.org wrote:
On Wed, Jun 25, 2014 at 11:07 AM, Andy Lutomirski l...@amacapital.net
wrote:
On Wed, Jun 25, 2014 at 11:00 AM, Kees Cook keesc...@chromium.org
On Fri, Jun 27, 2014 at 11:52 AM, Kees Cook keesc...@chromium.org wrote:
On Fri, Jun 27, 2014 at 11:39 AM, Andy Lutomirski l...@amacapital.net wrote:
On Fri, Jun 27, 2014 at 11:33 AM, Kees Cook keesc...@chromium.org wrote:
On Wed, Jun 25, 2014 at 11:07 AM, Andy Lutomirski l...@amacapital.net
On Fri, Jun 27, 2014 at 11:56 AM, Andy Lutomirski l...@amacapital.net wrote:
On Fri, Jun 27, 2014 at 11:52 AM, Kees Cook keesc...@chromium.org wrote:
On Fri, Jun 27, 2014 at 11:39 AM, Andy Lutomirski l...@amacapital.net
wrote:
On Fri, Jun 27, 2014 at 11:33 AM, Kees Cook keesc...@chromium.org
On Fri, Jun 27, 2014 at 12:04 PM, Kees Cook keesc...@chromium.org wrote:
On Fri, Jun 27, 2014 at 11:56 AM, Andy Lutomirski l...@amacapital.net wrote:
On Fri, Jun 27, 2014 at 11:52 AM, Kees Cook keesc...@chromium.org wrote:
On Fri, Jun 27, 2014 at 11:39 AM, Andy Lutomirski l...@amacapital.net
On 06/27, Kees Cook wrote:
It looks like SMP ARM issues dsb for rmb, which seems a bit expensive.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204g/CIHJFGFE.htm
...
I really want to avoid adding anything to the secure_computing()
execution path. :(
I must have missed
On Fri, Jun 27, 2014 at 12:27 PM, Oleg Nesterov o...@redhat.com wrote:
On 06/27, Kees Cook wrote:
It looks like SMP ARM issues dsb for rmb, which seems a bit expensive.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204g/CIHJFGFE.htm
...
I really want to avoid adding
On 06/27, Andy Lutomirski wrote:
On Fri, Jun 27, 2014 at 12:27 PM, Oleg Nesterov o...@redhat.com wrote:
On 06/27, Kees Cook wrote:
It looks like SMP ARM issues dsb for rmb, which seems a bit expensive.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204g/CIHJFGFE.htm
On Fri, Jun 27, 2014 at 12:55 PM, Oleg Nesterov o...@redhat.com wrote:
On 06/27, Andy Lutomirski wrote:
On Fri, Jun 27, 2014 at 12:27 PM, Oleg Nesterov o...@redhat.com wrote:
On 06/27, Kees Cook wrote:
It looks like SMP ARM issues dsb for rmb, which seems a bit expensive.
On Fri, Jun 27, 2014 at 12:55 PM, Oleg Nesterov o...@redhat.com wrote:
On 06/27, Andy Lutomirski wrote:
On Fri, Jun 27, 2014 at 12:27 PM, Oleg Nesterov o...@redhat.com wrote:
On 06/27, Kees Cook wrote:
It looks like SMP ARM issues dsb for rmb, which seems a bit expensive.
On Wed, Jun 25, 2014 at 11:00 AM, Kees Cook wrote:
> On Wed, Jun 25, 2014 at 10:51 AM, Oleg Nesterov wrote:
>> On 06/25, Andy Lutomirski wrote:
>>>
>>> On Wed, Jun 25, 2014 at 10:32 AM, Oleg Nesterov wrote:
>>> > On 06/25, Andy Lutomirski wrote:
>>> >>
>>> >> Write the filter, then smp_mb (or
On Wed, Jun 25, 2014 at 10:51 AM, Oleg Nesterov wrote:
> On 06/25, Andy Lutomirski wrote:
>>
>> On Wed, Jun 25, 2014 at 10:32 AM, Oleg Nesterov wrote:
>> > On 06/25, Andy Lutomirski wrote:
>> >>
>> >> Write the filter, then smp_mb (or maybe a weaker barrier is okay),
>> >> then set the bit.
>> >
On 06/25, Andy Lutomirski wrote:
>
> On Wed, Jun 25, 2014 at 10:32 AM, Oleg Nesterov wrote:
> > On 06/25, Andy Lutomirski wrote:
> >>
> >> Write the filter, then smp_mb (or maybe a weaker barrier is okay),
> >> then set the bit.
> >
> > Yes, exactly, this is what I meant. Plas rmb() in
On Wed, Jun 25, 2014 at 10:32 AM, Oleg Nesterov wrote:
> On 06/25, Andy Lutomirski wrote:
>>
>> Write the filter, then smp_mb (or maybe a weaker barrier is okay),
>> then set the bit.
>
> Yes, exactly, this is what I meant. Plas rmb() in __secure_computing().
>
> But I still can't understand the
On 06/25, Andy Lutomirski wrote:
>
> Write the filter, then smp_mb (or maybe a weaker barrier is okay),
> then set the bit.
Yes, exactly, this is what I meant. Plas rmb() in __secure_computing().
But I still can't understand the rest of your discussion about the
ordering we need ;)
Oleg.
--
To
On Wed, Jun 25, 2014 at 9:54 AM, Kees Cook wrote:
> On Wed, Jun 25, 2014 at 9:10 AM, Andy Lutomirski wrote:
>> On Wed, Jun 25, 2014 at 7:51 AM, Kees Cook wrote:
>>> On Wed, Jun 25, 2014 at 6:51 AM, Oleg Nesterov wrote:
On 06/24, Kees Cook wrote:
>
> +static inline void
On 06/25, Kees Cook wrote:
>
> On Wed, Jun 25, 2014 at 6:51 AM, Oleg Nesterov wrote:
> > On 06/24, Kees Cook wrote:
> >>
> >> +static inline void seccomp_assign_mode(struct task_struct *task,
> >> +unsigned long seccomp_mode)
> >> +{
> >> +
On Wed, Jun 25, 2014 at 9:10 AM, Andy Lutomirski wrote:
> On Wed, Jun 25, 2014 at 7:51 AM, Kees Cook wrote:
>> On Wed, Jun 25, 2014 at 6:51 AM, Oleg Nesterov wrote:
>>> On 06/24, Kees Cook wrote:
+static inline void seccomp_assign_mode(struct task_struct *task,
+
On Wed, Jun 25, 2014 at 7:51 AM, Kees Cook wrote:
> On Wed, Jun 25, 2014 at 6:51 AM, Oleg Nesterov wrote:
>> On 06/24, Kees Cook wrote:
>>>
>>> +static inline void seccomp_assign_mode(struct task_struct *task,
>>> +unsigned long seccomp_mode)
>>> +{
>>> +
On Wed, Jun 25, 2014 at 6:51 AM, Oleg Nesterov wrote:
> On 06/24, Kees Cook wrote:
>>
>> +static inline void seccomp_assign_mode(struct task_struct *task,
>> +unsigned long seccomp_mode)
>> +{
>> + BUG_ON(!spin_is_locked(>sighand->siglock));
>> +
>> +
On 06/24, Kees Cook wrote:
>
> +static inline void seccomp_assign_mode(struct task_struct *task,
> +unsigned long seccomp_mode)
> +{
> + BUG_ON(!spin_is_locked(>sighand->siglock));
> +
> + task->seccomp.mode = seccomp_mode;
> +
On 06/24, Kees Cook wrote:
+static inline void seccomp_assign_mode(struct task_struct *task,
+unsigned long seccomp_mode)
+{
+ BUG_ON(!spin_is_locked(task-sighand-siglock));
+
+ task-seccomp.mode = seccomp_mode;
+ set_tsk_thread_flag(task,
On Wed, Jun 25, 2014 at 6:51 AM, Oleg Nesterov o...@redhat.com wrote:
On 06/24, Kees Cook wrote:
+static inline void seccomp_assign_mode(struct task_struct *task,
+unsigned long seccomp_mode)
+{
+ BUG_ON(!spin_is_locked(task-sighand-siglock));
+
+
On Wed, Jun 25, 2014 at 7:51 AM, Kees Cook keesc...@chromium.org wrote:
On Wed, Jun 25, 2014 at 6:51 AM, Oleg Nesterov o...@redhat.com wrote:
On 06/24, Kees Cook wrote:
+static inline void seccomp_assign_mode(struct task_struct *task,
+unsigned long
On Wed, Jun 25, 2014 at 9:10 AM, Andy Lutomirski l...@amacapital.net wrote:
On Wed, Jun 25, 2014 at 7:51 AM, Kees Cook keesc...@chromium.org wrote:
On Wed, Jun 25, 2014 at 6:51 AM, Oleg Nesterov o...@redhat.com wrote:
On 06/24, Kees Cook wrote:
+static inline void seccomp_assign_mode(struct
On 06/25, Kees Cook wrote:
On Wed, Jun 25, 2014 at 6:51 AM, Oleg Nesterov o...@redhat.com wrote:
On 06/24, Kees Cook wrote:
+static inline void seccomp_assign_mode(struct task_struct *task,
+unsigned long seccomp_mode)
+{
+
On Wed, Jun 25, 2014 at 9:54 AM, Kees Cook keesc...@chromium.org wrote:
On Wed, Jun 25, 2014 at 9:10 AM, Andy Lutomirski l...@amacapital.net wrote:
On Wed, Jun 25, 2014 at 7:51 AM, Kees Cook keesc...@chromium.org wrote:
On Wed, Jun 25, 2014 at 6:51 AM, Oleg Nesterov o...@redhat.com wrote:
On
On 06/25, Andy Lutomirski wrote:
Write the filter, then smp_mb (or maybe a weaker barrier is okay),
then set the bit.
Yes, exactly, this is what I meant. Plas rmb() in __secure_computing().
But I still can't understand the rest of your discussion about the
ordering we need ;)
Oleg.
--
To
On Wed, Jun 25, 2014 at 10:32 AM, Oleg Nesterov o...@redhat.com wrote:
On 06/25, Andy Lutomirski wrote:
Write the filter, then smp_mb (or maybe a weaker barrier is okay),
then set the bit.
Yes, exactly, this is what I meant. Plas rmb() in __secure_computing().
But I still can't understand
On 06/25, Andy Lutomirski wrote:
On Wed, Jun 25, 2014 at 10:32 AM, Oleg Nesterov o...@redhat.com wrote:
On 06/25, Andy Lutomirski wrote:
Write the filter, then smp_mb (or maybe a weaker barrier is okay),
then set the bit.
Yes, exactly, this is what I meant. Plas rmb() in
On Wed, Jun 25, 2014 at 10:51 AM, Oleg Nesterov o...@redhat.com wrote:
On 06/25, Andy Lutomirski wrote:
On Wed, Jun 25, 2014 at 10:32 AM, Oleg Nesterov o...@redhat.com wrote:
On 06/25, Andy Lutomirski wrote:
Write the filter, then smp_mb (or maybe a weaker barrier is okay),
then set the
On Wed, Jun 25, 2014 at 11:00 AM, Kees Cook keesc...@chromium.org wrote:
On Wed, Jun 25, 2014 at 10:51 AM, Oleg Nesterov o...@redhat.com wrote:
On 06/25, Andy Lutomirski wrote:
On Wed, Jun 25, 2014 at 10:32 AM, Oleg Nesterov o...@redhat.com wrote:
On 06/25, Andy Lutomirski wrote:
Write
Extracts the common check/assign logic, and separates the two mode
setting paths to make things more readable with fewer #ifdefs within
function bodies.
Signed-off-by: Kees Cook
---
kernel/seccomp.c | 123 +-
1 file changed, 84 insertions(+),
Extracts the common check/assign logic, and separates the two mode
setting paths to make things more readable with fewer #ifdefs within
function bodies.
Signed-off-by: Kees Cook keesc...@chromium.org
---
kernel/seccomp.c | 123 +-
1 file
46 matches
Mail list logo