On Fri, Sep 01, 2017 at 05:52:13PM -0500, Brijesh Singh wrote:
> So far, we have not seen the need for having such functions except
> this cases. The approach we have right now works just fine and not
> sure if its worth adding new functions.
Then put the call to kvm_map_hv_shared_decrypted() int
On Tue, Aug 22, 2017 at 06:52:48PM +0200, Borislav Petkov wrote:
> As always, the devil is in the detail.
Ok, actually we can make this much simpler by using a static key. A
conceptual patch below - I only need to fix that crazy include hell I'm
stepping into with this.
In any case,
On Fri, Sep 15, 2017 at 09:13:00AM -0500, Brijesh Singh wrote:
> thanks for the suggestion Boris, it will make patch much simpler.
> I will try this out.
It won't build - this was supposed to show the general idea.
I need to figure out the include hell first.
--
Regards/Gruss,
Boris.
SUSE
On Fri, Sep 15, 2017 at 09:48:53AM -0500, Brijesh Singh wrote:
> I see the similar issue with non SEV guest with my simple patch below.
> Guest will reboot as soon as it tries to enable the key.
Can't do it there as the pagetable is not setup yet and you're probably
getting a #PF on any of the der
ped-by: Jini Susan George
Signed-off-by: Jini Susan George
Signed-off-by: Vignesh Balasubramanian
Signed-off-by: Borislav Petkov (AMD)
---
arch/x86/Kconfig | 1 +
arch/x86/include/asm/elf.h | 9
arch/x86/kernel/fpu/xstate.c | 84 +++
On Tue, Jul 05, 2022 at 09:44:17PM +0200, Jason A. Donenfeld wrote:
> Oh, huh. Maybe in that case I should adjust the message to say "consider
> using `random.trust_cpu=0`," which is the thing that would actually make
> a security difference.
Why isn't that option documented in
Documentation/admin
On Tue, Jul 05, 2022 at 02:50:34PM -0700, H. Peter Anvin wrote:
> It's just math. The only variable is your confidence level, i.e. at
> what level do you decide that the likelihood of pure chance is way
> smaller than the likelihood of hardware failure.
That might be but the likelyhood of certain
On Tue, Jul 19, 2022 at 03:02:07PM +0200, Jason A. Donenfeld wrote:
> Since callers need to check this return value and loop anyway, each arch
> implementation does not bother implementing its own loop to try again to
> fill the maximum number of longs. Additionally, all existing callers
> pass in
-time
> platforms, while performance is greatly improved on platforms such as
> s390.
>
> Cc: Will Deacon
> Cc: Alexander Gordeev
> Cc: Thomas Gleixner
> Cc: H. Peter Anvin
> Cc: Catalin Marinas
> Cc: Borislav Petkov
> Cc: Heiko Carstens
> Cc: Johanne
the new kernel.
>
> Signed-off-by: Jonathan McDowell
> Signed-off-by: Borislav Petkov
> Reviewed-by: Mimi Zohar # IMA function definitions
> Link: https://lore.kernel.org/r/YmKyvlF3my1yWTvK@noodles-fedora-PC23Y6EG
Is there any particular reason to keep sending a patch whic
On Fri, Aug 12, 2022 at 01:14:38PM -0400, Stefan Berger wrote:
> Yes, so this series can be tested by krobot.
You mean Intel's 0day robot?
I believe that thing has by now enough logic to figure out which branch
to base patches ontop. Or maybe there's some magic incantation to tell
it which base c
>
> > Had the mask_user_address() patch been put for review, this feedback
> > would have been given then.
> >
> >
> > AMD needs to arrange for bit 47 (bit 58 with LA57) to be the one
> > saturated by shifting, not bit 63.
>
> Ok... why?
I'
On Mon, Oct 14, 2024 at 04:39:26PM +0100, Andrew Cooper wrote:
> But, I expect it will malfunction on newer hardware when
> CONFIG_X86_5LEVEL=n, because it causes Linux to explicitly ignore the
> LA57 bit. That can be fixed by changing how CONFIG_X86_5LEVEL works.
https://lore.kernel.org/all/8073
On Wed, Oct 16, 2024 at 03:32:32PM -0700, Linus Torvalds wrote:
> My preference would actually be to do nothing, on the assumption that
> the AMD issue is actually impossible to trigger (due to CLAC/STAC
> serializing memory address checks - which the timings certainly imply
> they do).
I'm verify
On Sun, Oct 20, 2024 at 04:35:21PM -0700, Linus Torvalds wrote:
> So I think this time we push back on the hardware people and tell them
> it's *THEIR* damn problem, and if they can't even be bothered to say
> yay-or-nay, we just sit tight.
So I was able to get some info: CLAC/STAC in everything
've been meaning to reply to you but then gazillion things interrupted me and
... you know how it is. Sorry.
Acked-by: Borislav Petkov (AMD)
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Mon, Dec 23, 2024 at 03:32:01PM +0800, Weikang Guo wrote:
> First of all, thank you for your reminder and patience. In fact, this
> is the first time I received a patch discussion when submitting a
> patch.
> About Reviewed-by or Acked-by tags, I will not add it myself in the
> future. Regarding
On Fri, Jan 10, 2025 at 06:40:27PM +, Brendan Jackman wrote:
> Subject: Re: [PATCH RFC v2 01/29] mm: asi: Make some utility functions
> noinstr compatible
The tip tree preferred format for patch subject prefixes is
'subsys/component:', e.g. 'x86/apic:', 'x86/mm/fault:', 'sched/fair:',
'genirq
On Thu, Jan 16, 2025 at 01:18:58AM +0100, Borislav Petkov wrote:
> Long story short, lemme try to poke around tomorrow to try to figure out what
> actually happens. It could be caused by the part of Rik's patches and this one
> inlining things. We'll see...
Looks transient.
On Thu, Jan 16, 2025 at 02:22:42PM +0100, Brendan Jackman wrote:
> Sure. I'm actually not even sure that for a [PATCH]-quality thing this
> cross-cutting commit even makes sense - once we've decided on the
> general way to solve this problem, perhaps the changes should just be
> part of the commit
On Wed, Dec 18, 2024 at 09:55:11PM +1100, Michael Ellerman wrote:
> This driver can no longer be built since support for IBM Cell Blades was
> removed, in particular PPC_CELL_COMMON.
>
> Remove the driver.
>
> Signed-off-by: Michael Ellerman
> ---
> v2: Rebase.
>
> Cc: linux-e...@vger.kernel.or
On Fri, Jan 10, 2025 at 06:40:28PM +, Brendan Jackman wrote:
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index
> 7b9a7e8f39acc8e9aeb7d4213e87d71047865f5c..5a50582eb210e9d1309856a737d32b76fa1bfc85
> 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2519,6 +2519,20 @@ conf
On Fri, Jan 10, 2025 at 06:40:30PM +, Brendan Jackman wrote:
> Add a boot time parameter to control the newly added X86_FEATURE_ASI.
> "asi=on" or "asi=off" can be used in the kernel command line to enable
> or disable ASI at boot time. If not specified, ASI enablement depends
> on CONFIG_ADDRE
On Fri, Jan 10, 2025 at 06:40:29PM +, Brendan Jackman wrote:
> Subject: Re: [PATCH RFC v2 03/29] mm: asi: Introduce ASI core API
x86/asi: ...
> Introduce core API for Address Space Isolation (ASI). Kernel address
> space isolation provides the ability to run some kernel
> code with a restric
On Wed, Feb 19, 2025 at 02:53:03PM +0100, Brendan Jackman wrote:
> Argh, sorry, GMail switched back to HTML mode somehow. Maybe I have to
> get a proper mail client after all.
Yap, wouldn't be such a bad idea. And yes, it ain't easy - we have a whole doc
about it:
Documentation/process/email-clie
On Mon, Jul 21, 2025 at 03:13:40AM -0700, Breno Leitao wrote:
> Introduce a generic infrastructure for tracking recoverable hardware
> errors (HW errors that did not cause a panic) and record them for vmcore
> consumption. This aids post-mortem crash analysis tools by preserving
> a count and times
On Wed, Jul 23, 2025 at 08:36:52AM -0700, Breno Leitao wrote:
> Basically there are two approaches, from what I understand:
>
> 1) mark do_machine_check() as noinstr
do_machine_check is already noinstr. I think you mean mark
hwerr_log_error_type() noinstr.
And yes, you can mark it. hwerr_l
201 - 227 of 227 matches
Mail list logo
