Re: [RFC PATCH v3 1/8] Use refcount_t for ucounts reference counting

(Sorry for the gmail client) My 0.2, HTH: a) AFAIK, refcount_inc() (and similar friends) don't return any value b) they're designed to just WARN() if they saturate or if you're attempting to increment the value 0 (as it's possibly a UAF bug) c) refcount_inc_checked() is documented as "Similar to

cgroups v2: issues faced attempting to setup cpu limiting

Hi All, Am facing some issues getting CPU limiting working with cgroups v2. Pl read on for the details; a solution is much appreciated! Env: 5.0.0 Linux kernel on x86_64 Fedora 29 When attempting to setup CPU limiting using cgroups v2, I effectively disabled cgroups v1 by passing

cgroups v2: issues faced attempting to setup cpu limiting

Hi, Am facing some issues getting CPU limiting working with cgroups v2. Pl read on for the details; a solution is much appreciated! Env: custom 5.0.0 Linux kernel on x86_64 Fedora 29 When attempting to setup CPU limiting using cgroups v2, I effectively disabled cgroups v1 by passing

Re: [PATCH] leaking_addresses: add generic 32-bit support

e get_address_re sub). Also, we now have also builtin "stubs", for lack of a better term, where additional rules for other 64-bit arch's can be plugged into the code, in future, as applicable. Signed-off-by: Kaiwan N Billimoria <kaiwan.billimo..

Re: [PATCH] leaking_addresses: add generic 32-bit support

e get_address_re sub). Also, we now have also builtin "stubs", for lack of a better term, where additional rules for other 64-bit arch's can be plugged into the code, in future, as applicable. Signed-off-by: Kaiwan N Billimoria --- scripts/leaking_addresses.pl | 190 ++

Re: [PATCH] leaking_addresses: add generic 32-bit support

ot;rules") to detect special cases for > > x86_64 and ppc64 (in the get_address_re sub). Also, we now have > > also builtin "stubs", for lack of a better term, where additional > > rules for other 64-bit arch's can be plugged in, in future, as > > applicable. >

Re: [PATCH] leaking_addresses: add generic 32-bit support

t special cases for > > x86_64 and ppc64 (in the get_address_re sub). Also, we now have > > also builtin "stubs", for lack of a better term, where additional > > rules for other 64-bit arch's can be plugged in, in future, as > > applicable. > >

Re: [PATCH 4/5] leaking_addresses: add support for kernel config file

o ease > review. > > Add support for locating and parsing kernel configuration file. > > Signed-off-by: Tobin C. Harding <m...@tobin.cc> > Co-Developed-by: Kaiwan N Billimoria <kaiwan.billimo...@gmail.com> > --- > > get_kernel_config_option() is not super clean, any

Re: [PATCH 4/5] leaking_addresses: add support for kernel config file

; > Add support for locating and parsing kernel configuration file. > > Signed-off-by: Tobin C. Harding > Co-Developed-by: Kaiwan N Billimoria > --- > > get_kernel_config_option() is not super clean, any improvements most welcome. > > Kaiwan, > > This need

Re: [PATCH] leaking_addresses: add support for 32-bit kernel addresses

>> On Mon, 2017-12-04 at 19:21 +1100, Tobin C. Harding wrote: >>> On Mon, Dec 04, 2017 at 10:51:53AM +0530, Kaiwan N Billimoria wrote: >>> > > --- >>> > diff --git a/scripts/leaking_addresses.pl b/scripts/leaking_addresses.pl >>> > index 9

Re: [PATCH] leaking_addresses: add support for 32-bit kernel addresses

e: >>> On Mon, Dec 04, 2017 at 10:51:53AM +0530, Kaiwan N Billimoria wrote: >>> > > --- >>> > diff --git a/scripts/leaking_addresses.pl b/scripts/leaking_addresses.pl >>> > index 9906dcf8b807..260b52e456f1 100755 >>> > --- a/scripts/leaking_add

Re: [PATCH] leaking_addresses: add support for 32-bit kernel addresses

> On Mon, Dec 4, 2017 at 10:25 AM, Tobin C. Harding wrote: >> >> > With the 'eval', no warning, it's fine. >> >> Why not use hex()? > >> > >> > foreach my $config_file (@config_files) { >> > + $config_file =~ s/\R*//g; >> >> Is there some reason you don't use

Re: [PATCH] leaking_addresses: add support for 32-bit kernel addresses

> On Mon, Dec 4, 2017 at 10:25 AM, Tobin C. Harding wrote: >> >> > With the 'eval', no warning, it's fine. >> >> Why not use hex()? > >> > >> > foreach my $config_file (@config_files) { >> > + $config_file =~ s/\R*//g; >> >> Is there some reason you don't use chomp()? > Wrt

