On 15.3.2021 19.47, Uladzislau Rezki wrote:
On Mon, Mar 15, 2021 at 09:16:26AM -0700, Kees Cook wrote:
On Mon, Mar 15, 2021 at 01:24:10PM +0100, Uladzislau Rezki wrote:
On Mon, Mar 15, 2021 at 11:04:42AM +0200, Topi Miettinen wrote:
What's the problem with that? It seems to me that no
On 15.3.2021 20.02, Uladzislau Rezki wrote:
On Mon, Mar 15, 2021 at 06:23:37PM +0200, Topi Miettinen wrote:
On 15.3.2021 17.35, Uladzislau Rezki wrote:
On 14.3.2021 19.23, Uladzislau Rezki wrote:
Also, using vmaloc test driver i can trigger a kernel BUG:
[ 24.627577] kernel BUG at mm
On 15.3.2021 17.35, Uladzislau Rezki wrote:
On 14.3.2021 19.23, Uladzislau Rezki wrote:
Also, using vmaloc test driver i can trigger a kernel BUG:
[ 24.627577] kernel BUG at mm/vmalloc.c:1272!
It seems that most tests indeed fail. Perhaps the vmalloc subsystem isn't
very robust in face of
On 14.3.2021 19.23, Uladzislau Rezki wrote:
Also, using vmaloc test driver i can trigger a kernel BUG:
[ 24.627577] kernel BUG at mm/vmalloc.c:1272!
It seems that most tests indeed fail. Perhaps the vmalloc subsystem
isn't very robust in face of fragmented virtual memory. What could be
do
loc
randomized:
0xcb57611a8000-0xcb57611b1000 36864 kernel_clone+0xf9/0x560 pages=8
vmalloc
CC: Andrew Morton
CC: Andy Lutomirski
CC: Jann Horn
CC: Kees Cook
CC: Linux API
CC: Matthew Wilcox
CC: Mike Rapoport
CC: Vlad Rezki
Signed-off-by: Topi Miettinen
---
v2: retry allocation from other
64 kernel_clone+0xf9/0x560 pages=8
vmalloc
CC: Andrew Morton
CC: Andy Lutomirski
CC: Jann Horn
CC: Kees Cook
CC: Linux API
CC: Matthew Wilcox
CC: Mike Rapoport
CC: Vlad Rezki
Signed-off-by: Topi Miettinen
---
v2: retry allocation from other end of vmalloc space in case of
failure
On 8.3.2021 23.38, Kees Cook wrote:
On Mon, Feb 15, 2021 at 10:26:34PM +0200, Topi Miettinen wrote:
Memory mappings inside kernel allocated with vmalloc() are in
predictable order and packed tightly toward the low addresses, except
for per-cpu areas which start from top of the vmalloc area
On 6.3.2021 3.13, Andrew Morton wrote:
On Mon, 15 Feb 2021 22:26:34 +0200 Topi Miettinen wrote:
Memory mappings inside kernel allocated with vmalloc() are in
predictable order and packed tightly toward the low addresses, except
for per-cpu areas which start from top of the vmalloc area. With
64 kernel_clone+0xf9/0x560 pages=8
vmalloc
CC: Andrew Morton
CC: Andy Lutomirski
CC: Jann Horn
CC: Kees Cook
CC: Linux API
CC: Matthew Wilcox
CC: Mike Rapoport
CC: Vlad Rezki
Signed-off-by: Topi Miettinen
---
v2: retry allocation from other end of vmalloc space in case of
failure
On 15.2.2021 14.51, Uladzislau Rezki wrote:
On Sat, Feb 13, 2021 at 03:43:39PM +0200, Topi Miettinen wrote:
On 13.2.2021 13.55, Uladzislau Rezki wrote:
Hello,
Is there a chance of getting this reviewed and maybe even merged, please?
-Topi
I can review it and help with it. But before that i
CC: Andy Lutomirski
CC: Jann Horn
CC: Kees Cook
CC: Linux API
CC: Matthew Wilcox
CC: Mike Rapoport
Signed-off-by: Topi Miettinen
---
v2: retry allocation from other end of vmalloc space in case of
failure (Matthew Wilcox), improve commit message and documentation
---
.../admin-gu
Hello,
Is there a chance of getting this reviewed and maybe even merged, please?
-Topi
On 12.12.2020 19.56, Topi Miettinen wrote:
Memory mappings inside kernel allocated with vmalloc() are in
predictable order and packed tightly toward the low addresses. With
new kernel boot parameter
On 2.2.2021 17.30, Casey Schaufler wrote:
On 2/2/2021 4:05 AM, Topi Miettinen wrote:
On 26.1.2021 18.40, Casey Schaufler wrote:
This patchset provides the changes required for
the AppArmor security module to stack safely with any other.
In my test, when kernel command line has apparmor
On 26.1.2021 18.40, Casey Schaufler wrote:
This patchset provides the changes required for
the AppArmor security module to stack safely with any other.
In my test, when kernel command line has apparmor before selinux in lsm=
entry, the boot is not successful with enforcing=1:
systemd[1]: Fail
(0x70aa47ad, 4096, 4096, MREMAP_MAYMOVE) = 0x5b37dc166000
CC: Andrew Morton
CC: Jann Horn
CC: Kees Cook
CC: Matthew Wilcox
CC: Mike Rapoport
CC: Linux API
Signed-off-by: Topi Miettinen
---
Documentation/admin-guide/sysctl/kernel.rst | 9 +++
include/linux/mm.h | 2
= 0x15b9727a3aa0
exit(0) = ?
CC: Andrew Morton
CC: Jann Horn
CC: Kees Cook
CC: Matthew Wilcox
CC: Mike Rapoport
CC: Linux API
Signed-off-by: Topi Miettinen
Reported-by: kernel test robot
---
v2: also randomize mremap(..., MREMAP_MAYMOVE)
v3: avoid s
On 4.1.2021 17.53, Topi Miettinen wrote:
Writing a new value of 3 to /proc/sys/kernel/randomize_va_space
enables full randomization of memory mappings. With 2, the base of the
VMA used for such mappings is random, but the mappings are created in
predictable places within the VMA and in
s was already done for stack:
$ strace ./brk
brk(NULL) = 0x15b9727a3aa0
exit(0) = ?
CC: Andrew Morton
CC: Jann Horn
CC: Kees Cook
CC: Matthew Wilcox
CC: Mike Rapoport
CC: Linux API
Signed-off-by: Topi Miettinen
---
v2:
strace ./brk
brk(NULL) = 0x15b9727a3aa0
exit(0) = ?
CC: Andrew Morton
CC: Jann Horn
CC: Kees Cook
CC: Matthew Wilcox
CC: Mike Rapoport
CC: Linux API
Signed-off-by: Topi Miettinen
---
v2: also randomize mremap(..., MREMAP_MAYMOVE)
v3: avoid stack area and retry
6a2e000-76d786f9 r--p fe:0c 2474005
/usr/lib/locale/locale-archive
7e8f9a574000-7e8f9a595000 rw-p 00:00 0 [heap]
CC: Andrew Morton
CC: Jann Horn
CC: Kees Cook
CC: Matthew Wilcox
CC: Mike Rapoport
CC: Linux API
Signed-off-by:
743548368000-7435488ca000 r--p fe:0c 2474005
/usr/lib/locale/locale-archive
7dd3a185f000-7dd3a1861000 rw-p 00:00 0
CC: Andrew Morton
CC: Jann Horn
CC: Kees Cook
CC: Matthew Wilcox
CC: Mike Rapoport
CC: Linux API
Signed-off-by: Topi Miettinen
---
v2: also ran
orton
CC: Andy Lutomirski
CC: Jann Horn
CC: Kees Cook
CC: Linux API
CC: Matthew Wilcox
CC: Mike Rapoport
Signed-off-by: Topi Miettinen
---
v2: retry allocation from other end of vmalloc space in case of
failure (Matthew Wilcox), improve commit message and documentation
---
.../admin-guide/kernel
On 3.12.2020 8.58, Mike Rapoport wrote:
On Wed, Dec 02, 2020 at 08:49:06PM +0200, Topi Miettinen wrote:
On 1.12.2020 23.45, Topi Miettinen wrote:
Memory mappings inside kernel allocated with vmalloc() are in
predictable order and packed tightly toward the low addresses. With
new kernel boot
On 3.12.2020 8.58, Mike Rapoport wrote:
On Wed, Dec 02, 2020 at 08:49:06PM +0200, Topi Miettinen wrote:
On 1.12.2020 23.45, Topi Miettinen wrote:
Memory mappings inside kernel allocated with vmalloc() are in
predictable order and packed tightly toward the low addresses. With
new kernel boot
On 4.12.2020 15.33, David Laight wrote:
From: Topi Miettinen
Sent: 04 December 2020 10:58
On 4.12.2020 1.15, David Laight wrote:
From: Mike Rapoport
Sent: 03 December 2020 06:58
On Wed, Dec 02, 2020 at 08:49:06PM +0200, Topi Miettinen wrote:
On 1.12.2020 23.45, Topi Miettinen wrote
On 4.12.2020 1.15, David Laight wrote:
From: Mike Rapoport
Sent: 03 December 2020 06:58
On Wed, Dec 02, 2020 at 08:49:06PM +0200, Topi Miettinen wrote:
On 1.12.2020 23.45, Topi Miettinen wrote:
Memory mappings inside kernel allocated with vmalloc() are in
predictable order and packed tightly
On 3.12.2020 11.47, Florian Weimer wrote:
* Topi Miettinen:
+3 Additionally enable full randomization of memory mappings created
+with mmap(NULL, ...). With 2, the base of the VMA used for such
+mappings is random, but the mappings are created in predictable
+places within the
On 2.12.2020 20.53, Matthew Wilcox wrote:
On Tue, Dec 01, 2020 at 11:45:47PM +0200, Topi Miettinen wrote:
+ /* Randomize allocation */
+ if (randomize_vmalloc) {
+ voffset = get_random_long() & (roundup_pow_of_two(vend -
vstart) - 1);
+ vof
On 1.12.2020 23.45, Topi Miettinen wrote:
Memory mappings inside kernel allocated with vmalloc() are in
predictable order and packed tightly toward the low addresses. With
new kernel boot parameter 'randomize_vmalloc=1', the entire area is
used randomly to make the allocations less p
00 69632 pcpu_create_chunk+0x80/0x2c0
pages=16 vmalloc
0xe8c0-0xe8e0 2097152 pcpu_get_vm_areas+0x0/0x1a40
vmalloc
CC: Andrew Morton
CC: Andy Lutomirski
CC: Jann Horn
CC: Kees Cook
CC: Linux API
CC: Matthew Wilcox
CC: Mike Rapoport
Signed-off-by: Topi Miettinen
---
.../a
On 30.11.2020 19.57, Andy Lutomirski wrote:
On Sun, Nov 29, 2020 at 1:20 PM Topi Miettinen wrote:
Writing a new value of 3 to /proc/sys/kernel/randomize_va_space
enables full randomization of memory mappings created with mmap(NULL,
...). With 2, the base of the VMA used for such mappings is
1868624
/usr/bin/cat
CC: Andrew Morton
CC: Jann Horn
CC: Kees Cook
CC: Matthew Wilcox
CC: Mike Rapoport
CC: Linux API
Signed-off-by: Topi Miettinen
---
v2: also randomize mremap(..., MREMAP_MAYMOVE)
v3: avoid stack area and retry in case of bad random address (Jann
Horn), improve descri
On 20.11.2020 16.10, Cristiano Giuffrida wrote:
On Fri, Nov 20, 2020 at 9:38 AM Topi Miettinen wrote:
On 20.11.2020 0.20, Cristiano Giuffrida wrote:
On Thu, Nov 19, 2020 at 10:59 AM Topi Miettinen wrote:
On 18.11.2020 20.49, Cristiano Giuffrida wrote:
Interesting mitigation and
On 20.11.2020 0.20, Cristiano Giuffrida wrote:
On Thu, Nov 19, 2020 at 10:59 AM Topi Miettinen wrote:
On 18.11.2020 20.49, Cristiano Giuffrida wrote:
Interesting mitigation and discussion!
Regarding the impact on the AnC attack, indeed fine-grained (or full)
mmap() randomization affects AnC
f the AnC paper authors)
On Tue, Nov 17, 2020 at 10:21:30PM +0200, Topi Miettinen wrote:
On 17.11.2020 18.54, Matthew Wilcox wrote:
On Mon, Oct 26, 2020 at 06:05:18PM +0200, Topi Miettinen wrote:
Writing a new value of 3 to /proc/sys/kernel/randomize_va_space
enables full randomization of memory m
On 19.11.2020 0.42, Jann Horn wrote:
On Tue, Nov 17, 2020 at 5:55 PM Matthew Wilcox wrote:
On Mon, Oct 26, 2020 at 06:05:18PM +0200, Topi Miettinen wrote:
Writing a new value of 3 to /proc/sys/kernel/randomize_va_space
enables full randomization of memory mappings created with mmap(NULL
On 17.11.2020 18.54, Matthew Wilcox wrote:
On Mon, Oct 26, 2020 at 06:05:18PM +0200, Topi Miettinen wrote:
Writing a new value of 3 to /proc/sys/kernel/randomize_va_space
enables full randomization of memory mappings created with mmap(NULL,
...). With 2, the base of the VMA used for such
On 4.11.2020 16.35, Catalin Marinas wrote:
On Wed, Nov 04, 2020 at 11:55:57AM +0200, Topi Miettinen wrote:
On 4.11.2020 11.29, Florian Weimer wrote:
* Will Deacon:
Is there real value in this seccomp filter if it only looks at mprotect(),
or was it just implemented because it's easy
On 4.11.2020 11.29, Florian Weimer wrote:
* Will Deacon:
Is there real value in this seccomp filter if it only looks at mprotect(),
or was it just implemented because it's easy to do and sounds like a good
idea?
It seems bogus to me. Everyone will just create alias mappings instead,
just lik
On 3.11.2020 19.34, Mark Brown wrote:
On Tue, Nov 03, 2020 at 10:25:37AM +, Szabolcs Nagy wrote:
Re-mmap executable segments instead of mprotecting them in
case mprotect is seccomp filtered.
For the kernel mapped main executable we don't have the fd
for re-mmap so linux needs to be updat
On 5.10.2020 15.18, David Hildenbrand wrote:
On 05.10.20 13:21, David Laight wrote:
From: David Hildenbrand
Sent: 05 October 2020 10:55
...
If hardening and compatibility are seen as tradeoffs, perhaps there
could be a top level config choice (CONFIG_HARDENING_TRADEOFF) for this.
It would hav
On 26.10.2020 18.24, Dave Martin wrote:
On Wed, Oct 21, 2020 at 10:44:46PM -0500, Jeremy Linton via Libc-alpha wrote:
Hi,
There is a problem with glibc+systemd on BTI enabled systems. Systemd
has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny
PROT_EXEC changes. Glibc enables
On 26.10.2020 16.52, Catalin Marinas wrote:
On Sat, Oct 24, 2020 at 02:01:30PM +0300, Topi Miettinen wrote:
On 23.10.2020 12.02, Catalin Marinas wrote:
On Thu, Oct 22, 2020 at 01:02:18PM -0700, Kees Cook wrote:
Regardless, it makes sense to me to have the kernel load the executable
itself
0 0 [vdso]
CC: Andrew Morton
CC: Jann Horn
CC: Kees Cook
CC: Matthew Wilcox
CC: Mike Rapoport
Signed-off-by: Topi Miettinen
---
v2: also randomize mremap(..., MREMAP_MAYMOVE)
v3: avoid stack area and retry in case of bad random address (Jann
Horn), improve description
On 23.10.2020 20.52, Salvatore Mesoraca wrote:
Hi,
On Thu, 22 Oct 2020 at 23:24, Topi Miettinen wrote:
SARA looks interesting. What is missing is a prctl() to enable all W^X
protections irrevocably for the current process, then systemd could
enable it for services with MemoryDenyWriteExecute
On 23.10.2020 12.02, Catalin Marinas wrote:
On Thu, Oct 22, 2020 at 01:02:18PM -0700, Kees Cook wrote:
Regardless, it makes sense to me to have the kernel load the executable
itself with BTI enabled by default. I prefer gaining Catalin's suggested
patch[2]. :)
[...]
[2] https://lore.kernel.org
On 22.10.2020 23.02, Kees Cook wrote:
On Thu, Oct 22, 2020 at 01:39:07PM +0300, Topi Miettinen wrote:
But I think SELinux has a more complete solution (execmem) which can track
the pages better than is possible with seccomp solution which has a very
narrow field of view. Maybe this facility
On 22.10.2020 10.54, Szabolcs Nagy wrote:
The 10/21/2020 22:44, Jeremy Linton wrote:
There is a problem with glibc+systemd on BTI enabled systems. Systemd
has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny
PROT_EXEC changes. Glibc enables BTI only on segments which are marked
On 22.10.2020 12.31, Catalin Marinas wrote:
On Thu, Oct 22, 2020 at 10:38:23AM +0200, Lennart Poettering wrote:
On Do, 22.10.20 09:29, Szabolcs Nagy (szabolcs.n...@arm.com) wrote:
The dynamic loader has to process the LOAD segments to get to the ELF
note that says to enable BTI. Maybe we could
On 22.10.2020 11.29, Szabolcs Nagy wrote:
The 10/22/2020 11:17, Topi Miettinen via Libc-alpha wrote:
On 22.10.2020 10.54, Florian Weimer wrote:
* Lennart Poettering:
Did you see Topi's comments on the systemd issue?
https://github.com/systemd/systemd/issues/17368#issuecomment-7104855
On 22.10.2020 10.54, Florian Weimer wrote:
* Lennart Poettering:
On Mi, 21.10.20 22:44, Jeremy Linton (jeremy.lin...@arm.com) wrote:
Hi,
There is a problem with glibc+systemd on BTI enabled systems. Systemd
has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny
PROT_EXEC chan
98000
...
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=5642592, ...}) = 0
mmap(NULL, 5642592, PROT_READ, MAP_PRIVATE, 3, 0) = 0xbe351ab8000
Signed-off-by: Topi Miettinen
---
v2: also randomize mremap(..., MREMAP_MAYMO
On 8.10.2020 20.07, Matthew Wilcox wrote:
On Thu, Oct 08, 2020 at 07:54:08PM +0300, Topi Miettinen wrote:
+3 Additionally enable full randomization of memory mappings created
+with mmap(NULL, ...). With 2, the base of the VMA used for such
+mappings is random, but the mappings are
On 8.10.2020 20.13, Jann Horn wrote:
On Thu, Oct 8, 2020 at 6:54 PM Topi Miettinen wrote:
Writing a new value of 3 to /proc/sys/kernel/randomize_va_space
enables full randomization of memory mappings created with mmap(NULL,
...). With 2, the base of the VMA used for such mappings is random
..}) = 0
mmap(NULL, 5642592, PROT_READ, MAP_PRIVATE, 3, 0) = 0xbe351ab8000
Signed-off-by: Topi Miettinen
---
Resent also to hardening list (hopefully the right one)
v2: also randomize mremap(..., MREMAP_MAYMOVE)
---
Documentation/admin-guide/hw-vuln/spectre.rst | 6 +++---
Documentation/admin-guide
On 5.10.2020 15.25, David Laight wrote:
From: David Hildenbrand
Sent: 05 October 2020 13:19
On 05.10.20 13:21, David Laight wrote:
From: David Hildenbrand
Sent: 05 October 2020 10:55
...
If hardening and compatibility are seen as tradeoffs, perhaps there
could be a top level config choice (
On 5.10.2020 17.12, Jonathan Corbet wrote:
On Mon, 5 Oct 2020 11:11:35 +0300
Topi Miettinen wrote:
The point is not to shrink the kernel (it will shrink by one small
function) or get rid of complexity. The point is to disable an inferior
interface. Memory returned by mmap() is at a random
On 5.10.2020 12.13, David Hildenbrand wrote:
On 05.10.20 08:12, Michal Hocko wrote:
On Sat 03-10-20 00:44:09, Topi Miettinen wrote:
On 2.10.2020 20.52, David Hildenbrand wrote:
On 02.10.20 19:19, Topi Miettinen wrote:
The brk() system call allows to change data segment size (heap). This
is
On 5.10.2020 11.22, Michal Hocko wrote:
On Mon 05-10-20 11:11:35, Topi Miettinen wrote:
[...]
I think hardened, security oriented systems should disable brk() completely
because it will increase the randomization of the process address space
(ASLR). This wouldn't be a good option to enabl
On 5.10.2020 9.12, Michal Hocko wrote:
On Sat 03-10-20 00:44:09, Topi Miettinen wrote:
On 2.10.2020 20.52, David Hildenbrand wrote:
On 02.10.20 19:19, Topi Miettinen wrote:
The brk() system call allows to change data segment size (heap). This
is mainly used by glibc for memory allocation, but
On 2.10.2020 20.52, David Hildenbrand wrote:
On 02.10.20 19:19, Topi Miettinen wrote:
The brk() system call allows to change data segment size (heap). This
is mainly used by glibc for memory allocation, but it can use mmap()
and that results in more randomized memory mappings since the heap is
-off-by: Topi Miettinen
---
init/Kconfig| 15 +++
kernel/sys_ni.c | 2 ++
mm/mmap.c | 2 ++
3 files changed, 19 insertions(+)
diff --git a/init/Kconfig b/init/Kconfig
index c5ea2e694f6a..53735ac305d8 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1851,6 +1851,20 @@ config
..}) = 0
mmap(NULL, 5642592, PROT_READ, MAP_PRIVATE, 3, 0) = 0xbe351ab8000
Signed-off-by: Topi Miettinen
---
v2: also randomize mremap(..., MREMAP_MAYMOVE)
---
Documentation/admin-guide/hw-vuln/spectre.rst | 6 +++---
Documentation/admin-guide/sysctl/kernel.rst | 11 +++
init/Kconfig
Hi,
Maybe this is a stupid question and I didn't test this with SELinux, but
it looks to me that SELinux execmem does not prevent process from
getting writable and executable memory mappings by using shmat(...,
SHM_EXEC). Shouldn't this be blocked by execmem, I suppose it is there
to prevent this
Resending to lkml without cc's.
Hello,
I'm trying the systemtap approach and it looks promising. The script is
annotating strace-like output with capability, device access and RLIMIT
information. In the end there's a summary. Here's sample output from
wpa_supplicant run:
mprotect(0x7efebf14,
On 07/19/16 01:09, Tejun Heo wrote:
> On Sun, Jul 17, 2016 at 08:11:31PM +0000, Topi Miettinen wrote:
>> On 06/13/16 21:33, Tejun Heo wrote:
>>> Hello,
>>>
>>> On Mon, Jun 13, 2016 at 09:29:32PM +, Topi Miettinen wrote:
>>>> I used fork callba
On 07/18/16 22:52, Tejun Heo wrote:
> On Fri, Jul 15, 2016 at 05:15:41PM +0000, Topi Miettinen wrote:
>> There are clear semantics for the limits themselves, either they apply
>> per task or per user. It makes sense to gather values according to these
>> semantics. Then with s
On 06/13/16 21:33, Tejun Heo wrote:
> Hello,
>
> On Mon, Jun 13, 2016 at 09:29:32PM +0000, Topi Miettinen wrote:
>> I used fork callback as I don't want to lower the watermark in all cases
>> where the charge can be lowered, so I'd update the watermark only when
>
-timesyncd.service/pids.highwater_mark
2
root@debian:~# cat /etc/systemd/system/systemd-timesyncd.service.d/local.conf
[Service]
TasksMax=2
root@debian:~# systemctl status systemd-timesyncd.service | grep Tasks
Tasks: 2 (limit: 2)
Signed-off-by: Topi Miettinen
---
kernel/cgroup_pids.c | 51
-timesyncd.service/pids.highwater_mark
2
root@debian:~# cat /etc/systemd/system/systemd-timesyncd.service.d/local.conf
[Service]
TasksMax=2
root@debian:~# systemctl status systemd-timesyncd.service | grep Tasks
Tasks: 2 (limit: 2)
Signed-off-by: Topi Miettinen
---
kernel/cgroup_pids.c | 51
for configuration of PID and device cgroups.
Thanks to the commenters for the previous version.
-Topi
Topi Miettinen (2):
cgroup_pids: track highwater mark of pids
device_cgroup: track and present accessed devices
kernel/cgroup_pids.c | 51 ++--
security
ervice]
DevicePolicy=closed # implies /dev/null rwm
DeviceAllow=/dev/sda r
Signed-off-by: Topi Miettinen
---
security/device_cgroup.c | 86 ++--
1 file changed, 68 insertions(+), 18 deletions(-)
diff --git a/security/device_cgroup.c b/security/device_cgroup.c
Track maximum size of locked memory, to be able to configure
RLIMIT_MEMLOCK resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen
---
(Resending to lkml due to header size limits)
arch/ia64/kernel/perfmon.c
it+0x7d/0xb8
[0.148000] [] ? pid_namespaces_init+0x40/0x40
[0.148000] [] do_one_initcall+0x50/0x180
[0.148000] [] ? print_cpu_info+0x7d/0xe0
[0.148000] [] kernel_init_freeable+0x111/0x25d
[0.148000] [] kernel_init+0xe/0x100
[0.148000] [] ret_from_fork+0x1f/0x40
[0.148000] [] ? rest
On 07/15/16 14:10, Tejun Heo wrote:
> Hello, Topi.
>
> On Fri, Jul 15, 2016 at 01:35:49PM +0300, Topi Miettinen wrote:
>> Collect resource usage highwater marks of a task to cgroup
>> statistics when the task exits.
>
> I'm not sure how this makes sense. The lim
On 07/15/16 12:49, Nicolas Dichtel wrote:
> Le 15/07/2016 12:35, Topi Miettinen a écrit :
>> There are many basic ways to control processes, including capabilities,
>> cgroups and resource limits. However, there are far fewer ways to find out
>> useful values for the limits, e
Track maximum size of files created, to be able to configure
RLIMIT_FSIZE resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen
---
fs/attr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/attr.c b/fs/attr.c
index
Track maximum size of core dump written, to be able to configure
RLIMIT_CORE resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen
---
fs/coredump.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git
Track maximum size of data VM, to be able to configure
RLIMIT_DATA resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen
---
arch/x86/ia32/ia32_aout.c | 2 ++
fs/binfmt_aout.c | 2 ++
fs/binfmt_flat.c | 2
Track maximum number of pending signals, to be able to configure
RLIMIT_SIGPENDING resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen
---
kernel/signal.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/signal.c
Track maximum size of message queues, to be able to configure
RLIMIT_MSGQUEUE resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen
---
ipc/mqueue.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/ipc/mqueue.c b/ipc
Track maximum number of processes per user, to be able to configure
RLIMIT_NPROC resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen
---
include/linux/sched.h | 30 ++
kernel/cgroup.c | 31
Track maximum size of address space, to be able to configure
RLIMIT_AS resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen
---
mm/mmap.c | 4
mm/mremap.c | 3 +++
2 files changed, 7 insertions(+)
diff --git a/mm
Track maximum number of files for the process, to be able to configure
RLIMIT_NOFILE resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen
---
fs/file.c | 4
1 file changed, 4 insertions(+)
diff --git a/fs/file.c b/fs
Track maximum nice priority, to be able to configure
RLIMIT_NICE resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen
---
kernel/sched/core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/sched/core.c b/kernel
Track maximum RT priority, to be able to configure
RLIMIT_RTPRIO resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen
---
kernel/sched/core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/sched/core.c b/kernel
Collect resource usage highwater marks of a task to cgroup
statistics when the task exits.
Signed-off-by: Topi Miettinen
---
Documentation/accounting/getdelays.c | 10 ++-
include/linux/cgroup-defs.h | 5
include/uapi/linux/cgroupstats.h | 3 ++
kernel/cgroup.c
the resources can be seen using
taskstats netlink interface.
This depends on CONFIG_TASK_XACCT.
Signed-off-by: Topi Miettinen
---
Documentation/accounting/getdelays.c | 52 +---
include/linux/sched.h| 31 +
include/linux
Track maximum stack size, to be able to configure
RLIMIT_STACK resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen
---
mm/mmap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/mmap.c b/mm/mmap.c
index 0b10f56
On 07/12/16 13:16, Eric W. Biederman wrote:
> Topi Miettinen writes:
>
>> On 07/11/16 21:57, Eric W. Biederman wrote:
>>> Topi Miettinen writes:
>>>
>>>> There are many basic ways to control processes, including capabilities,
>>>> cgroups
On 07/12/16 14:59, Tejun Heo wrote:
> On Mon, Jul 11, 2016 at 07:47:44PM +0000, Topi Miettinen wrote:
>> It's really critical to be able to associate a task in the logs to
>> cgroups which were valid that time. Or can we infer somehow what cgroups
>
> When is "t
On 07/11/16 21:57, Eric W. Biederman wrote:
> Topi Miettinen writes:
>
>> There are many basic ways to control processes, including capabilities,
>> cgroups and resource limits. However, there are far fewer ways to find
>> out useful values for the limits, exce
On 07/11/16 17:09, Tejun Heo wrote:
> Hello,
>
> On Mon, Jul 11, 2016 at 02:14:31PM +0300, Topi Miettinen wrote:
>> [ 28.443674] audit: type=1327 audit(1468234333.144:520):
>> proctitle=6D6B6E6F64002F6465762F7A5F343639006300310032
>> [ 28.465888] audit: type=13
On 07/11/16 16:05, Topi Miettinen wrote:
> On 07/11/16 15:25, Serge E. Hallyn wrote:
>> Quoting Topi Miettinen (toiwo...@gmail.com):
>>> There are many basic ways to control processes, including capabilities,
>>> cgroups and resource limits. However, there are far fewer
On 07/11/16 15:25, Serge E. Hallyn wrote:
> Quoting Topi Miettinen (toiwo...@gmail.com):
>> There are many basic ways to control processes, including capabilities,
>> cgroups and resource limits. However, there are far fewer ways to find
>> out useful values for the limits, e
xe="/bin/chown" key=(null)
[ 34.828569] audit: type=1327 audit(1468234339.532:521):
proctitle=63686F776E0031323334002F6465762F7A5F343639
[ 34.848747] audit: type=1330 audit(1468234339.532:521):
cap_used=0001
[ 34.864404] audit: type=1331 audit(1468234339.532:521): cgro
On 07/08/16 09:13, Petr Mladek wrote:
> On Thu 2016-07-07 20:27:13, Topi Miettinen wrote:
>> On 07/07/16 09:16, Petr Mladek wrote:
>>> On Sun 2016-07-03 15:08:07, Topi Miettinen wrote:
>>>> The attached patch would make any uses of capabilities generate audit
>
On 07/08/16 09:13, Petr Mladek wrote:
> On Thu 2016-07-07 20:27:13, Topi Miettinen wrote:
>> On 07/07/16 09:16, Petr Mladek wrote:
>>> On Sun 2016-07-03 15:08:07, Topi Miettinen wrote:
>>>> The attached patch would make any uses of capabilities generate audit
>
On 07/07/16 09:16, Petr Mladek wrote:
> On Sun 2016-07-03 15:08:07, Topi Miettinen wrote:
>> The attached patch would make any uses of capabilities generate audit
>> messages. It works for simple tests as you can see from the commit
>> message, but unfortunately the call
On 06/27/16 19:49, Serge E. Hallyn wrote:
> Quoting Tejun Heo (t...@kernel.org):
>> Hello,
>>
>> On Mon, Jun 27, 2016 at 3:10 PM, Topi Miettinen wrote:
>>> I'll have to study these more. But from what I saw so far, it looks to
>>> me that a separate t
1 - 100 of 145 matches
Mail list logo
