Date   

[PATCH 4.4-cip 19/23] pwm: samsung: Fix to use lowest div for large enough modulation bits

Ben Hutchings <ben.hutchings@...>
 

From: Seung-Woo Kim <sw0312.kim@samsung.com>

commit 04d68dea26b0a409d44e87ea573a131b6dc67e78 upstream.

From pwm_samsung_calc_tin(), there is routine to find the lowest divider
possible to generate lower frequency than requested one. But it is
always possible to generate requested frequency with large enough
modulation bits except on s3c24xx, so this patch fixes to use lowest div
for the case. This patch removes following UBSAN warning:

UBSAN: Undefined behaviour in drivers/pwm/pwm-samsung.c:197:13
shift exponent 32 is too large for 32-bit type 'long unsigned int'
[...]
[<c0670248>] (ubsan_epilogue) from [<c06707b4>] (__ubsan_handle_shift_out_of_bounds+0xd8/0x120)
[<c06707b4>] (__ubsan_handle_shift_out_of_bounds) from [<c0694b28>] (pwm_samsung_config+0x508/0x6a4)
[<c0694b28>] (pwm_samsung_config) from [<c069286c>] (pwm_apply_state+0x174/0x40c)
[<c069286c>] (pwm_apply_state) from [<c0b2e070>] (pwm_fan_probe+0xc8/0x488)
[<c0b2e070>] (pwm_fan_probe) from [<c07ba8b0>] (platform_drv_probe+0x70/0x150)
[...]

