Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Ricardo Neri]

On Fri, 2016-11-11 at 23:51 +0300, Stas Sergeev wrote:
> 11.11.2016 07:14, Ricardo Neri пишет:
> >> 10.11.2016 09:46, Ricardo Neri пишет:
> >>> I took a closer look at the dosemu code. It appears that it does not
> >>> purposely utilize SGDT to obtain the descriptor table while in vm86. It
> >>> does use SGDT (in protected mode) to emulate certain functionality such
> >>> as the Virtual xxx Driver. In such a case, UMIP needs to be disabled.
> >>> However, this code seems to be disabled [1].
> >> Indeed.
> >> The code you've found, was copied from wine, because
> >> dosemu supports windows-3.1. But sgdt is in win32s part
> >> that is disabled in dosemu. It is however enabled in wine, or
> >> at least it was when I ported the VxD code from there. So you
> >> may want to ask wine devs if they still use sgdt and vm86.
> >> In dosemu, if we ever enable win32s support, we won't rely
> >> on sgdt. In fact, when some prot mode program under dosemu
> >> uses GDT selectors, in a fault handler we replace them with
> >> LDT selectors.
> > Actually, the SLDT instruction is also impacted by this feature. This
> We do not support programs that do SLDT.
> The "polite" programs use special DPMI API extension to get
> the selector that covers LDT. That allows us to manage an "ldt
> alias" - memory buffer where we emulate LDT by write-protecting it.
> If we ever support SLDT, we would very much like to trap it
> and provide the pointer to our alias. Some very old dos extenders
> for 286 may start to work with such change, that are currently
> unsupported.

I see.
> 
> > feature, will cause a GP fault if the instructions SGDT, SLDT, SIDT,
> > SMSW or STR are executed with CPL > 0. Would this be a problem for
> > dosemu?
> I am only a bit unsure about SMSW; the rest should be safe.
> Maybe some odd prog would use SMSW to check for FPU?
> Or to check for v86 mode by checking the PE bit?
> I am sure this is very uncommon, and if we find such prog, we
> can add an emulation of that instruction. I am pretty sure no one
> would get sufficiently hurt, but there will likely be 1-2 bug reports
> in our tracker, because if something is possible, then some DOS
> prog did that. :)

Fair enough.
> 
> >   The proposal now is to trap this GPU fault and give fake value
> > for these tables.
> If this fake value will be cooked up by the kernel without delivering
> the signal to dosemu process, then I don't see any problem at all.

Yes, the GP fault will be trapped in the kernel and not delivered to the
user space. All the user space will see is the fake value given by the
kernel.
> Of course you can provide the sane value for smsw.
> If that will go up to dosemu, then some coding may be needed
> on the user-space side.
> 
> > This is good news. This means that we could go ahead and give a fake
> > pointer to the GDT and the other impacted tables?
> Definitely.
> What these fake tables will look like, btw?
> Will they somehow resemble the real ones?
> Visible to user-space?
Since the intention is to hide these tables from the user space, I was
planning on giving 0x0 to all of it.

Thanks and BR,
Ricardo


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] x86/cpufeature: Add User-Mode Instruction Prevention definitions

[Ricardo Neri]

On Fri, 2016-11-11 at 11:22 +0100, Borislav Petkov wrote:
> On Thu, Nov 10, 2016 at 08:08:07PM -0800, Ricardo Neri wrote:
> > UMIP is enabled by setting a bit in CR4. If that bit is not supposed
> > to be set, that could cause a #GP fault.
> 
> Yeah, you do check CPUID first, AFAICT, so you should be ok...

Right. I missed this detail. Yes, there should not be a problem.
> 
> -- 
> Regards/Gruss,
> Boris.
> 
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 
> 21284 (AG Nürnberg)


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Stas Sergeev]

11.11.2016 07:14, Ricardo Neri пишет:

10.11.2016 09:46, Ricardo Neri пишет:

I took a closer look at the dosemu code. It appears that it does not
purposely utilize SGDT to obtain the descriptor table while in vm86. It
does use SGDT (in protected mode) to emulate certain functionality such
as the Virtual xxx Driver. In such a case, UMIP needs to be disabled.
However, this code seems to be disabled [1].

