On Mon, Nov 30, 2020 at 09:56:27PM +, Ernst, Justin wrote:
> After scratching my head for a while, I found that the issue was
> missing empty lines before three different code-block sections.
Oh great.
> The line number is definitely bogus, but I wasn't able to discover
> why.
Very helpful
On Tue, Dec 01, 2020 at 01:48:30AM +0800, Rongwei Wang wrote:
> MSR ARM driver aims to provide interfacs for user to read or write
> data to all system registers.
Just a warranty from x86 land: if I were an ARM arch maintainer, I would
never never *ever* take such driver exposing naked hw
On Sat, Nov 28, 2020 at 08:23:59AM -0800, Yu, Yu-cheng wrote:
> We have X86_BRANCH_TRACKING_USER too. My thought was, X86_CET means any of
> kernel/user shadow stack/ibt.
It is not about what it means - it is what you're going to use/need. You have
ifdeffery both with X86_CET and
On Wed, Nov 25, 2020 at 11:48:47PM +0900, Punit Agrawal wrote:
> Replace the raw values for AMD processor family with recently
> introduced identifier macros to improve code readability and
> maintainability.
>
> Signed-off-by: Punit Agrawal
> ---
> drivers/cpufreq/acpi-cpufreq.c | 6 +++---
>
is purpose.
>
> Signed-off-by: Punit Agrawal
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: x...@kernel.org
> ---
> arch/x86/include/asm/amd-family.h| 18 ++
> arch/x86/include/asm/cpu_device_id.h | 2 ++
> 2 files changed
On Sun, Nov 29, 2020 at 05:50:05PM +0900, Masami Hiramatsu wrote:
> Good point. I think we can return, e.g. -EFAULT if we failed in
> get_next(). Then, we can read out next page, for example.
Why -EFAULT?
Running this
size = 1;
ret = insn_decode(, b, size, INSN_MODE_64)
i.e.,
arch/x86/pci/i386.c:373: warning: Function parameter or member \
'pcibios_assign_resources' not described in 'fs_initcall'
[ bp: Massage and fixup comment while at it. ]
Signed-off-by: Alex Shi
Signed-off-by: Borislav Petkov
Link:
https://lkml.kernel.
On Mon, Nov 30, 2020 at 06:05:03PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (htmldocs) produced
> these warnings:
>
> Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected
> indentation.
>
On Sun, Nov 29, 2020 at 10:32:31AM -0800, Linus Torvalds wrote:
> This is not a problem, it's just a note for people to try to avoid
> surprising me..
Oh, sorry, forgot to mention: he surprised me too and I asked. He said
he's updated his subkeys, yeah, perhaps because they're about to expire
and
Hi Linus,
please pull more forwarded EFI urgent fixes.
Thx.
---
The following changes since commit c2fe61d8be491ff8188edaf22e838f81146b:
efi/x86: Free efi_pgd with free_pages() (2020-11-10 19:18:11 +0100)
are available in the Git repository at:
Hi Linus,
please pull a couple of urgent fixes which accumulated this last week.
Thx.
---
The following changes since commit 418baf2c28f3473039f2f7377760bd8f6897ae18:
Linux 5.10-rc5 (2020-11-22 15:36:08 -0800)
are available in the Git repository at:
On Fri, Nov 27, 2020 at 09:45:39AM -0800, Andy Lutomirski wrote:
> Is -22 (-EINVAL) the same error it returns if you pass in garbage?
Define garbage.
Yes, if you have a sequence of bytes which you can unambiguously
determine to be
- an invalid instruction in some of the tables
- REX prefix
On Thu, Nov 19, 2020 at 11:02:37AM -0800, Chang S. Bae wrote:
> +static void test_sigaltstack(void *altstack, unsigned long size)
> +{
> + if (setup_altstack(altstack, size))
> + err(1, "sigaltstack()");
> +
> + sigalrm_expected = (size > at_minstack_size) ? true : false;
> +
>
On Fri, Nov 27, 2020 at 12:13:24PM -0500, Arvind Sankar wrote:
> Commit
> 26bfa5f89486 ("x86, amd: Cleanup init_amd")
> moved the code that remaps the TSEG region using 4k pages from
> init_amd() to bsp_init_amd().
>
> However, bsp_init_amd() is executed well before the direct mapping is
>
On Tue, Nov 10, 2020 at 08:21:50AM -0800, Yu-cheng Yu wrote:
> +config X86_CET
> + def_bool n
> +
> +config ARCH_HAS_SHADOW_STACK
> + def_bool n
> +
> +config X86_SHADOW_STACK_USER
Is X86_SHADOW_STACK_KERNEL coming too?
Regardless, you can add it when it comes and you can use only
On Fri, Nov 13, 2020 at 10:26:54AM -0800, Sami Tolvanen wrote:
> e820__mapped_all is passed as a callback to is_mmconf_reserved, which
> expects a function of type:
>
> typedef bool (*check_reserved_t)(u64 start, u64 end, unsigned type);
>
> This trips indirect call checking with Clang's
2 --
> arch/x86/kernel/asm-offsets_64.c | 1 -
> arch/x86/kernel/paravirt.c| 1 -
> arch/x86/kernel/paravirt_patch.c | 3 ---
> arch/x86/xen/enlighten_pv.c | 3 ---
> 8 files changed, 13 insertions(+), 47 deletions(-)
I love patches like this one!
On Tue, Nov 10, 2020 at 08:21:49AM -0800, Yu-cheng Yu wrote:
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index e19df6cde35d..6c21c1e92605 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -598,6 +598,65 @@
From: Borislav Petkov
Fix this build warning on 32-bit:
drivers/staging/media/atomisp/pci/hmm/hmm.c: In function ‘hmm_alloc’:
drivers/staging/media/atomisp/pci/hmm/hmm.c:272:3: warning: format ‘%ld’ \
expects argument of type ‘long int’, but argument 6 has type ‘size_t {aka
unsigned
On Thu, Nov 26, 2020 at 10:37:09AM +0900, Masami Hiramatsu wrote:
> BTW, the instruction validation depends on who needs it, because to
> check the all invalid ops, we need more information in the x86-opcode-map.txt
> and it will bloat up the table size and consumes more time to analysis.
Yes,
On Thu, Nov 19, 2020 at 11:02:35AM -0800, Chang S. Bae wrote:
> Historically, signal.h defines MINSIGSTKSZ (2KB) and SIGSTKSZ (8KB), for
> use by all architectures with sigaltstack(2). Over time, the hardware state
> size grew, but these constants did not evolve. Today, literal use of these
>
On Tue, Nov 10, 2020 at 08:21:48AM -0800, Yu-cheng Yu wrote:
> diff --git a/arch/x86/include/asm/msr-index.h
> b/arch/x86/include/asm/msr-index.h
> index 972a34d93505..6f05ab2a1fa4 100644
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -922,4 +922,24 @@
>
On Thu, Nov 26, 2020 at 11:48:27AM +0100, Jan Kara wrote:
> I'd prefer that as well but if nobody pops up, I'll just push this to my
> tree next week and will see what breaks :)
Right. You could send a proper patch and Cc the usual suspects as now it
is buried in some thread which people might
On Thu, Nov 26, 2020 at 12:18:12AM +, Sean Christopherson wrote:
> The SEAM module needs to be loaded during early boot, it can't be
> deferred to a module, at least not without a lot more blood, sweat,
> and tears.
Are you also planning to support builtin seam or only thru initrd loading?
On Thu, Nov 19, 2020 at 11:53:44AM +0100, Mathieu Chouquet-Stringer wrote:
> ---
> TAINT_CPU_OUT_OF_SPEC now means what a bit more than what it implies as
s/now means what a bit/now means a bit/
> the flag isn't set just because of a CPU misconfiguration or mismatch.
> Historically it was for
On Mon, Nov 16, 2020 at 10:25:48AM -0800, isaku.yamah...@intel.com wrote:
> From: Zhang Chen
>
> Move get_builtin_firmware() to common.c so that it can be used to get
> non-ucode firmware, e.g. Intel's SEAM modules, even if MICROCODE=n.
What for?
This is used for microcode built in the kernel
On Thu, Nov 26, 2020 at 01:53:33AM +0900, Masami Hiramatsu wrote:
> (only from the viewpoint of VEX coding, a bit stricter, but not perfect.)
Yeah, I wanted to document the fact that it has changed behavior in the
commit message - we'll make it perfect later. :-)
> > @@ -98,8 +101,12 @@ static
On Thu, Nov 19, 2020 at 11:02:34AM -0800, Chang S. Bae wrote:
> Signal frames do not have a fixed format and can vary in size when a number
> of things change: support XSAVE features, 32 vs. 64-bit apps. Add the code
> to support a runtime method for userspace to dynamically discover how large
> a
On Tue, Nov 24, 2020 at 11:19:33AM +0100, Borislav Petkov wrote:
> In any case, at least the case where I give it
>
> 0x48 0xcf 0x48 0x83
>
> and say that buf size is 4, should return an error because the second
> insn is incomplete. So I need to go look at that now.
Ok, g
The following commit has been merged into the x86/sgx branch of tip:
Commit-ID: afe76eca862ccde2a0c30105fc97a46a0b59339b
Gitweb:
https://git.kernel.org/tip/afe76eca862ccde2a0c30105fc97a46a0b59339b
Author:Borislav Petkov
AuthorDate:Mon, 23 Nov 2020 11:11:17 +01:00
On Tue, Nov 24, 2020 at 11:20:33AM +0100, Jan Kara wrote:
> On Tue 24-11-20 09:45:07, Borislav Petkov wrote:
> > On Mon, Nov 23, 2020 at 11:46:51PM +0100, Paweł Jasiak wrote:
> > > On 23/11/20, Jan Kara wrote:
> > > > OK, with a help of Boris Petkov I think I
From: Borislav Petkov
Hi,
here's what I had in mind, finally split into proper patches. The final
goal is for all users of the decoder to simply call insn_decode() and
look at its retval. Simple.
As to amluto's question about detecting partial insns, see the diff
below.
Running that gives
From: Borislav Petkov
Rename insn_decode() to insn_decode_regs() to denote that it receives
regs as param and free the name for a generic version.
No functional changes.
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/insn-eval.h | 4 ++--
arch/x86/kernel/sev-es.c | 2
From: Borislav Petkov
Simplify code, no functional changes.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/cpu/mce/severity.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/cpu/mce/severity.c
b/arch/x86/kernel/cpu/mce/severity.c
index
From: Borislav Petkov
Users of the instruction decoder should use this to decode instruction
bytes. For that, have insn*() helpers return an int value to denote
success/failure.
While at it, make insn_get_opcode() more stricter as to whether what has
seen so far is a valid insn
From: Borislav Petkov
Simplify code, no functional changes.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/sev-es.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/sev-es.c b/arch/x86/kernel/sev-es.c
index 37736486603e..564cc9fc693d 100644
From: Borislav Petkov
Other than simplifying the code there should be no functional changes
resulting from this.
Signed-off-by: Borislav Petkov
---
arch/x86/boot/compressed/sev-es.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/x86/boot/compressed/sev
From: Borislav Petkov
No functional changes, just simplification.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/alternative.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 2400ad62f330
From: Borislav Petkov
intel_pmu_pebs_fixup_ip() needs only the insn length so use the
appropriate helper instead of a full decode. A full decode differs only
in running insn_complete() on the decoded insn but that is not needed
here.
Signed-off-by: Borislav Petkov
---
arch/x86/events/intel
From: Borislav Petkov
Simplify code, no functional changes.
Signed-off-by: Borislav Petkov
---
arch/x86/tools/insn_decoder_test.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/x86/tools/insn_decoder_test.c
b/arch/x86/tools/insn_decoder_test.c
index
From: Borislav Petkov
Simplify code, no functional changes.
Signed-off-by: Borislav Petkov
Cc: Arnaldo Carvalho de Melo
---
tools/perf/arch/x86/tests/insn-x86.c| 9 -
tools/perf/arch/x86/util/archinsn.c | 9 +
.../intel-pt-decoder/intel-pt-insn
From: Borislav Petkov
Now that it is not needed anymore, drop it.
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/insn.h | 11 ---
tools/arch/x86/include/asm/insn.h | 11 ---
2 files changed, 22 deletions(-)
diff --git a/arch/x86/include/asm/insn.h b/arch/x86
From: Borislav Petkov
Simplify code, no functional changes.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/traps.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index e1b78829d909..4a06f79aaeeb 100644
From: Borislav Petkov
Simplify code, no functional changes.
Signed-off-by: Borislav Petkov
---
tools/objtool/arch/x86/decode.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/tools/objtool/arch/x86/decode.c b/tools/objtool/arch/x86/decode.c
index cde9c36e40ae
From: Borislav Petkov
Simplify code, no functional changes.
Signed-off-by: Borislav Petkov
---
arch/x86/tools/insn_sanity.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/tools/insn_sanity.c b/arch/x86/tools/insn_sanity.c
index 185ceba9d289..51309df285b4
From: Borislav Petkov
Simplify code, no functional changes.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/kprobes/core.c | 17 +++--
arch/x86/kernel/kprobes/opt.c | 9 +++--
2 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/kprobes/core.c b
From: Borislav Petkov
Simplify code, no functional changes.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/uprobes.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index 3fdaa042823d..e5759310f499 100644
From: Borislav Petkov
... and move it above the only place it is used.
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/insn.h | 7 ---
arch/x86/lib/insn.c | 7 +++
tools/arch/x86/include/asm/insn.h | 7 ---
tools/arch/x86/lib/insn.c | 7
From: Borislav Petkov
branch_type() doesn't need to call the full insn_decode() because it
doesn't need it in all cases thus leave the calls separate.
Signed-off-by: Borislav Petkov
---
arch/x86/events/intel/lbr.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
From: Borislav Petkov
Now that the different instruction inspecting functions return a value,
test that and return early from callers if error has been encountered.
Signed-off-by: Borislav Petkov
---
arch/x86/lib/insn-eval.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions
From: Borislav Petkov
It wasn't documented so add it. No functional changes.
Signed-off-by: Borislav Petkov
---
arch/x86/lib/insn.c | 1 +
tools/arch/x86/lib/insn.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/x86/lib/insn.c b/arch/x86/lib/insn.c
index 404279563891
On Tue, Nov 24, 2020 at 09:25:06AM +, Kalra, Ashish wrote:
> But what will be the criteria to figure out this percentage?
>
> As I mentioned earlier, this can be made as complicated as possible by
> adding all kind of heuristics but without any predictable performance
> gain.
>
> Or it can be
On Mon, Nov 23, 2020 at 10:56:31PM +, Ashish Kalra wrote:
> As i mentioned earlier, the patch was initially based on using a % of
> guest memory,
Can you figure out how much the guest memory is and then allocate a
percentage?
--
Regards/Gruss,
Boris.
On Mon, Nov 23, 2020 at 01:43:27PM -0500, Konrad Rzeszutek Wilk wrote:
> I am assuming that TDX is going to have the same exact issue that
> AMD SEV will have.
>
> Are you recommending to have an unified x86 specific callback
> where we check if it:
>
> - CPUID_AMD_SEV or CPUID_INTEL_TDX is
On Mon, Nov 23, 2020 at 11:46:51PM +0100, Paweł Jasiak wrote:
> On 23/11/20, Jan Kara wrote:
> > OK, with a help of Boris Petkov I think I have a fix that looks correct
> > (attach). Can you please try whether it works for you? Thanks!
>
> Unfortunately I am getting a linker error.
>
> ld:
s changed, 12 insertions(+), 3 deletions(-)
Acked-by: Borislav Petkov
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Mon, Nov 23, 2020 at 05:40:21PM +, Paoloni, Gabriele wrote:
> Well it is not the easiest code to decode
Tell me about it - that's decades worth of crap being piled ontop. :-)
> Sure I can add another patch to the set to rename it.
Yeah, only if you really want to - that was more a
On Mon, Nov 23, 2020 at 12:56:32PM -0500, Konrad Rzeszutek Wilk wrote:
> This is not going to work for TDX. I think having a registration
> to SWIOTLB to have this function would be better going forward.
>
> As in there will be a swiotlb_register_adjuster() which AMD SEV
> code can call at start,
On Mon, Nov 23, 2020 at 05:06:31PM +, Paoloni, Gabriele wrote:
> From my understanding no_way_out and kill_it are different in principles:
> no_way_out is telling that an error occurred 'somewhere' in some CPU bank
> that requires the system to panic (e.g. PCC=1); kill_it is saying that the
>
On Thu, Nov 19, 2020 at 09:42:05PM +, Ashish Kalra wrote:
> From: Ashish Kalra
>
> For SEV, all DMA to and from guest has to use shared (un-encrypted) pages.
> SEV uses SWIOTLB to make this happen without requiring changes to device
> drivers. However, depending on workload being run, the
On Fri, Nov 20, 2020 at 06:33:42PM +0100, Borislav Petkov wrote:
> Sure, lemme go through the rest first.
Done, thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Wed, Nov 18, 2020 at 03:15:50PM +, Gabriele Paoloni wrote:
> Right now for local MCEs we panic(),if needed, right after lmce is
> set. For global MCEs mce_reign() takes care of calling mce_panic().
> Hence this patch:
> - improves readibility by moving the conditional evaluation of
>
'encl' not described in 'sgx_ioc_enclave_provision'
> arch/x86/kernel/cpu/sgx/ioctl.c:666: warning: Excess function parameter
> 'enclave' description in 'sgx_ioc_enclave_provision'
>
> Introduced by commit
>
> c82c61865024 ("x86/sgx: Add SGX_IOC_ENCLAVE_PROVISION")
---
From: Borislav
From: Borislav Petkov
In order to setup its PCI component, the driver needs any node private
instance in order to get a reference to the PCI device and hand that
into edac_pci_create_generic_ctl(). For convenience, it uses the 0th
memory controller descriptor under the assumption that if any
Hi Linus,
please pull the (forwarded) EFI urgent fixes for -rc5.
Thx.
--
The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:
Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)
are available in the Git repository at:
Hi Linus,
please pull the x86/urgent pile for -rc5.
Thx.
---
The following changes since commit 09162bc32c880a791c6c0668ce0745cf7958f576:
Linux 5.10-rc4 (2020-11-15 16:44:31 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
On Sat, Nov 21, 2020 at 11:38:02AM +0100, Ard Biesheuvel wrote:
> Acked-by: Ard Biesheuvel
Thanks!
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Thu, Nov 19, 2020 at 12:29:38PM -0600, Smita Koralahalli wrote:
> diff --git a/drivers/firmware/efi/cper-x86.c b/drivers/firmware/efi/cper-x86.c
> index 2531de49f56c..438ed9eff6d0 100644
> --- a/drivers/firmware/efi/cper-x86.c
> +++ b/drivers/firmware/efi/cper-x86.c
> @@ -2,6 +2,7 @@
> //
On Wed, Nov 18, 2020 at 03:15:49PM +, Gabriele Paoloni wrote:
> Currently if mce_end() fails no_way_out is set equal to worst.
> worst is the worst severirty that was found in the MCA banks
> associated to the current CPU; however at this point no_way_out
> could be already set by mca_start()
On Fri, Nov 20, 2020 at 05:31:32PM +, Paoloni, Gabriele wrote:
> I mean that on this CPU thread at this point mce_start() already cached
> global_nwo and hence could accumulate fatal severities of other CPUs.
>
> Now here if mce_end() fails we only consider the local 'worst' severity
> and we
On Wed, Nov 18, 2020 at 03:15:49PM +, Gabriele Paoloni wrote:
> Currently if mce_end() fails no_way_out is set equal to worst.
> worst is the worst severirty that was found in the MCA banks
^
Please introduce a spellchecker into your patch creation workflow.
>
On Sat, Oct 31, 2020 at 03:03:58AM +0800, Xiaochen Shen wrote:
> Willem reported growing of kernfs_node_cache entries in slabtop when
> repeatedly creating and removing resctrl subdirectories as well as when
> repeatedly mounting and unmounting resctrl filesystem.
>
> On resource group (control
On Thu, Nov 19, 2020 at 09:50:10PM +0800, Feng Tang wrote:
> That's really odd. I tried on 3 baremetal machines: one Skylake NUC device,
> one Xeon E5-2699 and one Xeon E5-2680.
Ah, sorry, not virt, virt is 0x4000_. Yeah, I remember now. It is
function 4 which AMD doesn't implement and I'm
The following commit has been merged into the x86/misc branch of tip:
Commit-ID: b023fd5f741f34d2cd90258ccc3f245924d2eadd
Gitweb:
https://git.kernel.org/tip/b023fd5f741f34d2cd90258ccc3f245924d2eadd
Author:Borislav Petkov
AuthorDate:Wed, 18 Nov 2020 13:34:07 +01:00
CPUID leaf definitions are kept in an .csv file which allows for
updating only that file to add support for new feature leafs.
This is based on prototype code from Borislav Petkov
(http://sr71.net/~dave/intel/stupid-cpuid.c).
[ bp: Massage, add #define _GNU_SOURCE to fix implicit declaration of
On Wed, Nov 18, 2020 at 08:12:43PM +, Ashish Kalra wrote:
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 3511736fbc74..0f42911cea57 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -1166,6 +1166,10 @@ void __init setup_arch(char **cmdline_p)
On Thu, Oct 22, 2020 at 01:21:23PM +0800, Feng Tang wrote:
> diff --git a/tools/arch/x86/kcpuid/kcpuid.c b/tools/arch/x86/kcpuid/kcpuid.c
> new file mode 100644
> index 000..9bd35b7
> --- /dev/null
> +++ b/tools/arch/x86/kcpuid/kcpuid.c
> @@ -0,0 +1,618 @@
> +// SPDX-License-Identifier:
On Wed, Nov 18, 2020 at 03:04:27PM +0100, Mathieu Chouquet-Stringer wrote:
> TAINT_CPU_OUT_OF_SPEC now means what it says. Historically it was for
> SMP kernel oops on an officially SMP incapable processor but now it also
> covers CPUs whose MSRs have been incorrectly poked at. Update
>
From: Borislav Petkov
It is a warning and not an error so use pr_warn().
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/msr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index b1147862730c..95e6b97b7d8b 100644
On Wed, Nov 18, 2020 at 10:09:29AM +0100, Mathieu Chouquet-Stringer wrote:
> Speaking of doc, looking at the patches you submitted, I didn't see any
> update to the documentation. Would you like me to create a patch for
> that?
Sure, that would be appreciated.
Thx.
--
Regards/Gruss,
Boris.
On Wed, Nov 18, 2020 at 08:41:42AM +0100, Alexandre Chartre wrote:
> Well, it looks like I wrongfully assume that KPTI was a well known performance
> overhead since it was introduced (because it adds extra page-table switches),
> but you are right I should be presenting my own numbers.
Here's one
On Tue, Nov 17, 2020 at 07:12:07PM +0100, Alexandre Chartre wrote:
> Some benchmarks are available, in particular from phoronix:
What I was expecting was benchmarks *you* have run which show that
perf penalty, not something one can find quickly on the internet and
something one cannot always
On Tue, Nov 17, 2020 at 08:02:51PM +0100, Alexandre Chartre wrote:
> No. This prevents the guest VM from gathering data from the host
> kernel on the same cpu-thread. But there's no mitigation for a guest
> VM running on a cpu-thread attacking another cpu-thread (which can be
> running another
On Tue, Nov 17, 2020 at 10:00:18PM +0100, Mathieu Chouquet-Stringer wrote:
> I'm late to the party but it seems allowing MSR_IA32_ENERGY_PERF_BIAS
> has the downside of flagging the kernel as tainted without telling you
> why if you use something like x86_energy_perf_policy (from
>
On Tue, Nov 17, 2020 at 09:23:07PM +0100, Enrico Weigelt, metux IT consult
wrote:
> Make it possible to opt-out from vmware support
Why?
I can think of a couple of reasons but maybe yours might not be the one
I'm thinking of.
> Signed-off-by: Enrico Weigelt, metux IT consult
> ---
>
On Tue, Nov 17, 2020 at 07:12:07PM +0100, Alexandre Chartre wrote:
> Yes. L1TF/MDS allow some inter cpu-thread attacks which are not mitigated at
> the moment. In particular, this allows a guest VM to attack another guest VM
> or the host kernel running on a sibling cpu-thread. Core Scheduling
On Fri, Nov 13, 2020 at 12:01:31AM +0200, Jarkko Sakkinen wrote:
> +bool encl_load(const char *path, struct encl *encl)
> +{
> + Elf64_Phdr *phdr_tbl;
> + off_t src_offset;
> + Elf64_Ehdr *ehdr;
> + int i, j;
> + int ret;
> +
> + memset(encl, 0, sizeof(*encl));
> +
> +
On Tue, Nov 17, 2020 at 09:19:01AM +0100, Alexandre Chartre wrote:
> We are not reversing PTI, we are extending it.
You're reversing it in the sense that you're mapping more kernel memory
into the user page table than what is mapped now.
> PTI removes all kernel mapping from the user page-table.
On Tue, Nov 17, 2020 at 08:56:23AM +0100, Alexandre Chartre wrote:
> The main goal of ASI is to provide KVM address space isolation to
> mitigate guest-to-host speculative attacks like L1TF or MDS.
Because the current L1TF and MDS mitigations are lacking or why?
> Current proposal of ASI is
On Mon, Nov 16, 2020 at 11:19:12AM -0700, Shuah Khan wrote:
> Please keep the list sorted alphabetically as stated
> in the comment above.
Done.
> This should be KSFT_FAIL.
and done.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Fri, Nov 13, 2020 at 12:01:30AM +0200, Jarkko Sakkinen wrote:
> diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
> index 2ad757fb3c23..9915fbd34264 100644
> --- a/arch/x86/entry/vdso/Makefile
> +++ b/arch/x86/entry/vdso/Makefile
> @@ -27,6 +27,7 @@
1f 80 00
00 00 00 48 8d 05 f9 61 0d 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00
f0 ff ff 77 54 c3 0f 1f 00 41 54 49 89 d4 55 48 89 f5 53
which is the shell doing the
$ echo t > /proc/sysrq-trigger
So
Reviewed-by: Borislav Petkov
Tested-by: Borislav Petkov
Thanks!
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Tue, Nov 17, 2020 at 10:25:18AM +0800, Chen Yu wrote:
> If I understand correctly, the only place that invokes
> save_mc_for_early() is in generic_load_microcode(). While in
> generic_load_microcode() only microcode has a newer version will be
> saved by checking has_newer_microcode(), and this
On Mon, Nov 16, 2020 at 01:30:19PM -0800, Raj, Ashok wrote:
> Stable is still left below. with #v4.10+
>
> Do you want to keep this? Also do you want him to resend or you have that
> covered?
No Ashok, read the section
"For all other submissions, choose one of the following procedures"
here:
On Mon, Nov 16, 2020 at 03:47:36PM +0100, Alexandre Chartre wrote:
> Deferring CR3 switch to C code means that we need to run more of the
> kernel entry code with the user page-table. To do so, we need to:
>
> - map more syscall, interrupt and exception entry code into the user
>page-table
On Mon, Nov 16, 2020 at 03:47:36PM +0100, Alexandre Chartre wrote:
> This RFC proposes to defer the PTI CR3 switch until we reach C code.
> The benefit is that this simplifies the assembly entry code, and make
> the PTI CR3 switch code easier to understand. This also paves the way
> for further
The following commit has been merged into the x86/misc branch of tip:
Commit-ID: 8113ab20e850491b4144a1a64246f07a2d737a49
Gitweb:
https://git.kernel.org/tip/8113ab20e850491b4144a1a64246f07a2d737a49
Author:Borislav Petkov
AuthorDate:Thu, 15 Oct 2020 12:28:58 +02:00
The following commit has been merged into the x86/misc branch of tip:
Commit-ID: fe0a5788624c8b8f113a35bbe4636e37f9321241
Gitweb:
https://git.kernel.org/tip/fe0a5788624c8b8f113a35bbe4636e37f9321241
Author:Borislav Petkov
AuthorDate:Thu, 15 Oct 2020 14:58:48 +02:00
The following commit has been merged into the x86/misc branch of tip:
Commit-ID: 6d6501d912a9a5e1b73d7fbf419b90a8ec11ed7a
Gitweb:
https://git.kernel.org/tip/6d6501d912a9a5e1b73d7fbf419b90a8ec11ed7a
Author:Borislav Petkov
AuthorDate:Thu, 15 Oct 2020 14:50:16 +02:00
The following commit has been merged into the x86/misc branch of tip:
Commit-ID: 18741a5251d018094536a2dffe284d269ebb07fe
Gitweb:
https://git.kernel.org/tip/18741a5251d018094536a2dffe284d269ebb07fe
Author:Borislav Petkov
AuthorDate:Thu, 15 Oct 2020 15:00:31 +02:00
801 - 900 of 23602 matches
Mail list logo
