On Wed, May 2, 2018 at 12:57 PM, Kees Cook wrote:
> On Wed, May 2, 2018 at 8:53 AM, Tyler Hicks wrote:
>> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
>> index da78835..9029d9d 100644
>> --- a/kernel/seccomp.c
>> +++ b/kernel/seccomp.c
>> @@
On Wed, 2 May 2018, Tyler Hicks wrote:
> type=CONFIG_CHANGE msg=audit(1525275325.613:142): op=seccomp-logging
> actions=kill_process,kill_thread,errno,trace,log
> old-actions=kill_process,kill_thread,errno,trace,log res=1
>
> No audit records are generated when reading the actions_logged
On Wed, 2 May 2018, Tyler Hicks wrote:
> The function that converts a bitmask of seccomp actions that are
> allowed to be logged is currently only used for constructing the display
> string for the kernel.seccomp.actions_logged sysctl. That string wants a
> space character to be used for the
On Wed, 2 May 2018, Tyler Hicks wrote:
> Break the read and write paths of the kernel.seccomp.actions_logged
> sysctl into separate functions to maintain readability. An upcoming
> change will need to audit writes, but not reads, of this sysctl which
> would introduce too many conditional code
On Wednesday, May 2, 2018 11:53:19 AM EDT Tyler Hicks wrote:
> The decision to log a seccomp action will always be subject to the
> value of the kernel.seccomp.actions_logged sysctl, even for processes
> that are being inspected via the audit subsystem, in an upcoming patch.
> Therefore, we need
On Wed, May 2, 2018 at 5:36 PM, Kirill A. Shutemov
wrote:
> On Wed, May 02, 2018 at 02:38:42PM +, Andrey Konovalov wrote:
>> > Does having a tagged address here makes any difference? I couldn't hit a
>> > failure with my simple tests (LD_PRELOAD a library that
Daniel Vetter writes:
> This came up in discussions when reviewing drm patches.
>
> Cc: Eric Anholt
> Cc: linux-doc@vger.kernel.org
> Cc: Jonathan Corbet
> Signed-off-by: Daniel Vetter
>
> --
>
> Aside: I wonder
On Wed, May 2, 2018 at 8:53 AM, Tyler Hicks wrote:
> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> index da78835..9029d9d 100644
> --- a/kernel/seccomp.c
> +++ b/kernel/seccomp.c
> @@ -584,18 +584,13 @@ static inline void seccomp_log(unsigned long syscall,
> long
On 1 May 2018 at 23:00, Leo Yan wrote:
> The driver prints pcsr twice: the first time it uses specifier %px to
> print hexadecimal pcsr value and the second time uses specifier %pS for
> output kernel symbols.
>
> As suggested by Kees, using %pS should be sufficient and %px
On 05/01/2018 12:25 PM, Paul Moore wrote:
> On Tue, May 1, 2018 at 12:41 PM, Steve Grubb wrote:
>> On Tuesday, May 1, 2018 11:18:55 AM EDT Paul Moore wrote:
>>> On Fri, Apr 27, 2018 at 3:16 PM, Tyler Hicks wrote:
The decision to log a seccomp action
The decision to log a seccomp action will always be subject to the
value of the kernel.seccomp.actions_logged sysctl, even for processes
that are being inspected via the audit subsystem, in an upcoming patch.
Therefore, we need to emit an audit record on attempts at writing to the
actions_logged
Seccomp logging for "handled" actions such as RET_TRAP, RET_TRACE, or
RET_ERRNO can be very noisy for processes that are being audited. This
patch modifies the seccomp logging behavior to treat processes that are
being inspected via the audit subsystem the same as processes that
aren't under
The function that converts a bitmask of seccomp actions that are
allowed to be logged is currently only used for constructing the display
string for the kernel.seccomp.actions_logged sysctl. That string wants a
space character to be used for the separator between actions.
A future patch will make
Break the read and write paths of the kernel.seccomp.actions_logged
sysctl into separate functions to maintain readability. An upcoming
change will need to audit writes, but not reads, of this sysctl which
would introduce too many conditional code paths on whether or not the
'write' parameter
Seccomp received improved logging controls in v4.14. Applications can opt into
logging of "handled" actions (SECCOMP_RET_TRAP, SECCOMP_RET_TRACE,
SECCOMP_RET_ERRNO) using the SECCOMP_FILTER_FLAG_LOG bit when loading filters.
They can also debug filter matching with the new SECCOMP_RET_LOG action.
On Wed, May 02, 2018 at 02:38:42PM +, Andrey Konovalov wrote:
> > Does having a tagged address here makes any difference? I couldn't hit a
> > failure with my simple tests (LD_PRELOAD a library that randomly adds
> > tags to pointers returned by malloc).
>
> I think you're right,
On Thu, Apr 26, 2018 at 5:47 PM, Catalin Marinas
wrote:
> On Wed, Apr 18, 2018 at 08:53:12PM +0200, Andrey Konovalov wrote:
>> @@ -238,12 +239,15 @@ static inline void uaccess_enable_not_uao(void)
>> /*
>> * Sanitise a uaccess pointer such that it becomes NULL if above
Waiman Long writes:
> On 05/01/2018 10:18 PM, Eric W. Biederman wrote:
>>
>>> The sysctl parameters msgmni, shmmni and semmni have an inherent limit
>>> of IPC_MNI (32k). However, users may not be aware of that because they
>>> can write a value much higher than that without
On Thu, Apr 26, 2018 at 7:47 PM, Catalin Marinas
wrote:
My approach with this was to add untagging to every gup.c function
that is exposed for external use, but perhaps adding untagging only
where it is actually required is a better approach.
> On Wed, Apr 18, 2018 at
On Wed, 2018-05-02 at 16:02 +0200, Peter Zijlstra wrote:
> On Wed, May 02, 2018 at 09:47:00AM -0400, Waiman Long wrote:
>
> > > I've read half of the next patch that adds the isolation thing. And
> > > while that kludges around the whole root cgorup is magic thing, it
> > > doesn't help if you
On Thu, Apr 19, 2018 at 09:47:02AM -0400, Waiman Long wrote:
> diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
> index c970bd7..8d89dc2 100644
> --- a/Documentation/cgroup-v2.txt
> +++ b/Documentation/cgroup-v2.txt
> @@ -1484,6 +1484,31 @@ Cpuset Interface Files
> a
On Wed, May 02, 2018 at 09:47:00AM -0400, Waiman Long wrote:
> > I've read half of the next patch that adds the isolation thing. And
> > while that kludges around the whole root cgorup is magic thing, it
> > doesn't help if you move the above scenario on level down:
> >
> >
> > R
> > /
On 05/02/2018 09:42 AM, Peter Zijlstra wrote:
> On Wed, May 02, 2018 at 09:29:54AM -0400, Waiman Long wrote:
>> On 05/02/2018 06:24 AM, Peter Zijlstra wrote:
>>> On Thu, Apr 19, 2018 at 09:47:01AM -0400, Waiman Long wrote:
+ cpuset.sched_load_balance
+ A read-write single value file
On Wed, May 02, 2018 at 09:29:54AM -0400, Waiman Long wrote:
> On 05/02/2018 06:24 AM, Peter Zijlstra wrote:
> > On Thu, Apr 19, 2018 at 09:47:01AM -0400, Waiman Long wrote:
> >> + cpuset.sched_load_balance
> >> + A read-write single value file which exists on non-root cgroups.
> > Uhhm.. it
On 05/02/2018 06:24 AM, Peter Zijlstra wrote:
> On Thu, Apr 19, 2018 at 09:47:01AM -0400, Waiman Long wrote:
>> + cpuset.sched_load_balance
>> +A read-write single value file which exists on non-root cgroups.
> Uhhm.. it should very much exist in the root group too. Otherwise you
> cannot
On 05/01/2018 10:18 PM, Eric W. Biederman wrote:
>
>> The sysctl parameters msgmni, shmmni and semmni have an inherent limit
>> of IPC_MNI (32k). However, users may not be aware of that because they
>> can write a value much higher than that without getting any error or
>> notification. Reading
On Thu, Apr 26, 2018 at 6:42 PM, Bartosz Golaszewski wrote:
> 2018-04-26 14:07 GMT+02:00 Linus Walleij :
>> On Tue, Apr 10, 2018 at 10:30 PM, Bartosz Golaszewski wrote:
>>
>>> Board files constitute a significant part of the users of the
Hi Greg,
On Wed, May 2, 2018 at 1:10 PM, Greg Kroah-Hartman
wrote:
> On Wed, May 02, 2018 at 11:47:49AM +0200, Geert Uytterhoeven wrote:
>> On Sun, Apr 29, 2018 at 3:37 PM, Greg Kroah-Hartman
>> wrote:
>> > On Fri, Mar 30, 2018 at
On Wed, May 02, 2018 at 11:47:49AM +0200, Geert Uytterhoeven wrote:
> Hi Greg,
>
> On Sun, Apr 29, 2018 at 3:37 PM, Greg Kroah-Hartman
> wrote:
> > On Fri, Mar 30, 2018 at 09:47:44AM +0200, Boris Brezillon wrote:
> >> Document sysfs files/directories/symlinks exposed
On Thu, Apr 19, 2018 at 09:47:01AM -0400, Waiman Long wrote:
> + cpuset.sched_load_balance
> + A read-write single value file which exists on non-root cgroups.
Uhhm.. it should very much exist in the root group too. Otherwise you
cannot disable it there, which is required to allow smaller
Hi Greg,
On Sun, Apr 29, 2018 at 3:37 PM, Greg Kroah-Hartman
wrote:
> On Fri, Mar 30, 2018 at 09:47:44AM +0200, Boris Brezillon wrote:
>> Document sysfs files/directories/symlinks exposed by the I3C subsystem.
>>
>> Signed-off-by: Boris Brezillon
This came up in discussions when reviewing drm patches.
Cc: Eric Anholt
Cc: linux-doc@vger.kernel.org
Cc: Jonathan Corbet
Signed-off-by: Daniel Vetter
--
Aside: I wonder whether we shouldn't move this to some other place and
rst-ify
On Tue, May 01, 2018 at 10:29:46PM -0700, Kees Cook wrote:
> On Tue, May 1, 2018 at 10:00 PM, Leo Yan wrote:
> > The driver prints pcsr twice: the first time it uses specifier %px to
> > print hexadecimal pcsr value and the second time uses specifier %pS for
> > output kernel
33 matches
Mail list logo