On Thu, Aug 11, 2016 at 2:33 PM, Rafael J. Wysocki wrote:
> On Thursday, August 11, 2016 11:47:27 AM Thomas Garnier wrote:
>> On Wed, Aug 10, 2016 at 6:35 PM, Rafael J. Wysocki wrote:
>> > On Thu, Aug 11, 2016 at 3:17 AM, Thomas Garnier
>> > wrote:
>> >> On Wed, Aug 10, 2016 at 5:35 PM, Rafael
On Thursday, August 11, 2016 11:47:27 AM Thomas Garnier wrote:
> On Wed, Aug 10, 2016 at 6:35 PM, Rafael J. Wysocki wrote:
> > On Thu, Aug 11, 2016 at 3:17 AM, Thomas Garnier wrote:
> >> On Wed, Aug 10, 2016 at 5:35 PM, Rafael J. Wysocki
> >> wrote:
> >>> On Wed, Aug 10, 2016 at 11:59 PM, Jiri
On Wed, Aug 10, 2016 at 6:35 PM, Rafael J. Wysocki wrote:
> On Thu, Aug 11, 2016 at 3:17 AM, Thomas Garnier wrote:
>> On Wed, Aug 10, 2016 at 5:35 PM, Rafael J. Wysocki wrote:
>>> On Wed, Aug 10, 2016 at 11:59 PM, Jiri Kosina wrote:
On Wed, 10 Aug 2016, Rafael J. Wysocki wrote:
>
On Thu, Aug 11, 2016 at 3:17 AM, Thomas Garnier wrote:
> On Wed, Aug 10, 2016 at 5:35 PM, Rafael J. Wysocki wrote:
>> On Wed, Aug 10, 2016 at 11:59 PM, Jiri Kosina wrote:
>>> On Wed, 10 Aug 2016, Rafael J. Wysocki wrote:
>>>
So I used your .config to generate one for my test machine and wit
On Wed, Aug 10, 2016 at 5:35 PM, Rafael J. Wysocki wrote:
> On Wed, Aug 10, 2016 at 11:59 PM, Jiri Kosina wrote:
>> On Wed, 10 Aug 2016, Rafael J. Wysocki wrote:
>>
>>> So I used your .config to generate one for my test machine and with
>>> that I can reproduce.
>>
>> Was that the config I've sen
On Wed, Aug 10, 2016 at 11:59 PM, Jiri Kosina wrote:
> On Wed, 10 Aug 2016, Rafael J. Wysocki wrote:
>
>> So I used your .config to generate one for my test machine and with
>> that I can reproduce.
>
> Was that the config I've sent, or did Boris provide one as well? Which one
> are you able to re
On Wed, 10 Aug 2016, Rafael J. Wysocki wrote:
> So I used your .config to generate one for my test machine and with
> that I can reproduce.
Was that the config I've sent, or did Boris provide one as well? Which one
are you able to reproduce with please?
> The hardware configuration doesn't matt
On Wed, Aug 10, 2016 at 11:52 PM, Jiri Kosina wrote:
> On Wed, 10 Aug 2016, Thomas Garnier wrote:
>
>> Ok, I want to know if the problem is the PUD alignment or the change
>> of PAGE_OFFSET based all together. Can you test the following change?
>> (on top of everything else with KASLR enabled). It
On Wed, 10 Aug 2016, Thomas Garnier wrote:
> Ok, I want to know if the problem is the PUD alignment or the change
> of PAGE_OFFSET based all together. Can you test the following change?
> (on top of everything else with KASLR enabled). It will randomize the
> memory sections only on PGD level.
>
On Wed, Aug 10, 2016 at 10:56 PM, Rafael J. Wysocki wrote:
> On Wed, Aug 10, 2016 at 6:35 PM, Borislav Petkov wrote:
>> On Wed, Aug 10, 2016 at 04:59:40PM +0200, Jiri Kosina wrote:
>>> Mine is Lenovo thinkpad x200s; I think Boris has been testing it on x230s,
>>
>> It says "X230" here under the s
On Wed, Aug 10, 2016 at 6:35 PM, Borislav Petkov wrote:
> On Wed, Aug 10, 2016 at 04:59:40PM +0200, Jiri Kosina wrote:
>> Mine is Lenovo thinkpad x200s; I think Boris has been testing it on x230s,
>
> It says "X230" here under the screen.
>
>> but not sure whether any of the latest patches didn't
On Wed, 10 Aug 2016, Thomas Garnier wrote:
> What type of machines are you testing it on? What is the memory size?
> Processor generation?
Mine is Lenovo thinkpad x200s; I think Boris has been testing it on x230s,
but not sure whether any of the latest patches didn't actually fix it for
him.
On Wednesday, August 10, 2016 09:50:15 AM Jiri Kosina wrote:
> On Wed, 10 Aug 2016, Rafael J. Wysocki wrote:
>
> > For the lack of better ideas, below is a patch to try.
> >
> > It avoids the possible issue with the restore kernel's identity mapping
> > overlap
> > with restore_jump_address by c
On Wed, Aug 10, 2016 at 6:18 AM, Jiri Kosina wrote:
> On Wed, 10 Aug 2016, Rafael J. Wysocki wrote:
>
>> The last patch I sent had a problem, because if restore_jump_address really
>> overlapped with the identity mapping of the restore kernel, it might share
>> PGD or PUD entries with that mapping
On Wed, Aug 10, 2016 at 9:35 AM, Borislav Petkov wrote:
> On Wed, Aug 10, 2016 at 04:59:40PM +0200, Jiri Kosina wrote:
>> Mine is Lenovo thinkpad x200s; I think Boris has been testing it on x230s,
>
> It says "X230" here under the screen.
>
>> but not sure whether any of the latest patches didn't
On Wed, Aug 10, 2016 at 04:59:40PM +0200, Jiri Kosina wrote:
> Mine is Lenovo thinkpad x200s; I think Boris has been testing it on x230s,
It says "X230" here under the screen.
> but not sure whether any of the latest patches didn't actually fix it for
> him.
Haven't tested them yet. I'm waiting
On Wed, 10 Aug 2016, Rafael J. Wysocki wrote:
> The last patch I sent had a problem, because if restore_jump_address really
> overlapped with the identity mapping of the restore kernel, it might share
> PGD or PUD entries with that mapping and that should have been taken into
> account.
>
> Here
On Wed, 10 Aug 2016, Rafael J. Wysocki wrote:
> For the lack of better ideas, below is a patch to try.
>
> It avoids the possible issue with the restore kernel's identity mapping
> overlap
> with restore_jump_address by creating special super-simple page tables just
> for the final jump to the i
On Tuesday, August 09, 2016 11:23:31 PM Rafael J. Wysocki wrote:
> On Tue, Aug 9, 2016 at 10:02 PM, Jiri Kosina wrote:
> > On Tue, 9 Aug 2016, Rafael J. Wysocki wrote:
> >
> >> I have a murky suspicion, but it is really weird. Namely, what if
> >> restore_jump_address in set_up_temporary_text_map
On Tue, Aug 9, 2016 at 10:02 PM, Jiri Kosina wrote:
> On Tue, 9 Aug 2016, Rafael J. Wysocki wrote:
>
>> I have a murky suspicion, but it is really weird. Namely, what if
>> restore_jump_address in set_up_temporary_text_mapping() happens to be
>> covered by the restore kernel's identity mapping?
On Tue, Aug 9, 2016 at 6:27 PM, Thomas Garnier wrote:
> On Tue, Aug 9, 2016 at 9:18 AM, Rafael J. Wysocki wrote:
>> On Tue, Aug 9, 2016 at 5:05 PM, Jiri Kosina wrote:
>>> On Tue, 9 Aug 2016, Thomas Garnier wrote:
>>>
>> Okay, I did one-by-one reverts, and the one above, i.e.
>>
>>
On Tue, 9 Aug 2016, Rafael J. Wysocki wrote:
> I have a murky suspicion, but it is really weird. Namely, what if
> restore_jump_address in set_up_temporary_text_mapping() happens to be
> covered by the restore kernel's identity mapping? Then, the image
> kernel's entry point may get overwritten
On Tue, Aug 9, 2016 at 9:18 AM, Rafael J. Wysocki wrote:
> On Tue, Aug 9, 2016 at 5:05 PM, Jiri Kosina wrote:
>> On Tue, 9 Aug 2016, Thomas Garnier wrote:
>>
>>> >> Okay, I did one-by-one reverts, and the one above, i.e.
>>> >>
>>> >> commit 021182e52fe01c1f7b126f97fd6ba048dc4234fd
>>> >>
On Tue, Aug 9, 2016 at 5:05 PM, Jiri Kosina wrote:
> On Tue, 9 Aug 2016, Thomas Garnier wrote:
>
>> >> Okay, I did one-by-one reverts, and the one above, i.e.
>> >>
>> >> commit 021182e52fe01c1f7b126f97fd6ba048dc4234fd
>> >> Author: Thomas Garnier
>> >> Date: Tue Jun 21 17:47:
On Tue, 9 Aug 2016, Thomas Garnier wrote:
> >> Okay, I did one-by-one reverts, and the one above, i.e.
> >>
> >> commit 021182e52fe01c1f7b126f97fd6ba048dc4234fd
> >> Author: Thomas Garnier
> >> Date: Tue Jun 21 17:47:03 2016 -0700
> >>
> >> x86/mm: Enable KASLR for p
On Tue, 9 Aug 2016, Jiri Kosina wrote:
> > 210e7a43fa90 mm: SLUB freelist randomization
> > 7c00fce98c3e mm: reorganize SLAB freelist randomization
> > 4ff5308744f5 x86/mm: Do not reference phys addr beyond kernel
> > 90397a417796 x86/mm: Add memory hotplug support for KASLR memory
> > randomizat
On Tue, 9 Aug 2016, Rafael J. Wysocki wrote:
> Here's a list of commits from Thomas that are related to memory randomization.
>
> 210e7a43fa90 mm: SLUB freelist randomization
> 7c00fce98c3e mm: reorganize SLAB freelist randomization
> 4ff5308744f5 x86/mm: Do not reference phys addr beyond kernel
On Tue, Aug 9, 2016 at 11:23 AM, Jiri Kosina wrote:
> On Mon, 8 Aug 2016, Rafael J. Wysocki wrote:
>
>> From: Rafael J. Wysocki
>>
>> The low-level resume-from-hibernation code on x86-64 uses
>> kernel_ident_mapping_init() to create the temoprary identity mapping,
>> but that function assumes tha
On Tue, Aug 9, 2016 at 9:02 AM, Borislav Petkov wrote:
> On Mon, Aug 08, 2016 at 03:54:48PM +0200, Rafael J. Wysocki wrote:
>> That should be the only one on top of plain 4.8-rc1.
>>
>> If it doesn't help, we need more work to do. :-)
>
> Yes, we do.
>
> The machine triple-faults *after* reading u
On Mon, 8 Aug 2016, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The low-level resume-from-hibernation code on x86-64 uses
> kernel_ident_mapping_init() to create the temoprary identity mapping,
> but that function assumes that the offset between kernel virtual
> addresses and physical
On Mon, Aug 08, 2016 at 03:54:48PM +0200, Rafael J. Wysocki wrote:
> That should be the only one on top of plain 4.8-rc1.
>
> If it doesn't help, we need more work to do. :-)
Yes, we do.
The machine triple-faults *after* reading up the hibernation image.
It hits 100%, then tries to switch to the
On Mon, Aug 8, 2016 at 8:00 PM, Thomas Garnier wrote:
> On Mon, Aug 8, 2016 at 6:54 AM, Rafael J. Wysocki wrote:
>> On Mon, Aug 8, 2016 at 3:40 PM, Borislav Petkov wrote:
>>> On Mon, Aug 08, 2016 at 03:31:31PM +0200, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki
The low-level
On Mon, Aug 8, 2016 at 6:54 AM, Rafael J. Wysocki wrote:
> On Mon, Aug 8, 2016 at 3:40 PM, Borislav Petkov wrote:
>> On Mon, Aug 08, 2016 at 03:31:31PM +0200, Rafael J. Wysocki wrote:
>>> From: Rafael J. Wysocki
>>>
>>> The low-level resume-from-hibernation code on x86-64 uses
>>> kernel_ident_m
On Mon, Aug 8, 2016 at 3:40 PM, Borislav Petkov wrote:
> On Mon, Aug 08, 2016 at 03:31:31PM +0200, Rafael J. Wysocki wrote:
>> From: Rafael J. Wysocki
>>
>> The low-level resume-from-hibernation code on x86-64 uses
>> kernel_ident_mapping_init() to create the temoprary identity mapping,
>> but th
On Mon, Aug 08, 2016 at 03:31:31PM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The low-level resume-from-hibernation code on x86-64 uses
> kernel_ident_mapping_init() to create the temoprary identity mapping,
> but that function assumes that the offset between kernel virtual
> a
From: Rafael J. Wysocki
The low-level resume-from-hibernation code on x86-64 uses
kernel_ident_mapping_init() to create the temoprary identity mapping,
but that function assumes that the offset between kernel virtual
addresses and physical addresses is aligned on the PGD level.
However, with a r
36 matches
Mail list logo