Cc: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
---
drivers/pwm/pwm-samsung.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
index ada2d326dc3e..f113cda47032 100644
--- a/drivers/pwm/pwm-samsung.c
+++ b/drivers/pwm/pwm-samsung.c
@@ -193,9 +193,18 @@ static unsigned long pwm_samsung_calc_tin(struct samsung_pwm_chip *chip,
* divider settings and choose the lowest divisor that can generate
* frequencies lower than requested.
*/
- for (div = variant->div_base; div < 4; ++div)
- if ((rate >> (variant->bits + div)) < freq)
- break;
+ if (variant->bits < 32) {
+ /* Only for s3c24xx */
+ for (div = variant->div_base; div < 4; ++div)
+ if ((rate >> (variant->bits + div)) < freq)
+ break;
+ } else {
+ /*
+ * Other variants have enough counter bits to generate any
+ * requested rate, so no need to check higher divisors.
+ */
+ div = variant->div_base;
+ }

pwm_samsung_set_divisor(chip, chan, BIT(div));

--
2.10.2


--
Ben Hutchings
Software Developer, Codethink Ltd.


[PATCH 4.4-cip 20/23] drm: fix signed integer overflow

Ben Hutchings <ben.hutchings@...>
 

From: Xie XiuQi <xiexiuqi@huawei.com>

commit ae0119f5f73b1e9cf7177fbbeea68d74c5751def upstream.

Use 1UL for unsigned long, or we'll meet a overflow issue with UBSAN.

[ 15.589489] UBSAN: Undefined behaviour in drivers/gpu/drm/drm_hashtab.c:145:35
[ 15.589500] signed integer overflow:
[ 15.589999] -2147483648 - 1 cannot be represented in type 'int'
[ 15.590434] CPU: 2 PID: 294 Comm: plymouthd Not tainted 3.10.0-327.28.3.el7.x86_64 #1
[ 15.590653] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 01/07/2011
[ 15.591001] 1ffff1000670fe83 000000000d6b385e ffff88003387f3e0 ffffffff81ee3140
[ 15.591028] ffff88003387f3f8 ffffffff81ee31fd ffffffffa032f460 ffff88003387f560
[ 15.591044] ffffffff81ee46e2 0000002d00000009 0000000000000001 0000000041b58ab3
[ 15.591059] Call Trace:
[ 15.591078] [<ffffffff81ee3140>] dump_stack+0x1e/0x20
[ 15.591093] [<ffffffff81ee31fd>] ubsan_epilogue+0x12/0x55
[ 15.591109] [<ffffffff81ee46e2>] handle_overflow+0x1ba/0x215
[ 15.591126] [<ffffffff81ee4528>] ? __ubsan_handle_negate_overflow+0x162/0x162
[ 15.591146] [<ffffffff8103416c>] ? print_context_stack+0x9c/0x160
[ 15.591163] [<ffffffff81031df2>] ? dump_trace+0x252/0x750
[ 15.591181] [<ffffffff81739023>] ? __list_add+0x93/0x160
[ 15.591197] [<ffffffff81ee4798>] __ubsan_handle_sub_overflow+0x2a/0x31
[ 15.591261] [<ffffffffa0282140>] drm_ht_just_insert_please+0x1e0/0x200 [drm]
[ 15.591290] [<ffffffffa0528c7a>] ttm_base_object_init+0x10a/0x270 [ttm]
[ 15.591316] [<ffffffffa052a34c>] ttm_vt_lock+0x28c/0x3a0 [ttm]
[ 15.591343] [<ffffffffa052a0c0>] ? ttm_write_lock+0x180/0x180 [ttm]
[ 15.591362] [<ffffffff81419526>] ? kasan_unpoison_shadow+0x36/0x50
[ 15.591379] [<ffffffff81419526>] ? kasan_unpoison_shadow+0x36/0x50
[ 15.591396] [<ffffffff81419526>] ? kasan_unpoison_shadow+0x36/0x50
[ 15.591413] [<ffffffff81419526>] ? kasan_unpoison_shadow+0x36/0x50
[ 15.591442] [<ffffffffa061cbe1>] vmw_master_set+0x121/0x470 [vmwgfx]
[ 15.591459] [<ffffffff811773a5>] ? __init_waitqueue_head+0x45/0x70
[ 15.591487] [<ffffffffa061cac0>] ? vmw_master_drop+0x310/0x310 [vmwgfx]
[ 15.591535] [<ffffffffa026946a>] drm_open+0x92a/0xc00 [drm]
[ 15.591563] [<ffffffffa0619ff0>] ? vmw_driver_open+0x170/0x170 [vmwgfx]
[ 15.591610] [<ffffffffa0268b40>] ? drm_poll+0xe0/0xe0 [drm]
[ 15.591661] [<ffffffffa02797b4>] drm_stub_open+0x224/0x330 [drm]
[ 15.591711] [<ffffffffa0279590>] ? drm_minor_acquire+0x240/0x240 [drm]
[ 15.591727] [<ffffffff8145fa8a>] chrdev_open+0x1fa/0x3f0
[ 15.591742] [<ffffffff8145f890>] ? cdev_put+0x50/0x50
[ 15.591761] [<ffffffff814f6dc3>] ? __fsnotify_parent+0x53/0x210
[ 15.591778] [<ffffffff8144fde1>] do_dentry_open+0x351/0x670
[ 15.591792] [<ffffffff8145f890>] ? cdev_put+0x50/0x50
[ 15.591807] [<ffffffff814503c2>] vfs_open+0xa2/0x170
[ 15.591824] [<ffffffff8147b5df>] do_last+0xccf/0x2c80
[ 15.591842] [<ffffffff8147a910>] ? filename_create+0x320/0x320
[ 15.591858] [<ffffffff81472549>] ? path_init+0x1b9/0xa90
[ 15.591875] [<ffffffff81472390>] ? mountpoint_last+0x9a0/0x9a0
[ 15.591894] [<ffffffff815f9ccf>] ? selinux_file_alloc_security+0xcf/0x130
[ 15.591911] [<ffffffff8147d777>] path_openat+0x1e7/0xcc0
[ 15.591927] [<ffffffff81031df2>] ? dump_trace+0x252/0x750
[ 15.591943] [<ffffffff8147d590>] ? do_last+0x2c80/0x2c80
[ 15.591959] [<ffffffff81739023>] ? __list_add+0x93/0x160
[ 15.591974] [<ffffffff8104b48d>] ? save_stack_trace+0x7d/0xb0
[ 15.591989] [<ffffffff81480824>] do_filp_open+0xa4/0x160
[ 15.592004] [<ffffffff81480780>] ? user_path_mountpoint_at+0x50/0x50
[ 15.592022] [<ffffffff8149d755>] ? __alloc_fd+0x175/0x300
[ 15.592039] [<ffffffff81453127>] do_sys_open+0x1b7/0x3f0
[ 15.592054] [<ffffffff81452f70>] ? filp_open+0x80/0x80
[ 15.592070] [<ffffffff81453392>] SyS_open+0x32/0x40
[ 15.592088] [<ffffffff81f08989>] system_call_fastpath+0x16/0x1b

Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
[seanpaul tweaked subject to remove "gpu/"]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1473152138-25335-1-git-send-email-xiexiuqi@huawei.com
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
---
drivers/gpu/drm/drm_hashtab.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
index c3b80fd65d62..fbbd9f0c2eef 100644
--- a/drivers/gpu/drm/drm_hashtab.c
+++ b/drivers/gpu/drm/drm_hashtab.c
@@ -142,7 +142,7 @@ int drm_ht_just_insert_please(struct drm_open_hash *ht, struct drm_hash_item *it
unsigned long add)
{
int ret;
- unsigned long mask = (1 << bits) - 1;
+ unsigned long mask = (1UL << bits) - 1;
unsigned long first, unshifted_key;

unshifted_key = hash_long(seed, bits);
--
2.10.2



--
Ben Hutchings
Software Developer, Codethink Ltd.


[PATCH 4.4-cip 21/23] xfs: fix signed integer overflow

Ben Hutchings <ben.hutchings@...>
 

From: Xie XiuQi <xiexiuqi@huawei.com>

commit 79c350e45ebc5a718cc2d7114b45ad560069423d upstream.

Use 1U for unsigned int to avoid a overflow warning from UBSAN.

[ 31.910858] UBSAN: Undefined behaviour in fs/xfs/xfs_buf_item.c:889:25
[ 31.911252] signed integer overflow:
[ 31.911478] -2147483648 - 1 cannot be represented in type 'int'
[ 31.911846] CPU: 1 PID: 1011 Comm: tuned Tainted: G B ---- ------- 3.10.0-327.28.3.el7.x86_64 #1
[ 31.911857] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 01/07/2011
[ 31.911866] 1ffff1004069cd3b 0000000076bec3fd ffff8802034e69a0 ffffffff81ee3140
[ 31.911883] ffff8802034e69b8 ffffffff81ee31fd ffffffffa0ad79e0 ffff8802034e6b20
[ 31.911898] ffffffff81ee46e2 0000002d515470c0 0000000000000001 0000000041b58ab3
[ 31.911913] Call Trace:
[ 31.911932] [<ffffffff81ee3140>] dump_stack+0x1e/0x20
[ 31.911947] [<ffffffff81ee31fd>] ubsan_epilogue+0x12/0x55
[ 31.911964] [<ffffffff81ee46e2>] handle_overflow+0x1ba/0x215
[ 31.912083] [<ffffffff81ee4798>] __ubsan_handle_sub_overflow+0x2a/0x31
[ 31.912204] [<ffffffffa08676fb>] xfs_buf_item_log+0x34b/0x3f0 [xfs]
[ 31.912314] [<ffffffffa0880490>] xfs_trans_log_buf+0x120/0x260 [xfs]
[ 31.912402] [<ffffffffa079a890>] xfs_btree_log_recs+0x80/0xc0 [xfs]
[ 31.912490] [<ffffffffa07a29f8>] xfs_btree_delrec+0x11a8/0x2d50 [xfs]
[ 31.913589] [<ffffffffa07a86f9>] xfs_btree_delete+0xc9/0x260 [xfs]
[ 31.913762] [<ffffffffa075b5cf>] xfs_free_ag_extent+0x63f/0xe20 [xfs]
[ 31.914339] [<ffffffffa075ec0f>] xfs_free_extent+0x2af/0x3e0 [xfs]
[ 31.914641] [<ffffffffa0801b2b>] xfs_bmap_finish+0x32b/0x4b0 [xfs]
[ 31.914841] [<ffffffffa083c2e7>] xfs_itruncate_extents+0x3b7/0x740 [xfs]
[ 31.915216] [<ffffffffa08342fa>] xfs_setattr_size+0x60a/0x860 [xfs]
[ 31.915471] [<ffffffffa08345ea>] xfs_vn_setattr+0x9a/0xe0 [xfs]
[ 31.915590] [<ffffffff8149ad38>] notify_change+0x5c8/0x8a0
[ 31.915607] [<ffffffff81450f22>] do_truncate+0x122/0x1d0
[ 31.915640] [<ffffffff8147beee>] do_last+0x15de/0x2c80
[ 31.915707] [<ffffffff8147d777>] path_openat+0x1e7/0xcc0
[ 31.915802] [<ffffffff81480824>] do_filp_open+0xa4/0x160
[ 31.915848] [<ffffffff81453127>] do_sys_open+0x1b7/0x3f0
[ 31.915879] [<ffffffff81453392>] SyS_open+0x32/0x40
[ 31.915897] [<ffffffff81f08989>] system_call_fastpath+0x16/0x1b

[ 240.086809] UBSAN: Undefined behaviour in fs/xfs/xfs_buf_item.c:866:34
[ 240.086820] signed integer overflow:
[ 240.086830] -2147483648 - 1 cannot be represented in type 'int'
[ 240.086846] CPU: 1 PID: 12969 Comm: rm Tainted: G B ---- ------- 3.10.0-327.28.3.el7.x86_64 #1
[ 240.086857] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 01/07/2011
[ 240.086868] 1ffff10040491def 00000000e2ea59c1 ffff88020248ef40 ffffffff81ee3140
[ 240.086885] ffff88020248ef58 ffffffff81ee31fd ffffffffa0ad79e0 ffff88020248f0c0
[ 240.086901] ffffffff81ee46e2 0000002d02488000 0000000000000001 0000000041b58ab3
[ 240.086915] Call Trace:
[ 240.086938] [<ffffffff81ee3140>] dump_stack+0x1e/0x20
[ 240.086953] [<ffffffff81ee31fd>] ubsan_epilogue+0x12/0x55
[ 240.086971] [<ffffffff81ee46e2>] handle_overflow+0x1ba/0x215
...

Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
---
fs/xfs/xfs_buf_item.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/xfs/xfs_buf_item.c b/fs/xfs/xfs_buf_item.c
index 7e986da34f6c..04b1d96e49c1 100644
--- a/fs/xfs/xfs_buf_item.c
+++ b/fs/xfs/xfs_buf_item.c
@@ -865,7 +865,7 @@ xfs_buf_item_log_segment(
*/
if (bit) {
end_bit = MIN(bit + bits_to_set, (uint)NBWORD);
- mask = ((1 << (end_bit - bit)) - 1) << bit;
+ mask = ((1U << (end_bit - bit)) - 1) << bit;
*wordp |= mask;
wordp++;
bits_set = end_bit - bit;
@@ -888,7 +888,7 @@ xfs_buf_item_log_segment(
*/
end_bit = bits_to_set - bits_set;
if (end_bit) {
- mask = (1 << end_bit) - 1;
+ mask = (1U << end_bit) - 1;
*wordp |= mask;
}
}
--
2.10.2



--
Ben Hutchings
Software Developer, Codethink Ltd.


[PATCH 4.4-cip 22/23] net: get rid of an signed integer overflow in ip_idents_reserve()

Ben Hutchings <ben.hutchings@...>
 

From: Eric Dumazet <edumazet@google.com>

commit adb03115f4590baa280ddc440a8eff08a6be0cb7 upstream.

Jiri Pirko reported an UBSAN warning happening in ip_idents_reserve()

[] UBSAN: Undefined behaviour in ./arch/x86/include/asm/atomic.h:156:11
[] signed integer overflow:
[] -2117905507 + -695755206 cannot be represented in type 'int'

Since we do not have uatomic_add_return() yet, use atomic_cmpxchg()
so that the arithmetics can be done using unsigned int.

Fixes: 04ca6973f7c1 ("ip: make IP identifiers less predictable")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
---
net/ipv4/route.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index b050cf980a57..a0270af75fa5 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -476,12 +476,18 @@ u32 ip_idents_reserve(u32 hash, int segs)
atomic_t *p_id = ip_idents + hash % IP_IDENTS_SZ;
u32 old = ACCESS_ONCE(*p_tstamp);
u32 now = (u32)jiffies;
- u32 delta = 0;
+ u32 new, delta = 0;

if (old != now && cmpxchg(p_tstamp, old, now) == old)
delta = prandom_u32_max(now - old);

- return atomic_add_return(segs + delta, p_id) - segs;
+ /* Do not use atomic_add_return() as it makes UBSAN unhappy */
+ do {
+ old = (u32)atomic_read(p_id);
+ new = old + delta + segs;
+ } while (atomic_cmpxchg(p_id, old, new) != old);
+
+ return new - segs;
}
EXPORT_SYMBOL(ip_idents_reserve);

--
2.10.2



--
Ben Hutchings
Software Developer, Codethink Ltd.


[PATCH 4.4-cip 23/23] mlx4: remove unused fields

Ben Hutchings <ben.hutchings@...>
 

From: David Decotigny <decot@googlers.com>

commit 5038056e6bd45788235e97e3bcfc43f96c52ca84 upstream.

This also can address following UBSAN warnings:
[ 36.640343] ================================================================================
[ 36.648772] UBSAN: Undefined behaviour in drivers/net/ethernet/mellanox/mlx4/fw.c:857:26
[ 36.656853] shift exponent 64 is too large for 32-bit type 'int'
[ 36.663348] ================================================================================
[ 36.671783] ================================================================================
[ 36.680213] UBSAN: Undefined behaviour in drivers/net/ethernet/mellanox/mlx4/fw.c:861:27
[ 36.688297] shift exponent 35 is too large for 32-bit type 'int'
[ 36.694702] ================================================================================

Tested:
reboot with UBSAN, no warning.

Signed-off-by: David Decotigny <decot@googlers.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
---
drivers/net/ethernet/mellanox/mlx4/fw.c | 4 ----
drivers/net/ethernet/mellanox/mlx4/fw.h | 2 --
2 files changed, 6 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/fw.c b/drivers/net/ethernet/mellanox/mlx4/fw.c
index 90db94e83fde..ebff502db8ff 100644
--- a/drivers/net/ethernet/mellanox/mlx4/fw.c
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.c
@@ -760,12 +760,8 @@ int mlx4_QUERY_DEV_CAP(struct mlx4_dev *dev, struct mlx4_dev_cap *dev_cap)
dev_cap->max_eqs = 1 << (field & 0xf);
MLX4_GET(field, outbox, QUERY_DEV_CAP_RSVD_MTT_OFFSET);
dev_cap->reserved_mtts = 1 << (field >> 4);
- MLX4_GET(field, outbox, QUERY_DEV_CAP_MAX_MRW_SZ_OFFSET);
- dev_cap->max_mrw_sz = 1 << field;
MLX4_GET(field, outbox, QUERY_DEV_CAP_RSVD_MRW_OFFSET);
dev_cap->reserved_mrws = 1 << (field & 0xf);
- MLX4_GET(field, outbox, QUERY_DEV_CAP_MAX_MTT_SEG_OFFSET);
- dev_cap->max_mtt_seg = 1 << (field & 0x3f);
MLX4_GET(size, outbox, QUERY_DEV_CAP_NUM_SYS_EQ_OFFSET);
dev_cap->num_sys_eqs = size & 0xfff;
MLX4_GET(field, outbox, QUERY_DEV_CAP_MAX_REQ_QP_OFFSET);
diff --git a/drivers/net/ethernet/mellanox/mlx4/fw.h b/drivers/net/ethernet/mellanox/mlx4/fw.h
index 08de5555c2f4..711af4e506f3 100644
--- a/drivers/net/ethernet/mellanox/mlx4/fw.h
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.h
@@ -78,9 +78,7 @@ struct mlx4_dev_cap {
int max_eqs;
int num_sys_eqs;
int reserved_mtts;
- int max_mrw_sz;
int reserved_mrws;
- int max_mtt_seg;
int max_requester_per_qp;
int max_responder_per_qp;
int max_rdma_global;
--
2.10.2


--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: [PATCH 4.4-cip 0/6] Extend user-space ASLR range

Jan Kiszka
 

On 2016-12-09 00:56, Ben Hutchings wrote:
This is a backport of changes in 4.5 to extend the range of Address
Space Layout Randomisation for user-space processes. When enabled, this
should make some user-space vulnerabilities harder to exploit, but it
can also cause some applications to fail if they currently use a large
proportion of the virtual address space.

The default ASLR range remains the same, but it can be changed through
kernel config (CONFIG_ARCH_MMAP_RND_BITS) or at run-time through sysctl
(vm.mmap_rnd_bits). (For 32-bit compat tasks, the range is controlled
through CONFIG_ARCH_MMAP_RND_COMPAT_BITS and vm.mmap_rnd_compat_bits.)

This includes support for arm, arm64 and x86 (32- and 64-bit). (arm64
is not currently supported by CIP, but it was easier to include it in
the backport than to leave it out.)

For this and other backports, I'm looking for feedback like:
- Did I miss a follow-up fix or an earlier dependency?
- Does this cause a regression (other than as explained above)?
- Are you likely to use it?
- Are there related features you want in 4.4?

Ben.

Daniel Cashman (6):
mm: mmap: add new /proc tunable for mmap_base ASLR
arm: mm: support ARCH_MMAP_RND_BITS
arm64: mm: support ARCH_MMAP_RND_BITS
x86: mm: support ARCH_MMAP_RND_BITS
drivers: char: random: add get_random_long()
mm: ASLR: use get_random_long()

Documentation/sysctl/vm.txt | 29 +++++++++++++++++
arch/Kconfig | 68 ++++++++++++++++++++++++++++++++++++++++
arch/arm/Kconfig | 9 ++++++
arch/arm/mm/mmap.c | 3 +-
arch/arm64/Kconfig | 29 +++++++++++++++++
arch/arm64/mm/mmap.c | 8 +++--
arch/mips/mm/mmap.c | 4 +--
arch/powerpc/kernel/process.c | 4 +--
arch/powerpc/mm/mmap.c | 4 +--
arch/sparc/kernel/sys_sparc_64.c | 2 +-
arch/x86/Kconfig | 16 ++++++++++
arch/x86/mm/mmap.c | 12 +++----
drivers/char/random.c | 22 +++++++++++++
fs/binfmt_elf.c | 2 +-
include/linux/mm.h | 11 +++++++
include/linux/random.h | 1 +
kernel/sysctl.c | 22 +++++++++++++
mm/mmap.c | 12 +++++++
18 files changed, 240 insertions(+), 18 deletions(-)
Did you try to discuss the back-port topic with the KSPP folks or other
key persons involved in these patches? In the ideal case, the authors
can be CC'ed, do not get annoyed by "these crazy people doing legacy
stuff", and may even do some reviews.

Jan

--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux


Update week 49

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

this is an overview of what is happening at CIP. Feel free to answer this mail with your bits.

++ Meetings

* Members meeting on Mon Nov 28th
** The next f2f meeting will take place at ELC in Portland in February
** Testing effort status

++ Kernel Maintenance

* First backports to provide hardware support for Beaglebone Black sent to the list for comments and evaluation.

* CIP repository already mirrored in Gitlab.com: https://gitlab.com/cip-project/linux-cip/commits/linux-4.4.y-cip Thanks Yoshi!

++ Testing

* Progress in the VM with kernelci
** Have browser on host able to view kernelci pages
** Some work (not yet complete) on getting this setup to happen on provisioning of the vm).
** Investigating issues with retrieving the build artifacts.
** Installing of lava2 on the vm

* Added a project in Gitlab.com to mirror the kernelci front end repository.

* Introduction to CIP testing effort published on the wiki: https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting

++ Other topics

* Robert Marshall, that is currently working on the kernelci VM will be at FOSDEM, like myself.

++ Next Tasks

* In the coming days CIP kernel will update from 4.4.30 to 4.4.37 Once we have testing in place it will make sense to test every release and update as soon as is everything ok from our side.

* Keep working on the kernelci VM

* Patches review/merge

Best Regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk


CIP Developer update

Robert Marshall <robert.marshall@...>
 

CIP developer update, we're including outstanding problems as gitlab
issues and there's more information at the issue links.

CIP

- On retrieving build artifacts - we still have issues here. Is it
the VM? have other cip-kernelci users seen this? We've tried manually
entering other likely sounding URLs but without success.
https://gitlab.com/cip-project/testing/issues/2
- github branches have been created for the frontend repos to allow connections from the host
to the VM, with that fork, bson isn't installing for the
frontend - am investigating.
https://gitlab.com/cip-project/testing/issues/3

LAVA
We have created a VM server for LAVA testing; we're trying to get LAVA2
tests to run - it currently doesn't see available devices.
https://gitlab.com/cip-project/testing/issues/4

There'll be a face 2 face discussion between the developers tomorrow to
address the current issues

Robert


Re: [PATCH 4.4-cip 0/6] Extend user-space ASLR range

Jan Kiszka
 

On 2016-12-09 13:20, Jan Kiszka wrote:
On 2016-12-09 00:56, Ben Hutchings wrote:
This is a backport of changes in 4.5 to extend the range of Address
Space Layout Randomisation for user-space processes. When enabled, this
should make some user-space vulnerabilities harder to exploit, but it
can also cause some applications to fail if they currently use a large
proportion of the virtual address space.

The default ASLR range remains the same, but it can be changed through
kernel config (CONFIG_ARCH_MMAP_RND_BITS) or at run-time through sysctl
(vm.mmap_rnd_bits). (For 32-bit compat tasks, the range is controlled
through CONFIG_ARCH_MMAP_RND_COMPAT_BITS and vm.mmap_rnd_compat_bits.)

This includes support for arm, arm64 and x86 (32- and 64-bit). (arm64
is not currently supported by CIP, but it was easier to include it in
the backport than to leave it out.)

For this and other backports, I'm looking for feedback like:
- Did I miss a follow-up fix or an earlier dependency?
- Does this cause a regression (other than as explained above)?
- Are you likely to use it?
- Are there related features you want in 4.4?

Ben.

Daniel Cashman (6):
mm: mmap: add new /proc tunable for mmap_base ASLR
arm: mm: support ARCH_MMAP_RND_BITS
arm64: mm: support ARCH_MMAP_RND_BITS
x86: mm: support ARCH_MMAP_RND_BITS
drivers: char: random: add get_random_long()
mm: ASLR: use get_random_long()

Documentation/sysctl/vm.txt | 29 +++++++++++++++++
arch/Kconfig | 68 ++++++++++++++++++++++++++++++++++++++++
arch/arm/Kconfig | 9 ++++++
arch/arm/mm/mmap.c | 3 +-
arch/arm64/Kconfig | 29 +++++++++++++++++
arch/arm64/mm/mmap.c | 8 +++--
arch/mips/mm/mmap.c | 4 +--
arch/powerpc/kernel/process.c | 4 +--
arch/powerpc/mm/mmap.c | 4 +--
arch/sparc/kernel/sys_sparc_64.c | 2 +-
arch/x86/Kconfig | 16 ++++++++++
arch/x86/mm/mmap.c | 12 +++----
drivers/char/random.c | 22 +++++++++++++
fs/binfmt_elf.c | 2 +-
include/linux/mm.h | 11 +++++++
include/linux/random.h | 1 +
kernel/sysctl.c | 22 +++++++++++++
mm/mmap.c | 12 +++++++
18 files changed, 240 insertions(+), 18 deletions(-)
Did you try to discuss the back-port topic with the KSPP folks or other
key persons involved in these patches? In the ideal case, the authors
can be CC'ed, do not get annoyed by "these crazy people doing legacy
stuff", and may even do some reviews.
I've chatted with Elena over this last week, and she talked to Kees who
pointed out that the Android people are also doing KSPP backports to 4.4
(thanks, folks!). I didn't check any details, just a heads-up to avoid
duplicate work.

Jan

--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux


CIP Developer update

Robert Marshall <robert.marshall@...>
 

As before we're including outstanding problems as gitlab
issues - read them for more information!

CIP

- build artifacts - we're still unable to retrieve these.
We have manually installed later versions of chef and worked
around issues with the validation.pem not being available but
are still getting 404 errors.
https://gitlab.com/cip-project/testing/issues/2

bson not installed error
https://gitlab.com/cip-project/testing/issues/3
still being investigated.

LAVA
LAVA2 tests now run, currently working around issues
with a DeviceDictionary error
https://gitlab.com/cip-project/testing/issues/5

Smoke test for QEMU created


Robert


Re: [PATCH 4.4-cip 0/6] Extend user-space ASLR range

Ben Hutchings <ben.hutchings@...>
 

[Sorry for the delay; I haven't been feeling well.]

On Fri, 2016-12-09 at 13:20 +0100, Jan Kiszka wrote:
Did you try to discuss the back-port topic with the KSPP folks or other
key persons involved in these patches? In the ideal case, the authors
can be CC'ed, do not get annoyed by "these crazy people doing legacy
stuff", and may even do some reviews.
I would normally cc the upstream developers, but I was hesitant to do so
for CIP because this is not related to an official stable branch.
Perhaps I should ask on the KSPP list whether a cc for such feature
backports would be appreciated?

On Mon, 2016-12-19 at 11:52 +0100, Jan Kiszka wrote:
I've chatted with Elena over this last week, and she talked to Kees
who
pointed out that the Android people are also doing KSPP backports to
4.4
(thanks, folks!). I didn't check any details, just a heads-up to avoid
duplicate work.
Thanks for letting me know.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


4.4 LTS basic info

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

in the previous CIP Members meeting a question was made related with the 4.4 LTS kernel EOL (end of life).

I have added to the wiki basic links that answers this question.

Link: https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance#cip-kernel-slts-kernel

Best regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk


Re: [PATCH 4.4-cip 0/6] Extend user-space ASLR range

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

On 23/12/16 16:46, Ben Hutchings wrote:
[Sorry for the delay; I haven't been feeling well.]

On Fri, 2016-12-09 at 13:20 +0100, Jan Kiszka wrote:
Did you try to discuss the back-port topic with the KSPP folks or other
key persons involved in these patches? In the ideal case, the authors
can be CC'ed, do not get annoyed by "these crazy people doing legacy
stuff", and may even do some reviews.
I would normally cc the upstream developers, but I was hesitant to do so
for CIP because this is not related to an official stable branch.
Perhaps I should ask on the KSPP list whether a cc for such feature
backports would be appreciated?
Please do so.


On Mon, 2016-12-19 at 11:52 +0100, Jan Kiszka wrote:
I've chatted with Elena over this last week, and she talked to Kees
who
pointed out that the Android people are also doing KSPP backports to
4.4
(thanks, folks!). I didn't check any details, just a heads-up to avoid
duplicate work.
Thanks for letting me know.

Ben.
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk


Re: [PATCH 4.4-cip 0/6] Extend user-space ASLR range

Kees Cook <keescook@...>
 

On Mon, Dec 19, 2016 at 2:52 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
On 2016-12-09 13:20, Jan Kiszka wrote:
On 2016-12-09 00:56, Ben Hutchings wrote:
This is a backport of changes in 4.5 to extend the range of Address
Space Layout Randomisation for user-space processes. When enabled, this
should make some user-space vulnerabilities harder to exploit, but it
can also cause some applications to fail if they currently use a large
proportion of the virtual address space.

The default ASLR range remains the same, but it can be changed through
kernel config (CONFIG_ARCH_MMAP_RND_BITS) or at run-time through sysctl
(vm.mmap_rnd_bits). (For 32-bit compat tasks, the range is controlled
through CONFIG_ARCH_MMAP_RND_COMPAT_BITS and vm.mmap_rnd_compat_bits.)

This includes support for arm, arm64 and x86 (32- and 64-bit). (arm64
is not currently supported by CIP, but it was easier to include it in
the backport than to leave it out.)

For this and other backports, I'm looking for feedback like:
- Did I miss a follow-up fix or an earlier dependency?
- Does this cause a regression (other than as explained above)?
- Are you likely to use it?
- Are there related features you want in 4.4?

Ben.

Daniel Cashman (6):
mm: mmap: add new /proc tunable for mmap_base ASLR
arm: mm: support ARCH_MMAP_RND_BITS
arm64: mm: support ARCH_MMAP_RND_BITS
x86: mm: support ARCH_MMAP_RND_BITS
drivers: char: random: add get_random_long()
mm: ASLR: use get_random_long()

Documentation/sysctl/vm.txt | 29 +++++++++++++++++
arch/Kconfig | 68 ++++++++++++++++++++++++++++++++++++++++
arch/arm/Kconfig | 9 ++++++
arch/arm/mm/mmap.c | 3 +-
arch/arm64/Kconfig | 29 +++++++++++++++++
arch/arm64/mm/mmap.c | 8 +++--
arch/mips/mm/mmap.c | 4 +--
arch/powerpc/kernel/process.c | 4 +--
arch/powerpc/mm/mmap.c | 4 +--
arch/sparc/kernel/sys_sparc_64.c | 2 +-
arch/x86/Kconfig | 16 ++++++++++
arch/x86/mm/mmap.c | 12 +++----
drivers/char/random.c | 22 +++++++++++++
fs/binfmt_elf.c | 2 +-
include/linux/mm.h | 11 +++++++
include/linux/random.h | 1 +
kernel/sysctl.c | 22 +++++++++++++
mm/mmap.c | 12 +++++++
18 files changed, 240 insertions(+), 18 deletions(-)
Did you try to discuss the back-port topic with the KSPP folks or other
key persons involved in these patches? In the ideal case, the authors
can be CC'ed, do not get annoyed by "these crazy people doing legacy
stuff", and may even do some reviews.
I've chatted with Elena over this last week, and she talked to Kees who
pointed out that the Android people are also doing KSPP backports to 4.4
(thanks, folks!). I didn't check any details, just a heads-up to avoid
duplicate work.
Hi!

The Android common kernel tree is visible here:

https://android.googlesource.com/kernel/common/

In the android-4.4 branch, the backport are these:

b471fcd FROMLIST: mm: ASLR: use get_random_long()
9a3fe39 FROMLIST: drivers: char: random: add get_random_long()
d51891f FROMLIST: x86: mm: support ARCH_MMAP_RND_BITS.
e2240a1 FROMLIST: arm64: mm: support ARCH_MMAP_RND_BITS.
25106ff FROMLIST: arm: mm: support ARCH_MMAP_RND_BITS.
d49d887 FROMLIST: mm: mmap: Add new /proc tunable for mmap_base ASLR.

Hopefully that helps!

-Kees


Jan

--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux


--
Kees Cook
Nexus Security


Re: [PATCH 4.4-cip 0/6] Extend user-space ASLR range

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

On 03/01/17 23:56, Kees Cook wrote:
On Mon, Dec 19, 2016 at 2:52 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
On 2016-12-09 13:20, Jan Kiszka wrote:
On 2016-12-09 00:56, Ben Hutchings wrote:
This is a backport of changes in 4.5 to extend the range of Address
Space Layout Randomisation for user-space processes. When enabled, this
should make some user-space vulnerabilities harder to exploit, but it
can also cause some applications to fail if they currently use a large
proportion of the virtual address space.

The default ASLR range remains the same, but it can be changed through
kernel config (CONFIG_ARCH_MMAP_RND_BITS) or at run-time through sysctl
(vm.mmap_rnd_bits). (For 32-bit compat tasks, the range is controlled
through CONFIG_ARCH_MMAP_RND_COMPAT_BITS and vm.mmap_rnd_compat_bits.)

This includes support for arm, arm64 and x86 (32- and 64-bit). (arm64
is not currently supported by CIP, but it was easier to include it in
the backport than to leave it out.)

For this and other backports, I'm looking for feedback like:
- Did I miss a follow-up fix or an earlier dependency?
- Does this cause a regression (other than as explained above)?
- Are you likely to use it?
- Are there related features you want in 4.4?

Ben.

Daniel Cashman (6):
mm: mmap: add new /proc tunable for mmap_base ASLR
arm: mm: support ARCH_MMAP_RND_BITS
arm64: mm: support ARCH_MMAP_RND_BITS
x86: mm: support ARCH_MMAP_RND_BITS
drivers: char: random: add get_random_long()
mm: ASLR: use get_random_long()

Documentation/sysctl/vm.txt | 29 +++++++++++++++++
arch/Kconfig | 68 ++++++++++++++++++++++++++++++++++++++++
arch/arm/Kconfig | 9 ++++++
arch/arm/mm/mmap.c | 3 +-
arch/arm64/Kconfig | 29 +++++++++++++++++
arch/arm64/mm/mmap.c | 8 +++--
arch/mips/mm/mmap.c | 4 +--
arch/powerpc/kernel/process.c | 4 +--
arch/powerpc/mm/mmap.c | 4 +--
arch/sparc/kernel/sys_sparc_64.c | 2 +-
arch/x86/Kconfig | 16 ++++++++++
arch/x86/mm/mmap.c | 12 +++----
drivers/char/random.c | 22 +++++++++++++
fs/binfmt_elf.c | 2 +-
include/linux/mm.h | 11 +++++++
include/linux/random.h | 1 +
kernel/sysctl.c | 22 +++++++++++++
mm/mmap.c | 12 +++++++
18 files changed, 240 insertions(+), 18 deletions(-)
Did you try to discuss the back-port topic with the KSPP folks or other
key persons involved in these patches? In the ideal case, the authors
can be CC'ed, do not get annoyed by "these crazy people doing legacy
stuff", and may even do some reviews.
I've chatted with Elena over this last week, and she talked to Kees who
pointed out that the Android people are also doing KSPP backports to 4.4
(thanks, folks!). I didn't check any details, just a heads-up to avoid
duplicate work.
Hi!

The Android common kernel tree is visible here:

https://android.googlesource.com/kernel/common/

In the android-4.4 branch, the backport are these:

b471fcd FROMLIST: mm: ASLR: use get_random_long()
9a3fe39 FROMLIST: drivers: char: random: add get_random_long()
d51891f FROMLIST: x86: mm: support ARCH_MMAP_RND_BITS.
e2240a1 FROMLIST: arm64: mm: support ARCH_MMAP_RND_BITS.
25106ff FROMLIST: arm: mm: support ARCH_MMAP_RND_BITS.
d49d887 FROMLIST: mm: mmap: Add new /proc tunable for mmap_base ASLR.

Hopefully that helps!
It does, thanks. I sent Dmitry Shmidt a mail this morning asking for this. Thanks.


-Kees


Jan

--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk


CIP update 07 WK 01

Robert Marshall <robert.marshall@...>
 

* Virtual machine creation for the testing
We've created 2 vagrant instances one for kernelci and the other for lava
(lava is Debian based and kernelci is ubuntu based) work is in
progress on merging these to make developer setup simpler and reduce
the memory requirements.
https://gitlab.com/cip-project/testing/issues/7

* There's a github branch to allow the host to view the kernelci vm webserver
https://github.com/RobertAJMarshall/kernelci-frontend-config/tree/external-http
this will be merged with the gitlab repository when
https://gitlab.com/cip-project/testing/issues/3
has been resolved.

* The DeviceDictionary error
https://gitlab.com/cip-project/testing/issues/5
is still outstanding

* Devices have been added to lava VM but are not yet running
https://gitlab.com/cip-project/testing/issues/9

* the lava gitlab and the vagrant instance now has been updated
with health check tests and extra documentation.

* The QEMU health check results in a KVM module not found failure
https://gitlab.com/cip-project/testing/issues/8

* Discussions in progress on adding a 'howto'
The developers have a document enumerating the steps involved in
getting the testing environment up and running, this document will
be streamlined and published to the wiki. Meanwhile, we will add the
WIP content to the repository so you can follow it.

* Minor additions to the wiki has been made, specially in the kernel
maintenance page.

Robert


Re: CIP update 07 WK 01

Robert Marshall <robert.marshall@...>
 

Apologies, the following item was missed out of the report:

* build artifacts - we're still unable to retrieve these and get
404 errors on selecting the link:
https://gitlab.com/cip-project/testing/issues/2


Robert Marshall <robert.marshall@codethink.co.uk> writes:

* Virtual machine creation for the testing
We've created 2 vagrant instances one for kernelci and the other for lava
(lava is Debian based and kernelci is ubuntu based) work is in
progress on merging these to make developer setup simpler and reduce
the memory requirements.
https://gitlab.com/cip-project/testing/issues/7

* There's a github branch to allow the host to view the kernelci vm webserver
https://github.com/RobertAJMarshall/kernelci-frontend-config/tree/external-http
this will be merged with the gitlab repository when
https://gitlab.com/cip-project/testing/issues/3
has been resolved.

* The DeviceDictionary error
https://gitlab.com/cip-project/testing/issues/5
is still outstanding

* Devices have been added to lava VM but are not yet running
https://gitlab.com/cip-project/testing/issues/9

* the lava gitlab and the vagrant instance now has been updated
with health check tests and extra documentation.

* The QEMU health check results in a KVM module not found failure
https://gitlab.com/cip-project/testing/issues/8

* Discussions in progress on adding a 'howto'
The developers have a document enumerating the steps involved in
getting the testing environment up and running, this document will
be streamlined and published to the wiki. Meanwhile, we will add the
WIP content to the repository so you can follow it.

* Minor additions to the wiki has been made, specially in the kernel
maintenance page.

Robert
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: [PATCH 4.4-cip 0/6] Extend user-space ASLR range

Ben Hutchings <ben.hutchings@...>
 

On Tue, 2017-01-03 at 15:56 -0800, Kees Cook wrote:
On Mon, Dec 19, 2016 at 2:52 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
On 2016-12-09 13:20, Jan Kiszka wrote:
[...]
Did you try to discuss the back-port topic with the KSPP folks or other
key persons involved in these patches? In the ideal case, the authors
can be CC'ed, do not get annoyed by "these crazy people doing legacy
stuff", and may even do some reviews.
I've chatted with Elena over this last week, and she talked to Kees who
pointed out that the Android people are also doing KSPP backports to 4.4
(thanks, folks!). I didn't check any details, just a heads-up to avoid
duplicate work.
Hi!

The Android common kernel tree is visible here:

https://android.googlesource.com/kernel/common/

In the android-4.4 branch, the backport are these:

b471fcd FROMLIST: mm: ASLR: use get_random_long()
9a3fe39 FROMLIST: drivers: char: random: add get_random_long()
d51891f FROMLIST: x86: mm: support ARCH_MMAP_RND_BITS.
e2240a1 FROMLIST: arm64: mm: support ARCH_MMAP_RND_BITS.
25106ff FROMLIST: arm: mm: support ARCH_MMAP_RND_BITS.
d49d887 FROMLIST: mm: mmap: Add new /proc tunable for mmap_base ASLR.

Hopefully that helps!
Thanks. My backports are identical aside from the placement of some
changes in Kconfig files, which shouldn't make a functional difference.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: [PATCH 4.4-cip 0/6] Extend user-space ASLR range

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

On 08/12/16 23:56, Ben Hutchings wrote:
This is a backport of changes in 4.5 to extend the range of Address
Space Layout Randomisation for user-space processes. When enabled, this
should make some user-space vulnerabilities harder to exploit, but it
can also cause some applications to fail if they currently use a large
proportion of the virtual address space.

The default ASLR range remains the same, but it can be changed through
kernel config (CONFIG_ARCH_MMAP_RND_BITS) or at run-time through sysctl
(vm.mmap_rnd_bits). (For 32-bit compat tasks, the range is controlled
through CONFIG_ARCH_MMAP_RND_COMPAT_BITS and vm.mmap_rnd_compat_bits.)

This includes support for arm, arm64 and x86 (32- and 64-bit). (arm64
is not currently supported by CIP, but it was easier to include it in
the backport than to leave it out.)

For this and other backports, I'm looking for feedback like:
- Did I miss a follow-up fix or an earlier dependency?
- Does this cause a regression (other than as explained above)?
- Are you likely to use it?
- Are there related features you want in 4.4?
since there is no further feedback, I assume you me merge the patches, isn't is?

Hopefully in a couple or three more weeks we can start testing it with kernelci tooling.


Ben.

Daniel Cashman (6):
mm: mmap: add new /proc tunable for mmap_base ASLR
arm: mm: support ARCH_MMAP_RND_BITS
arm64: mm: support ARCH_MMAP_RND_BITS
x86: mm: support ARCH_MMAP_RND_BITS
drivers: char: random: add get_random_long()
mm: ASLR: use get_random_long()

Documentation/sysctl/vm.txt | 29 +++++++++++++++++
arch/Kconfig | 68 ++++++++++++++++++++++++++++++++++++++++
arch/arm/Kconfig | 9 ++++++
arch/arm/mm/mmap.c | 3 +-
arch/arm64/Kconfig | 29 +++++++++++++++++
arch/arm64/mm/mmap.c | 8 +++--
arch/mips/mm/mmap.c | 4 +--
arch/powerpc/kernel/process.c | 4 +--
arch/powerpc/mm/mmap.c | 4 +--
arch/sparc/kernel/sys_sparc_64.c | 2 +-
arch/x86/Kconfig | 16 ++++++++++
arch/x86/mm/mmap.c | 12 +++----
drivers/char/random.c | 22 +++++++++++++
fs/binfmt_elf.c | 2 +-
include/linux/mm.h | 11 +++++++
include/linux/random.h | 1 +
kernel/sysctl.c | 22 +++++++++++++
mm/mmap.c | 12 +++++++
18 files changed, 240 insertions(+), 18 deletions(-)
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk


Re: [PATCH 4.4-cip 0/6] Extend user-space ASLR range

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

On 16/01/17 10:35, Agustin Benito Bethencourt wrote:
Hi,

On 08/12/16 23:56, Ben Hutchings wrote:
This is a backport of changes in 4.5 to extend the range of Address
Space Layout Randomisation for user-space processes. When enabled, this
should make some user-space vulnerabilities harder to exploit, but it
can also cause some applications to fail if they currently use a large
proportion of the virtual address space.

The default ASLR range remains the same, but it can be changed through
kernel config (CONFIG_ARCH_MMAP_RND_BITS) or at run-time through sysctl
(vm.mmap_rnd_bits). (For 32-bit compat tasks, the range is controlled
through CONFIG_ARCH_MMAP_RND_COMPAT_BITS and vm.mmap_rnd_compat_bits.)

This includes support for arm, arm64 and x86 (32- and 64-bit). (arm64
is not currently supported by CIP, but it was easier to include it in
the backport than to leave it out.)

For this and other backports, I'm looking for feedback like:
- Did I miss a follow-up fix or an earlier dependency?
- Does this cause a regression (other than as explained above)?
- Are you likely to use it?
- Are there related features you want in 4.4?
since there is no further feedback, I assume you me merge the patches,
isn't is?
since there is no further feedback, I assume you will merge the patches, isn't is?


Hopefully in a couple or three more weeks we can start testing it with
kernelci tooling.


Ben.

Daniel Cashman (6):
mm: mmap: add new /proc tunable for mmap_base ASLR
arm: mm: support ARCH_MMAP_RND_BITS
arm64: mm: support ARCH_MMAP_RND_BITS
x86: mm: support ARCH_MMAP_RND_BITS
drivers: char: random: add get_random_long()
mm: ASLR: use get_random_long()

Documentation/sysctl/vm.txt | 29 +++++++++++++++++
arch/Kconfig | 68
++++++++++++++++++++++++++++++++++++++++
arch/arm/Kconfig | 9 ++++++
arch/arm/mm/mmap.c | 3 +-
arch/arm64/Kconfig | 29 +++++++++++++++++
arch/arm64/mm/mmap.c | 8 +++--
arch/mips/mm/mmap.c | 4 +--
arch/powerpc/kernel/process.c | 4 +--
arch/powerpc/mm/mmap.c | 4 +--
arch/sparc/kernel/sys_sparc_64.c | 2 +-
arch/x86/Kconfig | 16 ++++++++++
arch/x86/mm/mmap.c | 12 +++----
drivers/char/random.c | 22 +++++++++++++
fs/binfmt_elf.c | 2 +-
include/linux/mm.h | 11 +++++++
include/linux/random.h | 1 +
kernel/sysctl.c | 22 +++++++++++++
mm/mmap.c | 12 +++++++
18 files changed, 240 insertions(+), 18 deletions(-)
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk

121 - 140 of 7061