Indeed.
The code you've found, was copied from wine, because
dosemu supports windows-3.1. But sgdt is in win32s part
that is disabled in dosemu. It is however enabled in wine, or
at least it was when I ported the VxD code from there. So you
may want to ask wine devs if they still use sgdt and vm86.
In dosemu, if we ever enable win32s support, we won't rely
on sgdt. In fact, when some prot mode program under dosemu
uses GDT selectors, in a fault handler we replace them with
LDT selectors.

Actually, the SLDT instruction is also impacted by this feature. This

We do not support programs that do SLDT.
The "polite" programs use special DPMI API extension to get
the selector that covers LDT. That allows us to manage an "ldt
alias" - memory buffer where we emulate LDT by write-protecting it.
If we ever support SLDT, we would very much like to trap it
and provide the pointer to our alias. Some very old dos extenders
for 286 may start to work with such change, that are currently
unsupported.


feature, will cause a GP fault if the instructions SGDT, SLDT, SIDT,
SMSW or STR are executed with CPL > 0. Would this be a problem for
dosemu?

I am only a bit unsure about SMSW; the rest should be safe.
Maybe some odd prog would use SMSW to check for FPU?
Or to check for v86 mode by checking the PE bit?
I am sure this is very uncommon, and if we find such prog, we
can add an emulation of that instruction. I am pretty sure no one
would get sufficiently hurt, but there will likely be 1-2 bug reports
in our tracker, because if something is possible, then some DOS
prog did that. :)


  The proposal now is to trap this GPU fault and give fake value
for these tables.

If this fake value will be cooked up by the kernel without delivering
the signal to dosemu process, then I don't see any problem at all.
Of course you can provide the sane value for smsw.
If that will go up to dosemu, then some coding may be needed
on the user-space side.


This is good news. This means that we could go ahead and give a fake
pointer to the GDT and the other impacted tables?

Definitely.
What these fake tables will look like, btw?
Will they somehow resemble the real ones?
Visible to user-space?
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 2/2] thinkpad_acpi: Add support for X1 Yoga (2016) Tablet Mode

[Lyude]

For whatever reason, the X1 Yoga doesn't support the normal method of
querying for tablet mode. Instead of providing the MHKG method under the
hotkey handle, we're instead given the CMMD method under the EC handle.
Values on this handle are either 0x1, laptop mode, or 0x6, tablet mode.

Tested-by: Daniel Martin 
Signed-off-by: Lyude 
---
Changes since v4:
 - Get rid of patch #2
 - Add BIOS model
 - Update documentation

 Documentation/laptops/thinkpad-acpi.txt |  1 +
 drivers/platform/x86/thinkpad_acpi.c| 39 +
 2 files changed, 36 insertions(+), 4 deletions(-)

diff --git a/Documentation/laptops/thinkpad-acpi.txt 
b/Documentation/laptops/thinkpad-acpi.txt
index 72a150d..ba2e7d2 100644
--- a/Documentation/laptops/thinkpad-acpi.txt
+++ b/Documentation/laptops/thinkpad-acpi.txt
@@ -540,6 +540,7 @@ Events that are propagated by the driver to userspace:
 0x6022 ALARM: a sensor is extremely hot
 0x6030 System thermal table changed
 0x6040 Nvidia Optimus/AC adapter related (TO BE VERIFIED)
+0x60C0 X1 Yoga 2016, Tablet mode status changed
 
 Battery nearly empty alarms are a last resort attempt to get the
 operating system to hibernate or shutdown cleanly (0x2313), or shutdown
