On 01.02.2021 11:26, Stefano Garzarella wrote:
> On Sun, Jan 31, 2021 at 01:59:14PM +0300, Alexander Popov wrote:
>> There are multiple similar bugs implicitly introduced by the
>> commit c0cfa2d8a788fcf4 ("vsock: add multi-transports support") and
>> commit 6a
4 ("vsock: add multi-transports support")
Reviewed-by: Stefano Garzarella
Signed-off-by: Alexander Popov
---
net/vmw_vsock/af_vsock.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index d10
able,
[2] lock_sock() is called,
[3] the local variable is used.
VSOCK multi-transport support introduced the race condition:
vsock_sock.transport value may change between [1] and [2].
Let's copy vsock_sock.transport pointer to local variables after
the lock_sock() call.
Signed-off-by: Alexa
-by: Alexander Popov
Reviewed-by: Alexander Potapenko
---
mm/slab.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index b1113561b98b..344a101e37e0 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3416,6 +3416,9 @@ static void cache_flusharray(struct kmem_cache
On 03.12.2020 23:49, Andrew Morton wrote:
> On Thu, 3 Dec 2020 22:50:27 +0300 Alexander Popov
> wrote:
>
>> On 30.09.2020 15:50, Alexander Potapenko wrote:
>>> On Tue, Sep 29, 2020 at 8:35 PM Alexander Popov
>>> wrote:
>>>>
>>>> Current
On 30.09.2020 15:50, Alexander Potapenko wrote:
> On Tue, Sep 29, 2020 at 8:35 PM Alexander Popov wrote:
>>
>> Currently in CONFIG_SLAB init_on_free happens too late, and heap
>> objects go to the heap quarantine being dirty. Lets move memory
>> clearing before calli
On 06.10.2020 21:37, Jann Horn wrote:
> On Tue, Oct 6, 2020 at 7:56 PM Alexander Popov wrote:
>>
>> On 06.10.2020 01:56, Jann Horn wrote:
>>> On Thu, Oct 1, 2020 at 9:43 PM Alexander Popov wrote:
>>>> On 29.09.2020 21:35, Alexander Popov wrote:
>>
On 06.10.2020 01:56, Jann Horn wrote:
> On Thu, Oct 1, 2020 at 9:43 PM Alexander Popov wrote:
>> On 29.09.2020 21:35, Alexander Popov wrote:
>>> This is the second version of the heap quarantine prototype for the Linux
>>> kernel. I performed a deeper evaluation
On 30.09.2020 15:50, Alexander Potapenko wrote:
> On Tue, Sep 29, 2020 at 8:35 PM Alexander Popov wrote:
>>
>> Currently in CONFIG_SLAB init_on_free happens too late, and heap
>> objects go to the heap quarantine being dirty. Lets move memory
>> clearing before calli
Hello! I have some performance numbers. Please see below.
On 29.09.2020 21:35, Alexander Popov wrote:
> Hello everyone! Requesting for your comments.
>
> This is the second version of the heap quarantine prototype for the Linux
> kernel. I performed a deeper evaluation of its securit
Add verbose debugging for deeper understanding of the heap quarantine
inner workings (this patch is not for merge).
Signed-off-by: Alexander Popov
---
mm/kasan/quarantine.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
the freed object at an unpredictable moment, which
is harmful for the heap spraying technique employed by use-after-free
exploits.
Signed-off-by: Alexander Popov
---
mm/kasan/quarantine.c | 79 +--
1 file changed, 69 insertions(+), 10 deletions(-)
diff --git
cache+0x57/0x93
new_kmalloc_cache+0x39/0x47
create_kmalloc_caches+0x33/0xd9
start_kernel+0x25b/0x532
secondary_startup_64+0xb6/0xc0
Thanks in advance for your feedback.
Best regards,
Alexander
Alexander Popov (6):
mm: Extract SLAB_QUARANTINE from KASAN
mm/slab: Perform init_on_fr
init_on_free that cleans objects before placing them into
the quarantine. CONFIG_PAGE_POISONING should be disabled since it
cuts off init_on_free.
Signed-off-by: Alexander Popov
---
init/Kconfig| 3 ++-
mm/page_alloc.c | 22 ++
2 files changed, 24 insertions(+), 1 deletion
use-after-free exploitation much harder.
Signed-off-by: Alexander Popov
---
drivers/misc/lkdtm/core.c | 2 +
drivers/misc/lkdtm/heap.c | 110 +
drivers/misc/lkdtm/lkdtm.h | 2 +
3 files changed, 114 insertions(+)
diff --git a/drivers/misc/lkdtm/core.c b
is another technique,
heap quarantine doesn't break it.
Signed-off-by: Alexander Popov
---
include/linux/kasan.h | 107 -
include/linux/slab_def.h | 2 +-
include/linux/slub_def.h | 2 +-
init/Kconfig | 13 +
mm/Makefile
Currently in CONFIG_SLAB init_on_free happens too late, and heap
objects go to the heap quarantine being dirty. Lets move memory
clearing before calling kasan_slab_free() to fix that.
Signed-off-by: Alexander Popov
---
mm/slab.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff
On 22.09.2020 08:59, Muchun Song wrote:
> On Mon, Sep 14, 2020 at 9:56 PM Alexander Popov wrote:
>>
>> On 07.09.2020 16:53, Muchun Song wrote:
>>> On Mon, Sep 7, 2020 at 7:24 PM Alexander Popov wrote:
>>>>
>>>> On 07.09.2020 05:54, Muchun So
On 07.09.2020 16:53, Muchun Song wrote:
> On Mon, Sep 7, 2020 at 7:24 PM Alexander Popov wrote:
>>
>> On 07.09.2020 05:54, Muchun Song wrote:
>>> Hi all,
>>>
>>> Any comments or suggestions? Thanks.
>>>
>>> On Fri, Aug 28, 2020 at
On 07.09.2020 05:54, Muchun Song wrote:
> Hi all,
>
> Any comments or suggestions? Thanks.
>
> On Fri, Aug 28, 2020 at 11:19 AM Muchun Song wrote:
>>
>> There is a race between the assignment of `table->data` and write value
>> to the pointer of `table->data` in the
On 18.08.2020 18:45, Andrey Konovalov wrote:
> On Mon, Aug 17, 2020 at 7:32 PM Alexander Popov wrote:
>>
>> On 15.08.2020 19:52, Kees Cook wrote:
>>> On Thu, Aug 13, 2020 at 06:19:21PM +0300, Alexander Popov wrote:
>>>> Heap spraying is an exploitation t
On 15.08.2020 19:39, Kees Cook wrote:
> On Thu, Aug 13, 2020 at 06:19:20PM +0300, Alexander Popov wrote:
>> I've found an easy way to break heap spraying for use-after-free
>> exploitation. I simply extracted slab freelist quarantine from KASAN
>> functionality and called it C
On 16.08.2020 22:59, Pavel Machek wrote:
> On Sat 2020-08-15 19:54:55, Matthew Wilcox wrote:
>> On Thu, Aug 13, 2020 at 06:19:21PM +0300, Alexander Popov wrote:
>>> +config SLAB_QUARANTINE
>>> + bool "Enable slab freelist quarantine"
>>> + de
On 15.08.2020 21:54, Matthew Wilcox wrote:
> On Thu, Aug 13, 2020 at 06:19:21PM +0300, Alexander Popov wrote:
>> +config SLAB_QUARANTINE
>> +bool "Enable slab freelist quarantine"
>> +depends on !KASAN && (SLAB || SLUB)
>> +help
>> +
On 15.08.2020 19:59, Kees Cook wrote:
> On Thu, Aug 13, 2020 at 06:19:22PM +0300, Alexander Popov wrote:
>> Add a simple test for CONFIG_SLAB_QUARANTINE.
>>
>> It performs heap spraying that aims to reallocate the recently freed heap
>> object. This technique is used fo
On 15.08.2020 19:52, Kees Cook wrote:
> On Thu, Aug 13, 2020 at 06:19:21PM +0300, Alexander Popov wrote:
>> Heap spraying is an exploitation technique that aims to put controlled
>> bytes at a predetermined memory location on the heap. Heap spraying for
>> exploiting use-af
On 13.08.2020 18:19, Alexander Popov wrote:
> Hello everyone! Requesting for your comments.
>
> Use-after-free vulnerabilities in the Linux kernel are very popular for
> exploitation. A few examples:
>
> https://googleprojectzero.blogspot.com/2018/09/a-cache-invalidation
technique.
Signed-off-by: Alexander Popov
---
drivers/misc/lkdtm/core.c | 1 +
drivers/misc/lkdtm/heap.c | 40 ++
drivers/misc/lkdtm/lkdtm.h | 1 +
3 files changed, 42 insertions(+)
diff --git a/drivers/misc/lkdtm/core.c b/drivers/misc/lkdtm/core.c
index
use-after-free vulnerabilities
in the kernel code.
If this feature is enabled, freed allocations are stored in the quarantine
and can't be instantly reallocated and overwritten by the exploit
performing heap spraying.
Signed-off-by: Alexander Popov
---
include/linux/kasan.h | 107
3.068, 3.103, 3.107
Mean: 3.0938
Standard deviation: 0.0144
CONFIG_SLAB_QUARANTINE enabled (x86_64, CONFIG_SLUB):
Times: 3.303, 3.329, 3.356, 3.314, 3.292
Mean: 3.3188 (+7.3%)
Standard deviation: 0.0223
I would appreciate your feedback!
Best regards,
Alexander
Alexander Popov (2):
mm: E
On 24.06.2020 15:53, Luis Chamberlain wrote:
> On Wed, Jun 24, 2020 at 03:33:30PM +0300, Alexander Popov wrote:
>> Add 'verbose' plugin parameter for stackleak gcc plugin.
>> It can be used for printing additional info about the kernel code
>> instrumentation.
>>
>&g
On 24.06.2020 15:52, Luis Chamberlain wrote:
> On Wed, Jun 24, 2020 at 03:33:27PM +0300, Alexander Popov wrote:
>> Don't use gcc plugins for building arch/arm/vdso/vgettimeofday.c to
>> avoid unneeded instrumentation.
>>
>> Signed-off-by: Alexander Popov
>
> Bu
-verbose
Signed-off-by: Alexander Popov
---
scripts/gcc-plugins/stackleak_plugin.c | 47 +++---
1 file changed, 42 insertions(+), 5 deletions(-)
diff --git a/scripts/gcc-plugins/stackleak_plugin.c
b/scripts/gcc-plugins/stackleak_plugin.c
index a18b0d4af456..48e141e07956 100644
ecurity blog
https://grsecurity.net/resolving_an_unfortunate_stackleak_interaction
Signed-off-by: Alexander Popov
Acked-by: Miguel Ojeda
---
include/linux/compiler_attributes.h| 13 ++
kernel/stackleak.c | 16 +-
scripts/Makefile.gcc-plugins | 2 +
Don't use gcc plugins for building arch/arm64/kernel/vdso/vgettimeofday.c
to avoid unneeded instrumentation.
Signed-off-by: Alexander Popov
---
arch/arm64/kernel/vdso/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel
Don't use gcc plugins for building arch/arm/vdso/vgettimeofday.c to
avoid unneeded instrumentation.
Signed-off-by: Alexander Popov
---
arch/arm/vdso/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/vdso/Makefile b/arch/arm/vdso/Makefile
index d3c9f03e7e79
There is no need to try instrumenting functions in kernel/stackleak.c.
Otherwise that can cause issues if the cleanup pass of stackleak gcc plugin
is disabled.
Signed-off-by: Alexander Popov
Acked-by: Kees Cook
---
kernel/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel
alphabetic order in include/linux/compiler_attributes.h.
Link to v1:
https://lore.kernel.org/lkml/20200604134957.505389-1-alex.po...@linux.com/
Alexander Popov (5):
gcc-plugins/stackleak: Don't instrument itself
ARM: vdso: Don't use gcc plugins for building vgettimeofday.c
arm64: vdso: Don't
On 22.06.2020 22:31, Kees Cook wrote:
> As Linux kernel stack protections have been constantly improving
> (vmap-based stack allocation with guard pages, removal of thread_info,
> STACKLEAK), attackers have had to find new ways for their exploits
> to work. They have done so, continuing to rely on
On 10.06.2020 10:30, Will Deacon wrote:
> On Tue, Jun 09, 2020 at 12:09:27PM -0700, Kees Cook wrote:
>> arm_ssp_per_task_plugin.c
>> 32-bit ARM only (but likely needs disabling for 32-bit ARM vDSO?)
I tested: on 32-bit arm vDSO is built with plugin flags. I will filter them out
in a separate
On 10.06.2020 23:03, Kees Cook wrote:
> On Wed, Jun 10, 2020 at 06:47:14PM +0300, Alexander Popov wrote:
>> On 09.06.2020 21:46, Kees Cook wrote:
>> The inline asm statement that is used for instrumentation is arch-specific.
>> Trying to add
>> asm volatile(
On 09.06.2020 21:47, Kees Cook wrote:
> On Thu, Jun 04, 2020 at 04:49:55PM +0300, Alexander Popov wrote:
>> Add 'verbose' plugin parameter for stackleak gcc plugin.
>> It can be used for printing additional info about the kernel code
>> instrumentation.
>>
>&g
On 09.06.2020 21:46, Kees Cook wrote:
> On Thu, Jun 04, 2020 at 04:49:54PM +0300, Alexander Popov wrote:
>> Let's improve the instrumentation to avoid this:
>>
>> 1. Make stackleak_track_stack() save all register that it works with.
>> Use no_caller_saved_registers
On 09.06.2020 21:39, Kees Cook wrote:
> On Thu, Jun 04, 2020 at 06:23:38PM +0300, Alexander Popov wrote:
>> On 04.06.2020 17:01, Jann Horn wrote:
>>> On Thu, Jun 4, 2020 at 3:51 PM Alexander Popov wrote:
>>>> Some time ago Variable Length Arrays (VLA) were removed fr
On 10.06.2020 10:30, Will Deacon wrote:
> On Tue, Jun 09, 2020 at 12:09:27PM -0700, Kees Cook wrote:
>> On Thu, Jun 04, 2020 at 02:58:06PM +0100, Will Deacon wrote:
>>> On Thu, Jun 04, 2020 at 04:49:57PM +0300, Alexander Popov wrote:
>>>> Don't try instrumenting
On 09.06.2020 22:15, Kees Cook wrote:
> On Thu, Jun 04, 2020 at 04:49:52PM +0300, Alexander Popov wrote:
>> In this patch series I collected various improvements of the stackleak
>> gcc plugin.
>
> Thanks!
>
>> Alexander Popov (5):
>> gcc-plug
On 04.06.2020 17:01, Jann Horn wrote:
> On Thu, Jun 4, 2020 at 3:51 PM Alexander Popov wrote:
>> Some time ago Variable Length Arrays (VLA) were removed from the kernel.
>> The kernel is built with '-Wvla'. Let's exclude alloca() from the
>> instrumentation logic and make
On 04.06.2020 17:25, Jann Horn wrote:
> On Thu, Jun 4, 2020 at 4:21 PM Alexander Popov wrote:
>> On 04.06.2020 17:14, Jann Horn wrote:
>>> Maybe at some point we should replace exclusions based on
>>> GCC_PLUGINS_CFLAGS and KASAN_SANITIZE and UBSAN_SANITIZE and
&g
On 04.06.2020 17:14, Jann Horn wrote:
> On Thu, Jun 4, 2020 at 3:58 PM Will Deacon wrote:
>> On Thu, Jun 04, 2020 at 04:49:57PM +0300, Alexander Popov wrote:
>>> Don't try instrumenting functions in arch/arm64/kernel/vdso/vgettimeofday.c.
>>> Otherwise that can cause
ed-off-by: Alexander Popov
---
scripts/gcc-plugins/stackleak_plugin.c | 51 +++---
1 file changed, 21 insertions(+), 30 deletions(-)
diff --git a/scripts/gcc-plugins/stackleak_plugin.c
b/scripts/gcc-plugins/stackleak_plugin.c
index cc75eeba0be1..1ecfe50d0bf5 100644
--- a/scripts/gcc-p
Don't try instrumenting functions in arch/arm64/kernel/vdso/vgettimeofday.c.
Otherwise that can cause issues if the cleanup pass of stackleak gcc plugin
is disabled.
Signed-off-by: Alexander Popov
---
arch/arm64/kernel/vdso/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
-verbose
Signed-off-by: Alexander Popov
---
scripts/gcc-plugins/stackleak_plugin.c | 31 +-
1 file changed, 26 insertions(+), 5 deletions(-)
diff --git a/scripts/gcc-plugins/stackleak_plugin.c
b/scripts/gcc-plugins/stackleak_plugin.c
index 0769c5b9156d..19358712d4ed 100644
ecurity blog
https://grsecurity.net/resolving_an_unfortunate_stackleak_interaction
Signed-off-by: Alexander Popov
---
include/linux/compiler_attributes.h| 13 ++
kernel/stackleak.c | 16 +-
scripts/Makefile.gcc-plugins | 2 +
scripts/gcc-plugins/stac
There is no need to try instrumenting functions in kernel/stackleak.c.
Otherwise that can cause issues if the cleanup pass of stackleak gcc plugin
is disabled.
Signed-off-by: Alexander Popov
---
kernel/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/Makefile b/kernel
/a13xp0p0v/kernel-build-containers
Alexander Popov (5):
gcc-plugins/stackleak: Exclude alloca() from the instrumentation logic
gcc-plugins/stackleak: Use asm instrumentation to avoid useless
register saving
gcc-plugins/stackleak: Add 'verbose' plugin parameter
gcc-plugins/stackleak: Don't
Hello Kees and Robin,
On 01.08.2019 23:14, Kees Cook wrote:
> On Thu, Aug 01, 2019 at 09:30:58AM +0200, Robin Lindner wrote:
>> Cleaned documentation comment up. I removed the "TODO" because it was very
>> old.
>> ---
>> scripts/gcc-plugins/stackleak_plugin.c | 2 --
>> 1 file changed, 2
:
...
CONFIG_BPF_STREAM_PARSER=y
CONFIG_NET_FLOW_LIMIT=y
#
# Network testing
#
CONFIG_NET_PKTGEN=y
CONFIG_NET_DROP_MONITOR=y
# end of Network testing
# end of Networking options
CONFIG_HAMRADIO=y
...
Signed-off-by: Alexander Popov
---
v3 changes:
- rebase onto the recent rc;
- don't print the end comment
7 May 2019 15:29:26 GMT+03:00, Masahiro Yamada
wrote:
>This patch breaks "make testconfig".
>
>Please get rid of the "endof" for the rootmenu
>at the end of the .config file.
Thanks a lot for having a look!
I'll fix this issue, test it and return with the next version.
Best regards,
On 24.04.2019 15:02, Alexander Popov wrote:
> Currently menu blocks start with a pretty header but end with nothing in
> the generated config. So next config options stick together with the
> options from the menu block.
>
> Let's terminate menu blocks in the generated config
On 23.04.2019 22:49, Kees Cook wrote:
> This moves the stackleak plugin options to Kconfig.hardening's memory
> initialization menu.
>
> Signed-off-by: Kees Cook
Hello Kees,
I see the changes in STACKLEAK help, looks good to me.
For this patch -
Reviewed-by: Alexander Popov
On 24.04.2019 13:09, Masahiro Yamada wrote:
> On Sat, Apr 20, 2019 at 4:12 AM Alexander Popov wrote:
>>
>> Currently menu blocks start with a pretty header but end with nothing in
>> the generated config. So next config options stick together with the
>> options from
:
...
CONFIG_BPF_STREAM_PARSER=y
CONFIG_NET_FLOW_LIMIT=y
#
# Network testing
#
CONFIG_NET_PKTGEN=y
CONFIG_NET_DROP_MONITOR=y
# end of Network testing
# end of Networking options
CONFIG_HAMRADIO=y
...
Signed-off-by: Alexander Popov
---
scripts/kconfig/confdata.c | 12 +++-
1 file changed, 11 insertions(+), 1
On 16.04.2019 16:56, Kees Cook wrote:
> On Tue, Apr 16, 2019 at 8:55 AM Alexander Popov wrote:
>>
>> On 16.04.2019 7:02, Kees Cook wrote:
>>> On Mon, Apr 15, 2019 at 11:44 AM Alexander Popov
>>> wrote:
>>>>
>>>> What do you think about s
Currently menu blocks start with a pretty header but end with nothing in
the generated config. So next config options stick together with the
options from the menu block.
Let's terminate menu blocks with a newline in the generated config.
Signed-off-by: Alexander Popov
---
scripts/kconfig
On 16.04.2019 7:02, Kees Cook wrote:
> On Mon, Apr 15, 2019 at 11:44 AM Alexander Popov wrote:
>>
>> What do you think about some separator between memory initialization options
>> and
>> CONFIG_CRYPTO?
>
> This was true before too
Hm, yes, it's a generic beh
On 11.04.2019 21:01, Kees Cook wrote:
> Right now kernel hardening options are scattered around various Kconfig
> files. This can be a central place to collect these kinds of options
> going forward. This is initially populated with the memory initialization
> options from the gcc-plugins.
>
>
Hello Kees, hello everyone,
On 12.02.2019 21:04, Kees Cook wrote:
> Building with CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL should give the
> kernel complete initialization coverage of all stack variables passed
> by reference, including padding (see lib/test_stackinit.c).
I would like to note that
On 23.01.2019 14:03, Kees Cook wrote:
> This adds a new plugin "stackinit" that attempts to perform unconditional
> initialization of all stack variables
Hello Kees! Hello everyone!
I was curious about the performance impact of the initialization of all stack
variables. So I did a very brief
On 21.01.2019 15:48, Alexander Popov wrote:
> The single-step debugging of KVM guests on x86 is broken: if we run
> gdb 'stepi' command at the breakpoint when the guest interrupts are
> enabled, RIP always jumps to native_apic_mem_write(). Then other
> nasty effects follow.
>
>
c8401dda2f0a00cd25c0 ("KVM: x86: fix singlestepping over syscall")
introduced the kvm_run.debug corruption: kvm_vcpu_do_singlestep() can
be called without X86_EFLAGS_TF set.
Let's fix it. Please consider that for -stable.
Signed-off-by: Alexander Popov
---
arch/x86/kvm/x86.c | 3 +--
1 file changed, 1
Oops. I've forgotten about checkpatch.pl.
I've fixed the commit message and will resend the patch shortly.
--
Alexander
The single-step debugging of KVM guests on x86 is broken: if we run
gdb 'stepi' command at the breakpoint when the guest interrupts are
enabled, RIP always jumps to native_apic_mem_write(). Then other
nasty effects follow.
Long investigation showed that the commit c8401dda2f0a00cd25c0 (Jun 7
Hello everyone,
I've carefully worked with this report, let me share the results.
On 18.12.2018 8:15, kernel test robot wrote:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
' pass. It's the moment when the stack frame size is
already final, function prologues and epilogues are generated, and the
machine-dependent code transformations are not done.
[1] https://www.openwall.com/lists/kernel-hardening/2018/11/23/2
Reported-by: kbuild test robot
Signed-off-by: Alexander
On 03.12.2018 21:25, Alexander Popov wrote:
> But I think it's better to register the 'stackleak_cleanup' pass just one pass
> earlier -- before the '*free_cfg' pass. I'll double check it for different
> versions of gcc on all supported architectures and return with a new patch.
I'
().
Reported-by: kernel test robot
Signed-off-by: Alexander Popov
---
kernel/stackleak.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/stackleak.c b/kernel/stackleak.c
index e428929..08cb57e 100644
--- a/kernel/stackleak.c
+++ b/kernel/stackleak.c
@@ -11,6 +11,7
().
Reported-by: kernel test robot
Signed-off-by: Alexander Popov
---
kernel/stackleak.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/stackleak.c b/kernel/stackleak.c
index e428929..08cb57e 100644
--- a/kernel/stackleak.c
+++ b/kernel/stackleak.c
@@ -11,6 +11,7
Hello Steven and Masami,
Thanks for your comments.
On 12.11.2018 5:50, Masami Hiramatsu wrote:
> Hi Alexander and Steve,
>
> On Sun, 11 Nov 2018 20:53:51 -0500
> Steven Rostedt wrote:
>
>> On Sun, 11 Nov 2018 13:19:45 +0300
>> Alexander Popov wrote:
>>
>&
Hello Steven and Masami,
Thanks for your comments.
On 12.11.2018 5:50, Masami Hiramatsu wrote:
> Hi Alexander and Steve,
>
> On Sun, 11 Nov 2018 20:53:51 -0500
> Steven Rostedt wrote:
>
>> On Sun, 11 Nov 2018 13:19:45 +0300
>> Alexander Popov wrote:
>>
>&
On 11.11.2018 2:30, Steven Rostedt wrote:
> On Sun, 11 Nov 2018 01:05:30 +0300
> Alexander Popov wrote:
>
>> The stackleak_erase() function is called on the trampoline stack at the
>> end of syscall. This stack is not big enough for ftrace operations,
>> e.g. it can
On 11.11.2018 2:30, Steven Rostedt wrote:
> On Sun, 11 Nov 2018 01:05:30 +0300
> Alexander Popov wrote:
>
>> The stackleak_erase() function is called on the trampoline stack at the
>> end of syscall. This stack is not big enough for ftrace operations,
>> e.g. it can
-by: kernel test robot
Signed-off-by: Alexander Popov
Reviewed-by: Kees Cook
---
kernel/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/Makefile b/kernel/Makefile
index 7343b3a..0906f6d 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_MULTIUSER
-by: kernel test robot
Signed-off-by: Alexander Popov
Reviewed-by: Kees Cook
---
kernel/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/Makefile b/kernel/Makefile
index 7343b3a..0906f6d 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_MULTIUSER
On 06.11.2018 18:50, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 163c8d54a997153ee1a1e07fcac087492ad85b37
> commit: 10e9ae9fabaf96c8e5227c1cd4827d58b3aa406d gcc-plugins: Add STACKLEAK
> plugin for tracking the kernel
On 06.11.2018 18:50, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 163c8d54a997153ee1a1e07fcac087492ad85b37
> commit: 10e9ae9fabaf96c8e5227c1cd4827d58b3aa406d gcc-plugins: Add STACKLEAK
> plugin for tracking the kernel
Hello Linus,
On 15.08.2018 22:04, Linus Torvalds wrote:
> On Wed, Aug 15, 2018 at 11:35 AM Kees Cook wrote:
>>
>> I swear I'm doing my best. Are you speaking of
>> stackleak_check_alloca() or stackleak_erase()? These were both
>> discussed on the list, and we weren't able to come up with
>>
Hello Linus,
On 15.08.2018 22:04, Linus Torvalds wrote:
> On Wed, Aug 15, 2018 at 11:35 AM Kees Cook wrote:
>>
>> I swear I'm doing my best. Are you speaking of
>> stackleak_check_alloca() or stackleak_erase()? These were both
>> discussed on the list, and we weren't able to come up with
>>
Kirin
620 SoC). The lkdtm tests for STACKLEAK work fine.
Acked-by: Alexander Popov
For testing I applied your patches above Kees' for-next/kspp:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=for-next/kspp
I've had one trouble with building CONFIG_STACKLEAK_RUNTIME_DISABL
Kirin
620 SoC). The lkdtm tests for STACKLEAK work fine.
Acked-by: Alexander Popov
For testing I applied your patches above Kees' for-next/kspp:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=for-next/kspp
I've had one trouble with building CONFIG_STACKLEAK_RUNTIME_DISABL
Hello Laura,
Thanks again for your work.
Please see some comments below.
On 19.07.2018 00:10, Laura Abbott wrote:
> Implementation of stackleak based heavily on the x86 version
>
> Signed-off-by: Laura Abbott
> ---
> Since last time: Minor style cleanups. Re-wrote check_alloca to
> correctly
Hello Laura,
Thanks again for your work.
Please see some comments below.
On 19.07.2018 00:10, Laura Abbott wrote:
> Implementation of stackleak based heavily on the x86 version
>
> Signed-off-by: Laura Abbott
> ---
> Since last time: Minor style cleanups. Re-wrote check_alloca to
> correctly
On 03.07.2018 18:03, Catalin Marinas wrote:
> On Tue, Jul 03, 2018 at 01:14:41PM +0100, Mark Rutland wrote:
>> On Mon, Jul 02, 2018 at 11:48:05AM -0700, Laura Abbott wrote:
>>> On 07/02/2018 06:02 AM, Alexander Popov wrote:
>>>> Could you rename the macro to STACKLEAK
On 03.07.2018 18:03, Catalin Marinas wrote:
> On Tue, Jul 03, 2018 at 01:14:41PM +0100, Mark Rutland wrote:
>> On Mon, Jul 02, 2018 at 11:48:05AM -0700, Laura Abbott wrote:
>>> On 07/02/2018 06:02 AM, Alexander Popov wrote:
>>>> Could you rename the macro to STACKLEAK
Hello Laura,
Thanks for your work!
Please see my comments below.
On 29.06.2018 22:05, Laura Abbott wrote:
> Implementation of stackleak based heavily on the x86 version
>
> Signed-off-by: Laura Abbott
> ---
> Changes since last time:
> - Minor name change in entry.S
> - Converted to use the
Hello Laura,
Thanks for your work!
Please see my comments below.
On 29.06.2018 22:05, Laura Abbott wrote:
> Implementation of stackleak based heavily on the x86 version
>
> Signed-off-by: Laura Abbott
> ---
> Changes since last time:
> - Minor name change in entry.S
> - Converted to use the
On 14.05.2018 13:06, Mark Rutland wrote:
> On Mon, May 14, 2018 at 12:35:25PM +0300, Alexander Popov wrote:
>> On 14.05.2018 08:15, Mark Rutland wrote:
>>> On Sun, May 13, 2018 at 11:40:07AM +0300, Alexander Popov wrote:
>>>> So what would you think if I do
On 14.05.2018 13:06, Mark Rutland wrote:
> On Mon, May 14, 2018 at 12:35:25PM +0300, Alexander Popov wrote:
>> On 14.05.2018 08:15, Mark Rutland wrote:
>>> On Sun, May 13, 2018 at 11:40:07AM +0300, Alexander Popov wrote:
>>>> So what would you think if I do
On 14.05.2018 08:15, Mark Rutland wrote:
> On Sun, May 13, 2018 at 11:40:07AM +0300, Alexander Popov wrote:
>> It seems that previously I was very "lucky" to accidentally have those
>> MIN_STACK_LEFT,
>> call trace depth and oops=panic together to experience a hang
On 14.05.2018 08:15, Mark Rutland wrote:
> On Sun, May 13, 2018 at 11:40:07AM +0300, Alexander Popov wrote:
>> It seems that previously I was very "lucky" to accidentally have those
>> MIN_STACK_LEFT,
>> call trace depth and oops=panic together to experience a hang
Hello Mark,
Thanks a lot for your reply!
On 11.05.2018 19:13, Mark Rutland wrote:
> On Fri, May 11, 2018 at 06:50:09PM +0300, Alexander Popov wrote:
>> On 06.05.2018 11:22, Alexander Popov wrote:
>>> On 04.05.2018 14:09, Mark Rutland wrote:
>>>>>>> +
1 - 100 of 333 matches
Mail list logo