Re: [PATCH] leaking_addresses: add support for 32-bit kernel addresses

On Mon, Dec 4, 2017 at 10:25 AM, Tobin C. Harding wrote: > > > With the 'eval', no warning, it's fine. > > Why not use hex()? > > > > foreach my $config_file (@config_files) { > > + $config_file =~ s/\R*//g; > > Is there some reason you don't use chomp()?

Re: [PATCH] leaking_addresses: add support for 32-bit kernel addresses

On Mon, Dec 4, 2017 at 10:25 AM, Tobin C. Harding wrote: > > > With the 'eval', no warning, it's fine. > > Why not use hex()? > > > > foreach my $config_file (@config_files) { > > + $config_file =~ s/\R*//g; > > Is there some reason you don't use chomp()? Tobin, now you

Re: [PATCH] leaking_addresses: add support for 32-bit kernel addresses

wrote: > On Wed, Nov 29, 2017 at 04:32:54PM +0530, Kaiwan N Billimoria wrote: >> This "fallback to 0xc000" I don't really agree with. >> Obviously, there are platforms out there that do not use a PAGE_OFFSET value >> of >> 0xc000. So I think that defau

Re: [PATCH] leaking_addresses: add support for 32-bit kernel addresses

Nov 29, 2017 at 04:32:54PM +0530, Kaiwan N Billimoria wrote: >> This "fallback to 0xc000" I don't really agree with. >> Obviously, there are platforms out there that do not use a PAGE_OFFSET value >> of >> 0xc000. So I think that defaulting to this is ki

Re: [PATCH] leaking_addresses: add support for 32-bit kernel addresses

Hi, On Wed, Nov 29, 2017 at 3:46 PM, Tobin C. Harding wrote: > On Wed, Nov 29, 2017 at 09:59:59AM +0200, Alexander Kapshuk wrote: >> On Tue, Nov 28, 2017 at 11:10 PM, Tobin C. Harding wrote: >> > On Tue, Nov 28, 2017 at 03:16:24PM +0200, Alexander Kapshuk wrote: >>

Re: [PATCH] leaking_addresses: add support for 32-bit kernel addresses

Hi, On Wed, Nov 29, 2017 at 3:46 PM, Tobin C. Harding wrote: > On Wed, Nov 29, 2017 at 09:59:59AM +0200, Alexander Kapshuk wrote: >> On Tue, Nov 28, 2017 at 11:10 PM, Tobin C. Harding wrote: >> > On Tue, Nov 28, 2017 at 03:16:24PM +0200, Alexander Kapshuk wrote: >> >> On Tue, Nov 28, 2017 at

Re: [PATCH v2] scripts: leaking_addresses: add support for 32-bit kernel addresses

On Tue, Nov 28, 2017 at 11:58 AM, Tobin C. Harding wrote: > > At this stage I am unsure > how best to convey my ideas back to you. It seems that adding 32 bit x86 > support is making a big enough change to the script that rather than you > patching and me maintaining we could see

Re: [PATCH v2] scripts: leaking_addresses: add support for 32-bit kernel addresses

On Tue, Nov 28, 2017 at 11:58 AM, Tobin C. Harding wrote: > > At this stage I am unsure > how best to convey my ideas back to you. It seems that adding 32 bit x86 > support is making a big enough change to the script that rather than you > patching and me maintaining we could see it more as

Re: [kernel-hardening] Re: [RFC 0/3] kallsyms: don't leak address when printing symbol

On Tue, Nov 28, 2017 at 7:20 AM, Tobin C. Harding wrote: > > Noob question: how do we _know_ this. In other words how do we know no > userland tools rely on the current behaviour? No stress to answer Kees, > this is a pretty general kernel dev question. Perhaps I'm reading this

Re: [kernel-hardening] Re: [RFC 0/3] kallsyms: don't leak address when printing symbol

On Tue, Nov 28, 2017 at 7:20 AM, Tobin C. Harding wrote: > > Noob question: how do we _know_ this. In other words how do we know no > userland tools rely on the current behaviour? No stress to answer Kees, > this is a pretty general kernel dev question. Perhaps I'm reading this wrong, but

Re: [PATCH 2/2] scripts: leaking_addresses: help screen updates

On Fri, Nov 24, 2017 at 11:29 AM, Tobin C. Harding wrote: > Neither of these patches applies to my tree. Are you editing the diff's > by hand? I noticed the patches don't end with the version signature, like > this: > > > 2.7.4 I cloned your tree from here:

Re: [PATCH 2/2] scripts: leaking_addresses: help screen updates

