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
| ||
|
Date: Tue, 1 Dec 2020 20:59:48 +0000 From: Will Deacon <will@...nel.org> To: Yanan Wang <wangyanan55@...wei.com> Cc: linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, Marc Zyngier <maz@...nel.org>, Catalin Marinas <catalin.marinas@....com>, James Morse <james.morse@....com>, Julien Thierry <julien.thierry.kdev@...il.com>, Suzuki K Poulose <suzuki.poulose@....com>, Gavin Shan <gshan@...hat.com>, Quentin Perret <qperret@...gle.com>, wanghaibin.wang@...wei.com, yezengruan@...wei.com, zhukeqian1@...wei.com, yuzenghui@...wei.com, jiangkunkun@...wei.com, wangjingyi11@...wei.com, lushenming@...wei.com Subject: Re: [PATCH v2 0/3] Fix several bugs in KVM stage 2 translation On Wed, Dec 02, 2020 at 04:10:31AM +0800, Yanan Wang wrote: > When installing a new pte entry or updating an old valid entry in stage 2 > translation, we use get_page()/put_page() to record page_count of the page-table > pages. PATCH 1/3 aims to fix incorrect use of get_page()/put_page() in stage 2, > which might make page-table pages unable to be freed when unmapping a range. > > When dirty logging of a guest with hugepages is finished, we should merge tables > back into a block entry if adjustment of huge mapping is found necessary. > In addition to installing the block entry, we should not only free the non-huge > page-table pages but also invalidate all the TLB entries of non-huge mappings for > the block. PATCH 2/3 adds enough TLBI when merging tables into a block entry. > > The rewrite of page-table code and fault handling add two different handlers > for "just relaxing permissions" and "map by stage2 page-table walk", that's > good improvement. Yet, in function user_mem_abort(), conditions where we choose > the above two fault handlers are not strictly distinguished. This will causes > guest errors such as infinite-loop (soft lockup will occur in result), because of > calling the inappropriate fault handler. So, a solution that can strictly > distinguish conditions is introduced in PATCH 3/3. For the series: Acked-by: Will Deacon <will@...nel.org> Thanks for reporting these, helping me to understand the issues and then spinning a v2 so promptly. Will
Powered by blists - more mailing lists