On Tue, Oct 24, 2023 at 04:32:48PM +0200, Rafael J. Wysocki wrote:
> So there are 3 designated reviewers for APEI: Tony Luck, Borislav
> Petkov and James Morse. I need an ACK or Reviewed-by from one of
> them, so I can proceed with an APEI patch.
Here's what I see:
cat /tmp/pat
Hi,
On Wed, Oct 25, 2023 at 02:09:37PM +, Jeshua Smith wrote:
<... snip a very detailed and good explanation... >
> Writing 128 nor-flash pages would then take 120us * 128 = 15ms
> typical, or 1800us * 128 = 230.4ms max.
This is perfectly suitable to be in the commit message - it explains in
g a
> timeout and will return success to pstore after the operation completes.
>
> Signed-off-by: Jeshua Smith
> ---
Reviewed-by: Borislav Petkov (AMD)
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Wed, Feb 07, 2024 at 07:05:31PM +0100, Marco Elver wrote:
> I think this would belong into some "hardening" config - while KFENCE
> is not a mitigation (due to sampling) it has the performance
> characteristics of unintrusive hardening techniques, so I think it
> would be a good fit. I think tha
On Wed, Feb 07, 2024 at 07:35:53PM +0100, Matthieu Baerts wrote:
> Sorry, I'm sure I understand your suggestion: do you mean not including
> KFENCE in hardening.config either, but in another one?
>
> For the networking tests, we are already merging .config files, e.g. the
> debug.config one. We ar
On Thu, Feb 08, 2024 at 08:47:37AM +0100, Marco Elver wrote:
> That's a good question, and I don't have the answer to that - maybe we
> need to ask Linus then.
Right, before that, lemme put my user hat on.
> We could argue that to improve memory safety of the Linux kernel more
> rapidly, enableme
On Thu, Feb 08, 2024 at 12:12:19PM +0100, Marco Elver wrote:
> git log --grep 'BUG: KFENCE: '
>
> There are more I'm aware of - also plenty I know of in downstream
> kernels (https://arxiv.org/pdf/2311.09394.pdf - Section 5.7).
Good.
> This is a problem shared by all other diagnostic and error r
On Mon, Mar 18, 2024 at 02:40:50PM -0700, Kees Cook wrote:
> Applied to for-next/hardening
Why?
This is a patch that should go through the tip tree, if at all.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Mon, Mar 18, 2024 at 04:45:45PM -0700, Kees Cook wrote:
> The commit it refs to landed via -hardening,
Yap, saw that. It should've gone through tip too as it is clearly a tip
tree patch.
> responsibility of landing this fix too. But it's fine to go via -tip
> if you prefer?
Yes, please. Just
s, please refrain from taking tip patches in the future. You know how
this works - get_maintainers.pl.
Thx.
Date: Fri, 22 Mar 2024 14:47:05 -0400
From: Sasha Levin
To: stable-comm...@vger.kernel.org, keesc...@chromium.org
Cc: Thomas Gleixner , Ingo Molnar ,
Borislav Petkov , Dave Hansen ,
x...@kern
On Fri, Mar 22, 2024 at 04:40:11PM -0700, Kees Cook wrote:
> The earlier patch, commit aaa8736370db ("x86, relocs: Ignore relocations
> in .notes section"), landed via my tree. It was sent out on Feb 22nd
> (v1[1]) and got a suggestion from HPA and a Review from Juergen Gross.
> I sent v2 Feb 27th[
On May 30, 2024 6:23:36 PM GMT+02:00, Jeff Johnson
wrote:
>On 5/30/2024 8:42 AM, Nikolay Borisov wrote:
>>
>>
>> On 29.05.24 г. 21:09 ч., Jeff Johnson wrote:
>>> As discussed in [1] add a prototype for __fortify_panic() to fix the
>>> 'make W=1 C=1' warning:
>>>
>>> arch/x86/boot/compressed/mis
On Fri, May 31, 2024 at 09:53:28AM -0700, Kees Cook wrote:
> Under CONFIG_FORTIFY_SOURCE, the boot code *does* still uses
> fortify-string.h. It lets us both catch mistakes we can discover at
> compile and will catch egregious runtime mistakes, though the reporting
> is much simpler in the boot cod
On Fri, May 31, 2024 at 01:46:37PM -0700, Kees Cook wrote:
> Please do not do this. It still benefits from compile-time sanity
> checking.
Care to elaborate how exactly it benefits?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Fri, May 31, 2024 at 02:06:48PM -0700, Kees Cook wrote:
> ...
> or refactors and forgets to change some name, etc. It's all for catching
> bugs before they happen, etc. And when source string lengths aren't
> known, the runtime checking can kick in too.
Aha, thanks for explaining.
> It happens
On Fri, May 31, 2024 at 02:34:07PM -0700, Kees Cook wrote:
> On Fri, May 31, 2024 at 11:20:09PM +0200, Borislav Petkov wrote:
> > So I get an allergic reaction everytime we wag the dog - i.e., fix the
> > code because some tool or option can't handle it even if it is
> >
On Wed, Jun 05, 2024 at 02:23:32PM +0800, Tony W Wang-oc wrote:
> After MCE has occurred, it is possible for the MCE handler to execute the
> add_taint() function without panic. For example, the fake_panic is
> configured.
fake_panic is an ancient debugging leftover. If you set it, you get what
yo
On Wed, Jun 05, 2024 at 06:10:07PM +0800, Tony W Wang-oc wrote:
> It may also happen without setting fake_panic, such as an MCE error of the
> UCNA/SRAO type occurred?
Which types exactly do you mean when you're looking at the severities[]
array in severity.c?
And what scenario are you talking ab
18 matches
Mail list logo
