On Mon, Nov 16, 2020 at 09:21:16AM -0800, Dave Hansen wrote:
> That works when there is something universal across the set, like if
> Sean Signed-off-by on each patch and we didn't have any other SoB's.
> Sean is also mentioned in at least one of five different tags:
So?
You git-format-patch,
On Fri, Nov 13, 2020 at 12:01:11AM +0200, Jarkko Sakkinen wrote:
> Sean Christopherson is a major contributor to this series. However, he
> has left Intel and his @intel.com address will soon be bouncing. He
> does not have a email he wants us to substitute or put in .mailmap for
> now. To
o the signature verification
before saving.
[ bp: Do signature verification in save_microcode_patch()
and rewrite commit message. ]
Fixes: 06b8534cb728 ("x86/microcode: Rework microcode loading")
Signed-off-by: Chen Yu
Signed-off-by: Borislav Petkov
Cc: sta...@vger.kerne
On Tue, Nov 10, 2020 at 11:40:34AM +0100, Paolo Bonzini wrote:
> However, f/m/s mean nothing when running virtualized. First, trying to
> derive any non-architectural property from the f/m/s is going to fail.
> Second, even the host can be anything as long as it's newer than the f/m/s
> that the
On Tue, Nov 10, 2020 at 09:50:43AM +0100, Paolo Bonzini wrote:
> 1) ignore_msrs _cannot_ be on by default. You cannot know in advance that
> for all non-architectural MSRs it's okay for them to read as zero and eat
> writes. For some non-architectural MSR which never reads as zero on real
>
On Mon, Nov 09, 2020 at 03:24:02PM -0800, Luck, Tony wrote:
> Booting as a guest under KVM results in error messages about
> unchecked MSR access:
>
> [6.814328][T0] unchecked MSR access error: RDMSR from 0x17f at rIP:
> 0x84483f16 (mce_intel_feature_init+0x156/0x270)
>
>
On Mon, Nov 09, 2020 at 05:15:03PM -0600, Tom Lendacky wrote:
> [ 105.325371] hpet: Lost 9601 RTC interrupts
> [ 105.485766] hpet: Lost 9600 RTC interrupts
> [ 105.639182] hpet: Lost 9601 RTC interrupts
> [ 105.792155] hpet: Lost 9601 RTC interrupts
> [ 105.947076] hpet: Lost 9601 RTC
On Sun, Nov 08, 2020 at 09:35:38AM -0800, Linus Torvalds wrote:
> So while we try to mark scripts executable, we then actually generally
> execute them using an explicit interpreter invocation anyway (ie using
>
> $(CONFIG_SHELL) "some-script-path"
>
> or similar).
Thanks for explaining!
--
On Sun, Nov 08, 2020 at 10:05:21AM +0100, Ingo Molnar wrote:
> So that mode change to executable was intentional, as mentioned in the
> changelog.
Yeah, I thought we don't make them executable in the tree but I guess we
do, at least most of them, from looking at git ls-files *.sh output.
Thx.
On Sat, Nov 07, 2020 at 03:13:58PM -, tip-bot2 for Ingo Molnar wrote:
> The following commit has been merged into the perf/kprobes branch of tip:
>
> Commit-ID: a70a04b3844f59c29573a8581d5c263225060dd6
> Gitweb:
> https://git.kernel.org/tip/a70a04b3844f59c29573a8581d5c263225060dd6
On Sat, Nov 07, 2020 at 12:04:02AM +0200, Jarkko Sakkinen wrote:
> There has been a change request to update callback that made perfect
> sense to me. Is there something else that I might have missed? Just
> checking.
With "change requests" I mean the usual going through the replies to a
patchset
On Fri, Nov 06, 2020 at 06:51:07PM +0200, Jarkko Sakkinen wrote:
> Both comments make sense to me. I'll refine this patch on Monday and
And while you're at it, I'd suggest you refine the whole patchset and
send a full v41 instead:
- please audit all your Reviewed-by, Acked-by tags as to for what
On Fri, Nov 06, 2020 at 11:48:26AM -0800, Yu, Yu-cheng wrote:
> I will drop it. It has been re-based many times, and probably I
> accidentally introduced something else?
Yah, I think I added my tag to this version:
https://lkml.kernel.org/lkml/20181119214809.6086-3-yu-cheng...@intel.com/
Do
On Mon, Oct 12, 2020 at 08:38:26AM -0700, Yu-cheng Yu wrote:
> Add CPU feature flags for Control-flow Enforcement Technology (CET).
>
> CPUID.(EAX=7,ECX=0):ECX[bit 7] Shadow stack
> CPUID.(EAX=7,ECX=0):EDX[bit 20] Indirect Branch Tracking
>
> Signed-off-by: Yu-cheng Yu
>
On Fri, Nov 06, 2020 at 10:16:47AM -0800, Yu, Yu-cheng wrote:
> In the current shell, if GLIBC_TUNABLES variable is set as such,
> applications started will have CET features disabled. I can put more
> details here, or maybe a reference to the GLIBC man pages.
Why do you keep repeating "the
On Mon, Oct 12, 2020 at 08:38:25AM -0700, Yu-cheng Yu wrote:
> +[1] Overview
> +
> +
> +Control-flow Enforcement Technology (CET) is an Intel processor feature
> +that provides protection against return/jump-oriented programming (ROP)
> +attacks. It can be set up to protect both
On Fri, Nov 06, 2020 at 06:07:42PM +0200, Jarkko Sakkinen wrote:
> On Thu, Nov 05, 2020 at 07:10:47PM +0100, Borislav Petkov wrote:
> > On Thu, Nov 05, 2020 at 07:57:45PM +0200, Jarkko Sakkinen wrote:
> > > I'll rather send a full patch set if required.
> >
> >
On Thu, Nov 05, 2020 at 10:30:05PM -0500, Hewenliang wrote:
> From: hewenliang
>
> It is necessary to initialize the value of ident mapping offset.
Why is it necessary?
> This can not only avoid using dirty data,
What happens to designated initializers when some of the members are not
On Tue, Nov 03, 2020 at 10:49:52AM -0600, Smita Koralahalli wrote:
> diff --git a/arch/x86/kernel/cpu/mce/apei.c b/arch/x86/kernel/cpu/mce/apei.c
> index af8d37962586..f56f0bc147e2 100644
> --- a/arch/x86/kernel/cpu/mce/apei.c
> +++ b/arch/x86/kernel/cpu/mce/apei.c
> @@ -51,6 +51,62 @@ void
On Fri, Nov 06, 2020 at 02:36:46PM +0900, Punit Agrawal 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 Fri, Nov 06, 2020 at 04:43:40PM +0800, Zhen Lei wrote:
> enum mce_notifier_prios {
> MCE_PRIO_LOWEST,
> MCE_PRIO_MCELOG,
> MCE_PRIO_EDAC,
>
> After commit c9c6d216ed28 ("x86/mce: Rename "first" function as "early""),
> there is no other integer between MCE_PRIO_MCELOG
On Thu, Nov 05, 2020 at 06:31:53PM -0600, Michael Roth wrote:
> I can confirm that patch fixes the issue. It is indeed a 5.9.1 tree, but
> looks like the SEV-ES patches didn't go in until v5.10-rc1
Yes, they went into 5.10-rc1 during the merge window.
> (this tree had a backport of them), so
On Thu, Nov 05, 2020 at 02:32:10PM -0600, Tom Lendacky wrote:
> Does it need a Fixes: tag?
Yah, this one:
Fixes: 21998a351512 ("x86/speculation: Avoid force-disabling IBPB based on
STIBP and enhanced IBRS.")
because it set mode to SPECTRE_V2_USER_STRICT_PREFERRED, leading to the
inability to
On Thu, Nov 05, 2020 at 07:57:45PM +0200, Jarkko Sakkinen wrote:
> I'll rather send a full patch set if required.
Why if the changes all belong to this patch and why should I take a
patch which clearly needs improving?
Just send the fixed version of this and I can take it now.
Thx.
--
On Thu, Nov 05, 2020 at 10:24:37AM -0600, Michael Roth wrote:
> > out_set_gif:
> > svm_set_gif(svm, !!(kvm_state->flags & KVM_STATE_NESTED_GIF_SET));
> > - return 0;
> > +
> > + ret = 0;
> > +out_free:
> > + kfree(save);
> > + kfree(ctl);
>
> This change seems to
On Thu, Nov 05, 2020 at 03:16:15AM +0200, Jarkko Sakkinen wrote:
> Further, I'd declare this as an inline function given how trivial it
> turn into.
>
...
So are you sending a new version of only this patch as a reply to this
subthread?
--
Regards/Gruss,
Boris.
On Wed, Nov 04, 2020 at 04:54:16PM +0200, Jarkko Sakkinen wrote:
> From: Sean Christopherson
>
> Background
> ==
>
> 1. SGX enclave pages are populated with data by copying from normal memory
>via ioctl() (SGX_IOC_ENCLAVE_ADD_PAGES), which will be added later in
>this series.
>
On Wed, Nov 04, 2020 at 04:54:15PM +0200, Jarkko Sakkinen wrote:
> The previous patch initialized a simple SGX page allocator. Add functions
> for runtime allocation and free.
>
> This allocator and its algorithms are as simple as it gets. They do a
> linear search across all EPC sections and
On Wed, Nov 04, 2020 at 09:09:03PM +0200, Jarkko Sakkinen wrote:
> If you want, I can do a resend of this version same time underlining
> that this the only difference and I do have a framework to check this
> thing in place.
No need - I'll simply reorder them here and see how far I'd get.
Thx.
On Wed, Nov 04, 2020 at 11:50:27AM +0800, Shuo A Liu wrote:
> On Tue 3.Nov'20 at 11:25:38 +0100, Borislav Petkov wrote:
> > On Tue, Nov 03, 2020 at 02:27:18PM +0800, Shuo A Liu wrote:
> > > The code just followed KVM style (see kvm_arch_para_features()).
> >
> > Do
On Wed, Nov 04, 2020 at 04:54:09PM +0200, Jarkko Sakkinen wrote:
> +static void __init sgx_init(void)
> +{
> + int i;
> +
> + if (!boot_cpu_has(X86_FEATURE_SGX))
Guys, you need to build-test *every* *single* patch - otherwise we break
bisectability and that is a no-no:
On Tue, Nov 03, 2020 at 12:47:39PM -0600, Segher Boessenkool wrote:
> > Oh well, should I open a low prio bug, would that help?
>
> Sure, thanks!
>
> > I probably should test with the latest gcc first, though...
>
> Yeah... FWIW, I tested with
> x86_64-linux-gcc (GCC) 11.0.0 20201015
On Tue, Nov 03, 2020 at 07:11:15PM +0100, Oleg Nesterov wrote:
> > I'm thinking copy_code() should not use copy_from_user_nmi() if former
> > can be called in non-atomic context too.
>
> I understand, but why do you think this makes sense?
Because the copy_from_user_nmi()'s name tells me that it
On Tue, Nov 03, 2020 at 06:47:44PM +0100, Oleg Nesterov wrote:
> > I'm thinking this should not use the atomic variant if it can get called
> > in !atomic context too.
>
> For what?
I'm thinking copy_code() should not use copy_from_user_nmi() if former
can be called in non-atomic context too.
On Tue, Nov 03, 2020 at 01:50:34PM +0100, Oleg Nesterov wrote:
> Another problem is that show_opcodes() makes no sense if user_mode(regs)
> and tsk is not current.
Because if not current, we would access *some* user address space but
not the one to which regs belong to?
> Try "echo t >
On Mon, Nov 02, 2020 at 05:18:09PM -0600, Segher Boessenkool wrote:
> That is invalid actually: local register asm as input to an inline asm
> should use *that* register!
>
> This is all correct until LRA ("reload"). Not that "movl %xmm0,$eax"
> works, but at least it screams its head off, as it
On Mon, Nov 02, 2020 at 11:02:10AM +1100, Anand K. Mistry wrote:
> > I like the idea of passing in the mode you want to check, but it appears
> > they are never used independently. The ibpb and stibp modes are always
> > checked together in one of the if statements below, so you could make this
>
On Tue, Nov 03, 2020 at 02:27:18PM +0800, Shuo A Liu wrote:
> The code just followed KVM style (see kvm_arch_para_features()).
Do you see Documentation/virt/kvm/cpuid.rst?
Now where is yours explaining what your hypervisor is doing?
> I can change to use
> cpuid_eax(acrn_cpuid_base() +
Hi Linus,
please pull a couple of SEV-ES hardening fixes against a malicious
hypervisor.
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:
On Mon, Nov 02, 2020 at 02:01:13PM -0600, Segher Boessenkool wrote:
> It just asks the general_operand function, which (for registers) accepts
> the hard registers that are accessible. This does include the float and
> vector etc. registers, normally.
>
> But you usually have a pseudo-register
On Fri, Oct 23, 2020 at 06:32:57PM +0200, Mauro Carvalho Chehab wrote:
> Kernel-doc markup should use this format:
> identifier - description
>
> Also, some enums are using wrong names at the kernel-doc
> markup.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
>
On Thu, Oct 01, 2020 at 03:04:48PM -0700, Andy Lutomirski wrote:
> On Thu, Oct 1, 2020 at 2:50 PM Dave Hansen wrote:
> > I'm not sure we should ever keep running userspace after an XRSTOR*
> > failure. For MPX, this might have provided a nice, additional vector
> > for an attacker to turn off
On Mon, Nov 02, 2020 at 12:10:00PM -0600, Segher Boessenkool wrote:
> movl works for moving anything g->r.
Right.
> This is not true for most insns, and not for most architectures at
> all (usually loading from memory has a separate mnemonic; moving an
> immediate number often as well (and it
On Mon, Nov 02, 2020 at 10:09:01AM -0600, Segher Boessenkool wrote:
> I think that will work for x86_64. But it won't matter much, most of
> the time you give an immediate number.
Yeah, my question is more along the lines of "is this constraint somehow
special, i.e., 'ir' (and not 'm') or can it
On Mon, Oct 19, 2020 at 02:17:50PM +0800, shuo.a@intel.com wrote:
> +static inline long acrn_hypercall0(unsigned long hcall_id)
> +{
> + long result;
> +
> + asm volatile("movl %1, %%r8d\n\t"
> + "vmcall\n\t"
> + : "=a" (result)
> + :
On Mon, Oct 19, 2020 at 02:17:49PM +0800, shuo.a@intel.com wrote:
> +bool acrn_is_privileged_vm(void)
> +{
> + return cpuid_eax(acrn_cpuid_base() | ACRN_CPUID_FEATURES) &
> + ACRN_FEATURE_PRIVILEGED_VM;
I asked in the previous review why that acrn_cpuid_base() is used
On Thu, Oct 29, 2020 at 04:32:43PM -0600, Shuah Khan wrote:
> > Because a patch should do one thing and one thing only. So a separate
> > patch which converts them all in one go should come ontop. But if you
> > insist for the ones I'm adding to have error handling, I can do that, of
> > course.
>
On Fri, Oct 30, 2020 at 12:08:07PM -0700, Luck, Tony wrote:
> On Fri, Oct 30, 2020 at 12:04:03PM -0700, Luck, Tony wrote:
>
> Bah, didn't notice this conversation didn't include LKML.
>
> > The Xeon versions of Sandy Bridge, Ivy Bridge and Haswell support an
> > optional additional error logging
On Fri, Oct 30, 2020 at 10:24:53AM +0900, Masami Hiramatsu wrote:
> What's the objdump say here?
The expected "bad":
0: c5 ec 95(bad)
3: b2 02 mov$0x2,%dl
5: bd 4b c8 a8 36 mov$0x36a8c84b,%ebp
a: b2 c5 mov
On Thu, Oct 29, 2020 at 04:32:43PM -0600, Shuah Khan wrote:
> if (numwritten < 1) {
> +perror("write failed");
>
> Please add filename to the error message.
Yes, you said so already and will do that in the next version.
--
Regards/Gruss,
Boris.
On Thu, Oct 29, 2020 at 03:38:43PM -0600, Shuah Khan wrote:
> All of the other ones should be changed as such. Why add more?
Because a patch should do one thing and one thing only. So a separate
patch which converts them all in one go should come ontop. But if you
insist for the ones I'm adding
On Wed, Oct 28, 2020 at 04:45:49PM -0400, Arvind Sankar wrote:
> It's become ABI I think: looks like it's included by that name in
> vmcoreinfo for kexec crash dumps.
Yeah, last time we had the ABI discussion we agreed with the kexec/crash
folks that this is not an ABI and that crash is "tied"
From: Borislav Petkov
... and stop poking at the MSR directly.
Signed-off-by: Borislav Petkov
---
.../x86_energy_perf_policy.c | 109 --
1 file changed, 99 insertions(+), 10 deletions(-)
diff --git a/tools/power/x86/x86_energy_perf_policy
From: Borislav Petkov
... instead of poking at the MSR. For that, move the accessor functions
to misc.c and add a sysfs-writing function too.
There should be no functional changes resulting from this.
Signed-off-by: Borislav Petkov
Cc: Thomas Renninger
Cc: Shuah Khan
---
tools/power
From: Borislav Petkov
... instead of poking at the MSR directly.
Signed-off-by: Borislav Petkov
Cc: Len Brown
Cc: linux...@vger.kernel.org
---
tools/power/x86/turbostat/turbostat.c | 29 ++-
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/tools/power
From: Borislav Petkov
Now that all in-kernel-tree users are converted to using the sysfs file,
remove the MSR from the "allowlist".
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/msr.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/kernel/msr.c b/arch/x86/ke
From: Borislav Petkov
Hi,
here's v2 with some of Shuah's comments integrated.
If no one has anything against it, I'll route them all through tip.
Thx.
---
Changelog:
v0:
--
here's something from my todo list: remove all in-kernel tools use of
that MSR and lastly drop it from the allowed
Hi Masami,
On Sat, Oct 24, 2020 at 01:27:41AM +0200, Borislav Petkov wrote:
> @@ -230,14 +231,20 @@ void insn_get_prefixes(struct insn *insn)
> * If necessary, first collects any preceding (prefix) bytes.
> * Sets @insn->opcode.value = opcode1. No effect if @insn->opcode.got
&
The following commit has been merged into the x86/cleanups branch of tip:
Commit-ID: 0d847ce7c17613d63401ac82336ee1d5df749120
Gitweb:
https://git.kernel.org/tip/0d847ce7c17613d63401ac82336ee1d5df749120
Author:Borislav Petkov
AuthorDate:Wed, 21 Oct 2020 18:39:47 +02:00
On Wed, Oct 28, 2020 at 12:45:51PM -0400, Arvind Sankar wrote:
> You don't want to try to run the kernel from physical address 0 in any
> case. The default is set to 16MiB to avoid low memory, historically to
> avoid the 24-bit ISA DMA range.
Sure, that's why I wrote:
"... so I guess this should
On Tue, Oct 27, 2020 at 05:14:22PM -0400, Arvind Sankar wrote:
> This is indeed just a small correctness fixlet, but I'm not following
> the rest of your comments.
I'm just trying to make sense of that house of cards we have here.
> PHYSICAL_START has an effect independent of the setting of
>
On Mon, Oct 05, 2020 at 11:15:39AM -0400, Arvind Sankar wrote:
> Commit b4e0409a36f4 ("x86: check vmlinux limits, 64-bit") added a check
> that the size of the 64-bit kernel is less than KERNEL_IMAGE_SIZE.
>
> The check uses (_end - _text), but this is not enough. The initial PMD
> used in
GFP_KERNEL);
> + new = krealloc_array(hw->dimms, hw->num_dimms + 16,
> + sizeof(struct dimm_info), GFP_KERNEL);
> if (!new) {
> WARN_ON_ONCE(1);
>
On Wed, Oct 14, 2020 at 12:49:27AM +, Fenghua Yu wrote:
> +static const struct mbm_correction_factor_table {
> + u32 rmidthreshold;
> + u64 cf;
> +} mbm_cf_table[] = {
That thing wants to be __initdata, AFAICT, since the only function
touching it is __init.
Made it so.
--
On Tue, Oct 27, 2020 at 08:20:00AM -0700, Dave Hansen wrote:
> I can't think of a *lot* of spots where we have sanity checks like this
> for memory. We have cgroups and the overcommit limits. But, in
> general, folks can allocate as much memory as they want until
> allocations start to fail.
>
>
On Sat, Oct 24, 2020 at 09:10:25AM -0700, Andy Lutomirski wrote:
> I can pretty much guarantee that a real modern CPU is able to decode a
> <15 byte instruction that is followed by unmapped or non-executable
> pages. I don't know specifically how the CPU implements it, but it
> works.
Yes, so
On Wed, Oct 21, 2020 at 02:39:38PM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> MMIO memory is usually not mapped encrypted, so there is no reason to
> support emulated MMIO when it is mapped encrypted.
>
> This prevents a possible hypervisor attack where it maps a RAM page as
On Wed, Oct 21, 2020 at 02:39:37PM +0200, Joerg Roedel wrote:
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index ebb7edc8bc0a..bd9b62af2e3d 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -39,6 +39,7 @@
> */
> u64 sme_me_mask
On Wed, Oct 21, 2020 at 02:39:36PM +0200, Joerg Roedel wrote:
> diff --git a/arch/x86/kernel/sev_verify_cbit.S
> b/arch/x86/kernel/sev_verify_cbit.S
> new file mode 100644
> index ..5075458ecad0
> --- /dev/null
> +++ b/arch/x86/kernel/sev_verify_cbit.S
Why a separate file? You're
On Wed, Oct 21, 2020 at 02:39:36PM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Check whether the hypervisor reported the correct C-bit when running as
> an SEV guest. Using a wrong C-bit position could be used to leak
> sensitive data from the guest to the hypervisor.
>
> The check
On Wed, Oct 21, 2020 at 02:39:35PM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> The early #VC handler which doesn't have a GHCB can only handle CPUID
> exit codes. It is needed by the early boot code to handle #VC
> exceptions raised in verify_cpu() and to get the position of the C
> bit.
On Mon, Oct 26, 2020 at 02:26:13PM -0700, Dave Hansen wrote:
> What were you concerned about here? Was it how long the syscall could
> take, or that one user could exhaust all the enclave memory in one call?
More the latter. And generally, to have a sanity-check on all requests
coming from
On Wed, Oct 21, 2020 at 02:39:34PM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Introduce sev_status and initialize it together with sme_me_mask to have
> an indicator which SEV features are enabled.
>
> Signed-off-by: Joerg Roedel
> ---
> arch/x86/boot/compressed/mem_encrypt.S | 10
On Mon, Oct 19, 2020 at 12:35:24PM -0700, t...@redhat.com wrote:
> From: Tom Rix
>
> A break is not needed if it is preceded by a return
>
> Signed-off-by: Tom Rix
> ---
> drivers/edac/amd64_edac.c | 8
> 1 file changed, 8 deletions(-)
Applied, thanks.
--
Regards/Gruss,
Boris.
Hi Linus,
please pull three SEV-ES fixes for 5.10. They got ready around the same
time the merge window opened so I gave them some additional testing and
soaking time before sending them your way.
Please pull,
thx.
---
The following changes since commit da9803dfd3955bd2f9909d55e23f188ad76dbe58:
On Sat, Oct 24, 2020 at 04:13:15PM +0900, Masami Hiramatsu wrote:
> Thanks, so will you split this into several patches, since I saw some
> cleanups in this patch?
Oh, most definitely. This was just a preview of where this is going...
> Yeah, that's good to me because in the most cases, user
On Fri, Oct 23, 2020 at 05:12:49PM -0700, Andy Lutomirski wrote:
> I disagree. A real CPU does exactly what I'm describing. If I stick
A real modern CPU fetches up to 32 bytes insn window which it tries
to decode etc. I don't know, though, what it does when that fetch
encounters a fault - I
insn_decode_fully();
Ok, good night and good luck. :-)
Author: Borislav Petkov
Date: Fri Oct 23 12:15:59 2020 +0200
insn: Reorg
- Rename insn_decode() to insn_decode_regs() to denote that it receives
regs as param and free the name for the generic version.
- intel/ds.c
On Fri, Oct 23, 2020 at 06:28:50PM +0900, Masami Hiramatsu wrote:
> OK, would you think we also better to integrate it with insn_init()?
That kinda makes sense because it would obviate the need to call it
as user of the interface but simply do insn_decode() which will do
everything for you. Lemme
On Thu, Oct 22, 2020 at 10:58:32AM -0700, Andy Lutomirski wrote:
> I'm guessing that the confusion here is that the kernel instruction
> decoder was originally designed to be used to decode kernel
> instructions, which are generally trusted to be valid, but that it's
> starting to be used to
On Thu, Oct 22, 2020 at 10:21:40PM +0900, Masami Hiramatsu wrote:
> extern void insn_init(struct insn *insn, const void *kaddr, int buf_len, int
> x86_64);
> extern void insn_get_prefixes(struct insn *insn);
> extern void insn_get_opcode(struct insn *insn);
> extern void insn_get_modrm(struct
On Wed, Oct 21, 2020 at 06:11:09AM -0700, Srinivas Pandruvada wrote:
> That is the problem. There is no public document.
Well, considering how important this functionality has become, maybe
they should be made public and maybe there should be a kernel undervolt
driver, as peterz suggests.
> > I
On Thu, Oct 22, 2020 at 04:31:00PM +0900, Masami Hiramatsu wrote:
> No, insn_get_length() implies it decodes whole of the instruction.
> (yeah, we need an alias of that, something like insn_get_complete())
That's exactly what I'm trying to point out: the whole API is not
entirely wrong - it just
On Wed, Oct 21, 2020 at 03:25:06PM -0700, Kees Cook wrote:
> It was a fix for the series Ingo took, so I seemed sensible to keep it
> together. Though at this point, I don't care who takes it. :)
That series is upstream already, I presume. And then it probably doesn't
matter who takes it...
Thx.
On Wed, Oct 21, 2020 at 01:04:35PM -0700, Kees Cook wrote:
> [thread ping: x86 maintainers, can someone please take this?]
$ ./scripts/get_maintainer.pl -f include/asm-generic/vmlinux.lds.h
Arnd Bergmann (maintainer:GENERIC INCLUDE/ASM HEADER FILES)
...
so that's Arnd's AFAICT.
--
From: Borislav Petkov
Commit
bb8187d35f82 ("MCA: delete all remaining traces of microchannel bus support.")
removed the remaining traces of Micro Channel Architecture support but
one trace remained - three variables in setup.c which have been unused
since 2012 at least.
Drop th
On Wed, Oct 21, 2020 at 11:26:13PM +0900, Masami Hiramatsu wrote:
> Hmm, I meant someone might think it can be used for filtering the
> instruction something like,
>
> insn_init(insn, buf, buflen, 1);
> ret = insn_get_length(insn);
> if (!ret) {
> /* OK, this is safe */
>
On Wed, Oct 21, 2020 at 09:50:13AM +0900, Masami Hiramatsu wrote:
> Agreed. So I'm OK for returning the result of "decoding".
> But we also need to note that the returning success doesn't
> mean the instruction is valid. That needs another validator.
>
...
>
> Yes, so let's add the return value
On Tue, Oct 20, 2020 at 10:21:48AM -0700, Srinivas Pandruvada wrote:
> These command id are model specific. There is no guarantee that even
> meaning changes. So I don't think we should write any code in kernel
> which can't stick.
Ok, is there a common *set* of values present on all models?
A
On Tue, Oct 20, 2020 at 11:27:00PM +0900, Masami Hiramatsu wrote:
> So, if this return value is optional, it is OK to me. But the success
> return value does NOT mean it a correctly encoded instruction.
Ok, so what is the correct way to find out whether the decoding was
successful?
Because as it
Hi guys,
this has come up a couple of times in the past, how about if those insn
decoder functions returned an error value so that callers can use that
instead of looking at different insn...got fields whether a certain
subset of the insn got decoded properly or not?
Here's a dirty diff to show
On Mon, Oct 19, 2020 at 09:08:03PM -0700, Dan Williams wrote:
> The COPY_MC_TEST facility has served its purpose for validating the
> early termination conditions of the copy_mc_fragile() implementation.
> Remove it and the EXPORT_SYMBOL_GPL of copy_mc_fragile().
>
> Reported-by:
On Mon, Oct 19, 2020 at 01:12:59PM -0400, Arvind Sankar wrote:
> No real reason. This will disappear anyway in the cleanup patch.
Ok, I'll change it to the MOV as it is less confusing, at least to me
:), this way.
Thx.
--
Regards/Gruss,
Boris.
On Tue, Sep 08, 2020 at 06:02:05PM -0700, Srinivas Pandruvada wrote:
> The actual OC mailbox implementation itself is implemented in Linux in
> intel_turbo_max_3 driver. So that is public.
> So someone can develop a driver and provide some sysfs to send mailbox
> commands, but kernel can't
On Fri, Oct 16, 2020 at 04:04:01PM -0400, Arvind Sankar wrote:
> Commits
>
> ca0e22d4f011 ("x86/boot/compressed/64: Always switch to own page table")
> 8570978ea030 ("x86/boot/compressed/64: Don't pre-map memory in KASLR code")
>
> set up a new page table in the decompressor stub, but
On Mon, Oct 19, 2020 at 11:45:58AM +0300, Jarkko Sakkinen wrote:
> On Sat, Oct 03, 2020 at 07:50:43AM +0300, Jarkko Sakkinen wrote:
> > +config INTEL_SGX
>
> Since the directory for this was renamed some iterations ago from
> arch/x86/kernel/cpu/sgx to intel_sgx given the feedback from Boris,
>
On Mon, Oct 19, 2020 at 03:27:48AM +0530, Jeffrin Jose T wrote:
> On Sun, 2020-10-18 at 23:03 +0200, Borislav Petkov wrote:
> > On Mon, Oct 19, 2020 at 01:51:34AM +0530, Jeffrin Jose T wrote:
> > > On Sun, 2020-10-18 at 19:49 +0200, Borislav Petkov wrote:
> > > > On S
On Mon, Oct 19, 2020 at 01:51:34AM +0530, Jeffrin Jose T wrote:
> On Sun, 2020-10-18 at 19:49 +0200, Borislav Petkov wrote:
> > On Sun, Oct 18, 2020 at 10:42:39PM +0530, Jeffrin Jose T wrote:
> > > smpboot: Scheduler frequency invariance went wobbly, disabling!
> > > [
On Sun, Oct 18, 2020 at 10:42:39PM +0530, Jeffrin Jose T wrote:
> smpboot: Scheduler frequency invariance went wobbly, disabling!
> [ 1112.592866] unchecked MSR access error: RDMSR from 0x123 at rIP:
> 0xb5c9a184 (native_read_msr+0x4/0x30)
> [ 1112.592869] Call Trace:
> [ 1112.592876]
On Sun, Oct 18, 2020 at 05:21:28AM +, Aisheng Dong wrote:
> Not sure if EDAC could be a better place.
> e.g.
> drivers/edac/sifive_edac.c
I don't see how this functionality has anything to do with EDAC.
> If not, maybe we can put in 'soc' first.
Or drivers/misc/
--
Regards/Gruss,
901 - 1000 of 23602 matches
Mail list logo
