gt;
> > So don't make the code uglier just to maintain a fiction that
> > something is tested when it isn't really.
>
> Sure fine with me unless Kees screams.
If we don't have set_fs, we don't need the tests. :)
--
Kees Cook
On Tue, Aug 18, 2020 at 10:00:16PM +0200, Christoph Hellwig wrote:
> On Tue, Aug 18, 2020 at 12:59:05PM -0700, Kees Cook wrote:
> > > I didn't see a problem bisecting, do you have something particular in
> > > mind?
> >
> > Oh, I misunderstood this patch to
On Tue, Aug 18, 2020 at 09:55:39PM +0200, Christoph Hellwig wrote:
> On Tue, Aug 18, 2020 at 12:44:49PM -0700, Kees Cook wrote:
> > On Mon, Aug 17, 2020 at 09:32:09AM +0200, Christoph Hellwig wrote:
> > > For 64-bit the only hing missing was a strategic _AC, and for 32-bit we
&g
On Tue, Aug 18, 2020 at 09:54:46PM +0200, Christoph Hellwig wrote:
> On Tue, Aug 18, 2020 at 12:39:34PM -0700, Kees Cook wrote:
> > On Mon, Aug 17, 2020 at 09:32:04AM +0200, Christoph Hellwig wrote:
> > > default_file_splice_write is the last piece of generic code that uses
&g
alternative is introduced, which just like the one in
> entry_64.S has to use the hardcoded virtual address bits to escape
> the fact that TASK_SIZE_MAX isn't actually a constant when 5-level
> page tables are enabled.
>
> Signed-off-by: Christoph Hellwig
Awesome. :)
Reviewed-by: Kees Cook
--
Kees Cook
E_MAX((1UL << __VIRTUAL_MASK_SHIFT) - PAGE_SIZE)
> +#define TASK_SIZE_MAX((_AC(1,UL) << __VIRTUAL_MASK_SHIFT) -
> PAGE_SIZE)
>
> #define DEFAULT_MAP_WINDOW ((1UL << 47) - PAGE_SIZE)
>
> --
> 2.28.0
>
--
Kees Cook
On Mon, Aug 17, 2020 at 09:32:06AM +0200, Christoph Hellwig wrote:
> We can't run the tests for userspace bitmap parsing if set_fs() doesn't
> exist.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
ided so that architectures can start to opt out of providing set_fs.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
t can be added back
> by switching them to the iter ops and using generic_file_splice_read.
>
> Signed-off-by: Christoph Hellwig
This seems a bit disruptive? I feel like this is going to make fuzzers
really noisy (e.g. trinity likes to splice random stuff out of /sys and
/proc).
Co
the regular ->read/->write methods and the iter
> variants those could have different semantics for messed up enough
> drivers. Also fails the kernel access to them in that case.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
ph Hellwig
Reviewed-by: Kees Cook
--
Kees Cook
++ b/drivers/misc/lkdtm/usercopy.c
> @@ -325,6 +325,7 @@ void lkdtm_USERCOPY_KERNEL(void)
> vm_munmap(user_addr, PAGE_SIZE);
> }
>
> +#ifdef CONFIG_SET_FS
> void lkdtm_USERCOPY_KERNEL_DS(void)
> {
> char __user *user_ptr =
> @@ -339,6 +340,7 @@ void lkdtm_USERCOPY_KERNEL_
On Mon, Aug 17, 2020 at 09:32:08AM +0200, Christoph Hellwig wrote:
> At least for 64-bit this moves them closer to some of the defines
> they are based on, and it prepares for using the TASK_SIZE_MAX
> definition from assembly.
>
> Signed-off-by: Christoph Hellwig
Reviewe
tasklet, typeof(*var), tasklet_fieldname)
>
> Just use container_of directly since we all understand what it does.
But then the lines get really long, wrapped, etc. This is what the
timer_struct conversion did too (added a container_of wrapper), so I
think it makes sense here too.
--
Kees Cook
Hi! Thanks for bisecting; yes, sorry for the trouble (I'm still trying
to understand why my compat tests _passed_...). Regardless, can you try
this patch:
https://lore.kernel.org/lkml/20200807173609.GJ4402@mussarela/
--
Kees Cook
*/
> + pr_err("FAIL: wrote to another cpu's patching area\n");
> + } else {
> + kthread_stop(patching_kthrd);
> + }
> +
> +out:
> + /* Restore the original insn for any future lkdtm tests */
> + patch_instruction(patch_site, original_insn);
Can this test be done for x86's instruction patching too?
> +}
> +
> +#else
> +
> +void lkdtm_HIJACK_PATCH(void)
> +{
> + if (!IS_ENABLED(CONFIG_PPC))
> + pr_err("XFAIL: this test is powerpc-only\n");
> + if (!IS_ENABLED(CONFIG_STRICT_KERNEL_RWX))
> + pr_err("XFAIL: this test requires CONFIG_STRICT_KERNEL_RWX\n");
> +}
> +
> +#endif /* CONFIG_PPC && CONFIG_STRICT_KERNEL_RWX */
> +
> void __init lkdtm_perms_init(void)
> {
> /* Make sure we can write to __ro_after_init values during __init */
> --
> 2.27.0
Otherwise, looks good!
--
Kees Cook
> its own separate late_initcall.
>
> Signed-off-by: Brendan Higgins
> ---
> arch/xtensa/kernel/vmlinux.lds.S | 4
If you ever find yourself modifying multiple arch linker scripts for a
series, something has gone wrong. ;)
--
Kees Cook
INIT_DATA_SECTION. Not all
architectures use the INIT_DATA_SECTION macro (e.g. arm64), but everything
uses INIT_DATA.
--
Kees Cook
user_stack_size, struct task_struct *p,
> unsigned long tls)
Maybe clean up the arg indentation too? I'm not sure how strongly people
feel about that, but I think it'd be nice.
Either way:
Reviewed-by: Kees Cook
--
Kees Cook
sufficient.
Reviewed-by: Kees Cook
--
Kees Cook
erches.com
Signed-off-by: Kees Cook
---
arch/powerpc/mm/book3s64/hash_utils.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/book3s64/hash_utils.c
b/arch/powerpc/mm/book3s64/hash_utils.c
index 8ed2411c3f39..cf2e1b06e5d4 100644
--- a/arch/powerpc/mm/book3s64/ha
On Wed, Jun 03, 2020 at 04:04:31PM -0700, Joe Perches wrote:
> On Wed, 2020-06-03 at 15:40 -0700, Kees Cook wrote:
> > The IS_ENABLED() use was missing the CONFIG_ prefix which would have
> > lead to skipping this code.
> >
> > Fixes: 3ad1f3a33286 ("pwm: Implement
"disabling 16M linear map alignment");
> + pr_warn("Kernel not 16M aligned, disabling 16M
> linear map alignment\n");
> aligned = false;
> }
Reviewed-by: Kees Cook
--
Kees Cook
On Fri, May 29, 2020 at 11:49:12AM +, Luis Chamberlain wrote:
> Yikes, sense, you're right. Nope, I left the random config tests to
> 0day. Will fix, thanks!
Yeah, I do the same for randconfig, but I always do an "allmodconfig"
build before sending stuff. It's a
me = "fs",
> - .data = NULL,
> - .maxlen = 0,
> - .mode = 0555,
> - .child = ocfs2_kern_table
> - },
> - { }
> -};
> + .data = NULL,
> + .data = NULL,
The conversion script doesn't like the .data field assignments. ;)
Was this series built with allmodconfig? I would have expected this to
blow up very badly. :)
--
Kees Cook
ed-off-by: Luis Chamberlain
Reviewed-by: Kees Cook
--
Kees Cook
.procname = "binfmt_misc",
> - .mode = 0555,
> - .child = sysctl_mount_point,
> - },
> -#endif
> {
> .procname = "pipe-max-size",
> .data = &pipe_max_size,
> --
> 2.26.2
>
--
Kees Cook
On Fri, May 22, 2020 at 06:51:20PM +0200, Petr Mladek wrote:
> On Fri 2020-05-15 11:44:30, Kees Cook wrote:
> > From: Pavel Tatashin
> >
> > kmsg_dump() allows to dump kmesg buffer for various system events: oops,
> > panic, reboot, etc. It provides an interface
On Wed, May 20, 2020 at 06:52:21PM -0500, Li Yang wrote:
> On Mon, May 18, 2020 at 5:57 PM Kees Cook wrote:
> > Hm, looking at this code, I see a few other things that need to be
> > fixed:
> >
> > 1) drivers/tty/serial/ucc_uart.c does not do a be32_to_cpu() conversio
On Mon, May 18, 2020 at 04:45:32PM -0600, Rob Herring wrote:
> On Fri, May 15, 2020 at 12:44 PM Kees Cook wrote:
> >
> > From: Pavel Tatashin
>
> Subject still has 'max_reason'.
>
> >
> > Currently, it is possible to dump kmsges for panic, or oo
if (code < firmware || code >= firmware_end ||
+ code + count < firmware || code + count >= firmware_end) {
+ printk(KERN_ERR "qe-firmware: invalid ucode offset\n");
+ return -EIO;
+ }
+ }
+
/*
* If the microcode calls for it, split the I-RAM.
*/
I haven't tested this.
--
Kees Cook
pdata.max_reason = ramoops_max_reason;
>
> (ramoops_max_reason >= 0) might make more sense here, we do not want
> negative max_reason even if it was provided by the user.
Yeah, that's a good point. I'll tweak that. Thanks!
--
Kees Cook
missing the patch where ramoops_parse_dt_size
> -> ramoops_parse_dt_u32 get renamed, and updated to handle default
> value.
Oops! Sorry, I cut the line in the wrong place for sending out the delta
on top of the pstore tree. :)
It's unchanged from:
https://lore.kernel.org/lkml/20200506211523.15
-keesc...@chromium.org/
Signed-off-by: Kees Cook
---
.../devicetree/bindings/reserved-memory/ramoops.txt | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/reserved-memory/ramoops.txt
b/Documentation/devicetree/bindings/reserved-memory
3555.543636-1-pasha.tatas...@soleen.com
Kees Cook (3):
printk: Collapse shutdown types into a single dump reason
printk: Introduce kmsg_dump_reason_str()
pstore/ram: Introduce max_reason and convert dump_oops
Pavel Tatashin (3):
printk: honor the max_reason field in kmsg_dumper
pstore/p
passed as kernel parameter.
Allow clients to decide max_reason, and keep the current behavior when
max_reason is not set.
Signed-off-by: Pavel Tatashin
Link: https://lore.kernel.org/lkml/20200506211523.15077-2-keesc...@chromium.org/
Signed-off-by: Kees Cook
---
include/linux/kmsg_dump.h | 1
rg/lkml/ca+ck2bapv5u1ih5y9t5funtyximtfctdyxjcpuyjoyhnokr...@mail.gmail.com/
Signed-off-by: Kees Cook
---
arch/powerpc/kernel/nvram_64.c | 4 +---
fs/pstore/platform.c | 8 ++--
include/linux/kmsg_dump.h | 4 +---
kernel/reboot.c| 6 +++---
4 files changed, 7 inserti
behavior: store only Oopses and Panics, or everything
if the printk.always_kmsg_dump boot param is set.
Signed-off-by: Pavel Tatashin
Link: https://lore.kernel.org/lkml/20200506211523.15077-3-keesc...@chromium.org/
Co-developed-by: Kees Cook
Signed-off-by: Kees Cook
---
fs/pstore/platform.c
ops to behave as
if max_reason was set to KMSG_DUMP_MAX.
Co-developed-by: Pavel Tatashin
Signed-off-by: Pavel Tatashin
Link: https://lore.kernel.org/lkml/20200506211523.15077-5-keesc...@chromium.org/
Signed-off-by: Kees Cook
---
Documentation/admin-guide/ramoops.rst | 14
: Petr Mladek
Acked-by: Sergey Senozhatsky
Signed-off-by: Kees Cook
---
fs/pstore/platform.c | 18 +-
include/linux/kmsg_dump.h | 7 +++
kernel/printk/printk.c| 17 +
3 files changed, 25 insertions(+), 17 deletions(-)
diff --git a/fs/pstore
On Thu, Apr 02, 2020 at 12:26:52PM -0700, Linus Torvalds wrote:
> On Thu, Apr 2, 2020 at 11:36 AM Kees Cook wrote:
> >
> > Yup, I think it's a weakness of the ARM implementation and I'd like to
> > not extend it further. AFAIK we should never nest, but I would no
AIK we should never nest, but I would not be
surprised at all if we did.
If we were looking at a design goal for all architectures, I'd like
to be doing what the public PaX patchset did for their memory access
switching, which is to alarm if calling into "enable" found the access
already enabled, etc. Such a condition would show an unexpected nesting
(like we've seen with similar constructs with set_fs() not getting reset
during an exception handler, etc etc).
--
Kees Cook
ecially since it is by definition live inside a user access region."
I share this concern -- we want to keep user/kernel access as static as
possible. It should be provable with static analysis, etc (e.g. objtool
does this already for x86).
Since this doesn't disrupt existing R+W access, I'd prefer the design of
this series as-is.
--
Kees Cook
ined, those new access helpers default on the
> existing user_access_begin and user_access_end.
>
> Signed-off-by: Christophe Leroy
Reviewed-by: Kees Cook
-Kees
> Link: https://patchwork.ozlabs.org/patch/1227926/
> ---
> Resending this series as I mistakenly only sent it to po
On Thu, Apr 02, 2020 at 07:34:19AM +, Christophe Leroy wrote:
> Add support for selective read or write user access with
> user_read_access_begin/end and user_write_access_begin/end.
>
> Signed-off-by: Christophe Leroy
Reviewed-by: Kees Cook
-Kees
> ---
> arch/powerpc/
Leroy
Why is this split from the other conversions?
Reviewed-by: Kees Cook
> ---
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/
; unsigned long *mask,
> }
> if (nr_compat_longs)
> unsafe_put_user((compat_ulong_t)*mask, umask++, Efault);
> - user_access_end();
> + user_write_access_end();
> return 0;
> Efault:
> - user_access_end();
> + user_write_access_end();
> return -EFAULT;
> }
(These correctly end write access.)
All the others look correct. With the above fixed:
Reviewed-by: Kees Cook
--
Kees Cook
gnore file instead of using the root one.
>
> Fixes: 68ca0fd272da ("selftest/lkdtm: Don't pollute 'git status'")
> Signed-off-by: Christophe Leroy
Yeah, that's better. Thanks!
Acked-by: Kees Cook
-Kees
> ---
> .gitignore | 4 ---
s would be handy to have on all architectures.
Reviewed-by: Kees Cook
-Kees
>
> Also fixed a typo.
>
> Signed-off-by: Russell Currey
> ---
> arch/powerpc/Kconfig.debug | 6 --
> arch/powerpc/mm/ptdump/ptdump.c | 21 -
> 2 files changed, 24
1a0f03d66 ("selftests/lkdtm: Add tests for LKDTM targets")
> Signed-off-by: Christophe Leroy
Ah! Yes, a very good idea. Thanks!
Reviewed-by: Kees Cook
-Kees
> ---
> .gitignore | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/.gitignore b/.gitignore
&g
n
I'm not sure what that should look like. Does the new
user_access_begin() API provide a way to query existing state? I'll go
read the series...
--
Kees Cook
nclude a hint to the config
name?
Regardless:
Acked-by: Kees Cook
-Kees
> ---
> init/main.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/init/main.c b/init/main.c
> index 2cd736059416..fd31b15cc910 100644
> --- a/init/main.c
> +++ b/init/main.c
&g
s://github.com/KSPP/linux/issues/3 with a link
to this current series.
--
Kees Cook
est by you to
Linus directly during the v5.5 merge window, via akpm, via akpm, via
Christian, or some other path? Besides Linus, it's not been clear who
should "claim" this series. :)
--
Kees Cook
On Mon, Nov 11, 2019 at 07:08:51PM +0100, Geert Uytterhoeven wrote:
> Hi Kees,
>
> On Mon, Nov 11, 2019 at 6:23 PM Kees Cook wrote:
> > On Mon, Nov 11, 2019 at 05:58:06PM +0100, Geert Uytterhoeven wrote:
> > > On Fri, Oct 11, 2019 at 2:07 AM Kees Cook wrote:
> >
On Mon, Nov 11, 2019 at 05:58:06PM +0100, Geert Uytterhoeven wrote:
> Hi Kees,
>
> On Fri, Oct 11, 2019 at 2:07 AM Kees Cook wrote:
> > There's no reason to keep the RODATA macro: replace the callers with
> > the expected RO_DATA macro.
> >
> > Signed-off-
The following commit has been merged into the x86/build branch of tip:
Commit-ID: 380e57e2d41e9631132beccac30058228dfd376f
Gitweb:
https://git.kernel.org/tip/380e57e2d41e9631132beccac30058228dfd376f
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:42 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: 7a42d41d9dc2829bdf589db855ce3f948de2da6b
Gitweb:
https://git.kernel.org/tip/7a42d41d9dc2829bdf589db855ce3f948de2da6b
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:29 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: 94174c9b71c62a0e1a4364c2594e1422ba8fffcd
Gitweb:
https://git.kernel.org/tip/94174c9b71c62a0e1a4364c2594e1422ba8fffcd
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:47 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: 9b30e704dd0d9ef9d99c7f88712318840cc8a338
Gitweb:
https://git.kernel.org/tip/9b30e704dd0d9ef9d99c7f88712318840cc8a338
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:43 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: 2d0004d19829c84aaf2c7d48b5e2892d548970b6
Gitweb:
https://git.kernel.org/tip/2d0004d19829c84aaf2c7d48b5e2892d548970b6
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:48 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: c82318254d15e5f83c75f60aedf2bb9eb408308f
Gitweb:
https://git.kernel.org/tip/c82318254d15e5f83c75f60aedf2bb9eb408308f
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:33 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: 19f6bc32c6f4216e099963f416de91eba7ca1430
Gitweb:
https://git.kernel.org/tip/19f6bc32c6f4216e099963f416de91eba7ca1430
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:40 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: 172c8b85dccf331826deda9ef6d7e75fa4f2b3e2
Gitweb:
https://git.kernel.org/tip/172c8b85dccf331826deda9ef6d7e75fa4f2b3e2
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:39 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: 1e51cd538809112a6ac702a48e9719a75152c902
Gitweb:
https://git.kernel.org/tip/1e51cd538809112a6ac702a48e9719a75152c902
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:41 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: 6e85e23ef2d004def8e1acd36eb155411499b7cc
Gitweb:
https://git.kernel.org/tip/6e85e23ef2d004def8e1acd36eb155411499b7cc
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:45 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: 5494c3a6a0b965906ffdcb620d94079ea4cb69ea
Gitweb:
https://git.kernel.org/tip/5494c3a6a0b965906ffdcb620d94079ea4cb69ea
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:49 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: b907693883fdcff5b492cf0cd02a0e264623055e
Gitweb:
https://git.kernel.org/tip/b907693883fdcff5b492cf0cd02a0e264623055e
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:37 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: 7705dc8557973d8ad8f10840f61d8ec805695e9e
Gitweb:
https://git.kernel.org/tip/7705dc8557973d8ad8f10840f61d8ec805695e9e
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:51 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: 4e9e559a0385930649c1c9cad703d475ee030206
Gitweb:
https://git.kernel.org/tip/4e9e559a0385930649c1c9cad703d475ee030206
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:46 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: 6434efbd9aefa3786b446c8e4745d1f49d2983b4
Gitweb:
https://git.kernel.org/tip/6434efbd9aefa3786b446c8e4745d1f49d2983b4
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:28 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: fbe6a8e618a2d70621cff277e24f6eb338d3d149
Gitweb:
https://git.kernel.org/tip/fbe6a8e618a2d70621cff277e24f6eb338d3d149
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:31 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: 441110a547f86a2fd0c40bf04b274853622c53cc
Gitweb:
https://git.kernel.org/tip/441110a547f86a2fd0c40bf04b274853622c53cc
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:30 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: 6fc4000656a10fb679ab6566dcd516ee672f1706
Gitweb:
https://git.kernel.org/tip/6fc4000656a10fb679ab6566dcd516ee672f1706
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:24 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: 65182e6e36195fbf9340808ac4a00d1c146bc05c
Gitweb:
https://git.kernel.org/tip/65182e6e36195fbf9340808ac4a00d1c146bc05c
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:26 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: af0f3e9e205c3d1bad91ad83e06bfd04df9712b2
Gitweb:
https://git.kernel.org/tip/af0f3e9e205c3d1bad91ad83e06bfd04df9712b2
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:25 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: ec556271bbb33809b73cdb238f8cb357345908e8
Gitweb:
https://git.kernel.org/tip/ec556271bbb33809b73cdb238f8cb357345908e8
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:23 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: c9174047b48d700a785b633319dd7d27288b86be
Gitweb:
https://git.kernel.org/tip/c9174047b48d700a785b633319dd7d27288b86be
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:35 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: 430c6b2647e215c4129f36646ad28a725996b410
Gitweb:
https://git.kernel.org/tip/430c6b2647e215c4129f36646ad28a725996b410
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:27 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: 93240b327929ff03c1878ea8badc5c6bd86f053f
Gitweb:
https://git.kernel.org/tip/93240b327929ff03c1878ea8badc5c6bd86f053f
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:34 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: 3bda6f37a7949c803b84cf27e11a3995d900a179
Gitweb:
https://git.kernel.org/tip/3bda6f37a7949c803b84cf27e11a3995d900a179
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:44 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: b8c2f776164c8f74ac31c5e370ca3f029be0aa19
Gitweb:
https://git.kernel.org/tip/b8c2f776164c8f74ac31c5e370ca3f029be0aa19
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:36 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: eaf937075c9a42eb8ba51eb3050773d7205d3595
Gitweb:
https://git.kernel.org/tip/eaf937075c9a42eb8ba51eb3050773d7205d3595
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:32 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: f0d7ee17d57c7a8510518a1e60366d053e2f3ff5
Gitweb:
https://git.kernel.org/tip/f0d7ee17d57c7a8510518a1e60366d053e2f3ff5
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:38 -07:00
Committer
The following commit has been merged into the x86/build branch of tip:
Commit-ID: a329975491aafcb1fb6e2fad0de22cae5c16154f
Gitweb:
https://git.kernel.org/tip/a329975491aafcb1fb6e2fad0de22cae5c16154f
Author:Kees Cook
AuthorDate:Tue, 29 Oct 2019 14:13:50 -07:00
Committer
On Wed, Oct 30, 2019 at 11:16:22AM +1100, Michael Ellerman wrote:
> Kees Cook writes:
> > On Mon, Oct 14, 2019 at 04:13:16PM +1100, Russell Currey wrote:
> >> v3 cover letter here:
> >> https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-October/198023.html
> >&
> a kernel area RO. Only user areas can be made RO.
As I understand it, the idea was for it to be mandatory (or at least
default-on) only for the subarches where it wasn't totally insane to
accomplish. :) (I'm not familiar with all the details on the subarchs,
but it sounded like the more modern systems would be the targets for
this?)
--
Kees Cook
h/powerpc/mm/ptdump/ptdump.c| 21 -
> 8 files changed, 123 insertions(+), 3 deletions(-)
> create mode 100644 arch/powerpc/include/asm/set_memory.h
> create mode 100644 arch/powerpc/mm/pageattr.c
>
> --
> 2.23.0
>
--
Kees Cook
rnel data
02a95000-035f : Kernel bss
Signed-off-by: Kees Cook
---
arch/x86/kernel/setup.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 77ea96b794bd..591e885a852e 100644
--- a/arch/x86/kernel/setup.c
+
Since the EXCEPTION_TABLE is read-only, collapse it into RO_DATA.
Signed-off-by: Kees Cook
Acked-by: Max Filippov
---
arch/xtensa/kernel/vmlinux.lds.S | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/xtensa/kernel/vmlinux.lds.S b/arch/xtensa/kernel/vmlinux.lds.S
index
Since the EXCEPTION_TABLE is read-only, collapse it into RO_DATA.
Signed-off-by: Kees Cook
---
arch/microblaze/kernel/vmlinux.lds.S | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/microblaze/kernel/vmlinux.lds.S
b/arch/microblaze/kernel/vmlinux.lds.S
index
Since the EXCEPTION_TABLE is read-only, collapse it into RO_DATA.
Signed-off-by: Kees Cook
Acked-by: Helge Deller
---
arch/parisc/kernel/vmlinux.lds.S | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/parisc/kernel/vmlinux.lds.S b/arch/parisc/kernel/vmlinux.lds.S
(text/rodata gap) memory: 2040K
[2.336927] Freeing unused kernel image (rodata/data gap) memory: 172K
Signed-off-by: Kees Cook
---
arch/x86/include/asm/processor.h | 2 +-
arch/x86/mm/init.c | 8
arch/x86/mm/init_64.c| 6 --
3 files changed, 9 insertions(
Since the EXCEPTION_TABLE is read-only, collapse it into RO_DATA.
Signed-off-by: Kees Cook
---
arch/powerpc/kernel/vmlinux.lds.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S
b/arch/powerpc/kernel/vmlinux.lds.S
index 4e7cec088c8b
There's no reason to keep the RODATA macro: replace the callers with
the expected RO_DATA macro.
Signed-off-by: Kees Cook
---
arch/alpha/kernel/vmlinux.lds.S | 2 +-
arch/ia64/kernel/vmlinux.lds.S | 2 +-
arch/microblaze/kernel/vmlinux.lds.S | 2 +-
arch/mips/kernel/vmlinux.
Since the EXCEPTION_TABLE is read-only, collapse it into RO_DATA.
Signed-off-by: Kees Cook
---
arch/ia64/kernel/vmlinux.lds.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/ia64/kernel/vmlinux.lds.S b/arch/ia64/kernel/vmlinux.lds.S
index 11d5115bc44d..1ec6b703c5b4
Finish renaming RO_DATA_SECTION to RO_DATA. (Calling this a "section"
is a lie, since it's multiple sections and section flags cannot be
applied to the macro.)
Signed-off-by: Kees Cook
Acked-by: Heiko Carstens # s390
Acked-by: Geert Uytterhoeven # m68k
---
arch/arc/kerne
Since the EXCEPTION_TABLE is read-only, collapse it into RO_DATA.
Signed-off-by: Kees Cook
---
arch/h8300/kernel/vmlinux.lds.S | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/h8300/kernel/vmlinux.lds.S b/arch/h8300/kernel/vmlinux.lds.S
index 2ac7bdcd2fe0
Rename RW_DATA_SECTION to RW_DATA. (Calling this a "section" is a lie,
since it's multiple sections and section flags cannot be applied to
the macro.)
Signed-off-by: Kees Cook
Acked-by: Heiko Carstens # s390
Acked-by: Geert Uytterhoeven # m68k
---
arch/alpha/kernel/vmlinux
added more rationale to patch #1 in the just-sent v3 of this
series. If I still can't convince you Segher, I'm happy to send "patch
30/29" to do a bulk rename to "notes". Let me know. :)
--
Kees Cook
201 - 300 of 748 matches
Mail list logo