read-only from
> the outset.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
Awesome!
Reviewed-by: Kees Cook <keesc...@chromium.org>
-Kees
--
Kees Cook
Pixel Security
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
h
EL_RO);
> +
> + /* flush the TLBs after updating live kernel mappings */
> + flush_tlb_all();
> +}
Oh, dur, sorry, I missed this the first time through. Nevermind! Looks
like linear will be RO, kernel will be ROX at runtime, and during
boot, kernel will be ROX, and linear will be RW. Nice!
-Kees
> +
> static void __init map_mem(pgd_t *pgd)
> {
> struct memblock_region *reg;
> --
> 2.7.4
>
--
Kees Cook
Pixel Security
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
execute the kernel mapping. Can't we
make the linear mapping match the kernel mapping permissions?
-Kees
--
Kees Cook
Pixel Security
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
On Thu, Apr 20, 2017 at 3:15 AM, Arnd Bergmann <a...@arndb.de> wrote:
> On Sun, Apr 16, 2017 at 9:52 PM, Kees Cook <keesc...@chromium.org> wrote:
>>>> The original gcc-4.3 release was in early 2008. If we decide to still
>>>> support that, we probably
ant the first 10 quirks in this series,
>> while gcc-4.6 (released in 2011) requires none of them.
I'd be in support of raising the minimum to gcc 4.6. (I'd actually
prefer 4.7, just to avoid some 4.6 packaging issues, and for better
gcc plugin support.)
I'm curious what gcc 4.6 binaries ar
On Fri, Apr 21, 2017 at 1:55 PM, Arnd Bergmann <a...@arndb.de> wrote:
> On Thu, Apr 20, 2017 at 9:52 PM, Kees Cook <keesc...@chromium.org> wrote:
>> On Thu, Apr 20, 2017 at 3:15 AM, Arnd Bergmann <a...@arndb.de> wrote:
>>> On Sun, Apr 16, 2017 at 9:52 PM, Kee
th the kernel docs moving to ReST markup[1], perhaps reformat this
to a .rst file and link to it from somewhere sensible in the ReST
tree, perhaps the userspace API section in
Documentation/userspace-api/index.rst?
-Kees
[1] https://www.kernel.org/doc/html/latest/doc-guide/sphinx.html
--
Ke
earlier gets removed from linux/compiler.h,
> and instead we add a summary of what I found, explaining that
> gcc-4.1 has active users on a few architectures.
> - We make the Makefile show a warning once during compilation for
> gcc earlier than 4.3.
This sounds good to me!
-K
m and the merge window both coming soon.
>
> I'll send a v2 myself later this week.
Okay, which patches would you like me to carry in the usercopy
whitelisting tree for the coming merge window?
-Kees
--
Kees Cook
Pixel Security
___
kvmarm mailin
On Tue, Dec 12, 2017 at 3:11 AM, Dave Martin <dave.mar...@arm.com> wrote:
> On Tue, Dec 12, 2017 at 10:40:30AM +, Will Deacon wrote:
>> On Mon, Dec 11, 2017 at 11:23:09AM -0800, Kees Cook wrote:
>> > On Mon, Dec 11, 2017 at 6:07 AM, Will Deacon <will.dea...@arm.com
On Thu, Dec 7, 2017 at 2:49 AM, Will Deacon <will.dea...@arm.com> wrote:
> Hi Kees,
>
> On Wed, Dec 06, 2017 at 11:56:50AM -0800, Kees Cook wrote:
>> On Tue, Oct 31, 2017 at 8:51 AM, Dave Martin <dave.mar...@arm.com> wrote:
>> > Miscellaneous:
>> >
>
On Mon, Dec 11, 2017 at 6:07 AM, Will Deacon <will.dea...@arm.com> wrote:
> On Thu, Dec 07, 2017 at 10:50:38AM -0800, Kees Cook wrote:
>> My question is mainly: why not just use copy_*() everywhere instead?
>> Having these things so spread out makes it fragile, and t
like it's
safely contained by in sf->uc.uc_mcontext.__reserved, but it's hard to
read, though I do see access_ok() checks against __reserved at the end
of the while loop.
Can we just drop all the __... calls for the fully checked
copy_to/from_user() instead?
-Kees
--
Kees Cook
Pixel Security
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
sive, and we'd
> like to avoid that, so we tell kvm_init_usercopy to whitelist accesses
> to out context structure.
>
> The debug system register accesses on arm64 are modified to work through
> an indirection instead.
>
> Cc: kernel-harden...@lists.openwall.com
> Cc: Kees Coo
]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Cc: Christoffer Dall
Cc: Marc Zyngier
Cc: Eric Auger
Cc: Andre Przywara
Cc: linux-arm-ker...@lists.infradead.org
Cc: kvmarm@lists.cs.columbia.edu
Signed-off-by: Kees Cook
---
virt/kvm/arm/vgic/vgic-its.c
On Mon, Jul 2, 2018 at 12:36 AM, Auger Eric wrote:
> Hi Kees,
>
> On 06/29/2018 08:46 PM, Kees Cook wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this
>> switches to using a maximum size and adds sanity checks. Additionally
>> cleans up s
On Mon, Jul 9, 2018 at 3:47 AM, Marc Zyngier wrote:
> Hi kees,
>
> On 02/07/18 18:15, Kees Cook wrote:
>> On Mon, Jul 2, 2018 at 12:36 AM, Auger Eric wrote:
>>> Hi Kees,
>>>
>>> On 06/29/2018 08:46 PM, Kees Cook wrote:
>>>> In the
support). Using cc-option runs the risk of
building a kernel with CONFIG_ARM64_PTR_AUTH set, but _not_ actually
using ptr auth.
-Kees
--
Kees Cook
Pixel Security
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
gt; +
> +Basic support
> +-
> +
> +When CONFIG_ARM64_PTR_AUTH is selected, and relevant HW support is
> +present, the kernel will assign a random APIAKey value to each process
> +at exec*() time. This key is shared by all threads within the process,
> +and
gt; - both of the above?
>
> Part of the answer to that may lie in the requirements of CRIU, where I
> strongly suspect they need explicit get/set operations, although these
> could be gated on CONFIG_CHECKPOINT_RESTORE=y.
Oh CRIU. Yikes. I'd like the get/set to be ga
On Fri, Oct 19, 2018 at 8:49 AM, Will Deacon wrote:
> On Fri, Oct 19, 2018 at 08:36:45AM -0700, Kees Cook wrote:
>> On Fri, Oct 19, 2018 at 4:24 AM, Will Deacon wrote:
>> > FWIW: I think we should be entertaining a prctl() interface to use a new
>> > key on a
...)
Thanks for the series! I'm quite excited for ARMv8.3 hardware. :)
-Kees
--
Kees Cook
Pixel Security
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
AC-related warning.
There are other "guesses" in __do_kernel_fault(), I think? Could a
"PAC mismatch?" warning be included in the Oops if execution fails in
the address range that PAC failures would resolve into?
-Kees
--
Kees Cook
_
On Wed, Nov 14, 2018 at 3:47 PM, Mark Rutland wrote:
> On Tue, Nov 13, 2018 at 05:09:00PM -0600, Kees Cook wrote:
>> On Tue, Nov 13, 2018 at 10:17 AM, Kristina Martsenko
>> wrote:
>> > When the PAC authentication fails, it doesn't actually generate an
>> &g
CLANG
> +CFLAGS_UBSAN += $(call cc-option, -fsanitize=array-bounds)
This would mean losing the local-bounds coverage? Isn't that for locally
defined arrays on the stack?
> + else
> +CFLAGS_UBSAN += $(call cc-option, -fsanitize=bounds)
> + endif
>
fine to turn that off.
--
Kees Cook
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
't like the coverage of some
mitigation or detection to "silently" vary between builds. e.g. someone
would build with/without UBSAN_TRAP and end up with unexpectedly
different coverage. I'd rather there be a separate CONFIG that appears.
--
Kees Cook
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
sues/1317
> Reported-by: Nathan Chancellor
> Suggested-by: Marc Zyngier
> Suggested-by: Ard Biesheuvel
> Signed-off-by: Sami Tolvanen
Reviewed-by: Kees Cook
--
Kees Cook
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
P_RET0_PREFIX __SCT__ret0__
#define STATIC_CALL_TRAMP_RET0(name)__PASTE(STATIC_CALL_TRAMP_RET0_PREFIX,
name)
#define DEFINE_STATIC_CALL_RET0(name, _func)\
static typeof(_func) STATIC_CALL_TRAMP_RET0(name) { return 0; } \
On Sun, Feb 06, 2022 at 09:28:52PM +0100, Peter Zijlstra wrote:
> On Sun, Feb 06, 2022 at 10:45:15AM -0800, Kees Cook wrote:
>
> > I'm digging through the macros to sort this out, but IIUC, an example of
> > the problem is:
> >
>
> > so the caller is
30 matches
Mail list logo
