dating 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
> Signed-off-by: Ard Biesheuvel
Awesome!
Reviewed-by: Kees Cook
-Kees
--
Kees Cook
Pixel Security
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
'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
he 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 b
On Thu, Apr 20, 2017 at 3:15 AM, Arnd Bergmann wrote:
> On Sun, Apr 16, 2017 at 9:52 PM, Kees Cook wrote:
>>>> The original gcc-4.3 release was in early 2008. If we decide to still
>>>> support that, we probably want the first 10 quirks in this series,
>>&
On Fri, Apr 21, 2017 at 1:55 PM, Arnd Bergmann wrote:
> On Thu, Apr 20, 2017 at 9:52 PM, Kees Cook wrote:
>> On Thu, Apr 20, 2017 at 3:15 AM, Arnd Bergmann wrote:
>>> On Sun, Apr 16, 2017 at 9:52 PM, Kees Cook wrote:
>>>>>> The original gcc-4.3 release was
oved 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!
-Kees
-
ection in
Documentation/userspace-api/index.rst?
-Kees
[1] https://www.kernel.org/doc/html/latest/doc-guide/sphinx.html
--
Kees Cook
Pixel Security
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
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 Cook
> Cc: Paolo Bonzini
&
e 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 mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
setup_sigframe().
And it's not clear if parse_user_sigframe() is safe either. Are
user->fpsimd and user->sve checked somewhere? It seems 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 __reserve
On Thu, Dec 7, 2017 at 2:49 AM, Will Deacon 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 wrote:
>> > Miscellaneous:
>> >
>> > * Change inconsistent c
On Mon, Dec 11, 2017 at 6:07 AM, Will Deacon 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 there's very
>> little perf
On Tue, Dec 12, 2017 at 3:11 AM, Dave Martin 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 wrote:
>> > > On Thu, Dec 07, 2017
print out any PAC-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
>> >
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
]
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 some
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 quest
is missing 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
; +
> +
> +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,
>
series...)
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
operation, or
> - 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
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 per-th
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)
> + endi
I'm fine to turn that off.
--
Kees Cook
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
I have is that I don'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
too?
#define STATIC_CALL_TRAMP_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
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 expe
30 matches
Mail list logo