On 02/23/2018 12:05 PM, Paolo Bonzini wrote:
On 22/02/2018 16:56, Brijesh Singh wrote:
On 02/21/2018 02:18 PM, Al Viro wrote:
On Wed, Feb 21, 2018 at 01:59:55PM -0600, Brijesh Singh wrote:
Sure, checking access_ok() does not guarantee that later
copy_from_user() will not fail. But it
On 02/23/2018 12:05 PM, Paolo Bonzini wrote:
On 22/02/2018 16:56, Brijesh Singh wrote:
On 02/21/2018 02:18 PM, Al Viro wrote:
On Wed, Feb 21, 2018 at 01:59:55PM -0600, Brijesh Singh wrote:
Sure, checking access_ok() does not guarantee that later
copy_from_user() will not fail. But it
On 22/02/2018 16:56, Brijesh Singh wrote:
>
>
> On 02/21/2018 02:18 PM, Al Viro wrote:
>> On Wed, Feb 21, 2018 at 01:59:55PM -0600, Brijesh Singh wrote:
>>
>>> Sure, checking access_ok() does not guarantee that later
>>> copy_from_user() will not fail. But it does eliminate one possible
>>>
On 22/02/2018 16:56, Brijesh Singh wrote:
>
>
> On 02/21/2018 02:18 PM, Al Viro wrote:
>> On Wed, Feb 21, 2018 at 01:59:55PM -0600, Brijesh Singh wrote:
>>
>>> Sure, checking access_ok() does not guarantee that later
>>> copy_from_user() will not fail. But it does eliminate one possible
>>>
On 02/21/2018 02:18 PM, Al Viro wrote:
On Wed, Feb 21, 2018 at 01:59:55PM -0600, Brijesh Singh wrote:
Sure, checking access_ok() does not guarantee that later
copy_from_user() will not fail. But it does eliminate one possible
reason for the failure. We are trying to validate most of the user
On 02/21/2018 02:18 PM, Al Viro wrote:
On Wed, Feb 21, 2018 at 01:59:55PM -0600, Brijesh Singh wrote:
Sure, checking access_ok() does not guarantee that later
copy_from_user() will not fail. But it does eliminate one possible
reason for the failure. We are trying to validate most of the user
On Wed, Feb 21, 2018 at 01:59:55PM -0600, Brijesh Singh wrote:
> Sure, checking access_ok() does not guarantee that later
> copy_from_user() will not fail. But it does eliminate one possible
> reason for the failure. We are trying to validate most of the user
> inputs before we invoke SEV
On Wed, Feb 21, 2018 at 01:59:55PM -0600, Brijesh Singh wrote:
> Sure, checking access_ok() does not guarantee that later
> copy_from_user() will not fail. But it does eliminate one possible
> reason for the failure. We are trying to validate most of the user
> inputs before we invoke SEV
On 2/21/18 11:49 AM, Al Viro wrote:
> On Mon, Feb 19, 2018 at 10:12:28AM -0600, Brijesh Singh wrote:
>> Fix sparse: incorrect type in argument 1 (different base types). Typecast
>> the userspace address argument.
> Better question: why the hell do we want that access_ok(), anyway? The only
>
On 2/21/18 11:49 AM, Al Viro wrote:
> On Mon, Feb 19, 2018 at 10:12:28AM -0600, Brijesh Singh wrote:
>> Fix sparse: incorrect type in argument 1 (different base types). Typecast
>> the userspace address argument.
> Better question: why the hell do we want that access_ok(), anyway? The only
>
On Mon, Feb 19, 2018 at 10:12:28AM -0600, Brijesh Singh wrote:
> Fix sparse: incorrect type in argument 1 (different base types). Typecast
> the userspace address argument.
Better question: why the hell do we want that access_ok(), anyway? The only
thing we do to params.uaddr is
if
On Mon, Feb 19, 2018 at 10:12:28AM -0600, Brijesh Singh wrote:
> Fix sparse: incorrect type in argument 1 (different base types). Typecast
> the userspace address argument.
Better question: why the hell do we want that access_ok(), anyway? The only
thing we do to params.uaddr is
if
Fix sparse: incorrect type in argument 1 (different base types). Typecast
the userspace address argument.
Fixes: 0d0736f76347 (KVM: SVM: Add support for KVM_SEV_LAUNCH_MEASURE ...)
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Borislav Petkov
Fix sparse: incorrect type in argument 1 (different base types). Typecast
the userspace address argument.
Fixes: 0d0736f76347 (KVM: SVM: Add support for KVM_SEV_LAUNCH_MEASURE ...)
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: linux-kernel@vger.kernel.org
Cc:
14 matches
Mail list logo