On Tue, 13 Nov 2018, I wrote:
> On Mon, 12 Nov 2018, Thomas Gleixner wrote:
>
> > > +static u32 clk_total;
> > > +
> > > +#define PCC_TIMER_CLOCK_FREQ 100
> > > +#define PCC_TIMER_CYCLES (PCC_TIMER_CLOCK_FREQ / HZ)
> > > +
> > > static irqreturn_t mvme16x_timer_int (int irq, void
On Tue, 13 Nov 2018, I wrote:
> On Mon, 12 Nov 2018, Thomas Gleixner wrote:
>
> > > +static u32 clk_total;
> > > +
> > > +#define PCC_TIMER_CLOCK_FREQ 100
> > > +#define PCC_TIMER_CYCLES (PCC_TIMER_CLOCK_FREQ / HZ)
> > > +
> > > static irqreturn_t mvme16x_timer_int (int irq, void
On Nov 13 2018, Brian Norris wrote:
> + } | grep -qv '^\(.. \)\?scripts/package'; then
\? is a GNU extension, so if you want to stay portable you need to
switch to ERE.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73
On Nov 13 2018, Brian Norris wrote:
> + } | grep -qv '^\(.. \)\?scripts/package'; then
\? is a GNU extension, so if you want to stay portable you need to
switch to ERE.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73
Hi Oleg!
On Tue, Nov 13, 2018 at 04:48:25PM +0100, Oleg Nesterov wrote:
> On 11/12, Roman Gushchin wrote:
> >
> > --- a/include/linux/sched.h
> > +++ b/include/linux/sched.h
> > @@ -83,7 +83,8 @@ struct task_group;
> > #define TASK_WAKING0x0200
> > #define TASK_NOLOAD
Hi Oleg!
On Tue, Nov 13, 2018 at 04:48:25PM +0100, Oleg Nesterov wrote:
> On 11/12, Roman Gushchin wrote:
> >
> > --- a/include/linux/sched.h
> > +++ b/include/linux/sched.h
> > @@ -83,7 +83,8 @@ struct task_group;
> > #define TASK_WAKING0x0200
> > #define TASK_NOLOAD
On Tue, 13 Nov 2018, Russell King - ARM Linux wrote:
> On Tue, Nov 13, 2018 at 02:39:00PM +1100, Finn Thain wrote:
> >
> > You could remove the old arch_gettimeoffset API without dropping any
> > platforms.
> >
> > If no-one converts a given platform to the clocksource API it would mean
> >
On Tue, 13 Nov 2018, Russell King - ARM Linux wrote:
> On Tue, Nov 13, 2018 at 02:39:00PM +1100, Finn Thain wrote:
> >
> > You could remove the old arch_gettimeoffset API without dropping any
> > platforms.
> >
> > If no-one converts a given platform to the clocksource API it would mean
> >
On 11/13/18 1:40 PM, Jarkko Sakkinen wrote:
> +int main(int argc, char **argv)
> +{
> + unsigned long bin_size = (unsigned long)_bin_end -
> + (unsigned long)_bin;
> + struct sgx_secs secs;
> + uint64_t result = 0;
> +
> + if (!encl_load(, bin_size))
>
On 11/13/18 1:40 PM, Jarkko Sakkinen wrote:
> +int main(int argc, char **argv)
> +{
> + unsigned long bin_size = (unsigned long)_bin_end -
> + (unsigned long)_bin;
> + struct sgx_secs secs;
> + uint64_t result = 0;
> +
> + if (!encl_load(, bin_size))
>
On Tue 2018-11-13 22:38:49, Geert Uytterhoeven wrote:
> Hi Pavel,
>
> On Mon, Nov 12, 2018 at 11:07 PM Pavel Machek wrote:
> > Not really, I'm afraid. Hard drives have no red LEDs on them (and the
> > LED would not be visible, anyway) so the "device" symlink in such case
> > would point to some
On Tue 2018-11-13 22:38:49, Geert Uytterhoeven wrote:
> Hi Pavel,
>
> On Mon, Nov 12, 2018 at 11:07 PM Pavel Machek wrote:
> > Not really, I'm afraid. Hard drives have no red LEDs on them (and the
> > LED would not be visible, anyway) so the "device" symlink in such case
> > would point to some
Add a selftest for SGX. It is a trivial test where a simple enclave
copies one 64-bit word of memory between two memory locations given to
the enclave as arguments.
Signed-off-by: Jarkko Sakkinen
---
Since this is my very first addition to selftests, I decided to roll out
an RFC patch before
Add a selftest for SGX. It is a trivial test where a simple enclave
copies one 64-bit word of memory between two memory locations given to
the enclave as arguments.
Signed-off-by: Jarkko Sakkinen
---
Since this is my very first addition to selftests, I decided to roll out
an RFC patch before
Hi Pavel,
On Mon, Nov 12, 2018 at 11:07 PM Pavel Machek wrote:
> Not really, I'm afraid. Hard drives have no red LEDs on them (and the
> LED would not be visible, anyway) so the "device" symlink in such case
> would point to some kind of i2c LED controller.
I've seen hard drives with LEDs on
Hi Pavel,
On Mon, Nov 12, 2018 at 11:07 PM Pavel Machek wrote:
> Not really, I'm afraid. Hard drives have no red LEDs on them (and the
> LED would not be visible, anyway) so the "device" symlink in such case
> would point to some kind of i2c LED controller.
I've seen hard drives with LEDs on
Hi Linus
Normally pull requests for kgdb come from Jason Wessel but he's seems to
have been struggling for time this dev cycle so I've stepped in. That
I've put this together at (somewhat past) the last minute goes some way
to explaining why I've included some -Wimplicit-fallthrough fixes here.
Hi Linus
Normally pull requests for kgdb come from Jason Wessel but he's seems to
have been struggling for time this dev cycle so I've stepped in. That
I've put this together at (somewhat past) the last minute goes some way
to explaining why I've included some -Wimplicit-fallthrough fixes here.
A Donation Of 1 Million British Pounds To You In Good Faith
A Donation Of 1 Million British Pounds To You In Good Faith
Running a runc testsuite [1] on an aarch64 server with the latest mainline (rc2)
triggered this,
[1] https://fedorapeople.org/cgit/caiqian/public_git/runctst.git/tree/runctst.py
=
# python runctst.py
...
- start: runc ocf poststart
load container root: container "root" does not
Running a runc testsuite [1] on an aarch64 server with the latest mainline (rc2)
triggered this,
[1] https://fedorapeople.org/cgit/caiqian/public_git/runctst.git/tree/runctst.py
=
# python runctst.py
...
- start: runc ocf poststart
load container root: container "root" does not
On 11/13/18 1:36 PM, Jarkko Sakkinen wrote:
Remove @flags from tpm_transmit() API. It is no longer used for
anything.
Signed-off-by: Jarkko Sakkinen
Reviewed-by: Stefan Berger
---
drivers/char/tpm/tpm-chip.c | 32 ++---
drivers/char/tpm/tpm-dev-common.c | 2 +-
On 11/13/18 1:36 PM, Jarkko Sakkinen wrote:
Remove @flags from tpm_transmit() API. It is no longer used for
anything.
Signed-off-by: Jarkko Sakkinen
Reviewed-by: Stefan Berger
---
drivers/char/tpm/tpm-chip.c | 32 ++---
drivers/char/tpm/tpm-dev-common.c | 2 +-
On 11/13/18 1:36 PM, Jarkko Sakkinen wrote:
Call tpm_chip_start() and tpm_chip_stop() in
* tpm_try_get_ops() and tpm_put_ops()
* tpm_chip_register()
* tpm2_del_space()
And remove these calls from tpm_transmit(). The core reason for this
change is that in tpm_vtpm_proxy a locality change
On 11/13/18 1:36 PM, Jarkko Sakkinen wrote:
Call tpm_chip_start() and tpm_chip_stop() in
* tpm_try_get_ops() and tpm_put_ops()
* tpm_chip_register()
* tpm2_del_space()
And remove these calls from tpm_transmit(). The core reason for this
change is that in tpm_vtpm_proxy a locality change
Hi Alex,
On 11/13/18 5:34 PM, Alex Williamson wrote:
> On Tue, 13 Nov 2018 15:42:49 +0100
> Auger Eric wrote:
>
>> Hi Alex,
>>
>> On 11/9/18 11:09 PM, Alex Williamson wrote:
>>> In commit 61d792562b53 ("vfio-pci: Use mutex around open, release, and
>>> remove") a mutex was added to freeze the
Hi Alex,
On 11/13/18 5:34 PM, Alex Williamson wrote:
> On Tue, 13 Nov 2018 15:42:49 +0100
> Auger Eric wrote:
>
>> Hi Alex,
>>
>> On 11/9/18 11:09 PM, Alex Williamson wrote:
>>> In commit 61d792562b53 ("vfio-pci: Use mutex around open, release, and
>>> remove") a mutex was added to freeze the
On 11/13/18 1:36 PM, Jarkko Sakkinen wrote:
Encapsulate power gating and locality functionality to tpm_chip_start()
and tpm_chip_stop() in order to clean up the branching mess in
tpm_transmit().
Signed-off-by: Jarkko Sakkinen
Reviewed-by: Stefan Berger
---
drivers/char/tpm/tpm-chip.c
On 11/13/18 1:36 PM, Jarkko Sakkinen wrote:
Encapsulate power gating and locality functionality to tpm_chip_start()
and tpm_chip_stop() in order to clean up the branching mess in
tpm_transmit().
Signed-off-by: Jarkko Sakkinen
Reviewed-by: Stefan Berger
---
drivers/char/tpm/tpm-chip.c
Hi Linus,
Please pull this fix for a bug introduced with '82f94f24475c ("KEYS:
Provide software public key query function [ver #2]")'.
The following changes since commit ccda4af0f4b92f7b4c308d3acc262f4a7e3affad:
Linux 4.20-rc2 (2018-11-11 17:12:31 -0600)
are available in the Git repository
Hi Linus,
Please pull this fix for a bug introduced with '82f94f24475c ("KEYS:
Provide software public key query function [ver #2]")'.
The following changes since commit ccda4af0f4b92f7b4c308d3acc262f4a7e3affad:
Linux 4.20-rc2 (2018-11-11 17:12:31 -0600)
are available in the Git repository
On Thu, Nov 08, 2018 at 05:46:10PM +0100, Bartosz Golaszewski wrote:
> Use devm_kstrdup_const() in the tegra-hsp driver. This mostly serves as
> an example of how to use this new routine to shrink driver code.
>
> Also use devm_kzalloc() instead of regular kzalloc() to shrink the
> driver even
On Thu, Nov 08, 2018 at 05:46:10PM +0100, Bartosz Golaszewski wrote:
> Use devm_kstrdup_const() in the tegra-hsp driver. This mostly serves as
> an example of how to use this new routine to shrink driver code.
>
> Also use devm_kzalloc() instead of regular kzalloc() to shrink the
> driver even
Please pull:
git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.20-1
Three nfsd bugfixes. None are new bugs, but they all take a little
effort to hit, which might explain why they weren't found sooner.
--b.
Frank Sorenson (1):
sunrpc: correct the computation for page_ptr when
Please pull:
git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.20-1
Three nfsd bugfixes. None are new bugs, but they all take a little
effort to hit, which might explain why they weren't found sooner.
--b.
Frank Sorenson (1):
sunrpc: correct the computation for page_ptr when
On Mon, Nov 12, 2018 at 03:43:37PM -0800, David Woodhouse wrote:
>
> That can't hurt. We should probably look at the time elapsed before you
> can *write* to it (when the background scan and crc checking is
> complete) rather than just reading.
>
Here are more data points. This is again with
On Mon, Nov 12, 2018 at 03:43:37PM -0800, David Woodhouse wrote:
>
> That can't hurt. We should probably look at the time elapsed before you
> can *write* to it (when the background scan and crc checking is
> complete) rather than just reading.
>
Here are more data points. This is again with
On Tue, Nov 13, 2018 at 08:55:11PM +, Roman Gushchin wrote:
> > > > > + if (lock_task_sighand(task, )) {
> > > > > + if (test_bit(CGRP_FREEZE, >flags))
> > > > > + task->jobctl |= JOBCTL_TRAP_FREEZE;
> > > > > + else
> > > > > +
> On Nov 13, 2018, at 11:39 AM, Dave Martin wrote:
>
> On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote:
>
> [...]
>
>> We can learn something from how Windows does things. On that system,
>> what we think of as "libc" is actually two parts. (More, actually, but
>> I'm
On Tue, Nov 13, 2018 at 08:55:11PM +, Roman Gushchin wrote:
> > > > > + if (lock_task_sighand(task, )) {
> > > > > + if (test_bit(CGRP_FREEZE, >flags))
> > > > > + task->jobctl |= JOBCTL_TRAP_FREEZE;
> > > > > + else
> > > > > +
> On Nov 13, 2018, at 11:39 AM, Dave Martin wrote:
>
> On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote:
>
> [...]
>
>> We can learn something from how Windows does things. On that system,
>> what we think of as "libc" is actually two parts. (More, actually, but
>> I'm
On 11/12/2018 11:06 PM, Pavel Machek wrote:
> On Mon 2018-11-12 21:11:32, Jacek Anaszewski wrote:
>> On 11/12/2018 08:05 PM, Pavel Machek wrote:
>>> Hi!
>>>
>>> My system looks like this:
>>>
>>> input16::capslocktpacpi::bay_activetpacpi::standby
>>> input16::numlock
On 11/12/2018 11:06 PM, Pavel Machek wrote:
> On Mon 2018-11-12 21:11:32, Jacek Anaszewski wrote:
>> On 11/12/2018 08:05 PM, Pavel Machek wrote:
>>> Hi!
>>>
>>> My system looks like this:
>>>
>>> input16::capslocktpacpi::bay_activetpacpi::standby
>>> input16::numlock
On 11/12/2018 07:27 PM, Rob Herring wrote:
> On Tue, Nov 06, 2018 at 11:07:12PM +0100, Jacek Anaszewski wrote:
>> Introduce dedicated properties for conveying information about
>> LED function and color. Mark old "label" property as deprecated.
>>
>> Signed-off-by: Jacek Anaszewski
>> Cc: Baolin
On 11/12/2018 07:27 PM, Rob Herring wrote:
> On Tue, Nov 06, 2018 at 11:07:12PM +0100, Jacek Anaszewski wrote:
>> Introduce dedicated properties for conveying information about
>> LED function and color. Mark old "label" property as deprecated.
>>
>> Signed-off-by: Jacek Anaszewski
>> Cc: Baolin
On Tue, Nov 13, 2018 at 11:15:41AM -0800, Tejun Heo wrote:
> Hello, Roman.
>
> On Tue, Nov 13, 2018 at 06:47:55PM +, Roman Gushchin wrote:
> > > > + /* Should the cgroup and its descendants be frozen. */
> > > > + bool freeze;
> > >
> > > Why not have this in freezer too?
> >
>
On Tue, Nov 13, 2018 at 11:15:41AM -0800, Tejun Heo wrote:
> Hello, Roman.
>
> On Tue, Nov 13, 2018 at 06:47:55PM +, Roman Gushchin wrote:
> > > > + /* Should the cgroup and its descendants be frozen. */
> > > > + bool freeze;
> > >
> > > Why not have this in freezer too?
> >
>
On Mon, Nov 12, 2018 at 11:55:44PM +0800, Changbin Du wrote:
> The third operand of mtspr instruction must be a constraint. To guarantee
> this condition, function cache_loop() which uses macro mtspr() must be
> inlined. So let's force it as 'inline'. This is to fix compiling error with
> new
On Mon, Nov 12, 2018 at 11:55:44PM +0800, Changbin Du wrote:
> The third operand of mtspr instruction must be a constraint. To guarantee
> this condition, function cache_loop() which uses macro mtspr() must be
> inlined. So let's force it as 'inline'. This is to fix compiling error with
> new
On Tue, 13 Nov 2018 17:55:58 +0100 Oleg Nesterov wrote:
> > However it would be basically cost-free to increase
> > BINPRM_BUF_SIZE up to the point where sizeof(struct linux_binprm) ==
> > PAGE_SIZE?
>
> I don't think we should take sizeof(struct linux_binprm) into account, the
> new members
On Tue, 13 Nov 2018 17:55:58 +0100 Oleg Nesterov wrote:
> > However it would be basically cost-free to increase
> > BINPRM_BUF_SIZE up to the point where sizeof(struct linux_binprm) ==
> > PAGE_SIZE?
>
> I don't think we should take sizeof(struct linux_binprm) into account, the
> new members
On 11/13/18 1:36 PM, Jarkko Sakkinen wrote:
Added locking as part of tpm_try_get_ops() and tpm_put_ops() as they are
anyway used in most of the call sites except in tpmrm_release() where we
take the locks manually.
Ok, so this is pulling the locking further up.
Signed-off-by: Jarkko Sakkinen
On 11/13/18 1:36 PM, Jarkko Sakkinen wrote:
Added locking as part of tpm_try_get_ops() and tpm_put_ops() as they are
anyway used in most of the call sites except in tpmrm_release() where we
take the locks manually.
Ok, so this is pulling the locking further up.
Signed-off-by: Jarkko Sakkinen
On Tue, Nov 13 2018, Jeff Layton wrote:
> On Mon, 2018-11-12 at 12:34 -0800, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:442b8cea2477 Add linux-next specific files for 20181109
>> git tree: linux-next
>> console output:
On Tue, Nov 13 2018, Jeff Layton wrote:
> On Mon, 2018-11-12 at 12:34 -0800, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:442b8cea2477 Add linux-next specific files for 20181109
>> git tree: linux-next
>> console output:
text_mutex is currently expected to be held before text_poke() is
called, but we kgdb does not take the mutex, and instead *supposedly*
ensures the lock is not taken and will not be acquired by any other core
while text_poke() is running.
The reason for the "supposedly" comment is that it is not
text_poke() already ensures that the written value is the correct one
and fails if that is not the case. There is no need for an additional
comparison. Remove it.
Signed-off-by: Nadav Amit
---
arch/x86/kernel/kgdb.c | 10 --
1 file changed, 10 deletions(-)
diff --git
This patch-set addresses some issues that might affect the security and
the correctness of code patching.
The main issue that the patches deal with is the fact that the fixmap
PTEs that are used for patching are available for access from other
cores and might be exploited. They are not even
To prevent improper use of the PTEs that are used for text patching, we
want to use a temporary mm struct. We initailize it by copying the init
mm.
The address that will be used for patching is taken from the lower area
that is usually used for the task memory. Doing so prevents the need to
text_poke() already ensures that the written value is the correct one
and fails if that is not the case. There is no need for an additional
comparison. Remove it.
Signed-off-by: Nadav Amit
---
arch/x86/kernel/kgdb.c | 10 --
1 file changed, 10 deletions(-)
diff --git
This patch-set addresses some issues that might affect the security and
the correctness of code patching.
The main issue that the patches deal with is the fact that the fixmap
PTEs that are used for patching are available for access from other
cores and might be exploited. They are not even
To prevent improper use of the PTEs that are used for text patching, we
want to use a temporary mm struct. We initailize it by copying the init
mm.
The address that will be used for patching is taken from the lower area
that is usually used for the task memory. Doing so prevents the need to
text_mutex is currently expected to be held before text_poke() is
called, but we kgdb does not take the mutex, and instead *supposedly*
ensures the lock is not taken and will not be acquired by any other core
while text_poke() is running.
The reason for the "supposedly" comment is that it is not
From: Andy Lutomirski
Sometimes we want to set a temporary page-table entries (PTEs) in one of
the cores, without allowing other cores to use - even speculatively -
these mappings. There are two benefits for doing so:
(1) Security: if sensitive PTEs are set, temporary mm prevents their use
in
When modules and BPF filters are loaded, there is a time window in
which some memory is both writable and executable. An attacker that has
already found another vulnerability (e.g., a dangling pointer) might be
able to exploit this behavior to overwrite kernel code. This patch
prevents having
text_poke() can potentially compromise the security as it sets temporary
PTEs in the fixmap. These PTEs might be used to rewrite the kernel code
from other cores accidentally or maliciously, if an attacker gains the
ability to write onto kernel memory.
Moreover, since remote TLBs are not flushed
Provide a function for copying init_mm. This function will be later used
for setting a temporary mm.
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Peter Zijlstra
Cc: Dave Hansen
Reviewed-by: Masami Hiramatsu
Tested-by: Masami Hiramatsu
Signed-off-by: Nadav Amit
---
include/linux/sched/task.h | 1
text_poke() can potentially compromise the security as it sets temporary
PTEs in the fixmap. These PTEs might be used to rewrite the kernel code
from other cores accidentally or maliciously, if an attacker gains the
ability to write onto kernel memory.
Moreover, since remote TLBs are not flushed
Provide a function for copying init_mm. This function will be later used
for setting a temporary mm.
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Peter Zijlstra
Cc: Dave Hansen
Reviewed-by: Masami Hiramatsu
Tested-by: Masami Hiramatsu
Signed-off-by: Nadav Amit
---
include/linux/sched/task.h | 1
From: Andy Lutomirski
Sometimes we want to set a temporary page-table entries (PTEs) in one of
the cores, without allowing other cores to use - even speculatively -
these mappings. There are two benefits for doing so:
(1) Security: if sensitive PTEs are set, temporary mm prevents their use
in
When modules and BPF filters are loaded, there is a time window in
which some memory is both writable and executable. An attacker that has
already found another vulnerability (e.g., a dangling pointer) might be
able to exploit this behavior to overwrite kernel code. This patch
prevents having
There are only two types of poking: early and breakpoint based. The use
of a function pointer to perform poking complicates the code and is
probably inefficient due to the use of indirect branches.
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Peter Zijlstra
Cc: Dave Hansen
Cc: Masami Hiramatsu
There is no apparent reason not to use text_poke_early() while we are
during early-init and we do not patch code that might be on the stack
(i.e., we'll return to the middle of the patched code). This appears to
be the case of jump-labels, so do so.
This is required for the next patches that
The return value of text_poke_early() and text_poke_bp() is useless.
Remove it.
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Peter Zijlstra
Cc: Dave Hansen
Cc: Masami Hiramatsu
Signed-off-by: Nadav Amit
---
arch/x86/include/asm/text-patching.h | 4 ++--
arch/x86/kernel/alternative.c| 11
There are only two types of poking: early and breakpoint based. The use
of a function pointer to perform poking complicates the code and is
probably inefficient due to the use of indirect branches.
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Peter Zijlstra
Cc: Dave Hansen
Cc: Masami Hiramatsu
There is no apparent reason not to use text_poke_early() while we are
during early-init and we do not patch code that might be on the stack
(i.e., we'll return to the middle of the patched code). This appears to
be the case of jump-labels, so do so.
This is required for the next patches that
The return value of text_poke_early() and text_poke_bp() is useless.
Remove it.
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Peter Zijlstra
Cc: Dave Hansen
Cc: Masami Hiramatsu
Signed-off-by: Nadav Amit
---
arch/x86/include/asm/text-patching.h | 4 ++--
arch/x86/kernel/alternative.c| 11
>From c1bbd933e5fae83f96acd3f748bb01a0300b315d Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Tue, 13 Nov 2018 12:06:41 -0800
Clearly mark the debug files and hide them by default by prefixing
".__DEBUG__.".
Signed-off-by: Tejun Heo
Cc: Peter Zijlstra (Intel)
Cc: Waiman Long
---
On Mon, Nov 12, 2018 at 10:09 AM, Oleg Nesterov wrote:
> load_script() simply truncates bprm->buf and this is very wrong if the
> length of shebang string exceeds BINPRM_BUF_SIZE-2. This can silently
> truncate i_arg or (worse) we can execute the wrong binary if buf[2:126]
> happens to be the
>From c1bbd933e5fae83f96acd3f748bb01a0300b315d Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Tue, 13 Nov 2018 12:06:41 -0800
Clearly mark the debug files and hide them by default by prefixing
".__DEBUG__.".
Signed-off-by: Tejun Heo
Cc: Peter Zijlstra (Intel)
Cc: Waiman Long
---
On Mon, Nov 12, 2018 at 10:09 AM, Oleg Nesterov wrote:
> load_script() simply truncates bprm->buf and this is very wrong if the
> length of shebang string exceeds BINPRM_BUF_SIZE-2. This can silently
> truncate i_arg or (worse) we can execute the wrong binary if buf[2:126]
> happens to be the
>From b1e3aeb11c5e86ee0988a038c4e7682d6beaa977 Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Tue, 13 Nov 2018 12:03:33 -0800
* Rename the partition file from "cpuset.sched.partition" to
"cpuset.cpus.partition".
* When writing to the partition file, drop "0" and "1" and only accept
"member"
On Tue, Nov 13, 2018 at 2:20 PM Qian Cai wrote:
> On Tue, 2018-11-13 at 16:16 +0100, Ondrej Mosnacek wrote:
> > selinux_sctp_bind_connect() must verify if the address buffer has
> > sufficient length before accessing the 'sa_family' field. See
> > __sctp_connect() for a similar check.
> >
> > The
>From b1e3aeb11c5e86ee0988a038c4e7682d6beaa977 Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Tue, 13 Nov 2018 12:03:33 -0800
* Rename the partition file from "cpuset.sched.partition" to
"cpuset.cpus.partition".
* When writing to the partition file, drop "0" and "1" and only accept
"member"
On Tue, Nov 13, 2018 at 2:20 PM Qian Cai wrote:
> On Tue, 2018-11-13 at 16:16 +0100, Ondrej Mosnacek wrote:
> > selinux_sctp_bind_connect() must verify if the address buffer has
> > sufficient length before accessing the 'sa_family' field. See
> > __sctp_connect() for a similar check.
> >
> > The
On Mon, Nov 12, 2018 at 3:08 PM, 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 and kprobes operations,
> e.g. it can be exhausted if we use kprobe_events for stackleak_erase().
>
> So
On Mon, Nov 12, 2018 at 3:08 PM, 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 and kprobes operations,
> e.g. it can be exhausted if we use kprobe_events for stackleak_erase().
>
> So
The patch
dt-binding: spi: add NPCM PSPI controller documentation
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
The patch
dt-binding: spi: add NPCM PSPI controller documentation
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
On Tue, 13 Nov 2018 at 19:40, Tigran Aivazian wrote:
>
> On Tue, 13 Nov 2018 at 08:31, Tigran Aivazian
> wrote:
> > Andrew, if you would like me to make the same patch against 4.19.1 as
> > well, please let me know.
>
> I decided to just go ahead and backport it to 4.19.1 anyway (see
>
On Tue, 13 Nov 2018 at 19:40, Tigran Aivazian wrote:
>
> On Tue, 13 Nov 2018 at 08:31, Tigran Aivazian
> wrote:
> > Andrew, if you would like me to make the same patch against 4.19.1 as
> > well, please let me know.
>
> I decided to just go ahead and backport it to 4.19.1 anyway (see
>
Needed for kprobes support. Copied and adapted from arm64 code.
Signed-off-by: Patrick Stählin
---
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/ptrace.h | 34 +++
arch/riscv/kernel/ptrace.c | 99 +
3 files changed, 134 insertions(+)
First implementation, adapted from arm64. The C.ADDISP16 instruction
gets simulated and the kprobes-handler called by inserting a C.EBREAK
instruction.
C.ADDISP16 was chosen as it sets-up the stack frame for functions.
Some work has been done to support probes on non-compressed
instructions but
Needed for kprobes support. Copied and adapted from arm64 code.
Signed-off-by: Patrick Stählin
---
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/ptrace.h | 34 +++
arch/riscv/kernel/ptrace.c | 99 +
3 files changed, 134 insertions(+)
First implementation, adapted from arm64. The C.ADDISP16 instruction
gets simulated and the kprobes-handler called by inserting a C.EBREAK
instruction.
C.ADDISP16 was chosen as it sets-up the stack frame for functions.
Some work has been done to support probes on non-compressed
instructions but
Hi,
this is first version of kprobes/kretprobe support for RISC-V. Most of
the code is based on arm64 but obviously without the single-step
functionality.
It will insert a C.EBREAK instruction that is later being captured. The
only instruction supported at the moment is C.ADDISP16 as this
Hi,
this is first version of kprobes/kretprobe support for RISC-V. Most of
the code is based on arm64 but obviously without the single-step
functionality.
It will insert a C.EBREAK instruction that is later being captured. The
only instruction supported at the moment is C.ADDISP16 as this
syzbot has found a reproducer for the following crash on:
HEAD commit:442b8cea2477 Add linux-next specific files for 20181109
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12fbd90540
kernel config:
syzbot has found a reproducer for the following crash on:
HEAD commit:442b8cea2477 Add linux-next specific files for 20181109
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12fbd90540
kernel config:
301 - 400 of 1256 matches
Mail list logo
