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: Mon, 14 Feb 2022 13:54:57 -0800 From: Kalesh Singh <kaleshsingh@...gle.com> To: Marc Zyngier <maz@...nel.org> Cc: Will Deacon <will@...nel.org>, Quentin Perret <qperret@...gle.com>, Fuad Tabba <tabba@...gle.com>, Suren Baghdasaryan <surenb@...gle.com>, "Cc: Android Kernel" <kernel-team@...roid.com>, Catalin Marinas <catalin.marinas@....com>, James Morse <james.morse@....com>, Alexandru Elisei <alexandru.elisei@....com>, Suzuki K Poulose <suzuki.poulose@....com>, Ard Biesheuvel <ardb@...nel.org>, Mark Rutland <mark.rutland@....com>, Pasha Tatashin <pasha.tatashin@...een.com>, Joey Gouly <joey.gouly@....com>, Peter Collingbourne <pcc@...gle.com>, Andrew Walbran <qwandor@...gle.com>, Andrew Scull <ascull@...gle.com>, Paolo Bonzini <pbonzini@...hat.com>, "moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)" <linux-arm-kernel@...ts.infradead.org>, LKML <linux-kernel@...r.kernel.org>, kvmarm@...ts.cs.columbia.edu Subject: Re: [PATCH 0/7] KVM: arm64: Hypervisor stack enhancements On Mon, Feb 14, 2022 at 3:41 AM Marc Zyngier <maz@...nel.org> wrote: > > On Thu, 10 Feb 2022 22:41:41 +0000, > Kalesh Singh <kaleshsingh@...gle.com> wrote: > > > > This series is based on v5.17-rc3 and adds the following stack features to > > the KVM nVHE hypervisor: > > > > == Hyp Stack Guard Pages == > > > > Based on the technique used by arm64 VMAP_STACK to detect overflow. > > i.e. the stack is aligned to twice its size which ensure that the > > 'stack shift' bit of any valid SP is 0. The 'stack shift' bit can be > > tested in the exception entry to detect overflow without corrupting GPRs. > > Having quickly parsed the code, this seems to only be effective for > pKVM and the EL2-allocated stack. Is there any technical reason not to > implement this for the much more common case of 'classic' KVM in nVHE > mode? Hi Marc, No technical reason. We hadn't thought of it from that perspective. It's a good idea, I'll look into this and repost a new version. Thanks, Kalesh > > Thanks, > > M. > > -- > Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists