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: <20130116022955.GB3854@home.goodmis.org>
Date:	Tue, 15 Jan 2013 21:29:55 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Alex Villacís Lasso <a_villacis@...osanto.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Use of memmap= to forcibly recover memory in 3GB-4GB range - is
 this safe?

On Tue, Jan 15, 2013 at 08:47:20PM -0500, Alex Villacís Lasso wrote:
> The system boots, apparently normally, and I can see the additional
> "memory" in all system reports. However, I cannot quite shake the
> feeling that this "memory" might be in fact an illusion, and an
> attempt to use it will wrap around to the bottom of the memory and
> corrupt anything there. Or worse.
> 
> Some tests that I have tried:
> 1) I have tried to occupy as much memory as possible, by starting
> two virtual machines, plus one instance of eclipse, a browser, and a
> bittorrent client, while running the graphical desktop. I have seen
> the free memory (as reported by "top") fall to under 200 Mb with no
> apparent instability, so this should prove that the extra memory is
> real, right?

If you ran all that and it didn't crash and burn, I'm thinking you are
pretty safe. I would think that if you had 768 megs mapped to nothing,
mirrored to other memory, or any number of other atrocities, your above
actions would most likely show some horrible failure.

I think you are correct in assuming that if the MTRR mappings shows
memory there, it may just be a bug in the BIOS that is not adding it.

> 2) I have recompiled the kernel to support the memtest parameter.
> When using it, the extra memory segment appears to be as healthy as
> other areas of memory. However this might only mean that it is
> wrapping into healthy low RAM.
> 
> Is my reasoning sane? Is there a way to know, once and for all,
> whether the extra "memory" is real and safe to use or not?

I can think of writing a kernel module that reads and writes to these
locations just to make sure. But other than that, I'm not aware of
anything. Maybe someone else could offer more.

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