Rainbow tables and brute forcing aren't relevant here.
The sha-512 password is salted. That means for whatever hash you have, the password begins with a salt value (ONf5M3F1u in this case). To generate a rainbow table, you have to generate a full list of sha-512 hashes for all typable strings beginning with "ONf5M3F1u".
Let's say you used the theoretical hash algorithm "CSUM-2", which simply adds up the characters and produces a 2-bit hash out of the least-significant bits. A rainbow table for CSUM-2 looks like the below:
Note that only the two LSB are relevant, so you really have four salts: d, a, b, and c.
So imagine these four hashes of the password 'b', with salts. The salt prepends, so you'd hash e.g. "db" to get just "b", or "ab" to get "c".
To use a rainbow table to crack CSUM-2, you need four separate rainbow tables of four entries each.
To crack sha-512 with a salt of nine characters as above, you need 62 full rainbow tables. A sha-512 rainbow table sufficient for up to 9 alphanumerical characters is 864GB in size; with this kind of salting, you need 62 of those, or 52TB of tables.
Note that 2^512 is a lot more than just 9-character passwords can provide. There are 1.3 x 10^154 hashes, and 1.35 x 10^19 9-character alphanumerical passwords. Longer passwords mean a larger password space, more entries, and bigger tables. That multiplies linearly by the number of salts, and exponentially by the length of the salt.
Someone has to generate and store all of those tables.
PBKDF2 simply performs the computation numerous times; however, a PBKDF2 output will always be the same, and so you're back to rainbow tables cracking PBKDF2 just like any other algorithm.
PAM can use the
rounds parameter to perform key stretching as well; the default is 5,000 and the minimum is 1,000.
rounds=65536 would run SHA-512 2^16 times on each log-in attempt. This would make brute forcing slower, although a precomputed rainbow table still doesn't care. Building and storing that rainbow table is, as stated above, hard.