Right now I'm using a simple padding system that takes the plaintext, hashes it with SHA512, and appends $x$ bytes of the hash as padding where $x$ is the delta between the plaintext and nearest blocksize multiple.
Is this considered a secure method of padding the message? I am also authenticating the encrypted data using HMAC-SHA512, would this effect the security?
The size of the padding could be made public, if you don't mind leaking some additional information about the plaintext size. Using a hash as padding bytes however does not make sense; you can not use the hash as authentication tag or to check the integrity, so the hash calculation becomes spurious. It may even leak data through a side channel. In the best case it simply eats CPU resources without accomplishing anything.
It is better to use a vetted padding method such as PKCS#7 or bit padding. They may use a block of ciphertext more, but otherwise the implementation light on resources. Both padding methods are however vulnerable to padding oracle attacks. So you should generate a MAC or HMAC (using a second key) over the ciphertext. You should include all public information in the MAC calculation as well.
Alternatively you could use zero byte padding and a padding or plain text length indicator byte as this may save you a block of bytes to encrypt. In that case you should definitely include the length indicator in the MAC calculation as an attacker could otherwise fool you into adding or removing bytes from the plain text by simply changing the length indicator.
Finally you could of course use a block cipher in counter mode, possibly using an authenticated scheme such as GCM. This would rid you of padding altogether (the plaintext size is the ciphertext size) and would generate a message authentication tag without having to resort to two separate keys. As in the MAC calculation you should include all public data as additional authenticated data (AAD). Furthermore, you should be sure never to repeat the nonce/IV. You would not need a separate nonce and IV either.
For AES CBC i would suggest you stick to the standards.
The PKCS7 padding scheme is pretty easy to implement and has been tested extensively now that its been out in the public for a while. I had implemented PKCS7 padding for my AES CBC cipher a few weeks ago and you can see the code here if it helps.
Note that hashing by itself does not provide you with authentication, you will need a MAC (Message Authentication Code) for that. If you like using the SHA family, you can use something like HMAC-SHA256.
Is there any particular reason why you wish to use hashed data as a pad? If you are looking for authenticated encryption, you should stick to the standards like GCM for AES.
You should use a vetted padding scheme. Unfortunately PKCS#7 is not the right one (search for "pkcs7 vulnerability").
It seems that ISO.2FIEC_7816-4 isn't vulnerable.
