Skip to content

V
V8
Switch branch/tag
  1. 08 Sep, 2014 1 commit
  3. 04 Aug, 2014 1 commit
  5. 02 Jul, 2014 1 commit
  7. 30 Jun, 2014 1 commit
  9. 27 Jun, 2014 1 commit
  11. 20 Jun, 2014 1 commit
  13. 12 Jun, 2014 3 commits
  15. 05 Jun, 2014 1 commit
  17. 03 Jun, 2014 1 commit
  19. 29 Apr, 2014 1 commit
  21. 28 Apr, 2014 1 commit
  23. 14 Mar, 2014 1 commit
  25. 27 Jan, 2014 1 commit
  27. 14 Jan, 2014 1 commit
  29. 23 Sep, 2013 1 commit
  31. 13 Sep, 2013 1 commit
  33. 11 Sep, 2013 4 commits
  35. 10 Sep, 2013 2 commits
    • bmeurer@chromium.org's avatar
      Introduce a RandonNumberGenerator class. Refactor the random/private_random... · eb381b94
      bmeurer@chromium.org authored 
      Introduce a RandonNumberGenerator class. Refactor the random/private_random uses in Isolate/Context.

The RandomNumberGenerator is a pseudorandom number generator
with 48-bit state. It is properly seeded using either

(1) the --random-seed if specified, or
(2) the entropy_source function if configured, or
(3) /dev/urandom if available, or
(4) falls back to Time and TimeTicks based seeding.

Each Isolate now contains a RandomNumberGenerator, which replaces
the previous private_random_seed.

Every native context still has its own random_seed. But this random
seed is now properly initialized during bootstrapping,
instead of on-demand initialization. This will allow us to cleanup
and speedup the HRandom implementation quite a lot (this is delayed
for a followup CL)!

Also stop messing with the system rand()/random(), which should
not be done from a library anyway! We probably re-seeded the
libc rand()/random() after the application (i.e. Chrome) already
seeded it (with better entropy than what we used).

Another followup CL will replace the use of the per-isolate
random number generator for the address randomization and
thereby get rid of the Isolate::UncheckedCurrent() usage in
the platform code.

TEST=cctest/test-random-number-generator,cctest/test-random
R=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/23548024

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16612 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      eb381b94
    • bmeurer@chromium.org's avatar
      Use PAGE_NOACCESS for guard pages in Windows. · 24a0cabd
      bmeurer@chromium.org authored 
      Up until now we used PAGE_GUARD for guard pages in Windows, which
will raise a STATUS_GUARD_PAGE_VIOLATION exception on first access
and grant regular access afterwards. This behavior is required to
implement automatic stack checking, or more generally to implement
applications that monitor the growth of large dynamic data structures.

However, this is not what we want for our guard pages, which are
used as a security mechanism. What we really want is PAGE_NOACCESS
here, which is the Windows-equivalent of PROT_NONE that we use on
all other platforms.

R=cdn@chromium.org

Review URL: https://codereview.chromium.org/23458022

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16604 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      24a0cabd
  37. 05 Sep, 2013 1 commit
  39. 02 Sep, 2013 1 commit
  41. 29 Aug, 2013 1 commit
  43. 31 Jul, 2013 1 commit
  45. 30 Jul, 2013 1 commit
  47. 25 Jul, 2013 3 commits
  49. 23 Jul, 2013 2 commits
  51. 11 Jul, 2013 1 commit
  53. 05 Jul, 2013 1 commit
  55. 20 Jun, 2013 1 commit
  57. 19 Apr, 2013 1 commit
  59. 16 Apr, 2013 2 commits