On Sun, Nov 12, 2023 at 09:23:24PM -0500, Mickaël Salaün wrote:
> From: Madhavan T. Venkataraman
>
> X86 uses a function called __text_poke() to modify executable code. This
> patching function is used by many features such as KProbes and FTrace.
>
> Update the permissions counters for the text
On Sun, Nov 12, 2023 at 09:23:25PM -0500, Mickaël Salaün wrote:
> From: Madhavan T. Venkataraman
>
> Implement a hypervisor function, kvm_protect_memory() that calls the
> KVM_HC_PROTECT_MEMORY hypercall to request the KVM hypervisor to
> set specified permissions on a list of guest pages.
>
> U
On Mon, Nov 27, 2023 at 11:05:23AM -0600, Madhavan T. Venkataraman wrote:
> Apologies for the late reply. I was on vacation. Please see my response below:
>
> On 11/13/23 02:54, Peter Zijlstra wrote:
> > On Sun, Nov 12, 2023 at 09:23:25PM -0500, Mickaël Salaün wrote:
> &
On Mon, Nov 27, 2023 at 10:48:29AM -0600, Madhavan T. Venkataraman wrote:
> Apologies for the late reply. I was on vacation. Please see my response below:
>
> On 11/13/23 02:19, Peter Zijlstra wrote:
> > On Sun, Nov 12, 2023 at 09:23:24PM -0500, Mickaël Salaün wrote:
> &
On Wed, Nov 29, 2023 at 03:07:15PM -0600, Madhavan T. Venkataraman wrote:
> Kernel Lockdown
> ---
>
> But, we must provide at least some security in V2. Otherwise, it is useless.
>
> So, we have implemented what we call a kernel lockdown. At the end of kernel
> boot, Heki establishes
On Wed, Dec 06, 2023 at 10:37:33AM -0600, Madhavan T. Venkataraman wrote:
>
>
> On 11/30/23 05:33, Peter Zijlstra wrote:
> > On Wed, Nov 29, 2023 at 03:07:15PM -0600, Madhavan T. Venkataraman wrote:
> >
> >> Kernel Lockdown
> >> ---
>
On Wed, Apr 24, 2024 at 12:17:34PM -0700, Kees Cook wrote:
> @@ -82,7 +83,7 @@ static __always_inline bool arch_atomic_add_negative(int i,
> atomic_t *v)
>
> static __always_inline int arch_atomic_add_return(int i, atomic_t *v)
> {
> - return i + xadd(&v->counter, i);
> + return wrapp
On Thu, Apr 25, 2024 at 12:41:41AM +0200, Peter Zijlstra wrote:
> On Wed, Apr 24, 2024 at 12:17:34PM -0700, Kees Cook wrote:
>
> > @@ -82,7 +83,7 @@ static __always_inline bool arch_atomic_add_negative(int
> > i, atomic_t *v)
> >
> > static __always_inline in
On Wed, Apr 24, 2024 at 03:45:07PM -0700, Kees Cook wrote:
> On Thu, Apr 25, 2024 at 12:41:41AM +0200, Peter Zijlstra wrote:
> > On Wed, Apr 24, 2024 at 12:17:34PM -0700, Kees Cook wrote:
> >
> > > @@ -82,7 +83,7 @@ static __always_inline bool
> > > arch_atomi
On Thu, Apr 25, 2024 at 12:54:36AM +0200, Peter Zijlstra wrote:
> On Wed, Apr 24, 2024 at 03:45:07PM -0700, Kees Cook wrote:
> > On Thu, Apr 25, 2024 at 12:41:41AM +0200, Peter Zijlstra wrote:
> > > On Wed, Apr 24, 2024 at 12:17:34PM -0700, Kees Cook wrote:
> > >
>
On Wed, Apr 24, 2024 at 04:20:20PM -0700, Kees Cook wrote:
> > This is arse-about-face. Signed stuff wraps per -fno-strict-overflow.
> > We've been writing code for years under that assumption.
>
> Right, which is why this is going to take time to roll out. :) What we
> were really doing with -fn
On Wed, Apr 24, 2024 at 04:30:50PM -0700, Kees Cook wrote:
> > That is, anything that actively warns about signed overflow when build
> > with -fno-strict-overflow is a bug. If you want this warning you have to
> > explicitly mark things.
>
> This is confusing UB with "overflow detection". We're
On Mon, Apr 29, 2024 at 07:40:58PM +0200, Erick Archer wrote:
> This is an effort to get rid of all multiplications from allocation
> functions in order to prevent integer overflows [1][2].
So personally I detest struct_size() because I can never remember wtf it
does, whereas the code it replaces
On Mon, Apr 29, 2024 at 10:18:03AM -0700, Kees Cook wrote:
> Peter and Ingo, you seem to traditionally take these changes (via -tip)?
> Can you please pick this up?
I have been explicitly not taking these things for perf and sched for a
while now. As I wrote in that other mail, I detest struct_si
On Fri, Apr 26, 2024 at 03:29:44PM -0700, Kees Cook wrote:
> - CONFIG_CFI_CLANG=y for x86 and arm64. (And disable FINEIBT since
> it isn't as secure as straight KCFI.)
Oi ?
On Tue, Apr 30, 2024 at 10:48:36AM -0700, Kees Cook wrote:
> On Tue, Apr 30, 2024 at 11:21:40AM +0200, Peter Zijlstra wrote:
> > On Fri, Apr 26, 2024 at 03:29:44PM -0700, Kees Cook wrote:
> >
> > > - CONFIG_CFI_CLANG=y for x86 and arm64. (And disable FINEIBT since
>
On Wed, May 01, 2024 at 01:21:42PM -0700, Kees Cook wrote:
> On Tue, Apr 30, 2024 at 11:15:04AM +0200, Peter Zijlstra wrote:
> > On Mon, Apr 29, 2024 at 07:40:58PM +0200, Erick Archer wrote:
> > > This is an effort to get rid of all multiplications from allocation
> >
elp find the root cause more easily. Additionally,
> this serves as a data corruption indicator that system owners using
> warn_limit or panic_on_warn would like to have detected.
>
> Link:
> https://lore.kernel.org/lkml/7c41cf3c-2a71-4dbb-8f34-033789090...@gmail.com/
> [1]
On Wed, May 08, 2024 at 04:47:25PM -0700, Linus Torvalds wrote:
> For example, the most common case of overflow we've ever had has very
> much been array indexing. Now, sometimes that has actually been actual
> undefined behavior, because it's been overflow in signed variables,
> and those are "eas
On Wed, May 08, 2024 at 04:47:25PM -0700, Linus Torvalds wrote:
> Now, another thing to do might be to treat assignments (and again,
> implicit casts) to 'size_t' specially. In most compilers (certainly in
> gcc), "size_t" is a special type.
>
> Now, in the kernel, we don't actually use __builtin
On Wed, May 15, 2024 at 10:12:20AM -0700, Justin Stitt wrote:
> Hi Peter,
>
> On Wed, May 15, 2024 at 12:36 AM Peter Zijlstra wrote:
> >
> > On Wed, May 08, 2024 at 04:47:25PM -0700, Linus Torvalds wrote:
> > > For example, the most common case of overflow we'v
On Thu, May 16, 2024 at 06:30:32AM -0700, Kees Cook wrote:
>
>
> On May 15, 2024 12:36:36 AM PDT, Peter Zijlstra wrote:
> >On Wed, May 08, 2024 at 04:47:25PM -0700, Linus Torvalds wrote:
> >> For example, the most common case of overflow we've ever had has very
ave decided to send these three patches in the same serie
> > since all of them has been rejected by the maintainers. I have used
> > the v4 tag since it is the latest iteration in one of the patches.
> >
> > The reason these patches were rejected is that Peter Zijlstra dete
On Mon, Jun 10, 2024 at 10:28:52AM -0700, Kees Cook wrote:
> On Sat, Jun 01, 2024 at 06:56:15PM +0200, Erick Archer wrote:
> > Hi everyone,
> >
> > This is an effort to get rid of all multiplications from allocation
> > functions in order to prevent integer overflows [1][2].
>
> I didn't actually
On Mon, Jun 10, 2024 at 02:46:09PM -0700, Kees Cook wrote:
> > I really detest this thing because it makes what was trivially readable
> > into something opaque. Get me that type qualifier that traps on overflow
> > and write plain C. All this __builtin_overflow garbage is just that,
> > unreadabl
On Wed, Jun 12, 2024 at 12:01:19PM -0700, Kees Cook wrote:
> On Tue, Jun 11, 2024 at 09:55:42AM +0200, Peter Zijlstra wrote:
> > On Mon, Jun 10, 2024 at 02:46:09PM -0700, Kees Cook wrote:
> >
> > > > I really detest this thing because it makes what was trivially read
On Wed, Jun 12, 2024 at 04:23:31PM -0700, Kees Cook wrote:
> On Thu, Jun 13, 2024 at 12:08:21AM +0200, Peter Zijlstra wrote:
> > On Wed, Jun 12, 2024 at 12:01:19PM -0700, Kees Cook wrote:
> > > I'm happy to take patches. And for this bikeshed, this would be better
>
On Mon, Jun 17, 2024 at 10:28:20AM -0700, Kees Cook wrote:
> But, using type attributes we have much more flexibility. Hence, the
> proposed "wraps" attribute:
> https://github.com/llvm/llvm-project/pull/86618
So I still think that's going about things backwards.
unsigned explicitly wraps. signe
On Mon, Jun 17, 2024 at 10:19:15AM -0700, Kees Cook wrote:
> On Fri, Jun 14, 2024 at 12:17:08PM +0200, Peter Zijlstra wrote:
> > On Wed, Jun 12, 2024 at 04:23:31PM -0700, Kees Cook wrote:
> > > On Thu, Jun 13, 2024 at 12:08:21AM +0200, Peter Zijlstra wrote:
> > > >
On Tue, Jun 25, 2024 at 03:24:55AM +, Gatlin Newhouse wrote:
> Currently ARM architectures output which specific sanitizer caused
> the trap, via the encoded data in the trap instruction. Clang on
> x86 currently encodes the same data in ud1 instructions but the x86
> handle_bug() and is_valid_
On Wed, Jun 26, 2024 at 12:07:52PM -0700, Kees Cook wrote:
> On Tue, Jun 25, 2024 at 11:37:19AM +0200, Peter Zijlstra wrote:
> > Also, wouldn't it be saner to write this something like:
> >
> > __always_inline int decode_bug(unsigned long addr, u32 *imm)
> > {
>
On Mon, Jun 24, 2024 at 05:58:59AM +, Dhananjay Ugwekar wrote:
> diff --git a/arch/x86/events/rapl.c b/arch/x86/events/rapl.c
> index b985ca79cf97..73be25e1f4b4 100644
> --- a/arch/x86/events/rapl.c
> +++ b/arch/x86/events/rapl.c
> @@ -103,6 +103,10 @@ static struct perf_pmu_events_att
On Mon, Jun 24, 2024 at 05:59:02AM +, Dhananjay Ugwekar wrote:
> This patch is in preparation for addition of per-core energy counter
> support for AMD CPUs.
>
> Per-core energy counter PMU will need a separate cpumask. It seems like
> a better approach to add the cpumask inside the rapl_pmus
On Mon, Jun 24, 2024 at 05:59:05AM +, Dhananjay Ugwekar wrote:
> Prep for addition of power_per_core PMU to handle core scope energy
> consumption for AMD CPUs.
>
> Replace the generic names with *_pkg*, to differentiate between the
> scopes of the two different PMUs and their variables.
But
On Fri, Jul 05, 2024 at 02:18:30AM +, Zhang, Rui wrote:
> > > > I have a doubt about this, won't the future Intel multi-die
> > > > systems
> > > > have die-scope for the RAPL PMU like Casecadelake-AP?
> > >
> > > For future multi-die systems that I know, the RAPL is still package
> > > scop
On Wed, Jul 10, 2024 at 08:32:38PM +, Gatlin Newhouse wrote:
> Currently ARM architectures extract which specific sanitizer
> has caused a trap via encoded data in the trap instruction.
> Clang on x86 currently encodes the same data in ud1 instructions
> but the x86 handle_bug() and is_valid_bu
On Thu, Jul 11, 2024 at 09:35:24AM -0700, Kees Cook wrote:
> On Thu, Jul 11, 2024 at 11:06:12AM +0200, Marco Elver wrote:
> > On Thu, 11 Jul 2024 at 10:10, Peter Zijlstra wrote:
> > >
> > > On Wed, Jul 10, 2024 at 08:32:38PM +, Gatlin Newhouse wrote:
> >
On Mon, Jul 08, 2024 at 01:22:06PM -0700, Kees Cook wrote:
> Modern (fortified) memcpy() prefers to avoid writing (or reading) beyond
> the end of the addressed destination (or source) struct member:
>
> In function ‘fortify_memcpy_chk’,
> inlined from ‘syscall_get_arguments’ at
> ./arch/x86/
On Thu, Jul 11, 2024 at 04:10:43PM -0700, Kees Cook wrote:
> The long answer is long, and comes in two halves: the language half and
> the fortify half.
>
> First, the C standard requires that all function argument arrays be
> decayed to pointers, so your prototype is semantically handled as if
>
On Fri, Jul 12, 2024 at 10:55:16AM -0700, Kees Cook wrote:
> > What will actually break if you 'fix' this? Given that inlining (see
> > below) changes the rules willy nilly, I feel we can (and should!) just
> > fix this.
>
> I'm not sure -- I have kind of given up on "standard" C helping with any
e UD1Lm template, which uses a
> OpSize32. See:
> https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/X86InstrSystem.td#L27
>
> Signed-off-by: Gatlin Newhouse
> ---
This will do I suppose,
Acked-by: Peter Zijlstra (Intel)
> ---
> MAINTAINERS |
On Mon, Aug 05, 2024 at 04:42:35PM -0600, Gustavo A. R. Silva wrote:
> -Wflex-array-member-not-at-end was introduced in GCC-14, and we are
> getting ready to enable it, globally.
>
> So, in order to avoid ending up with a flexible-array member in the
> middle of multiple other structs, we use the
On Tue, Aug 06, 2024 at 12:59:41PM +0200, Peter Zijlstra wrote:
> On Mon, Aug 05, 2024 at 04:42:35PM -0600, Gustavo A. R. Silva wrote:
> > -Wflex-array-member-not-at-end was introduced in GCC-14, and we are
> > getting ready to enable it, globally.
> >
> > So, in orde
On Thu, Oct 10, 2024 at 02:28:03PM +0200, Ard Biesheuvel wrote:
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index 3cb3e9b5ad0b..7f7981a93535 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -2101,6 +2101,8 @@ static int add_jump_table(struct objtool_file *f
On Thu, Oct 10, 2024 at 03:59:43PM +0200, Ard Biesheuvel wrote:
> On Thu, 10 Oct 2024 at 15:26, Peter Zijlstra wrote:
> >
> > On Thu, Oct 10, 2024 at 02:28:03PM +0200, Ard Biesheuvel wrote:
> > > diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> > >
On Fri, Dec 06, 2024 at 10:11:06AM +, Kevin Brodsky wrote:
> If CONFIG_KPKEYS_HARDENED_PGTABLES is enabled, map p4d/pgd pages
> using a privileged pkey (KPKEYS_PKEY_PGTABLES), so that they can
> only be written under guard(kpkeys_hardened_pgtables).
>
> The case where pgd is not page-sized is
On Fri, Dec 06, 2024 at 10:11:07AM +, Kevin Brodsky wrote:
> Page table pages are typically freed via tlb_remove_table() and
> friends. Ensure that the linear mapping for those pages is reset to
> the default pkey when CONFIG_KPKEYS_HARDENED_PGTABLES is enabled.
>
> This patch is a no-op if CO
On Fri, Dec 06, 2024 at 10:11:02AM +, Kevin Brodsky wrote:
> kernel_pgtables_set_pkey() allows setting the pkey of all page table
> pages in swapper_pg_dir, recursively. This will be needed by
> kpkeys_hardened_pgtables, as it relies on all PTPs being mapped with
> a non-default pkey. Those ini
On Tue, Dec 10, 2024 at 10:27:56AM +0100, Kevin Brodsky wrote:
> On 09/12/2024 11:24, Peter Zijlstra wrote:
> > On Fri, Dec 06, 2024 at 10:11:06AM +, Kevin Brodsky wrote:
> >> If CONFIG_KPKEYS_HARDENED_PGTABLES is enabled, map p4d/pgd pages
> >> using a privileged
On Tue, Dec 10, 2024 at 10:28:44AM +0100, Kevin Brodsky wrote:
> On 09/12/2024 11:29, Peter Zijlstra wrote:
> > On Fri, Dec 06, 2024 at 10:11:07AM +, Kevin Brodsky wrote:
> >> [...]
> >>
> >> diff --git a/arch/arm64/include/asm/tlb.h b/arch/arm64/inclu
On Fri, Feb 14, 2025 at 10:57:51AM +0100, Peter Zijlstra wrote:
> On Thu, Feb 13, 2025 at 12:53:28PM -0800, Kees Cook wrote:
>
> > Right, the "if they can control a function pointer" is the part I'm
> > focusing on. This attack depends on making an indirect call w
On Thu, Feb 13, 2025 at 12:53:28PM -0800, Kees Cook wrote:
> Right, the "if they can control a function pointer" is the part I'm
> focusing on. This attack depends on making an indirect call with a
> controlled pointer. Non-FineIBT CFI will protect against that step,
> so I think this is only an i
On Thu, Feb 13, 2025 at 01:31:30AM +, Andrew Cooper wrote:
> But, FRED support is slated for PantherLake/DiamondRapids which haven't
> shipped yet, so are no use to the problem right now.
FRED also fixes this IBT 'oopsie' IIRC.
On Thu, Feb 13, 2025 at 08:41:16PM +, Andrew Cooper wrote:
> The problem is that SYSCALL entry/exit is a toxic operating mode,
> because you only have to think about sneezing and another user->kernel
> priv-esc appears.
For a very brief moment I thought we could leave out the ENDBR there and
On Sun, Feb 16, 2025 at 03:51:27PM -0800, Kees Cook wrote:
> On Sat, Feb 15, 2025 at 10:07:29PM +0100, Peter Zijlstra wrote:
> > On Fri, Feb 14, 2025 at 10:57:51AM +0100, Peter Zijlstra wrote:
> > > On Thu, Feb 13, 2025 at 12:53:28PM -0800, Kees Cook wrote:
> > >
>
On Mon, Feb 17, 2025 at 01:06:29PM +, David Laight wrote:
> On Sat, 15 Feb 2025 22:07:29 +0100
> Peter Zijlstra wrote:
>
> > On Fri, Feb 14, 2025 at 10:57:51AM +0100, Peter Zijlstra wrote:
> > > On Thu, Feb 13, 2025 at 12:53:28PM -0800, Kees Cook wrote:
> > &g
On Mon, Feb 17, 2025 at 06:38:27PM +, David Laight wrote:
> I may not have retpolines enabled, a typical call site is (from vmlinux.o):
Make sure CONFIG_FINEIBT=y, otherwise there is no point in talking about
this. This requires KERNEL_IBT=y RETPOLINE=y CALL_PADDING=y CFI_CLANG=y.
Then look
On Wed, Mar 05, 2025 at 11:13:00PM -0800, Kees Cook wrote:
> On Wed, Mar 05, 2025 at 02:43:15PM +0100, Peter Zijlstra wrote:
> > Hi Kees,
> >
> > I keep getting hit by the struct_size() brigade, and I keep having
> > trouble reading that macro.
> >
> >
58 matches
Mail list logo