diff --git a/drivers/platform/x86/thinkpad_acpi.c 
b/drivers/platform/x86/thinkpad_acpi.c
index de4e734..700b8c8 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -190,6 +190,9 @@ enum tpacpi_hkey_event_t {
TP_HKEY_EV_LID_OPEN = 0x5002, /* laptop lid opened */
TP_HKEY_EV_TABLET_TABLET= 0x5009, /* tablet swivel up */
TP_HKEY_EV_TABLET_NOTEBOOK  = 0x500a, /* tablet swivel down */
+   TP_HKEY_EV_TABLET_CHANGED   = 0x60c0, /* X1 Yoga (2016):
+  * enter/leave tablet mode
+  */
TP_HKEY_EV_PEN_INSERTED = 0x500b, /* tablet pen inserted */
TP_HKEY_EV_PEN_REMOVED  = 0x500c, /* tablet pen removed */
TP_HKEY_EV_BRGHT_CHANGED= 0x5010, /* backlight control event */
@@ -305,6 +308,8 @@ static struct {
enum {
TP_HOTKEY_TABLET_NONE = 0,
TP_HOTKEY_TABLET_USES_MHKG,
+   /* X1 Yoga 2016, seen on BIOS N1FET44W */
+   TP_HOTKEY_TABLET_USES_CMMD,
} hotkey_tablet;
u32 kbdlight:1;
u32 light:1;
@@ -2062,6 +2067,8 @@ static void hotkey_poll_setup(const bool may_warn);
 
 /* HKEY.MHKG() return bits */
 #define TP_HOTKEY_TABLET_MASK (1 << 3)
+/* ThinkPad X1 Yoga (2016) */
+#define TP_EC_CMMD_TABLET_MODE 0x6
 
 static int hotkey_get_wlsw(void)
 {
@@ -2086,10 +2093,23 @@ static int hotkey_get_tablet_mode(int *status)
 {
int s;
 
-   if (!acpi_evalf(hkey_handle, , "MHKG", "d"))
-   return -EIO;
+   switch (tp_features.hotkey_tablet) {
+   case TP_HOTKEY_TABLET_USES_MHKG:
+   if (!acpi_evalf(hkey_handle, , "MHKG", "d"))
+   return -EIO;
+
+   *status = ((s & TP_HOTKEY_TABLET_MASK) != 0);
+   break;
+   case TP_HOTKEY_TABLET_USES_CMMD:
+   if (!acpi_evalf(ec_handle, , "CMMD", "d"))
+   return -EIO;
+
+   *status = (s == TP_EC_CMMD_TABLET_MODE);
+   break;
+   default:
+   break;
+   }
 
-   *status = ((s & TP_HOTKEY_TABLET_MASK) != 0);
return 0;
 }
 
@@ -3125,11 +3145,16 @@ static int hotkey_init_tablet_mode(void)
int in_tablet_mode, res;
char *type;
 
-   /* For X41t, X60t, X61t Tablets... */
if (acpi_evalf(hkey_handle, , "MHKG", "qd")) {
+   /* For X41t, X60t, X61t Tablets... */
tp_features.hotkey_tablet = TP_HOTKEY_TABLET_USES_MHKG;
in_tablet_mode = !!(res & TP_HOTKEY_TABLET_MASK);
type = "MHKG";
+   } else if (acpi_evalf(ec_handle, , "CMMD", "qd")) {
+   /* For X1 Yoga (2016) */
+   tp_features.hotkey_tablet = TP_HOTKEY_TABLET_USES_CMMD;
+   in_tablet_mode = res == TP_EC_CMMD_TABLET_MODE;
+   type = "CMMD";
}
 
if (!tp_features.hotkey_tablet)
@@ -3921,6 +3946,12 @@ static bool hotkey_notify_6xxx(const u32 hkey,
*ignore_acpi_ev = true;
return true;
 
+   case TP_HKEY_EV_TABLET_CHANGED:
+   tpacpi_input_send_tabletsw();
+   hotkey_tablet_mode_notify_change();
+   *send_acpi_ev = false;
+   break;
+
default:
pr_warn("unknown possible thermal alarm or keyboard event 
received\n");
known = false;
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: [PATCH 1/4] x86/cpufeature: Add User-Mode Instruction Prevention definitions

[Dave Hansen]

On 11/10/2016 08:08 PM, Ricardo Neri wrote:
> Thanks for the suggestions. Perhaps I can include these metrics in my
> V2. On th other hand, Dave Hansen gave a good argument on potential
> conflicts when, of instance running on an AMD CPU. UMIP is enabled by
> setting a bit in CR4. If that bit is not supposed to be set, that could
> cause a #GP fault.

I just meant that some folks probably appreciate being able to build out
all the Intel-specific features.  Not that it causes a functional problem.


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v3 10/20] Add support to access boot related data in the clear

[Kani, Toshimitsu]

On Wed, 2016-11-09 at 18:36 -0600, Tom Lendacky wrote:
> Boot data (such as EFI related data) is not encrypted when the system
> is booted and needs to be accessed unencrypted.  Add support to apply
> the proper attributes to the EFI page tables and to the
> early_memremap and memremap APIs to identify the type of data being
> accessed so that the proper encryption attribute can be applied.
 :
> +static bool memremap_apply_encryption(resource_size_t phys_addr,
> +   unsigned long size)
> +{
> + /* SME is not active, just return true */
> + if (!sme_me_mask)
> + return true;
> +
> + /* Check if the address is part of the setup data */
> + if (memremap_setup_data(phys_addr, size))
> + return false;
> +
> + /* Check if the address is part of EFI boot/runtime data */
> + switch (efi_mem_type(phys_addr)) {
> + case EFI_BOOT_SERVICES_DATA:
> + case EFI_RUNTIME_SERVICES_DATA:
> + return false;
> + }
> +
> + /* Check if the address is outside kernel usable area */
> + switch (e820_get_entry_type(phys_addr, phys_addr + size -
> 1)) {
> + case E820_RESERVED:
> + case E820_ACPI:
> + case E820_NVS:
> + case E820_UNUSABLE:
> + return false;
> + }
> +
> + return true;
> +}

Are you supporting encryption for E820_PMEM ranges?  If so, this
encryption will persist across a reboot and does not need to be
encrypted again, right?  Also, how do you keep a same key across a
reboot?

Thanks,
-ToshiN�r��yb�X��ǧv�^�)޺{.n�+{�v�"��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�

Re: [RESEND PATCH v1 02/11] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Sysctrl and Djtag dts bindings

[Anurup M]

On Friday 11 November 2016 05:23 PM, Mark Rutland wrote:

On Fri, Nov 11, 2016 at 04:49:03PM +0530, Anurup M wrote:

On Thursday 10 November 2016 10:53 PM, Mark Rutland wrote:

On Thu, Nov 03, 2016 at 01:41:58AM -0400, Anurup M wrote:

diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt 
b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
+Example:
+   /* for Hisilicon HiP05 djtag for CPU sysctrl */
+   djtag0: djtag@8001 {
+   compatible = "hisilicon,hip05-cpu-djtag-v1";
+   reg = <0x0 0x8001 0x0 0x1>;
+
+   /* For L3 cache PMU */
+   pmul3c0 {
+   compatible = "hisilicon,hisi-pmu-l3c-v1";
+   scl-id = <0x02>;
+   num-events = <0x16>;
+   num-counters = <0x08>;
+   module-id = <0x04>;
+   num-banks = <0x04>;
+   cfgen-map = <0x02 0x04 0x01 0x08>;
+   counter-reg = <0x170>;
+   evctrl-reg = <0x04>;
+   event-en = <0x100>;
+   evtype-reg = <0x140>;
+   };

This sub-node needs a binding document.

These properties are completely opaque

The L3 cache PMU bindings are defined @bindings/arm/hisilicon/pmu.txt.
Is it OK that I document here(hisilicon/djtag.txt), a reference to
the PMU bindings doc ?

At this point in the series, that file does not exist yet, and this is
an undocumented beinding.

Please introduce this sub-node long with the PMU bindings, later in the
series.

Thanks, I got your suggestion. Will add this later in series.

Thanks,
Mark.


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH v1 02/11] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Sysctrl and Djtag dts bindings

[Mark Rutland]

On Fri, Nov 11, 2016 at 04:49:03PM +0530, Anurup M wrote:
> On Thursday 10 November 2016 10:53 PM, Mark Rutland wrote:
> >On Thu, Nov 03, 2016 at 01:41:58AM -0400, Anurup M wrote:

> >>diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt 
> >>b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt

> >>+Example:
> >>+   /* for Hisilicon HiP05 djtag for CPU sysctrl */
> >>+   djtag0: djtag@8001 {
> >>+   compatible = "hisilicon,hip05-cpu-djtag-v1";
> >>+   reg = <0x0 0x8001 0x0 0x1>;
> >>+
> >>+   /* For L3 cache PMU */
> >>+   pmul3c0 {
> >>+   compatible = "hisilicon,hisi-pmu-l3c-v1";
> >>+   scl-id = <0x02>;
> >>+   num-events = <0x16>;
> >>+   num-counters = <0x08>;
> >>+   module-id = <0x04>;
> >>+   num-banks = <0x04>;
> >>+   cfgen-map = <0x02 0x04 0x01 0x08>;
> >>+   counter-reg = <0x170>;
> >>+   evctrl-reg = <0x04>;
> >>+   event-en = <0x100>;
> >>+   evtype-reg = <0x140>;
> >>+   };
> >This sub-node needs a binding document.
> >
> >These properties are completely opaque
> The L3 cache PMU bindings are defined @bindings/arm/hisilicon/pmu.txt.
> Is it OK that I document here(hisilicon/djtag.txt), a reference to
> the PMU bindings doc ?

At this point in the series, that file does not exist yet, and this is
an undocumented beinding.

Please introduce this sub-node long with the PMU bindings, later in the
series.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v3 03/20] x86: Add the Secure Memory Encryption cpu feature

[Borislav Petkov]

On Wed, Nov 09, 2016 at 06:34:59PM -0600, Tom Lendacky wrote:
> Update the cpu features to include identifying and reporting on the

Here and for all other commit messages:

s/cpu/CPU/g

> Secure Memory Encryption feature.
> 

...

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Ksummit-discuss] Including images on Sphinx documents

[Markus Heiser]

Am 11.11.2016 um 12:22 schrieb Jani Nikula :

> On Thu, 10 Nov 2016, Jani Nikula  wrote:
>> On Thu, 10 Nov 2016, Markus Heiser  wrote:
>>> Could this POC persuade you, if so, I send a more elaborate RFC,
>>> what do you think about?
>> 
>> Sorry, I do not wish to be part of this.
> 
> That was uncalled for, apologies.

It's OK, sometimes we are all in a hurry and want shorten things.

> Like I said, I don't think this is the right approach. Call it an
> unsubstantiated gut feel coming from experience.

Yes, building a bunch of symbolic links "smells". Unfortunately,
I currently see no other solution to solve the conflict of 
Linux's "O=/foo" and Sphinx's "sourcedir", so that was my
proposal.

> However, I do not have
> the time to properly dig into this either, and that frustrates me. I
> wish I could be more helpful, but I can't right now.

its a pity

-- Markus --
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Ksummit-discuss] Including images on Sphinx documents

[Jani Nikula]

On Thu, 10 Nov 2016, Jani Nikula  wrote:
> On Thu, 10 Nov 2016, Markus Heiser  wrote:
>> Could this POC persuade you, if so, I send a more elaborate RFC,
>> what do you think about?
>
> Sorry, I do not wish to be part of this.

That was uncalled for, apologies.

Like I said, I don't think this is the right approach. Call it an
unsubstantiated gut feel coming from experience. However, I do not have
the time to properly dig into this either, and that frustrates me. I
wish I could be more helpful, but I can't right now.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] x86/cpufeature: Add User-Mode Instruction Prevention definitions

[Borislav Petkov]

On Thu, Nov 10, 2016 at 08:08:07PM -0800, Ricardo Neri wrote:
> UMIP is enabled by setting a bit in CR4. If that bit is not supposed
> to be set, that could cause a #GP fault.

Yeah, you do check CPUID first, AFAICT, so you should be ok...

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Ksummit-discuss] Including images on Sphinx documents

[Mauro Carvalho Chehab]

Em Wed, 09 Nov 2016 13:58:12 +0200
Jani Nikula  escreveu:

> On Wed, 09 Nov 2016, Markus Heiser  wrote:
> > Am 09.11.2016 um 12:16 schrieb Jani Nikula :  
> >>> So I vote for :
> >>>   
>  1) copy (or symlink) all rst files to Documentation/output (or to the
>  build dir specified via O= directive) and generate the *.pdf there,
>  and produce those converted images via Makefile.;  
> >> 
> >> We're supposed to solve problems, not create new ones.  
> >
> > ... new ones? ...  
> 
> Handle in-tree builds without copying.
> 
> Make dependency analysis with source rst and "intermediate" rst work.
> 
> Make sure your copying gets the timestamps right.
> 
> Make Sphinx dependency analysis look at the right copies depending on
> in-tree vs. out-of-tree. Generally make sure it doesn't confuse Sphinx's
> own dependency analysis.

I agree with Jani here: copy the files will make Sphinx recompile
the entire documentation every time, with is bad. Ok, Some Makefile
logic could be added to copy only on changes, but that will increase
the Makefile complexity.

So, I prefer not using copy. As I said before, a Sphinx extension that
would make transparent for PDF document generation when a non-PDF image
is included, doing whatever conversion needed, seems to be the right fix 
here, but someone would need to step up and write such extension.

-- 

Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html