linux-kernel - Re: [PATCH v3] x86/gart/kcore: Exclude GART aperture from kcore

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190228231202.3wvojgxscrodoalt@dwarf.suse.cz>
Date:   Fri, 1 Mar 2019 00:12:02 +0100
From:   Jiri Bohac <jbohac@...e.cz>
To:     Kairui Song <kasong@...hat.com>
Cc:     linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        Alexey Dobriyan <adobriyan@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Omar Sandoval <osandov@...com>, Baoquan He <bhe@...hat.com>,
        Dave Young <dyoung@...hat.com>
Subject: Re: [PATCH v3] x86/gart/kcore: Exclude GART aperture from kcore

On Wed, Feb 13, 2019 at 04:28:00PM +0800, Kairui Song wrote:
> @@ -465,6 +472,12 @@ read_kcore(struct file *file, char __user *buffer, size_t buflen, loff_t *fpos)
>  				goto out;
>  			}
>  			m = NULL;	/* skip the list anchor */
> +		} else if (m->type == KCORE_NORAM) {
> +			/* for NORAM area just fill zero */
> +			if (clear_user(buffer, tsz)) {
> +				ret = -EFAULT;
> +				goto out;
> +			}

I don't think this works reliably. The loop filling the buffer
has this logic at the top:

        while (buflen) {
                /*
                 * If this is the first iteration or the address is not within
                 * the previous entry, search for a matching entry.
                 */
                if (!m || start < m->addr || start >= m->addr + m->size) {
                        list_for_each_entry(m, &kclist_head, list) {
                                if (start >= m->addr &&
                                    start < m->addr + m->size)
                                        break;
                        }
                }

This sets m to the kclist entry that contains the memory being
read. But if we do a large read that starts in valid KCORE_RAM
memory below the GART overlap and extends into the overlap, m
will not be set to the KCORE_NORAM entry. It will keep pointing
to the KCORE_RAM entry and the patch will have no effect.

But this seems already broken in existing cases as well, various
KCORE_* types overlap with KCORE_RAM, don't they?  So maybe
bf991c2231117d50a7645792b514354fc8d19dae ("proc/kcore: optimize
multiple page reads") broke this and once fixed, this KCORE_NORAM
approach will work. Omar?

Regards,

-- 
Jiri Bohac <jbohac@...e.cz>
SUSE Labs, Prague, Czechia