On Fri, Nov 24, 2017 at 11:29 AM, Tobin C. Harding wrote: > Neither of these patches applies to my tree. Are you editing the diff's > by hand? I noticed the patches don't end with the version signature, like > this: > > > 2.7.4 I cloned your tree from here:

Re: [PATCH v1] scripts: leaking_addresses.pl: add support for 32-bit kernel addresses

Thanks Tobin, for your detailed comments. On Wed, Nov 22, 2017 at 5:29 AM, Tobin C. Harding wrote: > You don't typically need [xxx v1] for version 1, the v1 is implicit. > > Please use the git brief description prefix that is already in use i.e > > leaking_addresses: add

Re: [PATCH v1] scripts: leaking_addresses.pl: add support for 32-bit kernel addresses

Thanks Tobin, for your detailed comments. On Wed, Nov 22, 2017 at 5:29 AM, Tobin C. Harding wrote: > You don't typically need [xxx v1] for version 1, the v1 is implicit. > > Please use the git brief description prefix that is already in use i.e > > leaking_addresses: add support for

Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl

On Mon, Nov 13, 2017 at 11:38 AM, Tobin C. Harding wrote: > On Mon, Nov 13, 2017 at 11:16:28AM +0530, kaiwan.billimo...@gmail.com wrote: >> On Mon, 2017-11-13 at 09:21 +1100, Tobin C. Harding wrote: >> > On Fri, Nov 10, 2017 at 07:26:34PM +0530, kaiwan.billimo...@gmail.com >> >

Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl

On Mon, Nov 13, 2017 at 11:38 AM, Tobin C. Harding wrote: > On Mon, Nov 13, 2017 at 11:16:28AM +0530, kaiwan.billimo...@gmail.com wrote: >> On Mon, 2017-11-13 at 09:21 +1100, Tobin C. Harding wrote: >> > On Fri, Nov 10, 2017 at 07:26:34PM +0530, kaiwan.billimo...@gmail.com >> > wrote: >> > > On

Re: [kernel-hardening] Re: [PATCH v4] scripts: add leaking_addresses.pl

On Mon, Nov 13, 2017 at 10:05 AM, Tobin C. Harding wrote: > On Mon, Nov 13, 2017 at 06:37:28AM +0300, Kirill A. Shutemov wrote: >> On Mon, Nov 13, 2017 at 10:06:46AM +1100, Tobin C. Harding wrote: >> > On Sun, Nov 12, 2017 at 02:10:07AM +0300, Kirill A. Shutemov wrote: ... >> > >>

Re: [kernel-hardening] Re: [PATCH v4] scripts: add leaking_addresses.pl

On Mon, Nov 13, 2017 at 10:05 AM, Tobin C. Harding wrote: > On Mon, Nov 13, 2017 at 06:37:28AM +0300, Kirill A. Shutemov wrote: >> On Mon, Nov 13, 2017 at 10:06:46AM +1100, Tobin C. Harding wrote: >> > On Sun, Nov 12, 2017 at 02:10:07AM +0300, Kirill A. Shutemov wrote: ... >> > >> > Thanks for

Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl

> > Yes, profiling and tracing are similar. And you need to be root to run > the recording anyway. Thus, as long as root user can read kallsyms, > trace-cmd should be fine. As trace-cmd requires root access to do any > ftrace tracing. > > -- Steve Got it, thanks..

Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl

> > Yes, profiling and tracing are similar. And you need to be root to run > the recording anyway. Thus, as long as root user can read kallsyms, > trace-cmd should be fine. As trace-cmd requires root access to do any > ftrace tracing. > > -- Steve Got it, thanks..

Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl

On Thu, Nov 9, 2017 at 10:13 AM, Kaiwan N Billimoria <kaiwan.billimo...@gmail.com> wrote: >> But I don't know if there is anything else than the profiling code >> that _really_ wants access to /proc/kallsyms in user space as a >> regular user. > Front-ends to ft

Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl

On Thu, Nov 9, 2017 at 10:13 AM, Kaiwan N Billimoria wrote: >> But I don't know if there is anything else than the profiling code >> that _really_ wants access to /proc/kallsyms in user space as a >> regular user. > Front-ends to ftrace, like trace-cmd? [from the trac

Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl

> But I don't know if there is anything else than the profiling code > that _really_ wants access to /proc/kallsyms in user space as a > regular user. Am unsure about this, but kprobes? (/jprobes/kretprobes), and by extension, wrappers over this infra (like SystemTap)? I (hazily) recollect a

Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl

> But I don't know if there is anything else than the profiling code > that _really_ wants access to /proc/kallsyms in user space as a > regular user. Am unsure about this, but kprobes? (/jprobes/kretprobes), and by extension, wrappers over this infra (like SystemTap)? I (hazily) recollect a