On lun., 2013-03-18 at 17:32 -0400, Matthew Garrett wrote:
This patch introduces CAP_COMPROMISE_KERNEL. Holding this capability
indicates that a process is empowered to perform tasks that may result
in
modification of the running kernel. While aimed at handling the
specific
use-case of
On mer., 2013-03-06 at 21:30 -0300, Henrique de Moraes Holschuh wrote:
On Mon, 04 Mar 2013, Borislav Petkov wrote:
I get this in dmesg with 3.9-rc1:
[ 12.951434] thinkpad_acpi: unhandled HKEY event 0x6050
[ 12.951438] thinkpad_acpi: please report the conditions when this
event
On lun., 2013-01-28 at 11:42 -0500, Matthew Garrett wrote:
Secure boot makes it possible to ensure that the on-disk representation of
the kernel hasn't been modified. This can be sidestepped if the in-memory
representation can be trivially altered. We currently have a large number
of
On mer., 2013-07-17 at 10:51 -0500, Felipe Contreras wrote:
On Sat, Jun 22, 2013 at 4:46 PM, Yves-Alexis Perez cor...@debian.org wrote:
Before Linux support for acpi_osi(Windows 2012) (and when booting with
acpi_osi=!Windows 2012), brightness keys were handled by the kernel
just fine
On mer., 2013-09-11 at 08:45 +, Matthew Garrett wrote:
On Wed, 2013-09-11 at 11:45 +0300, Jani Nikula wrote:
Before plunging forward, have you observed any difference between the
boot modes? We have reports [1] that the backlight behaviour is
different with UEFI vs. UEFI+CSM or legacy
On sam., 2013-10-12 at 01:27 +0200, Rafael J. Wysocki wrote:
If we are to use a Kconfig option, why don't we use one instead of rather than
in addition to a command line option? Say, we have
CONFIG_ACPI_VIDEO_WIN8_WORKAROUND and if that is set, the code will work like
the previous version of
On sam., 2013-10-12 at 00:10 +0200, Rafael J. Wysocki wrote:
On Friday, October 11, 2013 12:42:43 PM Josh Boyer wrote:
On Fri, Oct 11, 2013 at 9:27 AM, Aaron Lu aaron...@intel.com wrote:
v5:
1 Introduce video.use_native_backlight module parameter and set its
value to false by default
On dim., 2013-06-09 at 19:01 -0400, Matthew Garrett wrote:
The first two patches in this series are picked from other patchesets aimed at
solving similar problems. The last simply unregisters ACPI backlight control
on Windows 8 systems when using an Intel GPU. Similar code could be added to
On mar., 2013-06-25 at 17:08 +0100, Matthew Garrett wrote:
On Sat, Jun 22, 2013 at 11:46:39PM +0200, Yves-Alexis Perez wrote:
Before Linux support for acpi_osi(Windows 2012) (and when booting with
acpi_osi=!Windows 2012), brightness keys were handled by the kernel
just fine, whether
On mar., 2013-06-25 at 21:54 +0100, Matthew Garrett wrote:
On Tue, Jun 25, 2013 at 10:43:57PM +0200, Yves-Alexis Perez wrote:
On mar., 2013-06-25 at 17:08 +0100, Matthew Garrett wrote:
Right, the kernel has special-casing to hook the backlight keys up to
the ACPI backlight control
On mar., 2013-06-25 at 22:14 +0100, Matthew Garrett wrote:
On Tue, Jun 25, 2013 at 11:10:11PM +0200, Yves-Alexis Perez wrote:
On mar., 2013-06-25 at 21:54 +0100, Matthew Garrett wrote:
I agree, we should standardise the behaviour. And the only way we can
standardise the behaviour
On mar., 2013-06-25 at 22:33 +0100, Matthew Garrett wrote:
I was referring to “standardize the behaviour by leaving up to
userspace”. A lot of thinkpads (for example) (all the pre-windows 8
ones) have a perfectly working ACPI backlight interface.
And this patchset won't alter their
On jeu., 2013-07-04 at 07:53 +0200, Luca Barbato wrote:
On 07/01/2013 03:07 PM, Luca Barbato wrote:
Hopefully I will carve some time next weekend to play the restricted
bisect game.
Release 3.10 apparently doesn't show the problem, I guess problem solved
for me =)
lu
I've just tried
On jeu., 2013-07-04 at 10:37 +0200, Yves-Alexis Perez wrote:
On jeu., 2013-07-04 at 07:53 +0200, Luca Barbato wrote:
On 07/01/2013 03:07 PM, Luca Barbato wrote:
Hopefully I will carve some time next weekend to play the restricted
bisect game.
Release 3.10 apparently doesn't show
On mar., 2013-09-17 at 17:23 +0800, Aaron Lu wrote:
v1 has the subject of Rework ACPI video driver and is posted here:
http://lkml.org/lkml/2013/9/9/74
Since the objective is really to fix Win8 backlight issues, I changed
the subject in this version, sorry about that.
This patchset has
one.
APIs to selectively remove backlight control interface and/or event
delivery functionality can be easily added once needed.
Signed-off-by: Aaron Lu aaron...@intel.com
Tested-by: Yves-Alexis Perez cor...@debian.org
--
Yves-Alexis
signature.asc
Description: This is a digitally signed
by i915) is available and then do
things accordingly(e.g. avoid register its own on Win8 systems).
Signed-off-by: Aaron Lu aaron...@intel.com
Tested-by: Yves-Alexis Perez cor...@debian.org
--
Yves-Alexis
signature.asc
Description: This is a digitally signed message part
.
Signed-off-by: Aaron Lu aaron...@intel.com
Tested-by: Yves-Alexis Perez cor...@debian.org
--
Yves-Alexis
signature.asc
Description: This is a digitally signed message part
On ven., 2013-09-27 at 12:20 -0300, Henrique de Moraes Holschuh wrote:
Some testing on a *60 (T60,X60...) would also be best, I cannot test
this on
my T43.
Anyway, the code itself looks fine, so:
I can test on T61, would that help?
Regards,
--
Yves-Alexis
signature.asc
Description: This
On ven., 2013-09-27 at 15:05 -0300, Henrique de Moraes Holschuh wrote:
On Fri, 27 Sep 2013, Yves-Alexis Perez wrote:
On ven., 2013-09-27 at 12:20 -0300, Henrique de Moraes Holschuh wrote:
Some testing on a *60 (T60,X60...) would also be best, I cannot test
this on
my T43.
Anyway
On Thu, Mar 19, 2015 at 01:06:49PM -0400, Benjamin Tissoires wrote:
To solve your problem, your desktop environment must have a disable
touchpad switch in the configuration panel. At least, gnome has. This
way, your settings should come back at each login.
And if this is not sufficient enough,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Fri, Feb 06, 2015 at 03:04:28PM -0500, Benjamin Tissoires wrote:
Hi,
This is the second episode of the Lenovo 2015 party :)
Thanks to Andrew, we now have an idea within the driver of what are the extra
buttons aimed for, and the patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, Mar 19, 2015 at 10:46:27AM -0400, Benjamin Tissoires wrote:
On Mar 19 2015 or thereabouts, Yves-Alexis Perez wrote:
So I have two questions/remarks about this:
- if I don't use the touchpad, do I need xf86-input-synaptics at all
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, Mar 19, 2015 at 11:58:31AM -0400, Benjamin Tissoires wrote:
On Mar 19 2015 or thereabouts, Yves-Alexis Perez wrote:
Am I right? Thanks for the information, I'll also try to point our
kernel maintainers to that thread and ask them
On sam., 2015-04-11 at 17:27 +0200, Takashi Iwai wrote:
At Sat, 11 Apr 2015 09:31:35 +0200,
Yves-Alexis Perez wrote:
This model uses the same dock port as the previous generation.
Signed-off-by: Yves-Alexis Perez cor...@debian.org
Thanks, applied with Cc to stable.
But, at the next
This model uses the same dock port as the previous generation.
Signed-off-by: Yves-Alexis Perez cor...@debian.org
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 7438213..2087728 100644
how the ALSA
maintainers stand on this, but similar previous patches have been targeted to
stable so it might be worth adding it.
Regards,
--
Yves-Alexis Perez
Yves-Alexis Perez (1):
ALSA: hda - Add dock support for ThinkPad X250 (17aa:2226)
sound/pci/hda/patch_realtek.c | 1 +
1 file changed
On sam., 2015-04-11 at 17:27 +0200, Takashi Iwai wrote:
At Sat, 11 Apr 2015 09:31:35 +0200,
Yves-Alexis Perez wrote:
This model uses the same dock port as the previous generation.
Signed-off-by: Yves-Alexis Perez cor...@debian.org
Thanks, applied with Cc to stable.
But, at the next
A changes file (also called Debian upload control file) contains
information about binary packages, including the changelog entry, the
maintainer, the package list and the checksums.
It can be used by various Debian tools like dput and dcmd to execute
action on all the build packages at once, for
On jeu., 2015-05-14 at 14:35 +0200, Yves-Alexis Perez wrote:
+# Generate a change file
+(cd $KBUILD_OUTPUT; dpkg-genchanges -b
../linux_${packageversion}_${debarch}.changes)
+
Actually cwd during the build is KBUILD_OUTPUT already, so the cd part
is unnecessary (I can resend a v2 if really
On sam., 2015-04-11 at 11:40 +0200, Toralf Förster wrote:
Hi,
/me wonders why you didn't add the new line directly under Thinkpad X240 :
SND_PCI_QUIRK(0x17aa, 0x2214, Thinkpad X240,
ALC292_FIXUP_TPT440_DOCK),
SND_PCI_QUIRK(0x17aa, 0x2215, Thinkpad,
On jeu., 2015-03-19 at 11:58 -0400, Benjamin Tissoires wrote:
Am I right? Thanks for the information, I'll also try to point our
kernel maintainers to that thread and ask them if it's possible to
backport them to the 3.16 kernel for Jessie.
Yes, please do. For the record, they are
On dim., 2015-10-18 at 20:41 -0500, Serge E. Hallyn wrote:
> We shouldn't need a long-term solution. Your concern is bugs. After
> some time surely we'll feel that we have achieved a stable solution?
But this is actually the whole point: we need a long term solution, because
they will always be
On mer., 2016-04-06 at 11:43 -0700, Linus Torvalds wrote:
> Hibernation is really quite nasty when you have to have a fairly big
> special partition for it, and shrink your memory down. Writing things
> to disk was a whole lot more reasonable back in the days when laptops
> had 16MB of memory.
On mer., 2016-04-06 at 12:02 -0700, Linus Torvalds wrote:
> So yeah, maybe swap partitions are still more common than I thought.
> And I didn't even consider the possibility that people would hibernate
> a desktop like you do.
To be fair, it's *my* use case, because suspend won't work but I'm
On mer., 2016-04-06 at 14:45 -0700, Kees Cook wrote:
> > This security feature reduces the predictability of
> > the kernel slab allocator against heap overflows.
>
> I would add "... rendering attacks much less stable." And if you can
> find a specific example exploit that is foiled by this, I
On Wed, 2016-11-09 at 23:02 +0100, Luis R. Rodriguez wrote:
> Actually... we also set the timeout to MAX_JIFFY_OFFSET when FW_OPT_UEVENT is
> not set. This happens *only* when the UMH was explicitly requested on the
> async call, when the second argument to request_firmware_nowait() is false.
>
On Thu, 2016-11-10 at 11:48 -0800, Luis R. Rodriguez wrote:
> > I haven't verified that this particular use case actually worked before,
> > but this code works with lower timeout values (e.g. 60 in the fallback
> > case), so this looks isolated.
>
> This is true, but as I noted the broken aspect
e and only set retval in specific
cases.
Signed-off-by: Yves-Alexis Perez <cor...@corsac.net>
Fixes: 68ff2a00dbf5 "firmware_loader: handle timeout via
wait_for_completion_interruptible_timeout()"
Cc: Luis R. Rodriguez <mcg...@kernel.org>
Cc: Ming Lei <ming
Hi,
when trying to (ab)use the firmware loading interface in a local kernel module
(in order to load the EEPROM content into a PCIE card), I noticed that the
manual firmware loading interface (the one from
/sys/class/firmware//{loading,data}) was broken.
After instrumenting the kernel I noticed
From: Yves-Alexis Perez <cor...@debian.org>
wait_for_completion_interruptible_timeout() return value is either
-ERESTARTSYS (in case it was interrupted), 0 (in case the timeout expired)
or the number of jiffies left until timeout. The return value is stored in
On Sun, 2016-10-30 at 15:50 +0100, Yves-Alexis Perez wrote:
> wait_for_completion_interruptible_timeout() return value is either
> -ERESTARTSYS (in case it was interrupted), 0 (in case the timeout expired)
> or the number of jiffies left until timeout. The return value is stored in
rds,
>
> --
>
> From: Yves-Alexis Perez <cor...@corsac.net>
>
> commit 2e700f8d85975f516ccaad821278c1fe66b2cc98 upstream.
>
> When you use the firmware usermode helper fallback with a timeout value set
> to a
> value greater than INT_MAX (2147483647) a cast ov
On Thu, 2018-01-04 at 09:56 -0800, Tim Chen wrote:
> @@ -44,6 +47,7 @@ static inline void apm_bios_call_asm(u32 func, u32 ebx_in,
> u32 ecx_in,
> "=S" (*esi)
> : "a" (func), "b" (ebx_in), "c" (ecx_in)
> : "memory", "cc");
> +
On Thu, 2018-01-04 at 11:10 -0800, Tim Chen wrote:
> > Are there plans to make the corresponding microcode support available?
> >
>
> The microcode patches should be released soon.
In the meantime, Lenovo has started issuing BIOS/UEFI updates which include
microcode updates for this.
See for
On Mon, 2018-01-08 at 18:07 +0100, Yves-Alexis Perez wrote:
> On Sun, 2018-01-07 at 11:18 +0100, Willy Tarreau wrote:
> > - the highest performance impact on VMs comes from having PTI on the
> > guest kernel (-45%). At this point it makes no difference whether
> >
On Sun, 2018-01-07 at 11:18 +0100, Willy Tarreau wrote:
> - the highest performance impact on VMs comes from having PTI on the
> guest kernel (-45%). At this point it makes no difference whether
> the host kernel has it or not.
Hi Willy,
out of curiosity, is the pcid/invpcid flags
On Mon, 2018-01-08 at 19:26 +0100, Willy Tarreau wrote:
> You're totally right, I discovered during my later developments that
> indeed PCID is not exposed there. So we take the hit of a full TLB
> flush twice per syscall.
So I really think it might make sense to redo the tests with PCID, because
On Fri, 2018-01-05 at 14:28 +0100, Greg KH wrote:
> > iucode-tool -L -tr n10ur16w.iso |grep 2017-11
> >001/020: sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size
> > 18432
>
> That's been out for a while now:
>
On Fri, 2018-01-05 at 15:26 +0100, Paolo Bonzini wrote:
> Those from November seem way too early to include IBRS/IBPB. Maybe the
> two from December 3rd, but I wouldn't be 100% sure.
So, for my CPU with updated microcode:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
On Wed, 2018-01-24 at 16:57 +, David Woodhouse wrote:
> We don't refuse to load the affected microcodes; just refuse to use SPEC_CTRL
> if they're detected.
Hi David,
Are we sure those microcodes instability are only related to SPEC_CTRL?
Regards,
--
Yves-Alexis
signature.asc
Description:
On Wed, 2018-01-24 at 16:57 +, David Woodhouse wrote:
> Some old Atoms, anything in family 5 or 4, and newer CPUs when they advertise
> the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO bit set, are not
> vulnerable.
>
> Roll the AMD exemption into the x86_match_cpu() table too.
>
>
On Wed, 2018-02-07 at 13:50 -0500, Mike Maloney wrote:
> On Wed, Feb 7, 2018 at 12:23 PM, Yves-Alexis Perez <cor...@debian.org>
>
> Hi Yves-Alexis -
>
> I apologize for the problem. It seems to me that tunneling with an
> outer MTU that causes the inner MTU to
On Wed, 2018-02-07 at 20:46 +0100, Yves-Alexis Perez wrote:
> Maybe. I tried with removing the MTU setting, and I get (on ping again)
>
> févr. 07 20:44:01 scapa kernel: mtu: 1266
>
> which means I would get -EINVAL on standards kernels, which is not really good
> eithe
Hi Mike,
I noticed a regression in 4.14.16 stable kernel (I assume it's also
present in mainline).
I'm using an IPsec setup where I tunnel all my IP trafic to a gateway.
The tunnel can use either IPv6 or IPv4 (depending on what's available
locally) and will route both IPv4 and IPv6 (my gateway
On Wed, 2018-02-07 at 17:38 +0100, Yves-Alexis Perez wrote:
> Starting with 4.14.16, IPv6 traffic is broken. When trying a simple ping
> to an IPv6 address I get:
>
> ping: sendmsg: Invalid argument
I forgot an important bit of information: due to the way routers usually broke
path M
On Wed, 2018-02-07 at 18:05 +0100, Yves-Alexis Perez wrote:
> I'll try to printk the mtu before returning EINVAL to see why it's lower than
> 1280, but maybe the IP encapsulation is not correctly handled?
I did:
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 3763dc
On Tue, 2018-02-13 at 16:29 +0100, Greg Kroah-Hartman wrote:
> > arch/powerpc/kernel/entry_64.S: Assembler messages:
> > arch/powerpc/kernel/entry_64.S:260: Error: unrecognized opcode:
> > `rfi_to_user'
> > arch/powerpc/kernel/entry_64.S:270: Error: unrecognized opcode:
> > `rfi_to_kernel'
> >
On Tue, 2018-02-20 at 14:25 -0800, Jacob Pan wrote:
> I didn't know about chipsec but reading the code seems to rely on an
> out-of-tree kernel module. I don't think it matches what we need here.
Yes good indeed, I had forgot about that. Maybe the userland part is still
useful, but there's
On Thu, 2018-02-22 at 12:01 +1100, Michael Ellerman wrote:
> So I guess this patch is OK for now, but we do need a full back port of
> 222f20f to 4.9.
Hi,
in the light of this, do you know the full status of protections against
Meltdown on powerpc/ppc64el architecures on 4.9?
Regards,
--
On Fri, 2018-02-23 at 00:16 +1100, Michael Ellerman wrote:
> With the patches I just sent, for pseries and powernv, the mitigation
> should be in place. On machines with updated firmware we'll use the
> hardware-assisted L1 flush, otherwise we fallback to doing it in
> software.
So as of 4.9.82
On Thu, 2018-02-22 at 13:02 +0100, Yves-Alexis Perez wrote:
> On Thu, 2018-02-22 at 12:08 +0100, Greg Kroah-Hartman wrote:
> > Did you look at /sys/devices/system/cpu/vulnerabilities/ to see what the
> > files there say?
>
> Unfortunately I don't have access to a powerpc
On Thu, 2018-02-22 at 12:08 +0100, Greg Kroah-Hartman wrote:
> Did you look at /sys/devices/system/cpu/vulnerabilities/ to see what the
> files there say?
Unfortunately I don't have access to a powerpc box where I could run a new
kernel and try it on. I'll check with our ppc porters and see if I
On Tue, 2018-02-13 at 13:40 -0800, Raj, Ashok wrote:
> This version has only hw dumps for now, but we plan to add some other things
> like walking 2nd level page-tables, or get some SVM specific data from the
> driver in the future.
Hi,
I'm not sure how much you know about chipsec [1], but
On Sat, 2018-02-17 at 09:35 -0800, Guenter Roeck wrote:
> Hmm, that chunk really doesn't do what the original patch is supposed to do,
> meaning it won't provide the vulnerability protection it is supposed to
> provide
> (AFAICS that is Meltdown). Just a note in case anyone is concerned about
>
On mer., 2013-07-17 at 10:51 -0500, Felipe Contreras wrote:
> On Sat, Jun 22, 2013 at 4:46 PM, Yves-Alexis Perez wrote:
> > Before Linux support for acpi_osi("Windows 2012") (and when booting with
> > acpi_osi="!Windows 2012"), brightness keys were handled b
On dim., 2013-06-09 at 19:01 -0400, Matthew Garrett wrote:
> The first two patches in this series are picked from other patchesets aimed at
> solving similar problems. The last simply unregisters ACPI backlight control
> on Windows 8 systems when using an Intel GPU. Similar code could be added to
On lun., 2013-03-18 at 17:32 -0400, Matthew Garrett wrote:
> This patch introduces CAP_COMPROMISE_KERNEL. Holding this capability
> indicates that a process is empowered to perform tasks that may result
> in
> modification of the running kernel. While aimed at handling the
> specific
> use-case of
On sam., 2013-10-12 at 01:27 +0200, Rafael J. Wysocki wrote:
> If we are to use a Kconfig option, why don't we use one instead of rather than
> in addition to a command line option? Say, we have
> CONFIG_ACPI_VIDEO_WIN8_WORKAROUND and if that is set, the code will work like
> the previous version
On sam., 2013-10-12 at 00:10 +0200, Rafael J. Wysocki wrote:
> On Friday, October 11, 2013 12:42:43 PM Josh Boyer wrote:
> > On Fri, Oct 11, 2013 at 9:27 AM, Aaron Lu wrote:
> > > v5:
> > > 1 Introduce video.use_native_backlight module parameter and set its
> > > value to false by default as
On mar., 2013-09-17 at 17:23 +0800, Aaron Lu wrote:
> v1 has the subject of "Rework ACPI video driver" and is posted here:
> http://lkml.org/lkml/2013/9/9/74
> Since the objective is really to fix Win8 backlight issues, I changed
> the subject in this version, sorry about that.
>
> This patchset
unctionality without affecting the other one.
>
> APIs to selectively remove backlight control interface and/or event
> delivery functionality can be easily added once needed.
>
> Signed-off-by: Aaron Lu
Tested-by: Yves-Alexis Perez
--
Yves-Alexis
signature.asc
Description: This is a digitally signed message part
. the interface created by i915) is available and then do
> things accordingly(e.g. avoid register its own on Win8 systems).
>
> Signed-off-by: Aaron Lu
Tested-by: Yves-Alexis Perez
--
Yves-Alexis
signature.asc
Description: This is a digitally signed message part
rk done by Matthew Garrett,
> Chun-Yi Lee, Seth Forshee and Rafael J. Wysocki.
>
> Signed-off-by: Aaron Lu
Tested-by: Yves-Alexis Perez
--
Yves-Alexis
signature.asc
Description: This is a digitally signed message part
On mer., 2013-09-11 at 08:45 +, Matthew Garrett wrote:
> On Wed, 2013-09-11 at 11:45 +0300, Jani Nikula wrote:
>
> > Before plunging forward, have you observed any difference between the
> > boot modes? We have reports [1] that the backlight behaviour is
> > different with UEFI vs. UEFI+CSM
On mer., 2013-03-06 at 21:30 -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 04 Mar 2013, Borislav Petkov wrote:
> > I get this in dmesg with 3.9-rc1:
> >
> > [ 12.951434] thinkpad_acpi: unhandled HKEY event 0x6050
> > [ 12.951438] thinkpad_acpi: please report the conditions when this
>
On ven., 2013-09-27 at 12:20 -0300, Henrique de Moraes Holschuh wrote:
> Some testing on a *60 (T60,X60...) would also be best, I cannot test
> this on
> my T43.
>
> Anyway, the code itself looks fine, so:
I can test on T61, would that help?
Regards,
--
Yves-Alexis
signature.asc
Description:
On ven., 2013-09-27 at 15:05 -0300, Henrique de Moraes Holschuh wrote:
> On Fri, 27 Sep 2013, Yves-Alexis Perez wrote:
> > On ven., 2013-09-27 at 12:20 -0300, Henrique de Moraes Holschuh wrote:
> > > Some testing on a *60 (T60,X60...) would also be best, I cannot test
> >
On mar., 2013-06-25 at 17:08 +0100, Matthew Garrett wrote:
> On Sat, Jun 22, 2013 at 11:46:39PM +0200, Yves-Alexis Perez wrote:
>
> > Before Linux support for acpi_osi("Windows 2012") (and when booting with
> > acpi_osi="!Windows 2012"), brightness keys we
On mar., 2013-06-25 at 21:54 +0100, Matthew Garrett wrote:
> On Tue, Jun 25, 2013 at 10:43:57PM +0200, Yves-Alexis Perez wrote:
> > On mar., 2013-06-25 at 17:08 +0100, Matthew Garrett wrote:
> > > Right, the kernel has special-casing to hook the backlight keys up to
> &
On mar., 2013-06-25 at 22:14 +0100, Matthew Garrett wrote:
> On Tue, Jun 25, 2013 at 11:10:11PM +0200, Yves-Alexis Perez wrote:
> > On mar., 2013-06-25 at 21:54 +0100, Matthew Garrett wrote:
> > > I agree, we should standardise the behaviour. And the only way we can
On mar., 2013-06-25 at 22:33 +0100, Matthew Garrett wrote:
> > I was referring to “standardize the behaviour by leaving up to
> > userspace”. A lot of thinkpads (for example) (all the pre-windows 8
> > ones) have a perfectly working ACPI backlight interface.
>
> And this patchset won't alter
On lun., 2013-01-28 at 11:42 -0500, Matthew Garrett wrote:
> Secure boot makes it possible to ensure that the on-disk representation of
> the kernel hasn't been modified. This can be sidestepped if the in-memory
> representation can be trivially altered. We currently have a large number
> of
On jeu., 2013-07-04 at 07:53 +0200, Luca Barbato wrote:
> On 07/01/2013 03:07 PM, Luca Barbato wrote:
> > Hopefully I will carve some time next weekend to play the restricted
> > bisect game.
>
> Release 3.10 apparently doesn't show the problem, I guess problem solved
> for me =)
>
> lu
>
I've
On jeu., 2013-07-04 at 10:37 +0200, Yves-Alexis Perez wrote:
> On jeu., 2013-07-04 at 07:53 +0200, Luca Barbato wrote:
> > On 07/01/2013 03:07 PM, Luca Barbato wrote:
> > > Hopefully I will carve some time next weekend to play the restricted
> > > bisect game.
>
On Tue, 2018-02-20 at 14:25 -0800, Jacob Pan wrote:
> I didn't know about chipsec but reading the code seems to rely on an
> out-of-tree kernel module. I don't think it matches what we need here.
Yes good indeed, I had forgot about that. Maybe the userland part is still
useful, but there's
On Thu, 2018-02-22 at 12:01 +1100, Michael Ellerman wrote:
> So I guess this patch is OK for now, but we do need a full back port of
> 222f20f to 4.9.
Hi,
in the light of this, do you know the full status of protections against
Meltdown on powerpc/ppc64el architecures on 4.9?
Regards,
--
On Thu, 2018-02-22 at 12:08 +0100, Greg Kroah-Hartman wrote:
> Did you look at /sys/devices/system/cpu/vulnerabilities/ to see what the
> files there say?
Unfortunately I don't have access to a powerpc box where I could run a new
kernel and try it on. I'll check with our ppc porters and see if I
On Fri, 2018-02-23 at 00:16 +1100, Michael Ellerman wrote:
> With the patches I just sent, for pseries and powernv, the mitigation
> should be in place. On machines with updated firmware we'll use the
> hardware-assisted L1 flush, otherwise we fallback to doing it in
> software.
So as of 4.9.82
On Thu, 2018-02-22 at 13:02 +0100, Yves-Alexis Perez wrote:
> On Thu, 2018-02-22 at 12:08 +0100, Greg Kroah-Hartman wrote:
> > Did you look at /sys/devices/system/cpu/vulnerabilities/ to see what the
> > files there say?
>
> Unfortunately I don't have access to a powerpc
On Sun, 2018-01-07 at 11:18 +0100, Willy Tarreau wrote:
> - the highest performance impact on VMs comes from having PTI on the
> guest kernel (-45%). At this point it makes no difference whether
> the host kernel has it or not.
Hi Willy,
out of curiosity, is the pcid/invpcid flags
On Mon, 2018-01-08 at 18:07 +0100, Yves-Alexis Perez wrote:
> On Sun, 2018-01-07 at 11:18 +0100, Willy Tarreau wrote:
> > - the highest performance impact on VMs comes from having PTI on the
> > guest kernel (-45%). At this point it makes no difference whether
> >
On Mon, 2018-01-08 at 19:26 +0100, Willy Tarreau wrote:
> You're totally right, I discovered during my later developments that
> indeed PCID is not exposed there. So we take the hit of a full TLB
> flush twice per syscall.
So I really think it might make sense to redo the tests with PCID, because
On Thu, 2018-01-04 at 09:56 -0800, Tim Chen wrote:
> @@ -44,6 +47,7 @@ static inline void apm_bios_call_asm(u32 func, u32 ebx_in,
> u32 ecx_in,
> "=S" (*esi)
> : "a" (func), "b" (ebx_in), "c" (ecx_in)
> : "memory", "cc");
> +
On Thu, 2018-01-04 at 11:10 -0800, Tim Chen wrote:
> > Are there plans to make the corresponding microcode support available?
> >
>
> The microcode patches should be released soon.
In the meantime, Lenovo has started issuing BIOS/UEFI updates which include
microcode updates for this.
See for
On Fri, 2018-01-05 at 14:28 +0100, Greg KH wrote:
> > iucode-tool -L -tr n10ur16w.iso |grep 2017-11
> >001/020: sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size
> > 18432
>
> That's been out for a while now:
>
On Fri, 2018-01-05 at 15:26 +0100, Paolo Bonzini wrote:
> Those from November seem way too early to include IBRS/IBPB. Maybe the
> two from December 3rd, but I wouldn't be 100% sure.
So, for my CPU with updated microcode:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
On Tue, 2018-02-13 at 16:29 +0100, Greg Kroah-Hartman wrote:
> > arch/powerpc/kernel/entry_64.S: Assembler messages:
> > arch/powerpc/kernel/entry_64.S:260: Error: unrecognized opcode:
> > `rfi_to_user'
> > arch/powerpc/kernel/entry_64.S:270: Error: unrecognized opcode:
> > `rfi_to_kernel'
> >
On Sat, 2018-02-17 at 09:35 -0800, Guenter Roeck wrote:
> Hmm, that chunk really doesn't do what the original patch is supposed to do,
> meaning it won't provide the vulnerability protection it is supposed to
> provide
> (AFAICS that is Meltdown). Just a note in case anyone is concerned about
>
On Tue, 2018-02-13 at 13:40 -0800, Raj, Ashok wrote:
> This version has only hw dumps for now, but we plan to add some other things
> like walking 2nd level page-tables, or get some SVM specific data from the
> driver in the future.
Hi,
I'm not sure how much you know about chipsec [1], but
1 - 100 of 135 matches
Mail list logo
