: Kees Cook
---
drivers/net/xen-netback/common.h| 2 +-
drivers/net/xen-netback/interface.c | 2 +-
drivers/net/xen-netback/netback.c | 6 ++
3 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index
usable, and that seems to have improved performance:
https://gcc.gnu.org/gcc-5/changes.html
-Kees
--
Kees Cook
Pixel Security
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
t the percpu area
instead. This would let us solve the global stack protector problem on
the other architectures:
http://www.openwall.com/lists/kernel-hardening/2017/06/27/6
-Kees
--
Kees Cook
Pixel Security
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
This kind of thing got discussed recently, and like
CONFIG_EXPERIMENTAL, a global config doesn't really work. The best
thing to do is to document each config as well as possible and system
builders can decide.
-Kees
--
Kees Cook
Pixel Security
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
| 103
> tools/include/asm-generic/section-core.h | 341 +++
> tools/include/asm-generic/tables.h | 50 ++
Aren't a bunch of these files exact duplicates of the headers in include/linux?
-Kees
--
Kees Cook
Nexus Security
__
mode 100644 Documentation/sections/index.rst
> create mode 100644 Documentation/sections/linker-tables.rst
> create mode 100644 Documentation/sections/ranges.rst
> create mode 100644 Documentation/sections/section-core.rst
> create mode 100644 arch/c6x/include/asm/tables.h
> create mode 100644 arch/unicore32/include/asm/section-core.h
> create mode 100644 include/asm-generic/kprobes.h
> create mode 100644 include/asm-generic/ranges.h
> create mode 100644 include/asm-generic/section-core.h
> create mode 100644 include/asm-generic/tables.h
> create mode 100644 include/linux/ranges.h
> create mode 100644 include/linux/sections.h
> create mode 100644 include/linux/tables.h
> rename scripts/{module-common.lds => module-common.lds.S} (80%)
>
> --
> 2.9.2
>
--
Kees Cook
Nexus Security
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
gt; index 0a07f9014944..d1cb0cfdf1bf 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -12,6 +12,15 @@ export KBUILD_SUBDIR_CCFLAGS := $(KBUILD_SUBDIR_CCFLAGS)
> $(subdir-ccflags-y)
> # Figure out what we need to build from the various variables
> # ===
>
> +ifeq ($(CONFIG_BUILD_AVOID_BITROT),y)
> +extra-y += $(force-obj-) $(force-lib-)
> +endif
> +
> +obj-m += $(force-obj-m)
> +obj-y += $(force-obj-y)
> +lib-m += $(force-lib-m)
> +lib-y += $(force-lib-y)
> +
> # When an object is listed to be built compiled-in and modular,
> # only build the compiled-in version
>
> @@ -72,6 +81,8 @@ real-objs-m := $(foreach m, $(obj-m), $(if $(strip
> $($(m:.o=-objs)) $($(m:.o=-y)
> # Add subdir path
>
> extra-y:= $(addprefix $(obj)/,$(extra-y))
> +force-obj-y:= $(addprefix $(obj)/,$(force-obj-y))
> +force-obj-m:= $(addprefix $(obj)/,$(force-obj-m))
> always := $(addprefix $(obj)/,$(always))
> targets:= $(addprefix $(obj)/,$(targets))
> modorder := $(addprefix $(obj)/,$(modorder))
> --
> 2.9.2
>
--
Kees Cook
Nexus Security
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Fri, Aug 19, 2016 at 2:32 PM, wrote:
> From: "Luis R. Rodriguez"
>
> A linker table is a data structure that is stitched together from items
> in multiple object files. Linux has historically implicitly used linker
> tables for ages, however they were all built in an adhoc manner which
> requ
> + * @__section: ELF section to place section range into
> + *
> + * Constructs the beginning of a section range. You will typically not need
> + * to use this directly.
> + */
> +#define __SECTION_RANGE_BEGIN(name, __section) \
> + const __typeof__(VMLINUX_SYMBOL(name)[0]) \
> + __attribute__((used, \
> +weak, \
> +__aligned__(LINUX_SECTION_ALIGNMENT(name)),\
> +section(SECTION_RNG_LEVEL(__section, name,
> +
> +/**
> + * __SECTION_RANGE_END - Constructs the end of a section range
> + *
> + * @name: section range name
> + * @__section: ELF section to place section range into
> + *
> + * Constructs the end of a section range. You will typically not need
> + * to use this directly.
> + */
> +#define __SECTION_RANGE_END(name, __section) \
> + const __typeof__(VMLINUX_SYMBOL(name)[0]) \
> + __attribute__((used, \
> +__aligned__(LINUX_SECTION_ALIGNMENT(name)),\
> +section(SECTION_RNG_LEVEL(__section, name, ~
> +
> +/**
> + * DEFINE_SECTION_RANGE - Defines a section range
> + *
> + * @name: section range name
> + * @section: ELF section name to place section range into
> + *
> + * Defines a section range, used for executable code. Section ranges are
> + * defined in the code that takes ownership and makes use of the section
> + * range.
> + */
> +#define DEFINE_SECTION_RANGE(name, section)\
> + DECLARE_LINUX_SECTION_RO(char, name); \
> + __SECTION_RANGE_BEGIN(name, section) VMLINUX_SYMBOL(name)[0] = {};\
> + __SECTION_RANGE_END(name, section) VMLINUX_SYMBOL(name##__end)[0] = {}
> +
> +/**
> + * SECTION_ADDR_IN_RANGE - returns true if address is in range
> + *
> + * @name: section range name
> + * @addr: address to query for
> + *
> + * Returns true if the address is in the section range.
> + */
> +#define SECTION_ADDR_IN_RANGE(name, addr) \
> +(addr >= (unsigned long) LINUX_SECTION_START(name) && \
> + addr < (unsigned long) LINUX_SECTION_END(name))
> +
> +#endif /* __ASSEMBLY__ */
> +
> +#endif /* _LINUX_RANGES_H */
> --
> 2.9.2
>
-Kees
--
Kees Cook
Nexus Security
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
in Linux
> +=
> +
> +.. kernel-doc:: include/asm-generic/section-core.h
> + :doc: Standard ELF section use in Linux
> +
> +SECTION_RODATA
> +--
> +.. kernel-doc:: include/asm-generic/section-core.h
> + :doc: SECTION_ROD
Say N if you do you not have a
>> + good build machine or only want to compile what you've enabled for
>> + your kernel.
>> +
>> + Enabling this option never increases the size of your kernel.
>> +
>
> Other than those minor formulation nits, yeah, nice!
>
> Thanks.
>
> --
> Regards/Gruss,
> Boris.
>
> ECO tip #101: Trim your mails when you reply.
> --
-Kees
--
Kees Cook
Nexus Security
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
e OS was heavily optimized for boot
speed, it was designed to not need the initramfs at all. This is
actually enforced by the read-only boot firmware, so there's no
trivial way to _start_ using an initramfs on (existing) Chrome OS
devices either.
-Kees
--
Kees C
lenty of other things don't too). Being
able to build monolithic kernels (e.g. Android and Brillo) with
builtin firmware is very handy. Please don't remove built-in firmware
support.
-Kees
--
Kees Cook
Chrome OS & Brillo Security
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Mon, Aug 3, 2015 at 4:19 PM, Willy Tarreau wrote:
> On Mon, Aug 03, 2015 at 03:35:15PM -0700, Kees Cook wrote:
>> Yay for perm disable! Thank you! :)
>
> Andy would like to see this evolve towards something possibly
> more complete and/or generic. I think this needs more thou
proposes to temporarily disable it by default. This can be
> a safe alternative. A message is logged if an attempt was stopped so that
> it's easy to spot if/when it is needed.
>
> Cc: Andy Lutomirski
> Cc: Kees Cook
> Signed-off-by: Willy Tarreau
> ---
&
On Tue, Jul 28, 2015 at 1:03 PM, Willy Tarreau wrote:
> Hi Kees,
>
> On Tue, Jul 28, 2015 at 09:56:12AM -0700, Kees Cook wrote:
>> I look forward to the runtime disabling patch. :)
>
> Did you get my response to your comments regarding the proposed patch ?
>
> I can
On Mon, Jul 27, 2015 at 10:29 PM, Andy Lutomirski wrote:
> The modify_ldt syscall exposes a large attack surface and is
> unnecessary for modern userspace. Make it optional.
>
> Signed-off-by: Andy Lutomirski
Reviewed-by: Kees Cook
> ---
> arch/x86/Kconfig
t.
>
> Signed-off-by: Andy Lutomirski
Looks great!
Reviewed-by: Kees Cook
-Kees
> ---
> tools/testing/selftests/x86/Makefile | 2 +-
> tools/testing/selftests/x86/ldt_gdt.c | 520
> ++
> 2 files changed, 521 insertions(+), 1 deleti
ees as well.
This patch looks reasonable, but I'd prefer a tri-state (enable,
disable, hard-disable). I do something like this for Yama's ptrace
zero to max_scope range (which "pins" to max_scope if set):
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/security/yama/yama_lsm.c#n361
-Kees
--
Kees Cook
Chrome OS Security
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Thu, Jul 23, 2015 at 4:58 PM, Willy Tarreau wrote:
> On Thu, Jul 23, 2015 at 04:40:14PM -0700, Andy Lutomirski wrote:
>> On Thu, Jul 23, 2015 at 4:36 PM, Kees Cook wrote:
>> > I've been pondering something like this that is even MORE generic, for
>> > any sys
oc_dointvec,
> },
> + {
> + .procname = "modify_ldt",
> + .data = &sysctl_modify_ldt,
> + .maxlen = sizeof(int),
> + .mode = 0644,
> + .proc_handler = proc_dointvec,
> + },
> #endif
> #if defined(CONFIG_MMU)
> {
I've been pondering something like this that is even MORE generic, for
any syscall. Something like a "syscalls" directory under
/proc/sys/kernel, with 1 entry per syscall. "0" is "available", "1" is
disabled, and "-1" disabled until next boot.
-Kees
--
Kees Cook
Chrome OS Security
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
21 matches
Mail list logo
