On Tue, Apr 9, 2024 at 11:02 PM Andrew Pinski (QUIC)
wrote:
>
> While looking into PR 114666, I noticed that we don't verify COND_EXPR's
> first operand. In most of my recent patches to match.pd, I was assuming that
> it would be a boolean (or a type which would contain
> [0,1]) but this PR show
> note: some syscalls / features don't work without asm
> (posix thread cancellation, vfork, signal return,..)
That's true. On the other hand, POSIX compliance
is not always a goal or a requirement.
> and using raw syscalls outside of the single runtime the
> application is using is problematic (
> I see systems making it more difficult for code to make syscalls,
> not easier.
That's true.
I think it's because other systems can afford to keep that ABI unstable.
Since Linux is an independently developed kernel, it _must_ be possible
to target the kernel directly with no user space compone
> Now the question comes is the argument long or some other type?
I believe so. Every library I've seen and the kernel itself uses long.
Other types just get typecasted to long. I think it's just supposed to
mean "register type" since all the arguments must be in registers.
> E.g. for some 32bit
> As noted by J. Wakely, you don't need to have one variant
> for each number of arguments.
Yes, he is right about that. I have already deleted
all the variants from my code since the variadic
builtin will be able to generate optimal code,
unlike a variadic C function.
> I assume you're talking a
On 4/9/24 15:22, Sam James wrote:
Paul Eggert writes:
On 4/9/24 14:58, Sam James wrote:
Meson doesn't allow user-defined functions
Meson has ways to execute arbitrary user-defined code, so it's not
immune to this sort of exploit.
To be clear - not saying it's immune.
Sure, but someone who
Paul Eggert writes:
> On 4/9/24 14:58, Sam James wrote:
>> Meson doesn't allow user-defined functions
>
> Meson has ways to execute arbitrary user-defined code, so it's not
> immune to this sort of exploit.
To be clear - not saying it's immune. Just that it scopes the
user-defined code part to c
On 4/9/24 14:58, Sam James wrote:
Meson doesn't allow user-defined functions
Meson has ways to execute arbitrary user-defined code, so it's not
immune to this sort of exploit.
It's of course better (all other things being equal) to use a build
system with a smaller attack surface. However,
Jonathon Anderson writes:
> On Tue, 2024-04-09 at 14:50 -0700, Paul Eggert wrote:
>
> On 4/9/24 14:40, Jeffrey Walton wrote:
>
> Code provenance and code integrity was not enforced. Part of the problem is
> the Autotools design. It is from a
> bygone era.
>
> No, Andreas is right. This isn't
On Tue, 2024-04-09 at 14:50 -0700, Paul Eggert wrote:
> On 4/9/24 14:40, Jeffrey Walton wrote:
>
> > Code provenance and code integrity was not enforced. Part of the
> > problem is the Autotools design. It is from a bygone era.
>
>
> No, Andreas is right. This isn't an Autotools-vs-Meson thing.
Jonathon Anderson via Gdb writes:
> On Tue, 2024-04-09 at 16:11 -0400, Paul Koning wrote:
>>
>> On Apr 9, 2024, at 3:59 PM, Jonathon Anderson via Gcc
>> <[gcc@gcc.gnu.org](mailto:gcc@gcc.gnu.org)> wrote:
>>
>> > CMake has its own sandbox and rules and escapes (granted, much more of
>> > them). B
Paul Eggert writes:
> On 4/9/24 14:40, Jeffrey Walton wrote:
>> Code provenance and code integrity was not enforced. Part of the
>> problem is the Autotools design. It is from a bygone era.
>
> No, Andreas is right. This isn't an Autotools-vs-Meson thing.
>
> Most of the Autotools-based projects
On Tue, 2024-04-09 at 16:11 -0400, Paul Koning wrote:
>
> On Apr 9, 2024, at 3:59 PM, Jonathon Anderson via Gcc
> <[gcc@gcc.gnu.org](mailto:gcc@gcc.gnu.org)> wrote:
>
> > CMake has its own sandbox and rules and escapes (granted, much more of
> > them). But regardless, the injection code would be c
On 4/9/24 14:40, Jeffrey Walton wrote:
Code provenance and code integrity was not enforced. Part of the
problem is the Autotools design. It is from a bygone era.
No, Andreas is right. This isn't an Autotools-vs-Meson thing.
Most of the Autotools-based projects I help maintain would have been
On Tue, Apr 9, 2024 at 4:11 PM Paul Koning via Gdb wrote:
>
> > On Apr 9, 2024, at 3:59 PM, Jonathon Anderson via Gcc
> > wrote:
> >
> > On Tue, Apr 9, 2024, 10:57 Andreas Schwab wrote:
> >
> >> On Apr 09 2024, anderson.jonath...@gmail.com wrote:
> >>
> >>> - This xz backdoor injection unpacked
While looking into PR 114666, I noticed that we don't verify COND_EXPR's first
operand. In most of my recent patches to match.pd, I was assuming that it would
be a boolean (or a type which would contain
[0,1]) but this PR shows we could end up with an 1-bit signed integer in there.
We could fix m
> On Apr 9, 2024, at 3:59 PM, Jonathon Anderson via Gcc wrote:
>
> On Tue, Apr 9, 2024, 10:57 Andreas Schwab wrote:
>
>> On Apr 09 2024, anderson.jonath...@gmail.com wrote:
>>
>>> - This xz backdoor injection unpacked attacker-controlled files and ran
>> them during `configure`. Newer build
On Tue, Apr 9, 2024, 10:57 Andreas Schwab wrote:
> On Apr 09 2024, anderson.jonath...@gmail.com wrote:
>
> > - This xz backdoor injection unpacked attacker-controlled files and ran
> them during `configure`. Newer build systems implement a build abstraction
> (aka DSL) that acts similar to a sand
On Apr 09 2024, anderson.jonath...@gmail.com wrote:
> - This xz backdoor injection unpacked attacker-controlled files and ran them
> during `configure`. Newer build systems implement a build abstraction (aka
> DSL) that acts similar to a sandbox and enforces rules (e.g. the only code
> run duri
Hello,
On Thu, Apr 4, 2024, 09:00 Michael Matz wrote:
> Hello,
>
> On Wed, 3 Apr 2024, Jonathon Anderson wrote:
>
> > Of course, this doesn't make the build system any less complex, but
> > projects using newer build systems seem easier to secure and audit than
> > those using overly flexible
The 04/08/2024 06:19, Matheus Afonso Martins Moreira via Gcc wrote:
> __builtin_linux_system_call(long n, ...)
...
> Calling these builtins will make GCC place all the parameters
> in the correct registers for the system call, emit the appropriate
> instruction for the target architecture and r
On Tue, Apr 9, 2024 at 9:47 AM Jora Gevorgyan via Gcc wrote:
>
> Hi!
>
> We're trying to improve the optimization process in GCC by adding manual
> optimization attributes to some needed functions. I couldn't yet find the
> code routine where the attributes can be added to a special function
> dec
Hi!
We're trying to improve the optimization process in GCC by adding manual
optimization attributes to some needed functions. I couldn't yet find the
code routine where the attributes can be added to a special function
declaration. Could you please help me understand what's happening there?
Than
23 matches
Mail list logo
