[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e88870bf-b232-4fdf-816a-32128d3791f8@infradead.org>
Date: Tue, 20 May 2025 08:48:24 -0700
From: Randy Dunlap <rdunlap@...radead.org>
To: Mickaël Salaün <mic@...ikod.net>,
Kees Cook <kees@...nel.org>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Linux Next Mailing List <linux-next@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-security-module@...r.kernel.org, Günther Noack
<gnoack@...gle.com>
Subject: Re: linux-next: Tree for May 16 (security/landlock/ruleset.c)
On 5/20/25 7:45 AM, Mickaël Salaün wrote:
> On Mon, May 19, 2025 at 12:15:30PM -0700, Kees Cook wrote:
>> On Mon, May 19, 2025 at 08:41:17PM +0200, Mickaël Salaün wrote:
>>> On Mon, May 19, 2025 at 11:19:53AM -0700, Kees Cook wrote:
>>>> On Mon, May 19, 2025 at 05:29:30PM +0200, Mickaël Salaün wrote:
>>>>> On Fri, May 16, 2025 at 07:54:14PM -0700, Randy Dunlap wrote:
>>>>>>
>>>>>>
>>>>>> On 5/16/25 3:24 AM, Stephen Rothwell wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Changes since 20250515:
>>>>>
>>>>> Thanks for the report.
>>>>>
>>>>> It is the same warning as reported here:
>>>>> https://lore.kernel.org/all/202501040747.S3LYfvYq-lkp@intel.com/
>>>>>
[snip]
>>>
>>>>
>>>>
>>>> I'll take a look at ways to make either the overflow macros or memcpy
>>>> robust against this kind of weirdness...
>>>
>>> Thanks!
>>
>> I'm doing some build testing, but the below patch makes GCC happy.
>> Alternatively we could make CONFIG_PROFILE_ALL_BRANCHES=y depend on
>> CONFIG_FORTIFY_SOURCE=y ...
>>
>>
>> From 6fbf66fdfd0a7dac809b77faafdd72c60112bb8d Mon Sep 17 00:00:00 2001
>> From: Kees Cook <kees@...nel.org>
>> Date: Mon, 19 May 2025 11:52:06 -0700
>> Subject: [PATCH] string.h: Provide basic sanity checks for fallback memcpy()
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 8bit
>>
>> Instead of defining memcpy() in terms of __builtin_memcpy() deep
>> in arch/x86/include/asm/string_32.h, notice that it is needed up in
>> the general string.h, as done with other common C String APIs. This
>> allows us to add basic sanity checking for pathological "size"
>> arguments to memcpy(). Besides the run-time checking benefit, this
>> avoids GCC trying to be very smart about value range tracking[1] when
>> CONFIG_PROFILE_ALL_BRANCHES=y but FORTIFY_SOURCE=n.
>
> It works for me but I couldn't reproduce the issue. I tried with
> CONFIG_PROFILE_ALL_BRANCHES=y and CONFIG_FORTIFY_SOURCE=n but it always
> works without a warning. I'm using GCC 15. Is it specific to a version
> of GCC?
I dunno. I'm using GCC 14.2.1.
--
~Randy
Powered by blists - more mailing lists