lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20260112102957.359c8de904b11dc23cffd575@linux-foundation.org>
Date: Mon, 12 Jan 2026 10:29:57 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Maciej Wieczor-Retman <m.wieczorretman@...me>
Cc: corbet@....net, morbo@...gle.com, rppt@...nel.org,
 lorenzo.stoakes@...cle.com, ubizjak@...il.com, mingo@...hat.com,
 vincenzo.frascino@....com, maciej.wieczor-retman@...el.com, maz@...nel.org,
 catalin.marinas@....com, yeoreum.yun@....com, will@...nel.org,
 jackmanb@...gle.com, samuel.holland@...ive.com, glider@...gle.com,
 osandov@...com, nsc@...nel.org, luto@...nel.org, jpoimboe@...nel.org,
 Liam.Howlett@...cle.com, kees@...nel.org, jan.kiszka@...mens.com,
 thomas.lendacky@....com, jeremy.linton@....com, dvyukov@...gle.com,
 axelrasmussen@...gle.com, leitao@...ian.org, ryabinin.a.a@...il.com,
 bigeasy@...utronix.de, peterz@...radead.org, mark.rutland@....com,
 urezki@...il.com, brgerst@...il.com, hpa@...or.com, mhocko@...e.com,
 andreyknvl@...il.com, weixugc@...gle.com, kbingham@...nel.org,
 vbabka@...e.cz, nathan@...nel.org, trintaeoitogc@...il.com,
 samitolvanen@...gle.com, tglx@...nel.org, thuth@...hat.com,
 surenb@...gle.com, anshuman.khandual@....com, smostafa@...gle.com,
 yuanchu@...gle.com, ada.coupriediaz@....com, dave.hansen@...ux.intel.com,
 kas@...nel.org, nick.desaulniers+lkml@...il.com, david@...nel.org,
 bp@...en8.de, ardb@...nel.org, justinstitt@...gle.com,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 kasan-dev@...glegroups.com, llvm@...ts.linux.dev,
 linux-arm-kernel@...ts.infradead.org, linux-doc@...r.kernel.org,
 linux-kbuild@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH v8 00/14] kasan: x86: arm64: KASAN tag-based mode for
 x86

On Mon, 12 Jan 2026 17:26:29 +0000 Maciej Wieczor-Retman <m.wieczorretman@...me> wrote:

> The patchset aims to add a KASAN tag-based mode for the x86 architecture
> with the help of the new CPU feature called Linear Address Masking
> (LAM). Main improvement introduced by the series is 2x lower memory
> usage compared to KASAN's generic mode, the only currently available
> mode on x86. The tag based mode may also find errors that the generic
> mode couldn't because of differences in how these modes operate.

Well this is a hearty mixture of arm, x86 and MM.  I guess that means
mm.git.

The review process seems to be proceeding OK so I'll add this to
mm.git's mm-new branch, which is not included in linux-next.  I'll aim
to hold it there for a week while people check the patches over and
send out their acks (please).  Then I hope I can move it into mm.git's
mm-unstable branch where it will receive linux-next exposure.

> [1] Currently inline mode doesn't work on x86 due to things missing in
> the compiler. I have written a patch for clang that seems to fix the
> inline mode and I was able to boot and check that all patches regarding
> the inline mode work as expected. My hope is to post the patch to LLVM
> once this series is completed, and then make inline mode available in
> the kernel config.
> 
> [2] While I was able to boot the inline tag-based kernel with my
> compiler changes in a simulated environment, due to toolchain
> difficulties I couldn't get it to boot on the machine I had access to.
> Also boot time results from the simulation seem too good to be true, and
> they're much too worse for the generic case to be believable. Therefore
> I'm posting only results from the physical server platform.
> 
> ======= Compilation
> Clang was used to compile the series (make LLVM=1) since gcc doesn't
> seem to have support for KASAN tag-based compiler instrumentation on
> x86.

OK, known issues and they are understandable.  With this patchset is
there any way in which our testers can encounter these things?  If so
can we make changes to protect them from hitting known issues?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