| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20201028122209.GH1428094@kernel.org>
Date: Wed, 28 Oct 2020 14:22:09 +0200
From: Mike Rapoport <rppt@...nel.org>
To: David Hildenbrand <david@...hat.com>
Cc: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
"cl@...ux.com" <cl@...ux.com>,
"gor@...ux.ibm.com" <gor@...ux.ibm.com>,
"hpa@...or.com" <hpa@...or.com>,
"peterz@...radead.org" <peterz@...radead.org>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"borntraeger@...ibm.com" <borntraeger@...ibm.com>,
"penberg@...nel.org" <penberg@...nel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"iamjoonsoo.kim@....com" <iamjoonsoo.kim@....com>,
"will@...nel.org" <will@...nel.org>,
"aou@...s.berkeley.edu" <aou@...s.berkeley.edu>,
"kirill@...temov.name" <kirill@...temov.name>,
"rientjes@...gle.com" <rientjes@...gle.com>,
"rppt@...ux.ibm.com" <rppt@...ux.ibm.com>,
"paulus@...ba.org" <paulus@...ba.org>,
"hca@...ux.ibm.com" <hca@...ux.ibm.com>,
"bp@...en8.de" <bp@...en8.de>, "pavel@....cz" <pavel@....cz>,
"sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"luto@...nel.org" <luto@...nel.org>,
"davem@...emloft.net" <davem@...emloft.net>,
"mpe@...erman.id.au" <mpe@...erman.id.au>,
"benh@...nel.crashing.org" <benh@...nel.crashing.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"rjw@...ysocki.net" <rjw@...ysocki.net>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
"x86@...nel.org" <x86@...nel.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"palmer@...belt.com" <palmer@...belt.com>,
"Brown, Len" <len.brown@...el.com>,
"mingo@...hat.com" <mingo@...hat.com>,
"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"paul.walmsley@...ive.com" <paul.walmsley@...ive.com>
Subject: Re: [PATCH 0/4] arch, mm: improve robustness of direct map
manipulation
On Wed, Oct 28, 2020 at 12:17:35PM +0100, David Hildenbrand wrote:
> On 28.10.20 12:09, Mike Rapoport wrote:
> > On Tue, Oct 27, 2020 at 09:46:35AM +0100, David Hildenbrand wrote:
> > > On 27.10.20 09:38, Mike Rapoport wrote:
> > > > On Mon, Oct 26, 2020 at 06:05:30PM +0000, Edgecombe, Rick P wrote:
> > > >
> > > > > Beyond whatever you are seeing, for the latter case of new things
> > > > > getting introduced to an interface with hidden dependencies... Another
> > > > > edge case could be a new caller to set_memory_np() could result in
> > > > > large NP pages. None of the callers today should cause this AFAICT, but
> > > > > it's not great to rely on the callers to know these details.
> >
> > > > A caller of set_memory_*() or set_direct_map_*() should expect a failure
> > > > and be ready for that. So adding a WARN to safe_copy_page() is the first
> > > > step in that direction :)
> > > >
> > >
> > > I am probably missing something important, but why are we saving/restoring
> > > the content of pages that were explicitly removed from the identity mapping
> > > such that nobody will access them?
> >
> > Actually, we should not be saving/restoring free pages during
> > hibernation as there are several calls to mark_free_pages() that should
> > exclude the free pages from the snapshot. I've tried to find why the fix
> > that maps/unmaps a page to save it was required at the first place, but
> > I could not find bug reports.
> >
> > The closest I've got is an email from Rafael that asked to update
> > "hibernate: handle DEBUG_PAGEALLOC" patch:
> >
> > https://lore.kernel.org/linux-pm/200802200133.44098.rjw@sisk.pl/
> >
> > Could it be that safe_copy_page() tries to workaround a non-existent
> > problem?
> >
>
> Clould be! Also see
>
> https://lkml.kernel.org/r/38de5bb0-5559-d069-0ce0-daec66ef2746@suse.cz
>
> which restores free page content based on more kernel parameters, not based
> on the original content.
Ah, after looking at it now I've run kernel with DEBUG_PAGEALLOC=y and
CONFIG_INIT_ON_FREE_DEFAULT_ON=y and restore crahsed nicely.
[ 27.210093] PM: Image successfully loaded
[ 27.226709] Disabling non-boot CPUs ...
[ 27.231208] smpboot: CPU 1 is now offline
[ 27.363926] kvm-clock: cpu 0, msr 5c889001, primary cpu clock, resume
[ 27.363995] BUG: unable to handle page fault for address: ffff9f7a40108000
[ 27.367996] #PF: supervisor write access in kernel mode
[ 27.369558] #PF: error_code(0x0002) - not-present page
[ 27.371098] PGD 5ca01067 P4D 5ca01067 PUD 5ca02067 PMD 5ca03067 PTE 800ffffff
fef7060
[ 27.373421] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC PTI
[ 27.374905] CPU: 0 PID: 1200 Comm: bash Not tainted 5.10.0-rc1 #5
[ 27.376700] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14
.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 27.379879] RIP: 0010:clear_page_rep+0x7/0x10
[ 27.381218] Code: e8 be 88 75 00 44 89 e2 48 89 ee 48 89 df e8 60 ff ff ff c6
03 00 5b 5d 41 5c c3 cc cc cc cc cc cc cc cc b9 00 02 00 00 31 c0 <f3> 48 ab c3
0f 1f 44 00 00 31 c0 b9 40 00 00 00 66 0f 1f 84 00 00
[ 27.386457] RSP: 0018:ffffb6838046be08 EFLAGS: 00010046
[ 27.388011] RAX: 0000000000000000 RBX: ffff9f7a487c0ec0 RCX: 0000000000000200
[ 27.390082] RDX: ffff9f7a4c788000 RSI: 0000000000000000 RDI: ffff9f7a40108000
[ 27.392138] RBP: ffffffff8629c860 R08: 0000000000000000 R09: 0000000000000007
[ 27.394205] R10: 0000000000000004 R11: ffffb6838046bbf8 R12: 0000000000000000
[ 27.396271] R13: ffff9f7a419a62a0 R14: 0000000000000005 R15: ffff9f7a484f4da0
[ 27.398334] FS: 00007fe0c3f6a700(0000) GS:ffff9f7abf800000(0000) knlGS:0000000000000000
[ 27.400717] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 27.402432] CR2: ffff9f7a40108000 CR3: 000000000859a001 CR4: 0000000000060ef0
[ 27.404485] Call Trace:
[ 27.405326] clear_free_pages+0xf5/0x150
[ 27.406568] hibernation_snapshot+0x390/0x3d0
[ 27.407908] hibernate+0xdb/0x240
[ 27.408978] state_store+0xd7/0xe0
[ 27.410078] kernfs_fop_write+0x10e/0x1a0
[ 27.411333] vfs_write+0xbb/0x210
[ 27.412423] ksys_write+0x9c/0xd0
[ 27.413488] do_syscall_64+0x33/0x40
[ 27.414636] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 27.416150] RIP: 0033:0x7fe0c364e380
66 0f 1f 44 00 00 83 3d c9 23 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0
ff ff 73 31 c3 48 83 ec 08 e8 fe dd 01 00 48 89 04 24
[ 27.422500] RSP: 002b:00007ffeb64bd0c8 EFLAGS: 00000246 ORIG_RAX: 00000000000
00001
[ 27.424724] RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fe0c364e380
[ 27.426761] RDX: 0000000000000005 RSI: 0000000001eb6408 RDI: 0000000000000001
[ 27.428791] RBP: 0000000001eb6408 R08: 00007fe0c391d780 R09: 00007fe0c3f6a700
[ 27.430863] R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000000005
[ 27.432920] R13: 0000000000000001 R14: 00007fe0c391c620 R15: 0000000000000000
[ 27.434989] Modules linked in:
[ 27.436004] CR2: ffff9f7a40108000
[ 27.437075] ---[ end trace 424c466bcd2bfcad ]---
> --
> Thanks,
>
> David / dhildenb
>
--
Sincerely yours,
Mike.
Powered by blists - more mailing lists