On Thu, 17 Apr 2025 at 15:12, Coly Li wrote:
>
>
>
> > 2025年4月17日 15:10，Kees Cook 写道：
> >
> >
> >
> > On April 16, 2025 11:16:45 PM PDT, Ard Biesheuvel wrote:
> >> On Thu, 17 Apr 2025 at 00:01, Kees Cook wrote:
> >>>
> >>&g
On Thu, 17 Apr 2025 at 00:01, Kees Cook wrote:
>
> GCC 15's new -Wunterminated-string-initialization notices that the 16
> character lookup table "zero_uuid" (which is not used as a C-String)
> needs to be marked as "nonstring":
>
> drivers/md/bcache/super.c: In function 'uuid_find_empty':
> drive
t; Suggested-by: Arnd Bergmann
> Link:
> https://lore.kernel.org/all/08393aa3-05a3-4e3f-8004-f374a3ec4...@app.fastmail.com/
> [1]
> Signed-off-by: Kees Cook
> ---
> Cc: Ard Biesheuvel
> Cc: Chris Packham
> Cc: Douglas Anderson
> Cc: Russell King
> Cc: Masahiro Ya
On Tue, 18 Mar 2025 at 14:50, Ard Biesheuvel wrote:
>
> From: Ard Biesheuvel
>
> Since commit
>
> 97d6786e0669 ("arm64: mm: account for hotplug memory when randomizing the
> linear region")
>
> the decision whether or not to randomize the placement of the
From: Ard Biesheuvel
Since commit
97d6786e0669 ("arm64: mm: account for hotplug memory when randomizing the
linear region")
the decision whether or not to randomize the placement of the system's
DRAM inside the linear map is based on the capabilities of the CPU
rather than
On Wed, 22 Jan 2025 at 13:25, Joel Granados wrote:
>
> On Tue, Jan 21, 2025 at 02:40:16PM +0100, Alexander Gordeev wrote:
> > On Fri, Jan 10, 2025 at 03:16:08PM +0100, Joel Granados wrote:
> >
> > Hi Joel,
> >
> > > Add the const qualifier to all the ctl_tables in the tree except for
> > > watchdo
On Wed, 16 Oct 2024 at 04:10, Nathan Chancellor wrote:
>
> On Tue, Oct 15, 2024 at 12:56:57PM +0200, Ard Biesheuvel wrote:
> > On Mon, 14 Oct 2024 at 22:59, Kees Cook wrote:
> > >
> > > On Wed, Oct 09, 2024 at 02:43:53PM +0200, Ard Biesheuvel wrote:
> > >
On Mon, 14 Oct 2024 at 22:59, Kees Cook wrote:
>
> On Wed, Oct 09, 2024 at 02:43:53PM +0200, Ard Biesheuvel wrote:
> > However, if a non-TLS definition of the symbol in question is visible in
> > the same compilation unit (which amounts to the whole of vmlinux if LTO
> > i
On Mon, 14 Oct 2024 at 06:28, Eric Biggers wrote:
>
> On Fri, Oct 11, 2024 at 07:08:54PM +0200, Ard Biesheuvel wrote:
> > diff --git a/arch/x86/crypto/crc32c-pcl-intel-asm_64.S
> > b/arch/x86/crypto/crc32c-pcl-intel-asm_64.S
> > index bbcff1fb78cb..45b005935194 100644
&
From: Ard Biesheuvel
Tweak the asm crc32c asm code so that the jump table is more difficult
to decipher for objtool:
- load the address in the prologue
- move the jump table to the middle of .rodata, so that the section
offset and the symbol offset differ
- emit an entry following the jump
From: Ard Biesheuvel
Annotate the indirect jump with a relocation that correlates it with the
jump table emitted into .rodata. This helps objtool identify the jump
table, allowing it to infer the places in the code that are reachable
from the jump.
Signed-off-by: Ard Biesheuvel
---
arch/x86
From: Ard Biesheuvel
The original crc32c code used a place-relative jump table but with a
slightly awkward use of two separate symbols. To help objtool, this was
replaced with a bog-standard position dependent jump table call, which
was subsequently tweaked to use a RIP-relative reference to the
From: Ard Biesheuvel
Refactor the jump table handling code so that a generic code path is
provided that can identify jump tables attached to indirect jumps based
only on compiler provided annotations. This will be used by non-x86
architectures which do not support jump tables at all at this
From: Ard Biesheuvel
In preparation for implementing support for the use of compiler emitted
jump table annotations, move the existing code out of the generic
sources. This will permit a clean separation between the two approaches,
where the old one will not be wired up for architectures other
From: Ard Biesheuvel
Move some helpers around so they can be used from arch specific jump
table code that is getting refactored in the next patch.
Signed-off-by: Ard Biesheuvel
---
tools/objtool/check.c | 22
tools/objtool/include/objtool/check.h | 16
From: Ard Biesheuvel
In preparation for adding support for annotated jump tables, where
ELF relocations and symbols are used to describe the locations of jump
tables in the executable, refactor the jump table discovery logic so the
table size can be returned from arch_find_switch_table
From: Ard Biesheuvel
Relative jump tables contain entries that carry the offset between the
target of the jump and the start of the jump table. This permits the use
of the PIC idiom of
leaqjump_table(%rip), %tbl
movslq (%tbl,%idx,4), %offset
addq%offset, %tbl
jmp
From: Ard Biesheuvel
Jump table handling has faded into the background a little due to the
fact that jump tables are [currently] disabled when enabling retpoline
mitigations and/or IBT on x86.
However, this is likely to come back and bite us later, so it still
needs to be addressed. Given the
On Thu, 10 Oct 2024 at 21:52, Josh Poimboeuf wrote:
>
> On Thu, Oct 10, 2024 at 02:28:04PM +0200, Ard Biesheuvel wrote:
> > @@ -,7 +2234,6 @@ static void mark_func_jump_tables(struct objtool_file
> > *file,
> > struct symbol *func)
On Fri, 11 Oct 2024 at 18:05, Josh Poimboeuf wrote:
>
> On Fri, Oct 11, 2024 at 08:32:33AM +0200, Ard Biesheuvel wrote:
> > On Thu, 10 Oct 2024 at 22:34, Josh Poimboeuf wrote:
> > >
> > > On Thu, Oct 10, 2024 at 02:28:07PM +0200, Ard Biesheuvel wrote
On Thu, 10 Oct 2024 at 22:34, Josh Poimboeuf wrote:
>
> On Thu, Oct 10, 2024 at 02:28:07PM +0200, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel
> >
> > Tweak the jump table so
> > - the address is taken far way from its use
> > - its offset from the start of
On Thu, 10 Oct 2024 at 22:15, Josh Poimboeuf wrote:
>
> On Thu, Oct 10, 2024 at 02:28:05PM +0200, Ard Biesheuvel wrote:
> > +++ b/tools/objtool/arch/x86/special.c
> > @@ -115,30 +115,51 @@ struct reloc *arch_find_switch_table(struct
> > objtool_file *file,
> >
On Thu, 10 Oct 2024 at 14:28, Ard Biesheuvel wrote:
>
> From: Ard Biesheuvel
>
> Jump table handling has faded into the background a little due to the
> fact that jump tables are [currently] disabled when enabling retpoline
> mitigations and/or IBT on x86.
>
> However
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
> > index 3cb3e9b5ad0b..7f7981a93535 100644
> > --- a/tools/objtool/check.c
> &g
From: Ard Biesheuvel
Tweak the jump table so
- the address is taken far way from its use
- its offset from the start of .rodata is != 0x0
- its type is STT_OBJECT and its size is set to the size of the actual
table
- the indirect jump is annotated with a R_X86_64_NONE relocation
pointing to
From: Ard Biesheuvel
The original crc32c code used a place-relative jump table but with a
slightly awkward use of two separate symbols. To help objtool, this was
replaced with a bog-standard position dependent jump table call, which
was subsequently tweaked to use a RIP-relative reference to the
From: Ard Biesheuvel
Add logic to follow R_X86_64_NONE relocations attached to indirect
jumps, which are emitted to annotate jump tables, which are otherwise
difficult to spot reliably.
If an ELF symbol is associated with the jump table, its size is taken as
the size of the jump table, and
From: Ard Biesheuvel
In preparation for adding support for annotated jump tables, where
ELF relocations and symbols are used to describe the locations of jump
tables in the executable, refactor the jump table discovery logic so the
table size can be returned from arch_find_switch_table
From: Ard Biesheuvel
Relative jump tables contain entries that carry the offset between the
target of the jump and the start of the jump table. This permits the use
of the PIC idiom of
leaqjump_table(%rip), %tbl
movslq (%tbl,%idx,4), %offset
addq%offset, %tbl
jmp
From: Ard Biesheuvel
Jump table handling has faded into the background a little due to the
fact that jump tables are [currently] disabled when enabling retpoline
mitigations and/or IBT on x86.
However, this is likely to come back and bite us later, so it still
needs to be addressed. Given the
On Tue, 8 Oct 2024 at 19:42, Josh Poimboeuf wrote:
>
> On Tue, Oct 08, 2024 at 12:47:48AM +0200, Ard Biesheuvel wrote:
> > - /*
> > - * Use of RIP-relative switch jumps is quite rare, and
> > - * indicates a rare GCC quirk/bug which can leave dead
From: Ard Biesheuvel
GCC and Clang both implement stack protector support based on Thread
Local Storage (TLS) variables, and this is used in the kernel to
implement per-task stack cookies, by copying a task's stack cookie into
a per-CPU variable every time it is scheduled in.
Both now
On Fri, 9 Aug 2024 at 21:17, 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, use the `DEFINE_FLEX()` helper for multiple on-stack definitions
> of flexible structures where the size of their flexible
On Fri, 26 Jul 2024 at 11:11, Adrian Ratiu wrote:
>
> This adds a Kconfig option and boot param to allow removing
> the FOLL_FORCE flag from /proc/pid/mem write calls because
> it can be abused.
>
> The traditional forcing behavior is kept as default because
> it can break GDB and some other use c
On Thu, 13 Jun 2024 at 15:26, Steven Rostedt wrote:
>
> On Thu, 13 Jun 2024 08:11:48 +0200
> Ard Biesheuvel wrote:
> > >
> > > I've added one more comment to v5, with that fixed I can take this.
> > >
> >
> > So how is this supposed to work wr
On Thu, 13 Jun 2024 at 08:04, Mike Rapoport wrote:
>
> On Wed, Jun 12, 2024 at 02:52:28PM -0400, Steven Rostedt wrote:
> > On Wed, 12 Jun 2024 11:45:57 -0700
> > Kees Cook wrote:
> >
> > > On Tue, Jun 11, 2024 at 10:49:13AM -0400, Steven Rostedt wrote:
> > > > From: "Steven Rostedt (Google)"
> >
On Tue, 4 Jun 2024 at 01:35, Steven Rostedt wrote:
>
> From: "Steven Rostedt (Google)"
>
> In order to allow for requesting a memory region that can be used for
> things like pstore on multiple machines where the memory layout is not the
> same, add a new option to the kernel command line called
On Wed, 1 May 2024 at 16:59, Mike Rapoport wrote:
>
> On Mon, Apr 15, 2024 at 10:22:53AM -0700, Kees Cook wrote:
> > On Fri, Apr 12, 2024 at 06:19:40PM -0400, Steven Rostedt wrote:
> > > On Fri, 12 Apr 2024 23:59:07 +0300
> > > Mike Rapoport wrote:
> > >
> > > > On Tue, Apr 09, 2024 at 04:41:24PM
From: Ard Biesheuvel
The .head.text section carries the startup code that runs with the MMU
off or with a translation of memory that deviates from the ordinary one.
So avoid instrumentation with the stackleak plugin, which already avoids
.init.text and .noinstr.text entirely.
Fixes
On Thu, 21 Mar 2024 at 12:24, Russell King (Oracle)
wrote:
>
> On Thu, Mar 21, 2024 at 10:22:30AM +, David Laight wrote:
> > How aggressively does the compiler optimise 'noreturn' functions?
>
> I've seen cases where the compiler emits a BL instruction as the very
> last thing in the function,
On Thu, 25 Jan 2024 at 19:00, Kees Cook wrote:
>
> On Thu, Jan 25, 2024 at 01:19:19PM +0100, Ard Biesheuvel wrote:
> > On Wed, 24 Jan 2024 at 00:47, Kees Cook wrote:
> > >
> > > Recent versions of Clang gets confused about the possible size of th
On Wed, 24 Jan 2024 at 00:47, Kees Cook wrote:
>
> Recent versions of Clang gets confused about the possible size of the
> "user" allocation, and CONFIG_FORTIFY_SOURCE ends up emitting a
> warning[1]:
>
> repro.c:126:4: warning: call to '__write_overflow_field' declared with
> 'warning' attribute
On Tue, 23 Jan 2024 at 02:12, Kees Cook wrote:
>
> The common pattern in arm is to emit a "8<--- cut here ---" line for
> faults, but it was missing for do_PrefetchAbort(). Add it.
>
> Cc: "Russell King (Oracle)"
> Cc: Ard Biesheuvel
> Cc: Wang Kefe
ress. Make sure copy_from_kernel_nofault() does not attempt this
> any more.
>
> Reported-by: Mark Brown
> Link: https://lore.kernel.org/all/202401181125.D48DCB4C@keescook/ [1]
> Suggested-by: "Russell King (Oracle)"
> Cc: Russell King
> Cc: Ard Biesheuvel
> Cc: Wang Kefeng
>
(cc Kees, LAKML)
https://lkml.kernel.org/r/69fa6015256613ed10aee996e181ebd4%40horotw.com
On Mon, 15 Jan 2024 at 21:46, Matthew Wilcox wrote:
>
...
> Yeah, I don't know either. Outside my scope of expertise.
>
> I received a suggestion off-list that we only do the PMD alignment on
> 64-bit, whic
45 matches
Mail list logo
