On Fri, Oct 20, 2017 at 09:55:40AM +0200, Borislav Petkov wrote:
> On Wed, Oct 18, 2017 at 11:30:54PM -0700, Ricardo Neri wrote:
> > I saw that Documentation/process/email-clients.rst that emailed patches
> > should be in ASCII or UTF-8 encodings only, but my patch in UTF-8
> > causes problems. The
On Wed, Oct 18, 2017 at 11:30:54PM -0700, Ricardo Neri wrote:
> I saw that Documentation/process/email-clients.rst that emailed patches
> should be in ASCII or UTF-8 encodings only, but my patch in UTF-8
> causes problems. Then is UTF-8 not desirable?
Well, I don't think so even though I couldn't
On Wed, Oct 18, 2017 at 10:29:43PM +0200, Borislav Petkov wrote:
> On Tue, Oct 17, 2017 at 01:31:52PM -0700, Ricardo Neri wrote:
> > I apologize for the inconvenience, I have verified that may mail client
> > works properly this time. I double-checked that it did not wrap.
>
> But did you try appl
On Tue, Oct 17, 2017 at 01:31:52PM -0700, Ricardo Neri wrote:
> I apologize for the inconvenience, I have verified that may mail client
> works properly this time. I double-checked that it did not wrap.
But did you try applying the patch which you have sent to yourself first?
Because it doesn't w
On Tue, 2017-10-17 at 11:35 +0200, Borislav Petkov wrote:
> On Fri, Oct 13, 2017 at 11:43:43AM -0700, Ricardo Neri wrote:
> >
> > I think it does now. This is a modification of your second proposal (I hope
> > text
> > does not wrap):
> Instead of hoping that it doesn't wrap, please fix your mail
On Fri, Oct 13, 2017 at 11:43:43AM -0700, Ricardo Neri wrote:
> I think it does now. This is a modification of your second proposal (I hope
> text
> does not wrap):
Instead of hoping that it doesn't wrap, please fix your mail client. For
that, generate a diff and send it to yourself and try apply
On Fri, 2017-10-13 at 13:37 +0200, Borislav Petkov wrote:
> On Thu, Oct 12, 2017 at 06:08:17PM -0700, Ricardo Neri wrote:
> >
> > In my opinion it would be better to have all the checks in a single place.
> > This
> > makes the code easier to read that having this special case directly
> > in reso
On Thu, Oct 12, 2017 at 06:08:17PM -0700, Ricardo Neri wrote:
> In my opinion it would be better to have all the checks in a single place.
> This
> makes the code easier to read that having this special case directly
> in resolve_default_seg().
> ...
> Rather than checking for null insn in resolve
On Thu, 2017-10-12 at 11:48 +0200, Borislav Petkov wrote:
> On Wed, Oct 11, 2017 at 06:12:30PM -0700, Ricardo Neri wrote:
> >
> > Shouldn't this function check for a null insn since it is used here?
> I have to say, this whole codepath from insn_get_seg_base() with
> insn==NULL is nasty but I don'
On Wed, Oct 11, 2017 at 06:12:30PM -0700, Ricardo Neri wrote:
> Shouldn't this function check for a null insn since it is used here?
I have to say, this whole codepath from insn_get_seg_base() with
insn==NULL is nasty but I don't see a way around it as we need to know
how many bytes to copy and fr
On Wed, 2017-10-11 at 00:41 +0200, Borislav Petkov wrote:
> On Tue, Oct 03, 2017 at 08:54:16PM -0700, Ricardo Neri wrote:
> >
> > When computing a linear address and segmentation is used, we need to know
> > the base address of the segment involved in the computation. In most of
> > the cases, the
On Tue, Oct 03, 2017 at 08:54:16PM -0700, Ricardo Neri wrote:
> When computing a linear address and segmentation is used, we need to know
> the base address of the segment involved in the computation. In most of
> the cases, the segment base address will be zero as in USER_DS/USER32_DS.
...
> ---
When computing a linear address and segmentation is used, we need to know
the base address of the segment involved in the computation. In most of
the cases, the segment base address will be zero as in USER_DS/USER32_DS.
However, it may be possible that a user space program defines its own
segments
13 matches
Mail list logo
