On 2/24/25 10:55, Kees Cook wrote:
>> That logic is reasonable. But it's different from the _vast_ majority of
>> other flags.
>>
>> So what justifies VM_SEALED being so different? It's leading to pretty
>> objectively ugly code in this series.
> Note that VM_SEALED is the "is this VMA sealed?" bit
On 2/24/25 10:44, Jeff Xu wrote:
> For example:
> Consider the case below in src/third_party/kernel/v6.6/fs/proc/task_mmu.c,
>
> #ifdef CONFIG_64BIT
> [ilog2(VM_SEALED)] = "sl",
> #endif
>
> Redefining VM_SEALED to VM_NONE for 32 bit won't detect the problem
> in case that "#ifdef CONFIG_64BIT"
On 2/24/25 09:45, jef...@chromium.org wrote:
> +/*
> + * mseal of userspace process's system mappings.
> + */
> +#ifdef CONFIG_MSEAL_SYSTEM_MAPPINGS
> +#define MSEAL_SYSTEM_MAPPINGS_VM_FLAGVM_SEALED
> +#else
> +#define MSEAL_SYSTEM_MAPPINGS_VM_FLAGVM_NONE
> +#endif
This ends up loo
On 2/20/25 09:10, Valentin Schneider wrote:
>> The LDT and maybe the PEBS buffers are the only implicit supervisor
>> accesses to vmalloc()'d memory that I can think of. But those are both
>> handled specially and shouldn't ever get zapped while in use. The LDT
>> replacement has its own IPIs separ
On 2/19/25 07:13, Valentin Schneider wrote:
>> Maybe I missed part of the discussion though. Is VMEMMAP your only
>> concern? I would have guessed that the more generic vmalloc()
>> functionality would be harder to pin down.
> Urgh, that'll teach me to send emails that late - I did indeed mean the
On 2/19/25 09:08, Joel Fernandes wrote:
>> Pretty much so yeah. That is, *if* there such a vmalloc'd address access in
>> early entry code - testing says it's not the case, but I haven't found a
>> way to instrumentally verify this.
> Ok, thanks for confirming. Maybe there is an address sanitizer w
On 2/18/25 14:40, Valentin Schneider wrote:
>> In practice, it's mostly limited like that.
>>
>> Architecturally, there are no promises from the CPU. It is within its
>> rights to cache anything from the page tables at any time. If it's in
>> the CR3 tree, it's fair game.
>>
> So what if the VMEMMA
On 2/11/25 05:33, Valentin Schneider wrote:
>> 2. It's wrong to assume that TLB entries are only populated for
>> addresses you access - thanks to speculative execution, you have to
>> assume that the CPU might be populating random TLB entries all over
>> the place.
> Gotta love speculation. Now it
oes seem like we
should probably not be using 'char' and also shouldn't call it anything
close to "string". Maybe:
u8 message[64] __nonstring;
In any case, feel free to carry the annotation in your tree:
Acked-by: Dave Hansen
On 1/14/25 09:51, Valentin Schneider wrote:
> + cr4 = this_cpu_read(cpu_tlbstate.cr4);
> + asm volatile("mov %0,%%cr4": : "r" (cr4 ^ X86_CR4_PGE) : "memory");
> + asm volatile("mov %0,%%cr4": : "r" (cr4) : "memory");
> + /*
> + * In lieu of not having the pinning crap, hard fai
One of the sticker things in the x86 attempt to do the same thing was
context switching, both between normal tasks and in/out of exceptions
and interrupts.
The easiest place this manifested for us was code chunk like this:
kpkeys_set_level(KPKEYS_LVL_PGTABLES);
// modify page tabl
[1] = regs->cx;
> + args[2] = regs->dx;
> + args[3] = regs->si;
> + args[4] = regs->di;
> + args[5] = regs->bp;
> }
>
Yeah, that's much less magic. I'll stick this in the queue to go in to
the tree in a few weeks.
Acked-by: Dave Hansen
On 5/27/24 23:38, Tony W Wang-oc wrote:
...> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
> index c96ae8fee95e..ecadd0698d6a 100644
> --- a/arch/x86/kernel/hpet.c
> +++ b/arch/x86/kernel/hpet.c
> @@ -804,6 +804,12 @@ static u64 read_hpet(struct clocksource *cs)
> if (in_nmi())
o be overwritten
but does not need to be NULL-terminated.
But I wouldn't bother messing with it any more.
Acked-by: Dave Hansen
I'll stick this into the tdx branch tomorrow unless someone has stronger
feelings about it.
On 9/29/23 11:33, Kees Cook wrote:
> On Mon, 11 Sep 2023 18:27:25 +, Justin Stitt wrote:
>> `strncpy` is deprecated and we should prefer more robust string apis.
>>
>> In this case, `message.str` is not expected to be NUL-terminated as it
>> is simply a buffer of characters residing in a union
15 matches
Mail list logo
